venerdì 22 dicembre 2006

I feel fine

Gironzolando sulle radio di iTunes ho trovato Beatles-A-Rama, una web radio che trasmette solo musica, interviste e aneddoti sui Beatles e tutto ciò che gira intorno al mondo dei FabFour...


http://www.beatlesarama.com/


Ciao Piero

giovedì 14 dicembre 2006

MacBook Pro

Evvai dopo mille peripezie e con qualche accrocchio, domani sera avrò in mano il mio nuovissimo MacBook Pro 15", acquistato presso il nuovissimo Apple Power Reseller di Varese, fateci un girò è una novità!

Nella to-buy-list ora si sono accodati il TextMate, MacMini, la tastiera wireless per mac, e uno schermo panoramico piatto per il futuro macMini...

Ciao Piero

martedì 5 dicembre 2006

Debbuging or Thinking?

"The debugger isn't a substitute for good thinking. But in some case, thinking isn't a substitute for a good debugger either. The most effective combination is good thinking and a good debugger"

Steve McConnell, nel suo Code complete, fornisce una lauta Checklist a proposito del debugging.

Tra le tante voci vale la pena citare:


    • Exercise the code in your test suite

    • Reproduce the error several different ways

    • Use the result of negative tests

    • Keep a notepad by your desk, and make a list of things to try



Con questi piccoli accorgimenti sarà possibile fare bug fixing, qualora fosse indispensabile e il TDD non faccia luce sul problema, molto più velocemente. La velocità però non deve essere il principale fattore guida, troppa fretta porta altri bug rinchiudendo la fase di debugging in un circolo vizioso. Infatti la checklist continua con un "relax", questo è un buon consiglio. Se manca tempo, o il debugging porta al malditesta, prendere cinque minuti (o dieci) possono portare un vantaggio consistente nel lungo periodo.

Solo su una voce della lista non sono pienamente d'accordo: "Change the code only for good reason". E' vero, non devo fare sciocchezze nel codice, ma essere coraggiosi e apportare cambiamenti sostanziali al design può essere più che produttivo, e far ciò mi è facilitato se ho sviluppato tramite Test dato che in ogni momento che apporto una modifica al codice sarò certo se questo funzionerà correttamente o meno.

Un buon inizio per capire come fare red-green refactor o il TDD è wikipedia, o questo articolo su agiledata.

lunedì 4 dicembre 2006

Agile Day 2006

Venerdì 1° Dicembre 2006 mi sono recato insieme ad Andrea e a suo cugino Simone al terzo Italian Agile Day, tenutosi ad Assago (centro congressi Milanofiori - Milano).
L'Agile Day è una conferenza dedicata alla diffusione delle metodologie agili, quali eXtreme Programming e Scrum, e di tutto ciò che circonda il mondo agile (Linguaggi, metodi e tecniche, framework,ecc)
Partiti da Varese alle sette e mezza del mattino siamo arrivati ad Assago in poco più di un ora.

A dare il via ai lavori è stato Marco Abis, promotore dell'iniziativa. L'idea di quest'anno è stata l'open space conference: solo due sessioni plenarie e molti piccoli workshop in contemporanea (track).

La prima sessione plenaria è stata tenuta da Luca Minudel e Nicola Canalini del team Ferrari racing. E' stato bello vedere come Xp venga applicata con successo in team dove il dinamismo sia necessario e continuo, e dove i termini di consegna siano categorici e frequenti (se il gran premio o il test drive della macchina è alle 14:00 il software deve essere pronto e testato prima delle 14...).

Successivamente ho avuto modo di assistere a diverse sessioni. Nella prima, tenuta da Luca Grulla, si è parlato di Scrum. Scrum è una metodologia agile progenitrice di eXtreme Programming, ne condivide obbiettivi (come la massimizzazione della comunicazione tra il team e il costumer), ed è molto adatta a progetti che richiedono molto dinamismo. Non posso ancora esprimere una opinione precisa su Scrum: mi sembra più "libera" di Xp, dato che posso prendere le pratiche che più mi sembrano congeniali per il mio problema da altri metodi. Forse proprio questa libertà ne è il tallone d'Achille: troppa libertà può significare confusione.

Nel contempo Matteo Vaccari ha tenuto una seconda track sul Test Driven Development proponendo il classico kata del Bowling di Uncle Bob. Il TDD è un'ottima tecnica di Xp per sviluppare software testato e funzionante in breve tempo. Durante la track (e la giornata) è traspirato il fatto che molti scambiano il TDD con il Test First, ovvero prima faccio il test e poi scrivo la funzione. Il TDD è un metodo di sviluppo, il test evolve insieme a ciò che devo testare, e mi guida fino a trovare la soluzione.

Una sessione che ho seguito con interesse è stata "Agile Web Development with Django", tenuta da Carlo Miron. Django è un framework simile a Rails ma scritto in Python. Utilizza un modello di sviluppo simile al Model Controller View di RoR: MTV (Model Teplate View). Similmente a quanto accade nelle migrazioni di Rails, posso descrivere con il Modello lo schema di una tabella nel Db. Punto a sfavore è l'assenza delle migrazioni (sono in fase di sviluppo), che vanno fatte a mano.
Rispetto a rails, la localizzione è molto facilitata, esistono già traduzioni nelle lingue più disparate. Molto divertente è il testing delle applicazioni e del codice. Phyton permette di inserire del codice di testing nella documentazione della funzione.
Sebbene ne sia rimasto colpito, Django mi sembra meno maturo di rails, purtroppo non sono state mostrati slide o esempi di codice, che sicuramente sarebbero state molto utili.

Essere al contatto con persone e professionisti che lavorano nel mondo agile (e non lavoricchiano/studiano come me :-/ ) è stato molto stimolante e istruttivo. Spero che molti miei colleghi di Università e amici sviluppatori, possano in futuro utilizzare metodologie Agili e partecipare al prossimo Agile Day. Un buon punto di partenza sono l'eXtreme User Group di Varese e quello di Milano, oltre al sito dell'Agile Moviment in Italia.