Franco Lombardo

E' da qualche giorno che sulla lista italiana di "Exteme programming" infuoca una polemica su cosa sia XP, chi abbia il diritto di darne una definizione e quale definizione se ne debba dare. Non so perché, ma tutte queste discussioni mi fanno tornare in mente un brano dell'Apologia di Socrate. Ecco cosa Platone fa dire a Socrate.

E se qualcuno vi ha ancora detto che io faccio l’educatore e che ne ricavo gran guadagno, neppure questo è vero. Riconosco certo che è bello essere capace di educare gli uomini, come un Gorgia Leontino, un Prodico di Ceo, o un Ippia di Elide. A costoro è concesso, o Ateniesi, di andare di città in città e di attirare al loro insegnamento i giovani, i quali invece potrebbero benissimo, senza spendere nulla, frequentare l’insegnamento di quei concittadini che volessero scegliersi; quelli invece sanno persuaderli ad allontanarsi da questi e a venire loro, a pagarli profumatamente e a mostrare anche la dovuta gratitudine. Che dico? E’ venuto qui fra noi un sapiente uomo, un cittadino di Paro, come ho potuto apprendere per avere io parlato con uno che con i Sofisti ha speso più denaro che tutti gli altri messi insieme, Callia precisamente, il figlio d’Ipponico. Voi sapete che egli ha due figli; ebbene io ho voluto interrogarlo:
-Callia [...] A chi dunque è bene affidare [i giovani]? Chi è abile a sviluppare in loro le virtù proprie dell’uomo e del cittadino? Suppongo che tu ci abbia molto riflettuto, poiché hai dei figli. C’è qualcuno che ne sia capace o no?
-Certamente, mi rispose.
-E chi è costui, chiesi, e di quale paese è, e che prezzo chiede per il suo insegnamento?
-E’ Evèno di Paro, o Socrate, mi rispose, e chiede cinque mine.
-Felice Evèno, pensai io, se veramente possiede quest’arte e l’insegna a così modico prezzo! Anch’io mi sentirei fiero e felice se sapessi fare altrettanto; ma io non so, o Ateniesi.

Anche noi, come gli Ateniesi di oltre due millenni fa, ci troviamo nelle condizioni di dover distinguere gli insegnamenti dei sofisti da quelli dei socratici. Alcuni indizi potrebbero forse aiutarci.

• Il sofista è colui interessato più al guadagno che alla ricerca della verità.
• Il sofista annuncia agli altri di conoscere la verità, il socratico dichiara solo di ricercarla.
• Il sofista vuole imporre la propria autorità, al socratico l'autorevolezza è data dagli altri.

In base a questi criteri, in me molti dubbi sorgono su alcuni presunti "guru"....

All you know that TDD has god side effects. One of them is testing your application Another one is to force you to write less verbose code.
Sometimes (only sometimes ) when you write production code not writing tests (oh, well I do not do that, ehm) you accept that the code is not as concise and "speaking" as it should be: after all you are writing code that does its dirty work (maybe), that's enough!!! But when you write tests, you know that the goal of test code is to speak to other people. In other words, my attitude when I write production code is to write code that speaks to the machine, while when I write test code I'm trying to speak to people, and you know, when you're speaking to human beings you can't bore them. So your writing must be clear and concise. In order to do that, sometimes you're forced to write some helper classes that, after a short while, you'll find useful on the production side too.

I translated in English the presentation on Scala I gave to the XP User group of Bergamo:

As I said in a previous post, even if Scala is at the moment the best candidate to become the Next Big Language, I think that many things in its syntax are Byzantine and error prone. The examples in Klaus' comment are very explanatory in this sense.
In my search of the Holy Graal of the programming languages, I met Fantom (previously known as Fan), a very interesting attempt to create a language simple yet powerful.
First of all, let's have a look at a Fantom version of the semicolon inference example of my previous post. Note that, since I'm an absolute beginner in Fantom programming, the use of the language I made is far from optimal: any suggestion will be appreciated.

class GoodFantom {  

  static Int subtract1(Int a, Int b) {
    a -
    b
  }  

  static Int subtract2(Int a, Int b) {
    a
    - b
  }  

  static Void main() {
    echo(subtract1(10, 2))      //Prints 8
    echo(subtract2(10, 2))      //Prints 8 too!
  }
}

The Fantom way to handle statements ending seems pretty good. Anyway, I'm not sure that there are not drawbacks to this approach: again, any suggestion is welcome.
Now let's see how this example of creating a DSL fragment in Scala could be translated in Fantom.
So, let's define a Loop class:

class Loop {
  //Constructor that accepts a function without parameters that returns Void
  new make(|,| body)
  {
    this.body = body
  }  

  Void unless(|->Bool| cond)
  {
     body.call()
     if (!cond()) unless(cond)
  }  

  |,| body
}

Then we use it in our code:

using fanExercise::Loop  

class Main
{
  static Void main()
  {
    Int i := 10
    Loop(|,|
	{
      echo("${i--}")
    })
    .unless |->Bool| {i == 0}
  }
}

We can see that the Fantom version is slightly more verbose than the Scala one (even if, as I said, maybe a good Fantom programmer could do better), but, as the dot is mandatory in method calls, I think it's less error prone.

I know that AS400 gives its own native support to Tomcat and other application servers, but it does it in the IBM style: intricate and rigid. What if, for example, I need to use a version of Tomcat that it is not shipped with my operating system?
Here is one possible answer:

1) Download a copy of Apache Tomcat and unzip it in a directory of the Integrated File System of AS400.

2) In another directory of the Integrated File System Create a text file named tomcat with a simple script like this:

#The path of the JDK you want to use
export JAVA_HOME=/QIBM/ProdData/Java400/jdk14  

#The JVM option you want to use
#In this example -opt0 means 'no optimization'
export JAVA_OPTS='-opt0 -Djava.awt.headless=true'  

cd /path/to/my/tomcatdir/bin
catalina.sh %1

3) In a 5250 session (or in a batch job) execute this command

QSH CMD('/path/to/my/script/tomcat run')

Your Tomcat should be alive and kicking

4) In order to shut down Tomcat, use this command

QSH CMD('/path/to/my/script/tomcat stop')

Enjoy with Tomcat and AS400!!!

Un altro Agile Day è passato ed eccomi nuovamente a scrivere un sommario della mia esperienza.

Peter Stevens - Fixed Price Projects With Agile – It can be done!

Possiamo stimare a priori tempi e costi di un progetto agile? Possiamo applicare i metodi agili quando il costo ed il tempo sono scolpiti nella pietra? Certo, sarebbe bello poter vivere in un mondo in cui tutti i contratti fossero tagliati sul concetto di iterazione, di sviluppo incrementale. Purtroppo ci sono occasioni nelle quali dobbiamo stimare i costi, nei quali dobbiamo sapere se riusciremo a rilasciare entro una certa data, magari remota. Chi, ad esempio, sviluppa il software per gestire grandi eventi come i mondiali di calcio non può chiedere di spostare la data della finale perché lavora in un team agile e ha bisogno di una nuova iterazione per completare le storie!

Peter Stevens ritiene che lo sviluppo agile si possa adattare a queste situazioni, anzi che sia il miglior metodo da adottare. Questo perché è l'unico sistema per valutare in corso d'opera la velocità alla quale lo sviluppo si sta svolgendo.

• un cliente del quale fidarsi;
• una pianificazione che lasci "cuscinetti" liberi nei quali compensare eventuali ritardi;
• criteri certi (e automatizzabili) per determinare quando una funzionalità è conclusa;
• criteri per stabilire l'importanza delle varie funzionalità per realizzare prima le storie più importanti e consegnare alla fine del progetto, quando la pressione è maggiore e le energie si esauriscono, le funzioni di minor rilievo;
• un team esperto.

Maggiori dettagli sulla presentazione si trovano qui.

Alberto Brandolini - Possiamo fare di meglio

La presentazione mattutina di Alberto Brandolini è partita da una serie di provocazioni ad effetto sui seguenti temi.

• Spesso si rompe il rapporto di fiducia tra il software e chi lo usa, sia egli un utente finale o chi fa parte dello stesso team di sviluppo. Scatta allora il meccanismo della "complessità compensativa", cioè degli strani trucchi per aggirare i comportamenti errati dei sistemi.
• A volte gli sviluppatori accettano passivamente i requisiti che sono dati loro: ma chi dà questi requisiti è il vero esperto del problema, o, se lo è veramente, ha avuto modo di pensare ai requisiti in maniera critica? I requisiti non sono in alcuni casi semplicemente la mummificazione di un processo che potrebbe essere invece migliorato?
• Nei progetti software può nascere quello che è stato definito "technical debt". Brandolini suggerisce una metafora più calzante per questa progressiva deriva nella qualità del codice: inquinamento, ovverosia un processo estremamente dannoso, difficilmente reversibile e con un tempo di riparazione incalcolabile.
• A volte lo sviluppatore non ha abbastanza umiltà per capire di dover approfondire il dominio da un punto di vista non semplicemente informatico.

Dopo aver introdotto questi spunti di discussione, Brandolni ha lasciato la parola all'uditorio. L'esito di questo esperimento di "terapia di gruppo" a mio avviso non è però stato brillantissimo: purtroppo non è emerso molto di interessante, se non una collezione di aneddoti sul nostro lavoro.

Pietro Brambati - ASP.NET MVC: Programming & Testing

Dato che prima del pranzo non mi sembrava vi fossero relazioni degne d'interesse, mi sono infilato nell'auletta dedicata alla presentazione dell'ambiente di test creato per .NET MVC. Io odio gli strumenti di sviluppo Microsoft!!! Questo mio sentimento nacque anni fa quando Visual Basic 6, con un fantastico "Il controllo OCX non è registrato correttamente", mi fece affogare in un oceano marrone nel bel mezzo di una demo ad un centinaio di persone. Nonostante questo, mi è sembrato che il supporto di Microsoft ai test unitari sia discreto e che l'oratore, molto preparato, sia riuscito a dare a i colleghi della sponda Microsoft un buon numero di informazioni utili su come scrivere codice in modo più efficace. L'impressione comunque è che con questo prodotto Microsoft stia svolgendo un diligente compitino per conquistarsi la medaglietta "agile" e la relativa fetta di sviluppatori.

Alberto Quario - Scenario testing

Questo è forse stato l'intervento più interessante della giornata. All'Agile Day si è molto parlato di processi, ma ci si è un poco scordati del codice. Alberto Quario ci ha riportati nel cuore del problema, citando le parole di Gerard Meszaros: I test possono diventare il collo di bottiglia dei processi agili. (Ma allora non le sparavo così grosse quando parlavo dei test come palle al piede!). Uno dei principi da seguire per evitare che i nostri test divengano dei mostri incomprensibili, difficili da scrivere, leggere e manutenere è il seguente: nel corpo del test deve andare tutto e solo quanto è strettamente necessario per la sua comprensione.

Alcuni consigli sono quindi:

• radunare in metodi dal nome esplicito (operational methods) i dettagli di inizializzazione dello scenario del test
• se il test prevede, come nel caso si utilizzi DBUnit l'uso di file di inizializzazione, magari in XML, parametrizzarne la creazione rendendone chiaro l'intento all'interno del test

Francesco Mondora: vivere in un angolo proattivo

Francesco Mondora nel corso della sua presentazione ha detto di apprezzare eventuali riscontri da parte del pubblico. Ecco quindi il mio, che è purtroppo negativo. Il tema trattato mi è apparso fumoso, ed il tono ieratico utilizzato era probabilmente fuori luogo. Ma forse il problema è solo mio che non sono riuscito a capire cosa si volesse comunicare...

Alberto Brandolini - Introduzione al Domain Driven Design

Ecco un'altra gran bella sessione, nella quale Brandolini ha descritto con abilità e preparazione i principi del Domain Driven Design.

Entrare nel dettaglio di quanto visto è molto difficile, data la mole di informazioni trasmesse. Mi piacerebbe comunque segnalare il concetto di Bounded context, ossia il limite entro il quale il significato di un'astrazione del dominio è non ambigua, o, per usare una visione più orientata al codice, il limite di applicabilità di un gruppo di classi del sistema. Mi sono imbattuto in questo problema quando, nella mia presentazione su Scala, ho parlato di oggetti che ingrassano a dismisura. Da quanto ho capito, anche nel DDD ci si occupa di questo problema, ma da una prospettiva "sistemica": occorre definire l'ambito entro il quale è opportuno riutilizzare il codice che definisce un'astrazione. All'esterno di tale ambito è meno costoso riscrivere parte delle astrazioni ed accettare una certa duplicazione nei sistemi. Il tema, interessante e complesso, è alla base del fallimento di grandi utopie Object Oriented come il progetto San Francisco di IBM. Anzi, a mio avviso mette in discussione tutti i miti dell'Object Orientation a partire dalla riusabilità, ma forse converrà parlarne in un'altra occasione.

Conclusioni

Anche quest'anno l'Italian Agile Day non ha deluso le aspettative: relazioni quasi tutte di altissimo livello, con l'apprezzabile idea di aprire a contributi internazionali. Se proprio si vuole fare un piccolo appunto, si dovrebbe parlare di un'eccessiva enfasi posta sugli aspetti di processo a scapito delle sessioni "pratiche", anche se, come avete potuto leggere, i "puri" sviluppatori come me non hanno avuto occasione di annoiarsi.

Grazie a Marco Abis ed ai ragazzi dell'XPUG Bologna per l'enorme e riuscitissimo sforzo organizzativo.
(Ah, avete già donato qualcosa all'Agile Day? )

Ho partecipato ad un sondaggio promosso da un nostro fornitore. Alla domanda "Quali delle seguenti azioni sono state intraprese dalla Vostra azienda per affrontare la difficile congiuntura economica?" le risposte possibili erano:

• Riduzione dell’organico
• Riduzione degli stipendi
• Incremento dell’attività commerciale per trovare nuovi clienti
• Incremento delle tariffe
• Riduzione delle tariffe
• Automatizzazione delle attività svolte per i clienti
• Nessuna delle prededenti

La risposta "Investimento in ricerca e sviluppo per migliorare la qualità dei prodotti e dei servizi offerti" non era prevista!!!

Ecco, un bel sondaggio pensato da un managment lungimirante....

Ho deciso di provare il servizio di Slideshare pubblicando la presentazione su Scala che avevo tenuto presso l' XP-UG di bergamo qualche mese fa.

Ho finalmente completato il sito dell'artista contemporaneo Claudio Destito. Questo artista, che attinge al vocabolario del minimalismo reinterpretandolo in chiave nuova ed ironica, è a mio avviso uno degli autori più interessanti che operano attualmente nell'area di Milano.
E' stato interessante realizzare questo sito, sia perché le opere d'arte di Destito mi hanno coinvolto profondamente, sia perché ho avuto modo di scrivere codice di produzione in PHP.
L'impressione che ho avuto di questo linguaggio è stata ambivalente: da un lato PHP è uno strumento estremamente facile da apprendere, dall'altro...beh, forse non il più adatto a creare codice pulito. Ma probabilmente questo è solo l'impressione di un novizio: per avere un quadro diverso della situazione sarebbe magari opportuno seguire il corso sull'argomento di Francesco Cirillo

The way of organizing the code I will show in this post is very common, but, perhaps, it's useful to give it a name, and I will call it the "functional setter java idiom". Let's see.

In java there are no named parameters, i.e. parameters that I can pass to a method in the order I like calling them with their name. For example in Visual Basic for Applications we can sort some Excel cells this way:

 
SelectedSheets.PrintOut Copies:=1, _
    Preview:=True, _
    PrintToFile:=True, _
    Collate:= True
 

Note that the order in which I set the parameters is arbitrary, and that some parameters can be omitted, having it assigned with default values.

Now let's suppose we need to create an object with a long series of parameters (OK, I know, it's a code smell, but, please, close your nose for a while):

 
PrintType printType = new PrintType(1, true, true, true);
 

Well, not a good piece of code! Especially the sequence of boolean parameters is a mess. Moreover, sometimes I'd like to create my object with less parameters, having the others set with default values. I could create many constructors, but this would increase the complexity of my program.

I could solve the problem using some setters:

 
PrintType printType = new PrintType();
printType.setCopies(1);
printType.setPreview(true);
printType.setPrintToFile(true);
printType.setCollate(true);
 

Uhmm, better enough, but what if I need to assign my object to a constant, i.e. a final static field? I should write:

 
public final static PrintType DEFAULT_PRINT = new PrintType();
 
static {
	DEFAULT_PRINT.setCopies(1);
	DEFAULT_PRINT.setPreview(true);
	DEFAULT_PRINT.setPrintToFile(true);
	DEFAULT_PRINT.setCollate(true);
}
 

Mamma mia, this code is ugly! Maybe I could improve it just a bit using some functional setters, i.e. setters that have a return value, as a function. In the PrintType class I should write:

 
public PrintType setCopies(int copies) {
	this.copies = copies;
	return this;
}
 
public PrintType setPreview(boolean value) {
	this.preview = value;
	return this;
}
 
public PrintType setPrintToFile(boolean value) {
	this.printToFile = value;
	return this;
}
 
public PrintType setCollate(boolean value) {
	this.collate = value;
	return this;
}
 

Now the initialization of my static field becomes:

 
public final static PrintType DEFAULT_PRINT = new PrintType()
	.setCopies(1)
	.setPreview(true)
	.setPrintToFile(true)
	.setCollate(true);
 

This is not so bad, don't you think?