Ecco il video riassunto della eZ Conference 2009. Al minuto 6:00 ci sono le immagini della mia premiazione!!

Da molto tempo aspettavo questo momento, la possibilità di effettuare test funzionali su eZ Publish.

Non vi voglio annoiare spiegandovi l’importanza dei test automatici unitari e funzionali, ma lavorando con symfony e scoprendone le gioie ormai da più di due anni, la mancanza di questa feature su eZ Publish mi rendeva veramente nervoso.

Questa settimana ho lavorato con Jacopo su una nuova estensione che ora offre la possibilità di eseguire test funzionali con phpunit e sfWebBrowser sul famoso cms eZ Publish, dandoci il controllo completo sullo sviluppo.

L’implementazione è stata possibile grazie all’integrazione di phpunit in eZ Publish. Si finalmente anche loro hanno capito che devono testare le loro classi per poter far evolvere il CMS e fare refactoring. Però lo script integrato dà solo la possibilità di eseguire test unitari e non test funzionali.

Per questo motivo abbiamo realizzato una classe phpunit eZBrowserTestCase che è in grado di caricare classi, oggetti e nodi eZ Publish da un file YAML su database ed offre metodi proxy verso la classe sfWebBrowser per poter navigare un sito web da console proprio come se fosse un browser. Inoltre implementa metodi per testare la presenza di elementi sul dom attraverso i selettori CSS.
Read more →

Fantastico!! Torno da una settimana parigina veramente piena di emozioni.
Ho partecipato la settimana scorsa alla eZ Conference 2009, conferenza annua della eZ System. In occasione della conferenza si sono tenuti anche gli eZ Awards, riconoscimenti che vengono datai tutti gli anni a personaggi di spicco della comunità per il lavoro fatto.

Quest’anno sono stato nominato per “la pubblicazione dell’anno” con il libro che io e Fullo abbiamo scritto “eZ Publish 4: Enterprise web sites step by step“.

Giovedì sera il nostro lavoro ha ricevuto l’eZ Award come migliore pubblicazione dell’anno!!! E’ stato veramente emozionante.

Per questo premio voglio pubblicamente ringraziare ideato, Fullo, Packt Publishing ed eZ Systems.

Proprio oggi stavo facendo una riflessione sui metodo agili e sul famoso dilemma della responsabilità del bug-fixing.

In un processo waterfall la responsabilità del bug fixing è (quasi) sempre a carico del fornitore (azienda che sviluppa software), spesso causando gravi disagi nei tempi di consegna e nel pagamento delle risorse.

In un processo agile, dove l’azienda fornitrice mette a disposizione un team full-time (o con effort concordato) sul singolo progetto di un cliente, chi paga il bug fixing?

Dal mio punto di vista ritengo che se un team adotta tutte le buone pratiche agili dovrebbe essere in grado di creare software esente da bug. Ovviamente questo non è sempre possibile.

I punti deboli della catena possono essere:

• scrittura di un test non completo;
• storie troppo poco granulari;
• poco feedback tra team e cliente;

Ok, ammettiamo che il bug è stato creato, quindi siamo caduti in uno dei tre punti precedenti. Tutti e tre i punti indicano che è stato tolto tempo all’implementazione di una storia, poichè:

• scrivere test completi richiede tempo;
• splittare storie significa più tempo di sviluppo;
• più feedback significa più tempo con il cliente

La mia domanda a questo punto è: “Che cosa ha fatto il team di questo tempo non utilizzato?”

Se c’è un rapporto di fiducia e trasparenza tra cliente e fornitore direi che il team se non ha speso il tempo per le attività viste sopra lo ha speso per continuare lo sviluppo dell’iterazione, quindi ha sempre venduto valore al cliente.

Con ciò direi che il bug-fixing rientra nella normale vendita di valore che il team fa nei confronti del cliente e che ogni bug, come ben spiegato in tutti i manuali agili, va trasformato in storia, stimato e pianificato nelle iterazioni successive.

Il team agile vende il maggiore valore al cliente nel minor tempo possibile, il cliente deve pagare tutto il valore che il team crea.

E’ un po’ che sento il desiderio di organizzare un XP User Group romagnolo. Per chi non lo conosce, un XP User Group (XPUG) è un gruppo di utenti che si incontrano informalmente in orario extra lavorativo per parlare delle metodie agili e delle pratiche XP, nonchè per fare human network e bere birra !!

Solitamente gli incontri possono essere sotto forma di:

• Mini BarCamp
• Coding Dojo
• Workshop
• Talk

Il gruppo è aperto a sviluppatori che non conoscono ma sono interessati a conoscere l’XP, e a chi già lo conosce ma ha voglia di confrontarsi.

Vorrei sondare se c’è interesse nella realizzazione di questo progetto. Dal mio punto di vista, il gruppo può raccogliere sviluppatori di Cesena e zone limitrofi.

Lasciate un commento se siete interessati a partecipare, così organizziamo il primo incontro dove ci conosceremo e definiremo che cosa fare.