Archive for September, 2007

Esportare il Pomodoro in Belgio

Sunday, September 30th, 2007

La Tecnica del Pomodoro è un metodo di organizzazione del tempo molto semplice, basato sull’uso di un comune timer da cucina. E’ un’invenzione di Francesco Cirillo, e in Italia è molto diffusa fra gli agilisti; tutti gli XPer italiani sanno che cos’è e la maggior parte, credo la usano. Me compreso…

Il Pomodoro originale

Molto brevemente, uno lavora in periodi di lavoro concentrato di 25 minuti, seguiti da una pausa di 5. Questo semplice meccanismo (ma c’è di più; leggi l’articolo) ha numerosi benefici sulla qualità del lavoro, della pianificazione e del tracciamento.

All’estero, invece, la tecnica è in larga misura sconosciuta; una semplice ricerca su Google riporta 26 risultati in tutto, tutti quanti pagine di italiani. E’ un peccato! Perché è una tecnica molto utile che meriterebbe di essere più diffusa.

Ora, al prossimo XP Day Benelux, che si svolgerà in Belgio il 15/16 novembre, io e Federico Gobbo presenteremo una sessione sul Pomodoro. Sono molto contento. E sono molto curioso di vedere la reazione degli agilisti stranieri. Soprattutto spero che questo sassolino generi utili onde nello stagno…

Inoltre, l’evento XP Day è caldamente consigliato… io ho imparato moltissimo l’anno scorso. Partecipa! Volare a Brussel con Ryanair costa meno di 70 euro.

Attenti alla Grande Riscrittura!

Tuesday, September 25th, 2007

Siamo onesti… come programmatori, siamo costantemente tentati dalla Grande Riscrittura. “Se rifacessimo tutto in (Rails/Erlang/Wicket/whatever) …”. La realtà è che molto raramente la GR ha successo. Il vecchio codice contiene la conoscenza di tanti casi speciali che non abbiamo pensato (o che abbiamo dimenticato.) Il vecchio codice può essere brutto, ma chi ci dice che riscrivendolo saremo in grado di scrivere del codice significativamente migliore?

Se non siamo capaci di migliorare il codice giorno per giorno, pretendere di rifare tutto è velleitario. Prendete per esempio Derek Sivers, che due anni fa aveva annunciato in pompa magna l’imminente riscrittura del suo sito CDBaby da Php a Rails. Passati due anni, è ritornato a Php:

For 2 years, I thought Rails is genius, PHP is shit. Rails is powerful, PHP is crap. I was nearly killing my company in the name of blindly insisting Rails was the answer to all questions, timeframes be damned. But when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much. Ruby is prettier. Rails has nice shortcuts. But no big shortcuts I can’t code-up myself in a day if needed. Looked at from a real practical point of view, I could do anything in PHP, and there were many business reasons to do so.

A questo proposito, Chad Fowler ha scritto una serie di articoli:

On a big system with a lot of customers, data migration can be a huge problem. Not only do we have to keep track of what gets migrated when, but we have to actually perform the migration at some point. The Big Bang sounds like a lovely idea until you get to the actual event, and you realize it’s kind of like preparing for a world title boxing match when you know it’s the first and last time you’ll ever compete. The processes and software you have to create, the attention you have to pay before you can create an event like this is often as consuming, complex, and potentially disastrous as the system development effort itself.

Ci vuole coraggio e umiltà per sporcarsi le mani con una pila di codice, diciamo, non propriamente elegante, e migliorarlo a piccoli passi, facendo refactoring, un pezzetto alla volta, senza mai “rompere” la funzionalità. Ma ci sono molto maggiori probabilità di successo!

Essap 2007, second part

Tuesday, September 25th, 2007

Here is the second part of my comments about Essap 2007.

Friday. Last day.

The day started as usual with the standup meeting. We’re getting better and better at this; it only took 10 minutes today. We had a good feeling for what people appreciated yesterday (Fabrizio’s presentation expecially.) Noone reported any particular problems, perhaps because any problems they have they got used to it or there’s no more time to do much about it.

Working on the school project

Simone suggested an excursion for the late afternoon, when the school closes. We’re going to “Paradise Peak,” a suggestive vista point on the “Sacro Monte” near Varese.

Then Luca Grulla started his session on “Retrospective Techniques.” It’s amazing how much Luca has improved in self-confidence, compared to last year. In fact last year I had to insist that he lead the final retrospective, and took me some time to convince to do it (he was much better qualified than me, since he led a few already.) This year Luca answers with confidence many questions from the audience about agile in general. His presenting skill is very good: clear slides with little text and plenty of examples. It’s clear he knows his stuff from experience. He explains the basics of retrospectives: the goals of a retrospective, the Prime Directive (everyone did the best they could, there will be no talking of blame), the phases and exercises. Luca confirms what Gabriele told me already, that the “Agile Retrospectives” book is full of excellent advice on how to do retrospectives in an Agile setting (that is, not “at the end of a project”, but “at the end of an iteration”, or even “whenever you need one.”)

I did not know that the facilitator should preferably not be a member of the team. When you can, you have a member of another team in your company lead; otherwise, you can have someone in the team facilitate, but he should clearly mark the “change of hat” from when he is contributing as a team member to when he is facilitating.

After the presentation, Luca divided the audience in six four-people teams, and assigned a role-playing exercise to each. For instance:

You are the support development team of an important online bet agency. Customers call a 24/7 call center reporting problems and the call center talks to you to fix and close defects. The team is struggling due the high volume of requests that daily receives from the call center(and some of these are not actual defects).

2 Tester, 1 Developer, 1 Project Manager

We had some pizza in the park for lunch. Then in the afternoon Luca facilitated the retrospective on the Essap itself. Last year he had us place post-its on a timeline of the week. This year he had us do the “starfish” exercise, where we break the whitboard in six spaces: “stop doing”, “do less”, “keep doing”, “do more”, “start doing.” Then everyone writes no more than two post-its for each of the categories. There was a lot of people, so the whiteboard was very crowded. It was exciting to see the whiteboard covered thick with post-its!

My mind is full of thoughts of what I did wrong, what we can improve for next year. This retrospective was a very positive experience. The mood of the people was clearly positive; everyone looked happy and the there were much more stickies in the “keep doing” and “do more” sections.

I had many good suggestions from the “start doing” section, some really insightful. The main complaint was that we had not enough time to spend on the hands-on project. I will certainly agree to this. There was too much time allocated to sessions, and not enough time allocated to the project. Jacek suggested that we optimize session time so that exercitations in a session can be directly related to the hands-on project. Mikael suggested that we limit session topics to the most important things, so that we keep focus on the most fundamental things that are needed to start working in an agile way (with an eye towards the hands-on project.)

There were many stickies with “Ruby on Rails”, in the “keep doing section”, but quite a few with the same in the “stop doing” section. I understand this. Rails is fun and attractive. Yet it can be an obstacle to learning Agile techniques. Learning TDD and simple design is difficult enough, without the added difficulty of learning a new framework. It seems to me it will be a good idea to drop Rails and web applications in general for the next edition. It would be a good idea to keep technology to a minimum: no database, no GUI; focus on the domain objects. Luca suggested a command-line application.

It’s a bit of a pity for the JooB lab application. The idea was very good, and the people of the Varese XP UG did an excellent job of developing the skeleton application (and creating the lab infrastructure, and setting up the participants laptops!) But you must focus. On an Agile school you should stick to simple OO programming. In a Rails school JooB would be a great project. In fact I’d like to use it to teach Rails, if the authors will agree to publish it as an open-source project with a liberal license.

There were some post-its about better coaching during the labs. I agree with that, as well. There should also be an experienced coach for each team. This was not possible this year, for my two coaches were not available; Gabriele sick in bed, Federico away for a conference. Next year we should have at least a coach for team, and a spare one to cover for the unexpected. This means that we should have at least three coaches if we want to have three teams. And, the teams were too big. I would say 5 to 6 people is the maximum for a new team; this will limit the number of participants to, say, 16 if we have three coaches, or 12 participants if we only have 2 coaches…

There was an awkward moment for me, for many participants suggested that we give badges with the names on the first day; Luca noticed that the same item came up last year at the retrospective, and I did not act on it. The retrospective is a waste of time if you don’t implement the actions! My fault.

So what were the other actions that were suggested? Luca had us vote; the highest votes went to “more hands-on work” and “have printed material ready before the conference.” Point taken; I will implement these two. I asked Luca to be the appointed sponsor for the name badges :)

One thing that participants were enthusiastic about was the use of the pomodoro; they found a lot easier to follow a long session, when the organizer pauses for 5 minutes every 25. Some organizers didn’t follow the pomodoro rule strictly, and the audience found this annoying!

After the retrospective we closed the school. Most people left for their trains. A few stayed for the excursion on Paradise Peak. And it was worth it! I didn’t know there was such a nice wood just outside Varese. The view from the Peak was breathtaking, the weather was perfect. The smell from pines in the crisp air, the bright sunlight: Summer at its best.

Up the Sacro Monte

Http chat server in Erlang, il seguito

Tuesday, September 25th, 2007

Marco Trinci ha completato il suo lavoro di Tesi per la Laurea in Informatica triennale sul server di chat Http in Erlang. Si trova su http://buffy.sciva.uninsubria.it:8000, da cui si può scaricare anche la tesi.

Questo lavoro è interessante perché riesce ad usare HTTP per simulare l’invio di messaggi ascincrono da parte del server (il famoso push.) Non è semplice ottenerlo, perché il protocollo HTTP non è progettato per queste cose. Si tratta di una variante di Ajax chiamata Comet. Marco ha realizzato un server Comet in Erlang, che implementa un protocollo standard per fare Comet chiamato Bayeux. Infatti la parte client della chat è stata presa da un altro progetto, che usava un server Java.

E’ particolarmente importante che ci sia un’implementazione di Comet in Erlang, perché Comet è fatto per applicazioni più interattive della applicazione web media: ad esempio ricevere le quotazioni di borsa, giocare interattivamente, oppure editing distribuito di documenti. Esattamente il genere di applicazioni per cui Erlang eccelle. Grazie a Marco ora questa implementazione c’è!

Trattare il database agilmente

Friday, September 7th, 2007

Sulla mailing list di Extreme Programming si parla di strumenti per gestire il refactoring dei database. Secondo me lo strumento più carino sono le migrations di Rails… ma a parte questo, il mio contributo in mailing list è stato il seguente.

A proposito di database refactoring, ci sono alcune pratiche essenziali:

* ogni sviluppatore ha un suo database di sviluppo personale
* ogni sviluppatore ha un suo database personale per i test automatici
* è possibile ricostruire entrambi i database, aggiornando lo schema in development e in test, e caricando i dati di base, con un solo comando
* gli sviluppatori hanno la facoltà di modificare lo schema dei dati!

Ottenere questo è in parte un problema politico; alcuni DBA scricchiolano quando gli si chiede di creare così tanti database; oppure pretendono procedure burocratiche per modificare lo schema, o addirittura impongono schemi di nomenclatura assurdi (ho lavorato in un progetto dove ogni tabella aveva nomi tipo t0345customers, e i campi avevano nomi tipo int0345customer_id). In parte è un problema tecnico, che però si può gestire con script.

Se queste pratiche di base sono rispettate, allora diventa possibile fare evolvere lo schema dei dati con degli script progressivi. Ad esempio, prendendo spunto dalle migrations di Rails, in un progetto Java avevamo script con nome 001_create_customers.sql, 002_add_foobar_column.sql, eccetera; la nomenclatura permette di caricarli tutti nella sequenza corretta con un singolo comando:

cat ???_*.sql | mysql foo_development

Abbiamo trovato utile mettere in ciascuno dei file un istruzione tipo

update schema_info set version = 3;

in modo che in ciascun database abbiamo un informazione che ci dice a che livello si trova.

Non c’è bisogno di un gran che di tecnologia per usare queste pratiche, e secondo me permettono di risolvere una buona parte dei problemi di evoluzione della base dei dati.