Personalmente ho dato il mio piccolo contributo seguendo costantemente una sala per quanto riguarda le registrazioni e l’accoglienza dello speaker di turno oltre a rendermi disponibile per cos’altro fosse necessario. Sia chiaro: rappresenta forse meno dell’1% dello sforzo che tutto il direttivo si è sobbarcato per organizzare il tutto nei minimi dettagli.

Oltre a fare parte dello staff ho avuto il piacere di partecipare a questa edizione (la quarta per me) in veste di speaker presentando l’esperienza accumulata su un progetto che in azienda tutt’ora ci coinvolge: Symfony e grandi numeri: si…può…fare!

E’ stata una bellissima esperienza, sicuramente da rifare, che mi ha insegnato parecchie cose che sicuramente mi aiuteranno a migliorare per le prossime occasioni. Un po’ di tensione all’inizio mi ha fatto spingere un po’ troppo sull’acceleratore, dall’ultima prova fatta la mattina temevo di arrivare lungo sui 50 minuti a disposizione.

Fortunatamente il tempo avanzato a fine presentazione è stato completamente consumato dalle numerose domande ricevute da chi aveva deciso di seguire il mio talk (nonostante fosse nel primo slot la mattina dopo il meetup di Github con free beer!). Paradossalmente meglio di così non poteva andare in termini di tempo.

Alcuni numeri interessanti:

• 214 partecipanti (JsDay + phpDay)
• Circa 60 speaker da US ed EU
• Almeno 14 ragazze presenti alla conferenza
• Durante i 4 giorni di conferneza sono stati serviti circa 700 Spritz (non è dato sapere la birra consumata al meetup di Github)
• Più di 80 partecipanti hanno utilizzato la SPA dell’hotel San Marco
• Domenica tutto lo staff era debilitato in una forma o nell’altra
• Partecipanti al solo JsDay: 65
• Partecipanti al solo phpDay: 74
• Partecipanti full conference: 75
• Il giorno con più presenze è stato giovedì con 192 partecipanti (75.full + 65.js + 52.php)
• Sono stati registrati 120Gb di video

Alla prossima edizione!

Passi la location un po’ fuori mano per chi arriva da nord, giustificata dal fatto di minori costi (giustissimo) e dalla voglia di andare un po’ incontro (altrettanto giusto) anche agli sviluppatori del centro e del sud che altrimenti si ritrovano sempre nella posizione svantaggiata. Pieno appoggio.

Passi il fatto che nonostante Alba Adriatica si trovi tra i due aeroporti di Pescara e di Ancona non esista un volo dal nord-est (Trieste, Venezia, Treviso) ad un costo inferiore ai 300€.

Ma farsi quasi 600 chilometri in un tempo da maglia nera causa:

• 1 ora di coda per incidente a 30km da Venezia
• 30-45 minuti di coda per alluvione e grandine subito dopo Padova (vedansi foto)
• pioggia ininterrotta da Rimini in poi (con tutti i cantieri)

è stato un gran divertimento! Per fortuna ero in compagnia del buon Pierluigi che ha reso meno noioso il viaggio.

A questo punto, vista tutta questa fatica, sono sicuro che l’edizione 2010 del phpDay sarà memorabile.

Sono davvero felice di vedere questo traguardo raggiunto, il coronamento di tanto lavoro offerto da alcune persone in via del tutto volontaria e gratuita solo per il bene della comunità. Orgoglio di vedere il proprio nome tra i traduttori e gioia di ricevere una copia omaggio da parte di Sensio. Correte a comprarlo!

Tuttavia i vari sponsor hanno messo a disposizione parecchi regali, ecco cosa mi sono aggiudicato:

• Libro su Doctrine (che dovevo proprio prendere visto il passaggio da Propel a Doctrine che ho deciso)
  
• USB Fan + Light (ficherrimo)
  
• elephpant (ne ho già 2, ma uno vinto vale di più!)
  

L’iniziativa continua quindi proverò anche questo mese a chiudere un ticket al giorno augurandomi di raggiungere il mio obiettivo: essere a Parigi a febbraio! Il problema sarà rappresentato principalmente dal fatto che la connessione mobile con Fastweb non mi permette di utilizzare svn cosa quasi indispensabile per lavorare comodi tra revision e sorgenti vari…

L’occasione mi ha dato la possibilità di incontrare amici vecchi e nuovi del GrUSP, condividere esperienze e cosa più importante lavorare alla scrittura dei test assieme a sviluppatori di un certo calibro. Quest’ultima cosa permette di confrontare le diverse soluzioni che i presenti possono trovare per lo stesso problema, e chi non ha la fortuna di lavorare in team ringrazia per l’esistenza di eventi come questo. Il code dojo è stato molto utile e divertente.

Come promemoria alcuni appunti per la prossima edizione:

• siamo arrivati un po’ impreparati sul fronte virtual machine per eseguire i test confidando troppo in quella resa disponibile da Eric Stewart che così com’è non contempla il code coverage di gcov/lcov (cosa non bloccante), al prossimo giro sapremo preparare la macchina alcuni giorni prima ed i partecipanti la potranno installare direttamente all’evento;
• essendo la prima edizione in pochi erano subito “pronti” per scrivere test in modo completo e corretto. L’esperienza però è stata accumulata e la prossima volta le cose saranno più semplici;
• fare in modo che il meteo collabori, altrimeni le povere donne al seguito avranno ben poco da fare in tutto il weekend:

In attesa che vengano pubblicate le innumerevoli foto scattate durante l’evento non resta che ringraziare nuovamente tutti quelli che hanno fatto qualcosa per la sua riuscita (organizzato / partecipato / sostenuto…).

L’evento PHP TestFest è stato indetto per dare una spinta nel completamento dei test automatici necessari per testare tutto PHP.

Gli user group locali sono invitati a far parte del TestFest, gli usergroup possono incontrarsi fisicamente o virtualmente con lo scopo di cooperare ed imparare gli uni dagli altri.

Si tratta inoltre di una possibilità di fare amicizia con persone nuove con la tua stessa linea di pensiero; inoltre si spera di ridurre il lavoro dei Mentor PHP.net.

I test inviati dal gruppo saranno controllati dai membri di php.net prima di essere inclusi nella test suite ufficiale.

Insomma dopo tanto ricevere è giunto il momento di dare qualcosa. Grazie al GrUSP ed al forte impegno di Ideato anche la comunità italiana può dare il suo contributo ed è sicuro che i presenti faranno del loro meglio! Se non sei ancora iscritto ma vuoi partecipare sul wiki trovi tutte le info necessarie a contattare chi di dovere (Francesco Trucchia) per farti mettere in lista. Cosa aspetti?!

Innanzitutto va detto che Subversion è un version control system open source che si occupa di gestire file e directory e le modifiche che possono subire con il passare del tempo. Questo permette di recuperare una certa versione di un file, seguire l’evoluzione di certi contenuti nel tempo. Praticamente è una piccola macchina del tempo.

Subversion può lavorare in rete permettendo quindi a persone distanti anche migliaia di chilometri di lavorare sugli stessi file dello stesso progetto in modo semplice e sicuro. E’ possibile impostare diversi livelli di accesso a determinati file e directory. L’evoluzione dei dati gestiti da Subversion può essere molto rapida, tuttavia è altrettanto semplice risolvere un problema introdotto da una modifica tornando alla versione precedente del contenuto specifico.

Mi può servire?

Vi starete sicuramente chiedendo se Subversion è lo strumento che fa per voi. Capirlo è molto semplice.

Avete bisogno di archiviare vecchie versioni di file e directory con la possibilità di andare a ripescarle facilmente e di controllare la loro evoluzione nel tempo confrontando le singole modifiche dello stesso file in diverse versioni? Subversion fa per voi.

Avete la necessità di lavorare con altri colleghi sparsi in rete sugli stessi file, tenendo traccia di chi ha fatto una particolare modifica e quando? Subversion è lo strumento che fa per voi.

Vantaggi principali

Il problema principale derivante dal fatto di lavorare in team sullo stesso progetto senza uno strumento di versioning è quello delle sovrascritture dei file e quindi delle modifiche fatte dagli altri. Un’immagine ricavata dalla documentazione di Subversion è più esplicativa di mille parole:

Subversion si basa sul concetto copy-modify-merge e di working copy secondo i quali ogni utente lavora sulla propria copia locale del progetto prima di inviare le proprie modifiche al repository centrale. In questo modo è possibile lavorare in parallelo senza perdere tempo aspettanto l’unlock di un file come accade nel contesto lock-modify-unlock.

Chiaramente lavorando in parallelo sugli stessi file è possibile che si verifichino dei conflitti da risolvere manualmente se alcune modifiche sono in contrasto tra loro. Va anche detto che se il lavoro è ben distribuito non è frequente avere a che fare con dei conflitti da gestire, qualora ce ne fossero il tempo per gestirli sarebbe comunque minore al tempo perso in un sistema basato sui lock.

Concetti molto importanti sono quelli di branch e merge che permettono di avere rami paralleli di sviluppo e strumenti per la gestione semplice dei contenuti comuni oltre a permette di fondere poi i contenuti nuovamente in un unico ramo gestendo eventuli conflitti.

Per chiudere questa presentazione, assolutamente non esaustiva, cito anche il tag che rappresenta una vera e propria snapshot del progetto in un determinato momento. La creazione di un tag è associata molto spesso alla release del prodotto o di certe funzionalità aggiuntive di una certa entità. Puntanto quindi ad una specifica tag potremo ricavare il sistema come era in un determinato momento escludendo tutte le modifiche apportate in seguito.

Vantaggi per i piccoli team o per sviluppatori singoli

Personalmente non ho mai avuto la fortuna di lavorare in grandi team o su progetti molto vasti portati avanti da diverse persone. Questo ha comportato nella maggior parte dei casi che il progetto su cui stessi lavorando fosse tutto mio dall’inizio alla fine o che comunque nessuno avesse bisogno di scrivere codice su un file aperto da me. Anche le abitudini dell’azienda contano e purtroppo dove ho lavorato io nessuno mi ha mai “obbligato” ad usare uno strumento come Subversion.

Tuttavia anche lavorando da solo su un progetto molte volte ho sentito la necessità di poter utilizzare uno strumento di versioning per il semplice fatto di poter “tornare indietro” ed analizzare le modifiche fatte ad un file. Un semplice esempio può esprimere meglio il concetto:

Il cliente chiede di far visualizzare una galleria fotografica in un certo modo piuttosto elaborato rispetto alla versione attuale presente sul suo sito. Sappiamo tutti che il cliente non ha ben chiaro nè cosa vuole nè come dirlo, proprio per questo ci troveremo a sviluppare N versioni della galleria che man mano andranno a sovrascrivere la versione precedente. E’ altresì molto probabile che nessuno faccia una copia di backup di tutte le versioni ma si proceda per iterazioni rilasciando sempre ciò che si modifica.

Ad un certo punto il cliente decide che la versione N-x era quella giusta. Come fare? Senza versioning ci si deve augurare di ricordarsi alla meno peggio ciò che si era fatto (che può essere moooolto distante dalla versione attuale) e riscrivere il codice totalmente da zero. Con il versioning basta cercare la versione corretta del file e recuperarla o analizzare le differenze con la versione attuale per muoversi al meglio.

Altro esempio potrebbe essere quello di dover recuperare quel frammento di codice usato tempo fa e poi dismesso ma che ora serve nuovamente. Non è bello lasciare porzioni di codice commentato nei propri listati in attesa di essere forse riutilizzati, con il versioning si possono eliminare e andare a recuperarli quando e SE serviranno.

Anche la possibilità di sfruttare il branching di un progetto e quindi di portare avanti in modo parallelo lo sviluppo della nuova area del sito o della nuova funzionalità dell’applicazione e lo sviluppo/mantenimento di ciò che già esiste rappresenta un bel vantaggio. Mentre nel trunk continuiamo ad avere una versione completamente funzionante dell’applicazione, su cui eventualmente si eseguono piccoli bug fix o leggere modifiche, nel branch creato è possibile sviluppare in tutta calma le nuove funzionalità (che occupano un arco temporale anche di una certa entità) fino a quando saranno ultimate e fatte ricadere quindi nel trunk.

In questo modo non esistono più attività bloccanti che impediscono di fare altre cose perchè ora il codice “è cambiato”, c’è sempre una versione funzionante da poter utilizzare e su cui poter lavorare senza pensieri.

Concludendo

I progetti più attivi su cui lavoro ho già provveduto ad importarli sull’svn aziendale creato ad hoc. Checkout e commit sono ormai all’ordine del giorno ed i dati delle revisioni possono essere sfruttati per alimentare altre applicazioni come Trac o Redmine che permettono una più facile lettura di questa mole di informazioni. Visto che di questo si potrebbero scrivere altri N post non mi dilungo, se qualcuno è interessato possiamo parlarne nei commenti. I nuovi progetti invece partiranno da svn in modo “nativo” per mia gran gioia.

Tornare indietro? Non se ne parla nemmeno! Mai più senza SVN! E voi come rispondereste?

This tutorial is the best way to get started with symfony. It explains everything you need to know about symfony installation. In a matter of minutes, you will be ready to use symfony and start your next project.

Si parla quindi di installazione e setup per partire con il piede giusto. La comunità italiana, con il sottoscritto in prima fila, si è subito mobilitata per creare la traduzione in italiano anche di questa parte di documentazione. Credo che domani in giornata possa essere già ultimata a disponibile sul sito ufficiale. Ci auguriamo di vedere la bandierina italiana prima di tutte le altre.

UPDATE 27/05: a meno di 24 ore dal rilascio della documentazione tutte le parti del nuovo tutorial sono state tradotte (6) o sono in carico ai traduttori (2). Entro domani sera anche le mancanti dovrebbero essere portate a termine.

Venerdì 15

Si parte all’alba delle 7.00 per raggiungere Verona poco dopo le 9.00, magie del passante di Mestre. Arrivati, io e Orietta sì, all’Hotel San Marco in modo molto semplice grazie al navigatore abbiamo avuto anche il tempo di fare il check in per lasciare i bagagli in camera prima che mi dovessi presentare alla registrazione per ricevere badge, maglietta e gadget vari. Tutte cose che rientrano nel costo dell’iscrizione che compreneva anche iscrizione al GrUSP e due pranzi oltre ai coffee break.

Non ripeto ciò che ho seguito, ho scritto un post appositamente per comunicarlo prima, mi limito a sottolineare la presenza di Rasmus Lerdorf e di Fabien Potencier che con i loro talk hanno saputo ripagare sicuramente la sete di PHP dei presenti. Notevole anche il talk di Filippo De Santis Mocking objects practices for Symfony che ha avuto l’accortezza di far toccare con mano le potenzialità e l’utilità dei test unitari.

Scrivere i test per ciò che si sviluppa dovrebbe essere la norma, ma sappiamo tutti che non è così. Personalmente ho iniziato da poco ad utilizzare Symfony per progetti reali, al lavoro, e questo mi permette di applicare il TDD e tutta una serie di pratiche XP che con gli strumenti usati fino ad’ora (PHP4 e codice procedurale) non erano pensabili. In pochissimo tempo mi sono reso conto che non potrei più tornare indietro dormendo sonni tranquilli.

La presenza di Potencier inoltre è stata utile per capire l’evoluzione del progetto riguardante la traduzione in primis del Jobeet Tutorial oltre a future traduzioni (pre esempio dei vari libri dei components della Symfony Platform). Presto sarà disponibile anche la versione cartacea della traduzione in italiano, restate sintonizzati per aggiornamenti.

Sabato 16

Giornata di workshop per me e molti altri che hanno seguito Francesco Trucchia in Spaghetti code refactoring. Francesco è garanzia di qualità ed è sempre capace di suscitare interesse nei presenti. L’ossatura principale del suo workshop era rappresentata dai test, primo passo da affrontare ogni volta che ci si dedichi al refactoring. L’unico modo per sapere che tutto funziona, anche in posti lontani dell’applicazioni, è quello di poter fare affidamento su dei test seri.

Tra i vari strumenti utilizzati per ricavare ed eseguire i test vi consiglio di dare un’occhiata a Selenium e Selenium RC che sono stati utilizzati in relazione a PHPUnit.

Incastrato al workshop, in termini temporali, c’era il talk di Jacopo Romei che sono riuscito a seguire solo in parte ma che mi ha permesso comunque di carpire utili informazioni per la gestione dei contratti e dei preventivi in contesti agili. Non si finisce mai di imparare ed ogni volta si aprono nuovi orizzonti da esplorare.

Altra presenza notevole è stata quella di Jonathan Wage Sympal: The flexible Symfony CMS che ha presentato il suo CMF, più di un plugin nonostante le risorse a sua disposizione non siano molte visto che già si deve occupare di Doctrine. Nei prossimi giorni farò sicuramente alcuni test con Sympal passando quindi a Doctrine, due piccioni con una fava quindi visto che attualmente utilizzo Propel.

Chiusura dei lavori con uno spritz a bordo piscina e poi via a casa! Alcune foto le trovate sul mio account Flickr, molte altre le potrete trovare sul gruppo Flickr dedicato al PHPDay 2009.

In conclusione

L’evento è un punto di riferimento per tutti gli sviluppatori PHP, non posso immaginare come uno sviluppatore che abbia un minimo di interesse per la comunità non possa parteciparvi. Avevo già parlato a suo tempo delle lamentele derivanti dal fatto che l’edizione di quest’anno fosse a pagamento, a posteriori non posso che confermare quanto previsto: la qualità dei contenuti, dei presenti e l’ottima organizzazione valgono molto di più del contributo richiesto per la partecipazione.

Complimenti al GrUSP ed a tutti quelli che si sono sbattuti per far sì che l’evento avesse il successo che ha raggiunto. Ci si vede alla TestFest a Cesena!