Archive for November, 2006

Linux è più veloce

Friday, November 24th, 2006

Summary: Linux is way snappier than either Mac OS X or Windows. So what else is new? :-)

Non c’è niente da fare. Avevo la sensazione che il mio amato MacBook Pro non fosse tanto snappy quanto desideravo e adesso ho capito perché. Ho installato Slackware su una macchina virtuale, e ho installato Rails dentro alla slackware virtuale. Eseguiamo ora un semplice test: time rails. Non fa quasi nulla, serve solo a vedere quanto tempo ci mette a caricare Ruby e Rails e ad eseguire dalla riga di comando. Il risultato: dentro al Linux virtuale ci mette 660 ms , mentre nel Mac OS che ospita la macchina virtuale ci mette 923 ms.

XP Day Benelux, the last day

Wednesday, November 22nd, 2006

Summary: second part of my report about XP Day Benelux

November 17

Again, it’s difficult to choose among many concurrent sessions. I choose Joseph Pelrine’s and Ben Fuchs’ presentation “Turning up the heat (without getting burned.)” Joseph is a coach and Scrum master; Ben is a psychologist. The idea is an analogy about cooking; when the temperature is too high, food burns; a team might get in bitter fights. At the right temp, the food is cooking, and so is a team. The cooking temperature might be higher than comfortable, meaning that *some* amount of discomfort might be good for team performance. If the temp is too low, the team stagnates and stops improving. Most geeks like me are introverts who will usually avoid conflict; we like “peace.” Yet peace might simply mean that conflicts are tacitly ignored and left unsolved.

So, part of the job of a coach is keeping the temperature of a team in cooking range. There are techniques for defusing destructive conflicts; and there are techniques for productively “destabilizing” a team. It all seems very delicate stuff to me; in fact Joseph recommends to go about it in an agile way: try a small change and evaluate the results in a short iteration. All in all, an amazing presentation; I wish I could know more about this, but it seems a very deep subject, quite unlike anything I’ve been prepared to handle. The most important thing I think I got from this is more confidence in handling conflict in the workplace. Another important thing is “don’t play psychologist”; just like you wouldn’t want a psychologist to write your software.

In the afternoon, I attended Steve Freeman‘s and Mike Hill’s “Telling stories with Fit”. Nice introduction to the complexities of turning waterfall-ish specs into nice Fit tables. The audience was split in teams of five people. Each team was given a spec; ours was about computing fares for a rent-a-car service, and it had more than enough special cases and arbitrary complexities. We had to explain the spec by means of tables, written with a felt pen on a large sheet of paper. After 15 minutes, a presenter from each team had to take the sheet and take it to the next table, to see what the other team could get from it. Then the presenter had to turn their back on the table, and the team was asked to criticise brutally :-) while the presenter takes notes. Unfortunately I could not attend to the end of the presentation; but I think I learned quite a lot about Fit in a very short time.

We still had a little time before our taxi came, so we peeked a little in Pascal’s presentation about “Presentation Zen.” It’s all about effective presentation, and it seems like powerpoint bullets are heavily démodé. Pascal showed us videos from some impressive presenters, like Lawrence Lessig. I can see how powerpoint can get very tiresome. Yet some good presentations I attended in these two days used bullets. I guess that in the end, having content behind the slides is still a deciding factor :-)

Conclusion

One thing I liked was the heavy use of 1-minute presentations. In the morning, the presenters got to present their own stuff in a minute, to help you decide which presentation to follow. At the end of the day, there was a one-minute debriefing given by someone in the audience, about each presentation. Pascal’s blog contains much other interesting notes about the process of selecting and then refining the presentations.

I think it was very much a worthwile trip. I got a lot from it, both about content and about format. The organization was very professional in all respects. The atmosphere was nice, friendly and knowledgeable. Can’t wait for the next time!

XP Day Benelux: the report

Monday, November 20th, 2006

Summary: my report of the XP Day Benelux.

November 15, the arrival

I arrive with my friend Uberto to Charleroi airport in the morning. Pascal is so kind to pick us up and take us to Bruxelles on his sleek coupe. We have a nice meal right in the center of the old town, then we meet Philippe who takes us for a long walk around town. Then Pascal takes us to the conference center, a nice hotel in the middle of the autumn Belgian country. In the evening we meet again with them and a few other participants for a dinner in the nearby town of Mechelen. I have too much Belgian beer! Very nice evening.

Willem tells me “if you’ve come here to listen, you’ve come to the wrong conference.” And boy, was he right! Almost all the presentations I attendend in the next two days involved the participants to do some work.

November 16, first day

There’s so many different presentations to attend, and many are run in parallel! It’s a difficult choice. In the morning I attend the Coding Tournament by Markus Hjort and Lasse Koskela. It’s about writing a bot for an online game, and trying to do that in a way that is both XP, and is better than everyone else’s bot. The game is a simplified version of poker. There are a Java and a Ruby toolkit; in principle any language could be used, as long as you speak the right protocol to the Poker server. In practice there’s not enough time to write networking code. If you take the Java or Ruby route, all you have to do is implement an interface; no networking is required.

The rules of the game are simple: you are given a single card, but you can’t look at it. You can only look at everyone else’s cards. Each organizer demonstrated this by holding a card up to his forehead so that everyone but him could see it. Then a round of betting starts. Each player has a choice of staying, folding, or raising the bet. The betting stops when everyone has stayed or has folded. The point of the game is that you must base your decisions on what everyone else has, and how the others are betting.

My pair was Pascal Vogel from Philips, (Hi Pascal!) who doesn’t usually do Java; he knows C# though, and that is enough. We decide on a simple strategy, and write an acceptance test in JUnit for it. Then, we comment out the failing acceptance test, and TDD our way until the AT works. The idea is simply to look at the average value of everyone else’s cards, and fold if the average is high, and stay if it is low. This is more than enough to win a few games against the other bots.

Later we improved on this strategy by raising the pot when the average of everyone else’s cards is very low. Again, first we improved the AT, then we TDD’d until the AT was green.

Yes, it’s a very simplistic strategy. Yes, it may even be wrong (why take the average? The highest card may be more important.) Yet, this strategy won the final tournament! Yep, we won :-) It’s quite a challenge to implement correcly even as simple a strategy as this in about three hours. I don’t think we could have done it as well without TDD. It was tiring work, but not stressful.

My impression is that the choice of the rules is excellent. It’s complicated enough to make it interesting, yet simple enough that you can write a simple bot in the given time. The API you have to code to is adequate. I’m not so convinced about the format of the event though. The idea was to explain the game, and then do four iterations composed of 15′ coding and a 5′ bot tournament. After the fourth iteration the real tournament starts.

I was expecting something more along the lines of “now we coach you to do proper AT’s and proper TDD and proper pairing,” but we were more or less left to our own. Perhaps the organizers saw we were chugging along just fine, and spent their time coaching the other pairs. I was also expecting to be given some intermediate goals other than “write the best bot.” Something like, “first write a bot that always stays; then write a bot that folds when someone else has an ace”. I think the format of the presentation could be improved along these lines. I was given permission by Markus and Lasse to replicate the event, and I intend to try it with my local XP user group. Thanks guys!

In the afternoon I followed Vera Peeters presentation about simple design. It’s about how software can be made simple by not implementing unneeded features. The case in point were unit testing frameworks for C++, and how Vera got along fine with a tiny framework of her own, that was essentially just a few macros. After a brief presentation about what is good design, Vera asked us to form groups of five to six people. Then she had us write down on cards features of testing frameworks in general. Then she had us estimate how useful that feature is to us, and how well supported it is in our favourite testing framework. This allowed us to plot each feature on a graph and see how features are clustered. Finally, each group had to select a presenter to discuss and relate their findings. I found the whole experience interesting, both because of the subject matter, and because of the way the event was run. Quite unlike any conference I’ve been before!

The last presentation I attended was “A Fugue about Paradigms and Functional Programming”, by Emmanuel Gaillot & Christophe Thibaut. It was basically a coding kata done in Haskell. It is clear how skilled the two are at doing these public kata; the dialogue between the two was interesting and witty. Also the cheers at every green bar were fun! I haven’t done functional programming in a long time. It’s nice to see how clear and concise a functional program can be. The final program was a composition of functions; it involved very few variables, and no control structures except recursion (and it was very simple recursion.) The use of pattern matching pretty much does away with conditional statements. Getting rid of control structures is a worthy goal in code style, IMO. A great many important topics were demonstrated in very little time; interested people should definitely get a book about functional programming. The point of the exercise was also to pitch for a more functional style of programming, even when we program in non-functional languages. Modern languages like Ruby make it easy to do so.

In the evening, we are treated to a fine Belgian dinner. I manage to drink less this time!

Stay tuned for my report of the next day…

Boccioni, futurista

Saturday, November 4th, 2006

Summary: the Boccioni exposition in Milano is very nice

Ho appena visto la mostra di Boccioni al Palazzo Reale; sono molto contento. Il tema è Boccioni scultore; salta fuori che l’attività di scultore si è limitata a pochi mesi, nei quali ha prodotto poco più di una dozzina di sculture, molte delle quali oggi perdute. In mostra c’è il famoso omino in movimento, quello che appare sulla moneta da 20 centesimi, e lo “Sviluppo di una bottiglia nello spazio.”

Boccioni - Forme uniche della continuita nello spazio

Ci sono anche molti disegni e alcuni dipinti bellissimi. La creatività e l’energia dei primi dieci anni del novecento dove sono adesso? Boccioni dipingeva, scolpiva, sfidava le avanguardie parigine sul loro terreno (la natura morta con bottiglia…) scriveva libri, teneva conferenze… E ogni cosa pareva dare uno spunto per idee nuove. La stessa idea che il pittore dovesse celebrare la bellezza femminile gli dava l’idea per l'”Antigrazioso”, per cui la bellezza canonica veniva di proposito evitata (e sbeffeggiata!)

Boccioni - Sviluppo di una bottiglia nello spazio (Milano, 1912).jpg

Divertente il suo “Manifesto tecnico della scultura futurista”, che inizia con

La scultura, nei monumenti e nelle esposizioni di tutte le città d’Europa, offre uno spettacolo così compassionevole di barbarie, di goffaggine e di monotona imitazione, che il mio occhio futurista se ne ritrae con profondo disgusto! Nella scultura d’ogni paese domina l’imitazione cieca e balorda delle formule ereditate dal passato, imitazione che viene incoraggiata dalla doppia vigliaccheria della tradizione e della facilità.

Sembra quasi di sentire parlare un ardente sostenitore dei metodi agili:

Il software, nelle aziende e nelle università di tutte le città d’Europa, Asia e America, offre uno spettacolo così compassionevole di barbarie, di goffaggine e di monotona imitazione, che il mio occhio agilista se ne ritrae con profondo disgusto! :-)

Unica nota di demerito: non c’era in vendita neanche un manifesto, eccetto la locandina, troppo scarsa perché mi venga voglia di appenderla in casa. In compenso, milioni di manifesti di Tamara De Lempicka, che fanno un effetto molto volgare dopo aver visto tutti i Boccioni.

Insomma, nei primi del novecento l’arte figurativa veniva rivoltata come un calzino dagli artisti europei (e russi); come anche la musica. La matematica veniva scossa nelle sue fondamenta dai paradossi portati alla luce dalla logica. La fisica veniva ribaltata dalla relatività, e poco dopo dai quanti. Vedremo mai un periodo simile a quello?

To mock or not to mock

Friday, November 3rd, 2006

Summary: nice paper by Jeff Langr on the subject of mocks

Pubblicato oggi nella sezione file della lista http://groups.yahoo.com/group/testdrivendevelopment/

No perfect way to implement mocks exists. … This should suggest that while mocks can be useful in testing, they introduce other issues into a system … Mocking is still an extremely valuable tool. Slightly imperfect design is almost always the better choice over the inability to test. But the rule for mocking is still, don’t… unless you must.

Langr esprime alcune perplessità che ho sempre avuto sui mock, ma che non ero in grado di spiegare bene. Introdurre un mock comporta sempre una modifica al design del sistema, che non sarebbe stata introdotta se non per il testing. Io sono sempre dell’idea che vale la pena di introdurre modifiche nel codice, se sono necessarie per testarlo. Qualsiasi circuito integrato contiene della circuiteria che ha il solo scopo di testarne il funzionamento. Jeff discute le possibili alternative: passare l’interfaccia da mock-are nel costruttore, con alcune varianti, oppure la soluzione preferita, il deferred factory-based mocking..

Sono d’accordo con le conclusioni di Jeff:

  • Meglio usare i veri collaboratori di una classe, se possibile, piuttosto che un mock.
  • Non usare i mock come scusa per non sforzarsi di trovare un design meno complesso
  • Preferire lo state-based testing al test basato sulle sequenze di chiamate attese; quest’ultimo rende difficile il refactoring
  • meglio usare un mock fatto a mano, piuttosto che un jMock o simili