REST per semplificare

July 26th, 2006

Summary: cool post by Scott Raymond Update 2011/06/08: backup copy on the Internet Archive

Scott Raymond scrive di avere adottato per il suo sito lo stile REST, in cui si cerca di modellare tutto in termini delle operazioni CRUD: Create, Read, Update, Delete. Si diminuisce drasticamente il numero di azioni, si aumenta il numero di risorse su cui queste azioni standard si applicano. Il bello è che queste azioni standard si mappano bene sui metodi di HTTP: POST, GET, PUT, DELETE. Questo permette di ridurre il numero di url necessarie. GET /users/3 significa dammi i dati dell’utente con id 3, mentre DELETE /users/3 cancella l’utente numero 3, ecc.

Rails è un eccellente design che si basa su alcune idee importanti: DRY, MVC, Convention over configuration, buon gusto. La nuova buona idea che si aggiunge a queste è REST, come DHH ha spiegato nell’ultima RailsConf.

Il bello è che come conseguenza di questo ulteriore vincolo di design, le applicazioni si semplificano. Raymond scrive:

So, by adding a few controllers, I cut the total number of actions by almost twenty. That’s a pretty big deal, because actions are like moving parts in a machine—the more there are, the more can go wrong. The fact that I could cut almost twenty actions indicates that there was a lot of redundancy hiding beneath the surface. …

Cutting actions is great, but even more significant is that the remaining ones are almost completely uniform. There are seven standard Rails actions: index, new, create, show, edit, update, and destroy. Everything else—oddball actions—are usually a clue that you’re doing RPC. … The upshot is that the controllers are very uniform, which makes the entire application conceptually simpler, and thus easier to maintain, test, and extend.

Finalmente!

July 16th, 2006

Summary: we’re running on WordPress.

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

Manual mocks can be valuable

June 23rd, 2006

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.

Incontro con Pascal Van Cauwenberghe

June 22nd, 2006

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!

Tirocini presso xplabs

June 22nd, 2006

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.

Memorable quotes

June 21st, 2006

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

Un cantico per Leibowitz

May 21st, 2006

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.)

Bush e la Libia

May 16th, 2006

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?

Chi possiede il tuo computer?

May 14th, 2006

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.”

Testing Extreme Programming

May 12th, 2006

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.