Extreme Enthusiasm

Summary: we’re running on WordPress.

Ho installato un nuovo blog basato su WordPress. Finalmente riabilito la funzione di commento.

Summary: replacing a jMock with a hand-crafted fake led to an absurdly simple, and better, solution

L’altro giorno ho dovuto portare un progetto Java su un nuovo PC, sul
quale non era installata una versione molto recente di Java. Ho
scoperto allora che l’ultima versione di jMock richiede Java 1.5.
Visto che in quel progetto usavo un mock solo, piuttosto che scaricare
e installare un nuovo JDK ho provato a mockare manualmente; cioè ho
definito una

 class FakePdfWriter implements PdfWriter {
 }

e ho lasciato che Eclipse generasse stub per tutti i metodi
dell’interfaccia PdfWriter. Poi ho aggiunto alcuni campi per
registrare quali chiamate erano state fatte, tipo

 class FakePdfWriter implements PdfWriter {
  public List strings = new ArrayList();

  public void writeThis(String text, int llx, int lly, 
                               int urx, int ury) {
     strings.add(text); // don't care about coords
  }
 }

Devo dire che il risultato alla fine, anche se non era preciso come un
jMock, era più flessibile e facile da usare. Da quando ho questo fake
l’ho usato per supportarmi in una serie di altri test che prima ero
riluttante a scrivere. La soddisfazione è che in confronto a jMock è
assurdamente semplice…

Aggiornamento: c’è un articolo Unit Testing With Hand Crafted Mocks su questo argomento.

Summary: if you really want to learn XP, apply for an apprenticeship at xplabs

Francesco Cirillo, CEO di xplabs, mi segnala la possibilità di fare un tirocinio presso la sua azienda, a Sutri in provincia di Roma. Francesco è probabilmente il primo XPer italiano, e ha imparato XP dalle fonti primarie (Beck e compagni). Ha interiorizzato l’arte e, da maestro, l’ha integrata con contributi personali. E’ coltissimo e al tempo stesso una persona molto piacevole con cui stare.

Se siete giovani e avete passione per imparare, non posso che incitarvi: andate da XP Labs! Fatevi prendere! Gli studenti dell’Insubria possono fare valere il tirocinio come stage.

Francesco è uno dei docenti della nostra prossima scuola estiva a Varese.

Per chi non partecipa alla Essap, c’è la possibilità di ascoltarlo alla Java Conference il 27 giugno a Milano.

Summary: on July 5 the Milano XP User Group will meet Pascal Van Cauwenberghe. The meeting is 19:00, hosted by D&T in Largo Promessi Sposi�4. All XP/Agile fans are invited!

Il Milano XP User Group organizza
una riunione il 5 luglio per incontrare Pascal Van Cauwenberghe, un agilista molto attivo e fra l’altro coinventore dell’XP Game. Pascal sarà in zona perché è uno dei docenti della scuola estiva ESSAP. Speriamo che tutti gli appassionati di XP/Agile riescano a fare un salto! Il luogo è la sede di D&T, Largo Promessi Sposi�4 (vedi volantino).

L’ora è le 19:00, il programma da definire.
Seguirà cena presso il vicino ristorante-pizzeria cinese. Tutti i curiosi e gli appassionati sono invitati!

Summary: a few things worth remembering

il ritmo più “naturale” viene perso facilmente; soprattutto quando si avrebbe proprio bisogno di prendere un attimo per schiarire le idee.
Una cosa del tipo: “no, no, adesso non posso, sono troppo dentro questa cosa”
… appunto, proprio per questo dovresti fare un attimo di pausa.

Simone Genini, sulla mailing list del Milano XP-UG

How do you balance work and family?? You don’t balance it, you go home!

There is no ‘more time’: it’s just [a matter of] using your time more effectively

Letto sul blog di PierG (anche in italiano)

If we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”

E.W. Dijkstra, On the cruelty of really teaching computer science

Summary: A canticle for Leibowitz by Walter Miller Jr. is a very good book. I often think about this story now that small and big countries are hot on nuclear weapons again.

E’ uno dei pochi romanzi di fantascienza che viene correntemente letto da non-appassionati di fantascienza. Scritto negli anni ’50, narra la storia di come la Chiesa Cattolica sopravvive, insieme a pochi scampoli di umanità, a una guerra atomica su larga scala. E’ una storia che mi torna in mente spesso, in questi tempi di tentazioni nucleari di Paesi piccoli e grandi.

Piergiuliano mi ha segnalato una Guida alla lettura in Italiano (attenzione: spoiler.)

Grande fondo di Magdi Allam sul Corriere di oggi.

La decisione americana di ripristinare le relazioni diplomatiche con
la Libia di Gheddafi … Con un brusco rimescolamento delle carte,
Bush ha sostanzialmente infranto il sogno di una rivoluzione democratica.

Tanto parlare della Guerra Al Terrore, e poi si fa la pace con il
terrorista Gheddafi, dittatore e sponsor della strage di Lockerbie.
Perché pace con Gheddafi e guerra con Saddam? Perché i princìpi si
possono invocare o ignorare secondo capriccio?

Just because computers were a liberating force in the past doesn’t mean they will be in the future. There is enormous political and economic power behind the idea that you shouldn’t truly own your computer or your software, despite having paid for it.

Bruce Scnheier, Everyone Wants to ‘Own’ Your PC

+5, Insightful. “Quando la tecnologia serve i suoi padroni, è
libertaria. Quando è progettata per servire qualcun altro, è
oppressiva.”

Ricordo una discussione che ebbi con Yuri Gurevich a proposito della linea di ricerca che seguivo, ai tempi in cui ero studente di dottorato. Lui mi attaccava dicendo che il mio lavoro sulla derivazione di programmi non valeva nulla, in quanto non è possibile definire il successo. Gurevich era particolarmente veemente nei suoi attacchi in quanto apparteneva a una parrocchia di ricerca diversa; in sostanza non apprezzava la tradizione di Dijkstra quanto l’apprezzo io. Gli tenni testa (di fronte agli altri studenti di dottorato che ci osservavano un po’ stupiti, non capendo il perché dell’animata, per quanto civilissima, diatriba.) Ma in sostanza sulla sua obiezione “non puoi definire il successo, quindi anything goes” non gli seppi dare, credo, una buona risposta.

Una discussione che c’è stata in pizzeria ieri sera, dopo la riunione del gruppo di Extreme Programming, mi ha fatto venire in mente argomenti che avrei potuto opporre, ancora più validi. Gabriele mi ha detto: “e i letterati, come fanno a stabilire il successo? Non fanno anche loro ricerca?”

Pensiamo un’attimo a tutte le cose che hanno senso e importanza in informatica, anche se non si riesce bene a quantificare questa importanza. L’eleganza e l’espressività di un linguaggio di programmazione, ad esempio. Ho conosciuto persone che mi hanno detto “ho fatto la tesi sul progetto di linguaggi di programmazione, ma non mi occupo più di quelle cose, perché il valore di un linguaggio di programmazione è una questione di giudizio soggettivo”.

La informatica, intesa come scienza, ci dice che possiamo scrivere qualsiasi programma usando qualsiasi formalismo, comprese le famose macchine di Turing. E’ un fatto scientifico. E’ un fatto altrettanto vero e tangibile, però, che nella realtà non possiamo scrivere programmi significativi nel linguaggio delle macchine di Turing, e infatti nessuno lo fa. La dimensione dei programmi, sia applicativi che di sistema, aumenta in termini di linee di codice di circa un ordine di grandezza ogni decennio. Come è possibile ciò? Dipende forse dal fatto che i linguaggi di programmazione effettivamente migliorano… E’ un fatto che Java è un linguaggio di programmazione migliore di C per scrivere i programmi gestionali. E’ un fatto che Java 1.5 è un linguaggio migliore, per molti versi, di Java 1.4. Come puoi provarlo? Io lo posso argomentare; ma non in maniera precisa, quantitativa.

I letterati possono senz’altro stabilire il successo, ovvero il valore, di un’opera d’arte. Ci potranno essere opinioni divergenti su alcune cose; correnti di pensiero. Strawinsky piuttosto che Brahms. Haskell piuttosto che Smalltalk. Gli argomenti pro e contro possono essere molto tecnici! E anche molto soggettivi. In nessun caso però si riesce a stabilire numericamente una superiorità.

Quindi in sostanza, occuparsi in accademia di argomenti come l’eleganza di un linguaggio di programmazione, o l’eleganza di uno stile di derivazione di algoritmi è estremamente frustrante, perché la comunità scientifica si aspetta da te che tu possa fornire una misura oggettiva del progresso che il tuo lavoro costituisce rispetto al passato. Questo conduce gran parte della ricerca in informatica ad occuparsi di questioni essenzialmente irrilevanti, tipo migliorare di un epsilon la complessità asintotica di un algoritmo che nessuno userà mai, che risolve un problema che nessuno ha bisogno di risolvere. Tipo l’ubriaco che cerca le sue chiavi sotto il lampione, perché almeno sotto il lampione c’è luce.

Ci sono tanti problemi difficili e rilevanti in informatica che non ammettono una misura matematica di successo. Iniziamo ad accettare il fatto che il valore di molte cose può essere discusso in termini di eleganza e bellezza. Un esempio: il kernel di Linux pare bellissimo a taluni, orrido a talaltri, ma Torvalds ha sempre detto che il suo principale criterio per selezionare i collaboratori è il buon gusto dal punto di vista tecnico.

As to how to solve the complexity problem, so far the real solution has been good taste.

… I mean a lot of patches end up getting rejected because they’re ugly. And a lot of patches end up getting accepted because they clean up certain things.

… the maintainers were having nightmares with ifdefs, and saying “I can’t manage this any more, so we need to clean it up.” And people did. Good taste. Ifdefs are bad. Fix them. Not, “Okay, let’s have tools that verify that we use them correctly.” See? That’s the difference.

Ho appena finito di leggere Testing Extreme Programming di Lisa Crispin e Tip House.

Descrive il ruolo dei tester in un team XP. Si concentra quindi sugli acceptance tests. Per me gli AT erano un po’ misteriosi; sono riuscito a praticare bene gli unit test, ma gli AT li ho sempre un po’ trascurati. A volte con risultati disastrosi: una mia debacle è stata dovuta, fra l’altro, al fatto di non avere pronti degli AT che dimostravano che gli interventi tecnici fatti da qualcun’altro sul nostro progetto avevano distrutto 90% delle storie funzionanti. Ma sto divagando.

Il grosso del libro è discorsivo e spiega il ruolo del tester nelle varie fasi del progetto XP. La parte che per me è stata più utile sono invece i brevi capitoletti su come tecnicamente realizzare gli AT. Lo stile che viene presentato qui è assurdamente semplice, e per questo mi piace molto!

In pratica gli AT vengono realizzati con JUnit, con la differenza che si cerca di renderli il più possibile vicini al linguaggio del cliente, con cui sono espresse le user stories. Ho cercato di applicare questa lezione nel progettino che stiamo realizzando nell’XP user group di Milano.

Per esempio, la user story Pagina contenente le news ha un test di accettazione che dice, in italiano:

IF una news è presente nel sistema THEN appare nella pagina

Riscritto in JUnit diventa:

public void testIfInseritaThenAppare() {
  insertNews("Titolo", "Testo testo testo", 
             insertedToday(), expiresTomorrow());
  assertEquals(1, numberOfNewsInPublicPage());
  assertNewsPresent("Titolo", "Testo testo testo", 
                    insertedToday());
}

Forse si può migliorare ancora, ma mi sembra che il codice parli a sufficienza.

UPDATE: Gabriele (sempre lui!) mi ha segnalato questo articolo: Literate
Programming with jMock. Molto carino: presenta tecniche su come
rendere gli acceptance test sempre più parlante, sempre più
vicino a qualcosa che si legga come lingua naturale.

Non sono convintissimo che sia questo però quello che Knuth aveva in
mente quando parlava di literate programming. Lui si preoccupava
soprattutto di cose come il fatto che i commenti fossero dentro al
codice, piuttosto che essere il codice dentro a un documento
leggibile dagli esseri umani. Giustissimo! Ad esempio, anche se il
codice di un dato programma è scritto benissimo, in generale non è
chiaro da dove mi conviene iniziare a leggerlo. In literate
programming, l’autore prepara un percorso di lettura ideale, che non
necessariamente parte con il main.

L’ideale di codice parlante degli XPer invece è una cosa diversa.
Si tratta di limare e ripulire il codice fino a quando non
c’è bisogno di altri commenti. Il codice di Knuth non è
esattamente leggibile. Anche il linguaggio TeX, che Knuth ha
inventato, è molto poco leggibile. Credo che gli XPer facciano cose
che sono nello spirito di LP, ma molto diverse nell’esecuzione.