Ci vediamo lì!

La soluzione più semplice che ho trovato è la seguente:

1. Eseguire il dump del database codificato con SQL_ASCII

pg_dump database > database.sql

2. Conversione a UTF-8

iconv -f ISO8859-1 -t UTF-8 database.sql > database.utf8.sql

3. Importazione dei dati sul nuovo database (creato con encoding UTF-8)

psql database_utf8 < database.utf8.sql

Da qui poi è tutta discesa dato che utilizzando gli strumenti più conosciuti esportare i dati verso MySQL non ha riservato sorprese.

L’evento è organizzato dall’Italian Agile Movement che festeggia 9 anni di attività e si terrà sabato 19 Novembre 2011 a Roma. Maggiori informazioni sulla sede nella pagina ad essa dedicata.

Dato che i 600 posti a disposizione stanno andando a ruba, vi consiglio di registrarvi (e fare una donazione) per assicurarvi di partecipare ad un evento di sicuro interesse!

Doctrine and NoSQL – Benjamin Eberlei
Interessante presentazione dell’ODM di Doctrine2 per sfruttare quanto offerto nell’area NoSQL da CouchDB e da MongoDB. Il focus era sulla semplicità di mappare gli oggetti sui database non relazionali a differenza di quelli relazionali dovuta al fatto che vengono a mancare molti vincoli che fino ad oggi ci hanno complicato la vita non poco. Alcuni esempi molto chiari hanno supportato il tutto nel migliore dei modi. Ovviamente in alcuni casi questi due prodotti NoSQL non sono ancora raccomandabili: si pensi a contesti in cui le transazioni sono necessarie o casi in cui ‘lintegrità referenziale non può essere demandata all’applicazione.

This Way or the other Way? – Stefan Priebsch
Experiment Driven Development, ovvero prendere decisioni basate su dati empirici ricavati da test piuttosto che basandosi su ipotesi che spesso si rivelano errate. E’ questo il succo del discorso del talk di Priebsch che presenta una semplice demo in cui i concetti di Factory e Dependency Injection sono alla base della soluzione adottata per poter sostituire intere classi in base a particolari dati che ci permettono di decidere a quali utenti od in quali situazione presentare un risultato (pensate ad una nuova pagina del profilo) piuttosto che un altro. Un semplice log può collezionare i risultati di una votazione (star rating 1-5 per esempio) da parte degli utenti per valutare con dati alla mano se la modifica introdotta ha riscosso successo oppure no.

One Click Deployment with Jenkins – Thorsten Rinne
Presentazione del flusso di lavoro e del processo di deploy di una delle più grandi realtà tedesche nel campo dello sviluppo di applicazioni PHP basato su Jenkins ma non solo.

Doctrine 2: Next Generation ORM – Benjamin Eberlei
Introduzione completa all’ORM di Doctrine2 analizzando quali sono i problemi degli ORM e del loro utilizzo e quali le soluzioni adottate da Doctrine2 (N+1 problem, non-object results).

Ringrazio HTML.it che con il suo contributo ha reso possibile la mia partecipazione all’evento più importante dell’anno in ambito PHP.

Large-Scale Data Processing with Hadoop and PHP – David Zuelke
Processare enormi quantità di dati non è mai stato così facile: Hadoop e Map/Reduce in nostro soccorso! La maggior parte degli sviluppatori difficilmente si troverà di fronte a problemi del genere: avere svariate centinaia di GB di log o simili da cui estrapolare alcuni dati non capita di sicuro tutti i giorni. Ma per quelli che invece il problema l’hanno incontrato questo talk ha presentato una soluzione percorribile, raccomandata ed adottata da molti grandi player del settore.

Profiling PHP Applications – Derick Rethans
Dall’autore di Xdebug arriva un talk sul profiling delle applicazioni PHP con un monito iniziale verso tutte le microttimizzazioni che si possono trovare in rete quando si cercano informazioni riguardo al profiling: print vs echo, “” vs ” e così via. Tutte cose che non apportano benefici significativi alle performance delle nostre applicazioni. Per poter migliorare un’applicazione però è necessario capirne il funzionamento (potrebbe essere stata sviluppata da altri) ed individuare quelle porzioni di codice che più di altre consumano tempo e risorse. Come? Attraverso alcuni strumenti come Xdebug, XHprof, Inclued, KCacheGrind…

How the Web Evolves with Hypermedia – David Zuelke
Di gran lunga il miglior intervento di tutta la conferenza ed i feedback su join.in lo testimoniano. Keynote sull’evoluzione del web grazie all’utilizzo dell’hypermedia: REST, HATEOAS e Uniform interface al centro dell’argomentazione. Assolutamente da vedere, attendiamo il video.

Designing HTTP Interfaces and RESTful Web Services – David Zuelke
Si fa presto a dire di avere un’api REST, molti lo fanno senza nemmeno sapere effettivamente quali siano i requisiti indispensabili per poter dire che un’api è RESTful o meno. Regole e best practice da ricordare e rispettare durante lo sviluppo per partire con il piede giusto.

Symfony2 by Code – Lukas Smith
Effettivamente solo codice senza slide. Più che altro un workshop condensato in session attraverso il quale Lukas ha introdotto i concetti principali alla base di Symfony2 seguendo quello che è il flusso dell’applicazione dall’arrivo della richiesta al front controller al rendering della pagina. Alcuni accenni a bundle utili che possono risparmiare un sacco di codice per affrontare problemi comuni.

Scalable high-performance Architectures – Stefan Priebsch
Presentazione diversa dal solito in cui si parla di scalabilità di architetture ad alte prestazioni nel campo della ristorazione: caso specifico un fast food. Singolare quanto i processi ed i possibili colli di bottiglia possano essere mappati su una tipica infrastruttura IT a cui siamo tanto abituati. Diversi approcci per portare alla luce pro e contro di soluzioni diverse.

Ringrazio HTML.it che con il suo contributo ha reso possibile la mia partecipazione all’evento più importante dell’anno in ambito PHP.

Kanban Pizza Game – Ralf Kruse
Talk introduttivo all’utilizzo di Kanban attraverso un gioco con i presenti per estrarre la teoria direttamente dalla pratica.

A due gruppi di 5 persone è stato chiesto di creare delle fette di pizza (con carta, post-it, pennarelli e forbici) nel minore tempo possibile, con il minor scarto possibile e con strumenti limitati (solo 2 forbici per gruppo, un solo pennarello…per spingere il gruppo verso la creazione di un processo piuttosto che farli lavorare separatamente).

Dopo una prima manche sono stati tracciati i risultati ed è stato chiesto ai gruppi di rispettare la richiesta di riduzione al minimo dello scarto introducendo dei limiti sui “pezzi” che ogni stazione del processo poteva elaborare contemporaneamente. E’ stata data la possibilità di ottimizzare il processo in base alle idee dei partecipanti per aumentare la produttività del gruppo.

Seconda manche con risultati nettamente migliori rispetto alla prima dati dalla migliore organizzazione raggiunta e dalla possibilità di ciascuno di focalizzare il proprio lavoro sul compito assegnato.
Terza manche a cui è stata aggiunta una particolare richiesta preparare la rucola per farcire la pizza dopo la cottura. I risultati sono ancora migliorati nonostante la nuova richiesta. Segno di raffinamento ulteriore del processo.

E’ davvero giunto il momento di testare l’utilizzo del Kanban.
Date un’occhiata a questo pdf molto esauriente Kanban kick-start example

10 Years of PHPUnit: What works, what doesn’t – Sebastian Bergmann
Panoramica dalla nascita dei primi strumenti di QA per PHP allo stato dell’arte attuale tracciando l’evoluzione degli stessi analizzando le cause di alcuni cambiamenti (vedi passaggio da Hudson a Jenkins). Ne è uscito che gli attuali strumenti sono nati da sviluppatori tedeschi (salvo PHP_CodeSniffer).

Infine presentate alcune novità riguardanti PHPUnit 3.6 che vedrà comparire cose come:

- notation per small, medium, large test
- notation per dipendenze (versione di PHP, versione di PHPUnit per esempio)
- notation per dipendenze

Geolocation and Maps with PHP – Derick Rethans
Web, PHP e mappe: non c’è solo Google! Rethans presenta alcune alternative per rispondere a diverse necessità che tirano in ballo l’utilizzo di mappe e di servizi di geolocalizzazione. Ampio spazio dedicato al progetto OpenStreetMap che tra i punti di forza, oltre ad offrire una quantità davvero sbalorditiva di dati, ha quello di essere aggiornato dagli utenti che avranno sempre e comunque l’accesso ai dati che offrono.

PHP Testing Tools – Sebastian Bergmann
Altra panoramica su strumenti dedicati al testing diversi da PHPUnit. Tra soluzioni poco comode o solo parzialmente documentate risalta sicuramente Behat per il behavior driven development che offre un nuovo modo di presentare il testing rendendolo accessibile (il suo output) anche ai non tecnici.

Tre suggerimenti utili per quanto riguarda gli strumenti di profiling/benchmarking sono:
- gprof2dot.py che offre un migliore output per grafico rispetto a KCacheGrind (basandosi sul log di Xdebug)
- XHProf WebUI per comparare due sessioni di lavoro con la stessa codebase e verificare cambiamenti di performance rispetto ad attività di fine tuning
- Pylot per benchmarking con richieste parallele (ab è sequenziale)

Ringrazio HTML.it che con il suo contributo ha reso possibile la mia partecipazione all’evento più importante dell’anno in ambito PHP.

Primo workshop CouchDB for PHP Developers di Jan Lehnardt dove partendo da un’introduzione di base si è passati a vedere come interrogare il db, spingendosi infine ad analizzare i vantaggi offerti dalla replica messa a disposizione da CouchDB. Strumento sicuramente molto interessante che può sicuramente dare il massimo in situazioni in cui i dati possono essere distribuiti e sincronizzati tra di loro quando in presenza di connessione.

Secondo workshop HTML5 for Developers di Thorsten Rinne che ha fatto una carrellata molto esaustiva di quelle che sono le novità introdotte da HTML5 (particolare attenzione per WebForm, Web Storage e Websockets) ricorrendo a molte demo su diversi browser per testimoniare lo stato di avanzamento degli stessi nel supportare il nuovo standard. Attualmente Chrome è il browser più avanti rispetto agli altri. Anche qui sono usciti spunti molto interessanti da iniziare magari a proporre in parallelo alle soluzioni attuali: tag video e canvas su tutti.

Se vi interessa il servizio ho generato il promo code PHPBLOG50 che potrete utilizzare per registrarvi risparmiando 50$ sulla registrazione annuale o 60$ su quella biennale.

Le situazioni che portano a dover affrontare questo problema sono essenzialmente due:

1) una certa applicazione inizia a generare più traffico di quello che l’infrastruttura attuale riesce a sostenere: è quindi necessario scalare orizzontalmente per distribuire le richieste e frazionare il rischio

2) stiamo lavorando ad un’applicazione che già a priori sappiamo genererà parecchio traffico da richiedere un sistema bilanciato anche per assicurarne la disponibilità

Nel primo caso l’applicazione andrà adattata, nel secondo sarà più semplice partire già seguendo la strada giusta.

Il problema da risolvere, per applicazioni e/o infrastrutture non progettate per lo scopo, è il seguente. In un sistema bilanciato richieste successive degli utenti vengono distribuite da un bilanciatore sui vari nodi componenti il cluster frontend (server web) dell’infrastruttura. Dato che PHP di default salva i dati della sessione sul disco della singola macchina che ha elaborato la richiesta (singolo server web) è facilmente intuibile che alla richiesta successiva, che presumibilmente verrà indirizzata ad un altro server web, i dati della sessione non saranno più disponibili per l’applicazione essendo così la causa potenziale di non pochi problemi.

Per ovviare al problema le strade percorribili sono diverse.

NFS: soluzione sconsigliata, citata solo per completezza e ragioni storiche. Ricorrendo all’utilizzo in un network file system possiamo fare in modo che tutti i server web utilizzino questo spazio condiviso per leggere e scrivere in un unico punti i dati delle sessioni degli utenti. In questo modo senza alcuna modifica all’applicazione abbiamo centralizzato i dati permettendo a tutti i web server di vedere le sessioni create dagli altri. Purtroppo però i contro sono rappresentati da performance poco raccomandabili e problemi di data corruption che si possono incontrare specialmente quando le scritture iniziano ad essere elevate.

COOKIE: ricorrere all’utilizzo di cookie criptati permette di far viaggiare i dati della sessione assieme alle richieste effettuate dall’utente. I dati sono salvati lato client, quindi non c’è bisogno di uno storage centralizzato. E’ una soluzione facile da realizzare e che può incontrare solo problemi legati alla dimensione dei dati da memorizzare. Il prezzo da pagare è quello di un leggero incremento della banda utilizzata per lo scambio di queste informazioni aggiuntive.

DATABASE: utilizzare un database permette di centralizzare le sessioni e renderle facilmente disponibili ai vari webserver oltre che facilitarne la persistenza. In contesti con traffico non eccessivo può essere una buona soluzione per l’utilizzo di uno strumento “semplice” come un database. All’aumentare del traffico però il rapporto tra letture e scritture inizia a creare qualche problema dato che non è possibile ottimizzare il servizio per  l’una o l’altra operazione, inoltre senza il passaggio ad un sistema master-slave o master-master con N slave (creando ulteriore complessità nell’architettura generale) il database rappresenta il single point of failure per questo tipo di approccio. Inoltre può trasformarsi in un collo di bottiglia non indifferente.

MEMCACHED: utilizzare la memoria per leggere e scrivere dati permette di avere prestazioni che filesystem e database relazionali non possono nemmeno sognare. Memcached essendo poi clusterizzabile rappresenta una soluzione molto interessante specie in quei casi dove l’eventuale perdita dei dati (corruzione memoria) non è un evento tragico. Infatti avendo a che fare con la memoria i problemi possono derivare dalla corruzione della stessa, che porta alla perdita di tutti i dati presenti in quel momento perchè non vi è un sistema di persistenza. Inoltre la memoria è ciclica percui se la quantità di memoria allocata a Memcached non è correttamente proporzionata i dati più “vecchi” vengono eliminati per lasciare spazio a quelli “nuovi”.

REDIS (CLUSTER): come visto per Memcached sappiamo che la memoria rappresenta uno strumento ottimale in termini di performance. Redis permette inoltre di evitare i problemi di persistenza perchè ad intervalli regolari salva i dati anche su disco. Dalla versione 2.4 (al momento in sviluppo) sarà disponibile anche la versione cluster che quindi permetterà di allestire infrastrutture al pari di quelle realizzate con Memcached.

STICKY SU BALANCER HW (LAYER 7): una soluzione che non richiede modifiche all’applicazione ed all’infrastuttura è a disposizione nel caso in cui si utilizzi un balancer hardware che gestisce le sessioni in modo persistente. In questo modo l’utente verrebbe indirizzato durante la sua sessione di navigazione sempre verso lo stesso webserver. Il vantaggio è che l’applicazione non andrebbe modificata, le gestione delle sessioni è tutta a monte demandata al bilanciatore di carico. Il rovescio della medaglia? Il costo: balancer di questo tipo comportano spese ben superiori rispetto a balancer non persistenti che si possono realizzare anche con un semplice server predisposto per smistare il traffico.

Domande? Curiosità? I commenti sono aperti.

Di seguito l’abstract e le slide del talk:

Le testimonianze dei grandi player di settore non mancano: Yahoo!, Delicious, Dailymotion…tuttavia non sempre è possibile confrontarsi con grandi sfide in termini di traffico, alta disponibilità e scalabilità.

La realizzazione di Calciomercato.com utilizzando symfony ci ha permesso di toccare con mano le potenzialità offerte dal framework potendo contare su numeri di una certa importanza: 3,3M visitatori unici e oltre 36M pagine viste (agosto 2010). Load balancing, database in replica, APC, memcached sono tutti strumenti indispensabili sia per il funzionamento del sito oltre che per lo sviluppo di funzionalità altrimenti non realizzabili.