“Mi commenti questo fumetto…”
:-)
update: yep, this is from the excellent xkcd web comic. I did forget to link to them, or rather I messed up with Marsedit. Sorry if it looked like I presented this as my own stuff.
Pare che ci sia un sacco di interesse in PHP nella comunità Java… non sanno più chi invidiare! Ma reimplementare PHP in Java è un idea non cattiva, è pessima. Il vantaggio di PHP, nella sua implementazione canonica mod_php è che funziona senza rompimenti di scatole, e funziona sempre. Sta in piedi con il bello e il brutto tempo, perché sta in piedi fintantoché sta in piedi il server Apache che lo contiene, quindi praticamente sta in piedi fino a che non dai fuoco al server o tagli il cavo di rete. L’installazione è semplicissima, basta copiare i tuoi file sul server, e la tua webapp è già in funzione.
Se lo reimplementi in Java che cosa ci guadagni? La fragilità e la lentezza della JVM, e la difficoltà di configurazione di Tomcat?
Un altro vantaggio di PHP è che è un ottimo insegnante: ti insegna a scrivere applicazioni basandoti su HTTP e HTML, i materiali di base del Web. Ti insegna che tutto quello che ti serve è avere le idee chiare sullo schema dei dati e la navigazione delle pagine, e il resto è un dettaglio di implementazione. Sì lo so che poi le applicazioni PHP tendono a diventare dei grovigli non manutenibili; alcuni grovigli di questo tipo li ho fatti anch’io! Infatti oggi io raccomanderei PHP solo per il valore didattico. Per sviluppo vero di applicazioni Web userei Rails senza alcun dubbio.
E’ Java che resta fuori dal loop; troppo scomodo, lento e farraginoso. E la situazione non viene migliorata dalla pletora di pessimi framework amati dai Javisti.
Ho da poco ripreso il mio corso di Applicazioni Web. Nelle prime lezioni cerco di sottolineare che non si può diventare bravi a fare applicazioni Web se non si conoscono bene gli standard del Web: HTTP, URI e HTML.
Molti sviluppatori imparano a sviluppare applicazioni Web usando framework che li isolano da questi standard di base. Per esempio, fra gli sviluppatori Java va molto di moda Wicket… che cerca di fare finta che un’app Web sia come un’applicazione desktop: il suo modello di programmazione è simile, mi dicono, a quello di swing.
Per me questo modo di pensare è perdente: può anche essere che un programmatore che conosce Swing riesca a fare le sue applicazioni più velocemente con Wicket, ma non potrà mai fare delle belle applicazioni. Perché Wicket ti toglie il controllo sulla forma delle tue URI e sulla maniera in cui usi il protocollo HTTP. E sulla quantità di memoria che il server usa per ogni sessione!
Per avere successo come sviluppatori occorre essere tecnicamente molto competenti. Nel campo delle Applicazioni Web, lo ripeto: per essere molto competente devi imparare gli standard che stanno alla base del Web: HTTP, URI e HTML.
Ma aggiungerei che insieme alla competenza occorre un buon gusto tecnico. Il buon gusto tecnico è quello che ti fa preferire le soluzioni semplici ed eleganti alle soluzioni goffe e farraginose. Per esempio, il buon gusto ti fa preferire POJO a EJB, oppure REST a SOAP e compagnia.
Linus Torvalds cita spesso il buon gusto come una caratteristica fondamentale di un ingegnere:
I see myself as not just a common repository, but also as an arbiter of “good taste.”
e
Q. What do you think is the most important skill every programmer should posses?
It’s a thing I call “taste”.
I tend to judge the people I work with not by how proficient they are …, but more by how they react to other people’s code, and then obviously by what their own code looks like, and what approaches they chose. That tells me whether they have “good taste” or not, and the thing is, a person without “good taste” often is not very good at judging other peoples code, but his own code often ends up not being wonderfully good.
Abbiamo parlato un po’ di queste cose, e di REST vs RPC, nell’ultima riunione dello XP User Group di Milano… sul wiki trovi le mie slide della serata.
Recentemente ho spostato questo blog su un nuovo provider; nel farlo ho trasferito i dati da una vecchissima installazione di Mysql 3.23 a un ragionevole Mysql 5.x. Purtroppo l’encoding del database si era rovinato; tutte le accentate apparivano come punti di domanda. Quello che era successo è che il vecchio Mysql usava l’encoding iso8859-1 (ovvero latin1), ma non lo dichiarava esplicitamente nel mysqldump. Caricandolo sul nuovo Mysql, senza dichiarare l’encoding, il testo è stato caricato assumendo utf-8. Quindi il database pensava di contenere testo codificato in utf-8, ma non era vero.
Per riparare la situazione, ho dovuto dare:
ALTER TABLE wp_posts MODIFY post_content blob;
che dichiara la colonna come dati binari; poi
ALTER TABLE wp_posts MODIFY post_content text charset latin1;
che la dichiara come testo con encoding latin1. Non potevo dare subito quest’ultimo comando, perché Mysql avrebbe allora cercato di trascodificare erroneamente. Infine ho dato l’encoding desiderato con il comando
ALTER TABLE wp_posts MODIFY post_content text charset utf8;
che la trasforma in utf-8.
Ebbene sì, questo post serve solo per ricordarmi di questi comandi se ne dovessi avere mai ancora bisogno. Altre risorse:
Per sapere il charset del database corrente si può usare
show variables like "character_set_database";
show variables like "collation_database";
oppure
SHOW CREATE DATABASE `DB_NAME`
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…
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.
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!
Here is the second part of my comments about Essap 2007.
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.
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.
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’è!
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.
These are my notes on the first days of this year’s European Summer School on Agile Programming (Essap.) It is a week-long school on XP and Agile, organized by myself and Federico Gobbo, with the Università dell’Insubria. It’s an event run entirely by volunteers. This is the second edition. Last year was a very successful event for me. I learned a lot, and gained a lot of confidence in my ability to teach and apply XP.
One of the things I was afraid of was that the Italian participants would keep speaking Italian, and leave our foreign students and speakers out of their conversations. This did not really happen; ever since the Welcome Pizza on Sunday, English was spoken all around. I’m proud of you!
Monday I arrived at the hotel De Filippi and picked up people. We arrived at the Villa in time for the opening session from prof. Aurelio Lanzarone, the head of the C.S. Dept. of the Insubria University. His speech lasted one pomodoro (that is, 25 minutes. The “pomodoro technique” is a time-management technique invented by Francesco Cirillo, that is fully described in the paper. “Pomodoro” is Italian for “tomato”. The name comes from the use of a tomato-shaped kitchen timer to mark 25 minutes periods. By the way, plural is “pomodori”). After that I gave a talk about values and practices in XP and Agile. I hope my love and enthusiasm for this topic came through; I had many positive comments in the standup meeting the next day. My talk lasted three pomodori, then there was a long pause for coffee.
After the pause, it was the turn of Rick Mugridge and David Hussman. Their talk was about “From Personas to Stories to Story tests.” It was a modified version of their talk about “Executable Documents” which they gave at XP 2007. I can’t express how grateful I am to Rick and David that spent more days away from their families to help our school. Thanks a million, guys! Now I read (most of) Rick’s book about Fitnesse, and I thought I knew a good deal about stories and acceptance tests; was I wrong! For one thing, I learned that a much better word for “acceptance test” is “story test”, which they tell me is an invention of Joshua Kerievsky. It sounds much better, and it’s much easier to pronounce for me. (Now please someone invent a new word for “fixture”, that Italians find almost impossible to pronounce! But i digress.)
Then David and Rick taught us about “personas,” which is a way to invent personalities that are like “characters” in user stories. To define a persona, invent a name and a title. For instance, “Mary the Hopeful” is a user of a job-finding application. Then sketch her face; just don’t draw the usual UML stick figure. Then describe her; what’s her personality? What does she look like? Finally, define what is important for her. This will help you define what stories will be most important for this persona.
The personas technique is very natural once you learn about it. Also the persona are very useful when it’s time to define story tests. It’s much more concise and precise to say “mary does this…” than to say “the job-seeking user does this…”. The personas then will become elements of test fixtures. It all fits very nicely. An example of personas in story tests is in Jamis Buck’s post on integration testing in Rails.
Rick and David used a lot the trick of “pairing” people. I know that managers all around the world take a dim view of “pair programming” (and they’re wrong!) One way to let pair programming in is to take away the word “programming.” In fact, pairing is a very useful thing to do in many activities (ahem.) What David and Rick did was to let us do simple exercises, of no more than 5 minutes, such as “define a persona”; every exercise was to be done in pair, and we were to always look for a different person to pair with. This is very effective in engaging the audience, in having them actually do the exercise well, and in getting to know other participants. One of the exercises was about writing story tests, and then turning them into Fitnesse tests by simply drawing boxes around words.
Writing story tests is one thing I never did. I knew about it in theory, but never got round to actually do it. Now that I saw people who do it well, I’m inspired to do it for real. It’s been the same for me with unit testing, with agile planning, and other things: I knew about them, but didn’t “grok” them. Kent Beck also describes this, when he pairs program with people who say “so you *really* never write code without a failing test?!?” :-)
Another thing I got from their session was how interactive they could make it. They made me feel like my style of making speeches is that of a penguin robot, never engaging the audience in doing anything. They got beyond the usual “how many of you have heard about X”. They actively encouraged people to interrupt with questions, saying that they would regard it a bad smell if noone interrupted :-)
Finally, I got the real sense of a community. These two persons are highly successful consultants and they did volunteer for this school. They did what they did with passion, and they looked like they were having fun. They said they appreciated our work at the school and they meant it. There is something about the XP and Agile community!
I got home very tired and happy. Kudos to Federico and Fabio who stayed up late with me sorting out the pieces of the XP Game! And to the people of the Varese XP User Group. They spent a lot of time preparing the basic application for the school project. This is a real gift economy.
Fabio and Federico were with me again today. I needed them to coach the XP Game, so I could not let them sleep in the car… I gave them a copy each of the XP Game manual :) We arrived at the Villa on time, and I asked Fabio to lead the morning stand-up meeting. We had agreed that instead of the canonical questions “what did you work on yesterday, what will you work on today, what problems do you have”, which do not really apply for the “work” at the school, we would ask “what did you learn yesterday, what do you expect to learn today, what problems do you have.” Fabio had this brilliant idea of not leading the meeting in the predictable circular order. Instead, he threw a colored pen to a random person in the circle, selecting him as the first person to speak. This way you stop people from thinking “three more people then it’s my turn” instead of listening to others speak.
The first standup was longer than one pomodoro, so the XP game started at 10:00 instead of 9:30. This is not a big problem, since we had allocated all morning to it. I spent one pomodoro explaning how the game works. Then we moved in the room with the big table and broke the audience in four teams. We had a great fun! The coaches were me, Fabio, Federico and Piero. Piero’s team won… This is the fourth time I present this game. I was careful to keep the participants’ attention on the meaning of the game. I think it’s a great vehicle to teach about planning and velocity. Yet someone mentioned, in the standup on Wednesday, that they got too wrapped up in the playing and the competition and winning! It’s all right folks, if you’re not engaged you don’t learn.
After lunch, we had Federico introduce Mind Maps. His presentation last year focused on the history of mind mapping, and the use of mind maps for personal use. This year he talked more about the use of maps in team, for brainstorming, and as an aid in the development of ubiquitous language for domain-driven design. More power to him! We realized how effective David and Rick were in using dialogue in their presentation. They keep the attention up, and get their point across more easily. I did not prepare anything of the kind with Federico, yet we improvised a bit of dialogue in the second part of his talk. I think it was a good idea.
The last work period was the first session for “JooB“, the school project. It’s a Job-finding web app, with a nice web-2.0-ish flavour. We split the participants in three teams; I lead the A team through brainstorming the user stories. Matteo F. wore the hat of the “customer” and got to answer the questions from the rest of the team. I think we did a good job; we used what Rick and David taught us about “personas” and identified a number of stories that related to them. It really is more effective to define “Rick the headhunter” and say “Rick posts a job offer” rather than “As a Head of Human Resources I want to post a job offer”. Jacek was very precise and coded every story with a progressive number, and the initial letter of its persona.
Note for next year: the first work period after lunch should *not* be a presentation; let us do something practical, or we’ll all fall asleep in the wonderfully crisp and perfumed air of June.
The day started well with the standup meeting. Today it was much faster than yesterday; we’re getting better at it. It took about 20 minutes, and the number of people is about 30. It’s very informative; unfortunately I keep forgetting to have my notebook handy. Some remarks are precious, and if you don’t write them down they’re lost. It took less than one pomodoro.
At 9:30, Carlo Bottiglieri led the session on Test-Driven Development. The first part of his talk was a very concise and to-the-point explanation of what TDD is. I think he got the idea across very well; my only suggestion is to use *way* more examples. Another thing that I really appreciated is the focus on design and refactoring. All too often TDD is explained in terms of “testing”, when it’s really about design. Carlo went through a very simple example of TDD in an object-oriented domain model class. He showed a test, and then the simplest code that could make the test pass. Then he started refactoring. The code he started with was *very* simple; it was amazing to see how much it could be further improved!
In the second part of his session, Carlo showed us a real world example. He took a Java web app he’s currently working on, and showed us how to add functionality to it with TDD. I’m afraid that the code was too complex though; it clearly was very simple to him, but it took him a long time to explain what he was doing, so that in the end he could only do one red-green-refactor cycle. Overall the example was too technical, and no meaningful suggestions could come from the audience. I think this presentation would have been excellent for a Java User Group, but a bit too advanced for the Essap audience. For instance, mock objects are an advanced topic. But one thing is clear: developing web apps in Java is painful, *expecially* if you use frameworks. On the other hand, developing tests for a Rails application is a snap!
Thank you Carlo for helping us! The participants asked a lot of questions, were engaged, learned about TDD *and* simple design. I’m very happy we had your session.
Today lunch took longer than usual, so we were ready to start again at about quarter to three. The first session in the afternoon was about planning the release for the school project. Yesterday we did brainstorm to find the stories, today the teams had to estimate them (on a 1-to-6 scale, much like the XP Game) and then have the “customer” prioritize them. I explained to the teams the value of time-boxing their activities, and asked them to arrive at a plan in no more than three pomodori. Which they did :)
In the second work period of the afternoon we were left with little more than two pomodori, which were spent on implementing the stories. I must commend the hard work of the Essap tutors, who spent two and a half days installing and checking the participant’s laptops. Last year we had plenty of technical problems with software installation; this year when coding started, it went really smooth.
I went around the rooms checking what the participants were doing, answering questions. I found that not everyone had understood what a “story test” is. I also helped people with Rails; but I saw too many puzzled faces.
At 18:00 the Villa closes down and we’re out. In the garden outside the villa I led a very short (10 minutes) retrospective. This was really thrilling to me: it was the first time I led one. I liked very much the brevity of it all. I followed the schema that David and Rick taught us the first day: I asked what worked today (and we should do more.) I had positive feelings about pairing. I agree with that. Then I asked what didn’t work. The main point that came out was that people knew too little of Rails. Then came the “actions” part. I proposed that I do some more Rails teaching, and distribute a few notes for people to copy. It was approved by many people. Not bad for ten minutes’ work.
Today we were not rigorous in our use of the pomodoro in the morning, and we came from lunch late, so that we worked only 6 pomodori in the morning and 5 in the afternoon. My feelings coming home: I’m totally exhausted, and I’m missing my buddies Federico and Fabio.
