Franco Lombardo

Sono già passati 20 anni dalla strage di piazza Tiananmen, ma sembra che siano 1000.
Chi potrebbe infatti ricordare eventi così spiacevoli, che potrebbero turbare i rapporti con uno dei nostri interlocutori commerciali più importanti, specialmente ora, in tempo di crisi?
Pecunia non olet, nemmeno di sangue...

Ieri, 29 maggio 2009, ho tenuto una breve presentazione sul linguaggio Scala alla riunione dell'XP User Group di Bergamo. Parlare con delle persone brillanti come gli amici dell'XP-UG-BG è stato veramente una bella esperienza. L'unico mio rammarico è quello di non essere stato in grado di creare una presentazione sufficientemente chiara. Come sempre, la cosa più complessa è essere semplici! Il principio KISS è il più difficile da seguire. Spero comunque di poter fare meglio la prossima volta.

E' stata una coincidenza fortunata. Nei giorni scorsi stavo scrivendo del codice, per la prima volta da tempo del codice altamente algoritmico. Da bravo scolaretto XP, avevo creato una serie completa di test, avevo rifattorizzato estraendo metodi, rinominando variabili, abbassando il numero ciclomatico. Le classi erano piccole, i metodi corti, eppure il codice, pur funzionando egregiamente, in qualche modo mi infastidiva.
Poi alla scorsa riunione dell'XP-UG di Milano, Matteo Vaccari ha parlato brevissimamente dell'argomento, ed è stato illuminante. Da qui il suo interessante post.
In particolare una frase pesa come un macigno su quanti, come me, pensano di essere agili solo perché fanno TDD (o qualche altra pratica XP):
"TDD could be a crouch that allows you to give up finding a good design and settle for a mediocre one".
Puoi fare tutto quello che dice il libro bianco di Kent Beck, ma forse non ti accorgi che c'è una tessera mancante....

Nei sistemi Unix esiste il comando su che permette, avendone la password, di impersonare il "superutente" root.
Anche su AS400 ciò è possibile, anzi, se si possiede l'autorizzazione *USE sul profilo utente desiderato, si può far girare il proprio lavoro sotto mentite spoglie.

Ecco un semplice CL che a tale scopo usa le API di sistema QSYGETPH e QWTSETP.

             PGM        PARM(&UTENTE)

             DCL        VAR(&UTENTE) TYPE(*CHAR) LEN(10)
             DCL        VAR(&USCITA) TYPE(*CHAR) LEN(50)
             DCL        VAR(&TESTOERROR) TYPE(*CHAR) LEN(100)
             DCL        VAR(&HUSER) TYPE(*CHAR) LEN(12)

             MONMSG     MSGID(CPF0000) EXEC(GOTO CMDLBL(ERRORE))
/*------------------------------------------------------------------*/
/* RECUPERO L'HANDLE DEL PROFILO UTENTE                             */
             CALL       PGM(QSYS/QSYGETPH) PARM(&UTENTE *NOPWDCHK +
                          &HUSER)
/* PASSO AL NUOVO PROFILO UTENTE                                   */
             CALL       PGM(QSYS/QWTSETP) PARM(&HUSER)
/* INVIO UN MESSAGGIO DI COMPLETAMENTO OPERAZIONE                  */
             SNDPGMMSG  MSG('Profilo utente cambiato')
/*------------------------------------------------------------------*/
/* FINE                                                             */
/*                                                                  */
             GOTO       CMDLBL(FINE)

/* GESTIONE ERRORI                                                  */
  ERRORE:     RCVMSG     MSGTYPE(*EXCP) MSG(&TESTOERROR)
              SNDPGMMSG  MSG(&TESTOERROR)
/*                                                                  */
FINE:
     ENDPGM

I vantaggi dei test unitari sono ben noti a tutti: miglioramento del design, documentazione del codice, aumento della qualità tramite la diminuzione dei bachi e la possibilità di ristrutturare il codice in modo sicuro. Quello che gli agilisti (a volte) non dicono è che i test unitari, pur portando tutti questi benefici, rappresentano anche un costo nel processo di sviluppo. Un primo costo è banalmente rappresentato dal tempo necessario per il loro sviluppo, ma questo non è l'aspetto principale del problema. L'onere principale dei test, forse più difficile da cogliere, ci è indicato proprio dalle metodologie agili: tutto il codice prodotto comporta un costo di manutenzione, anche lo stesso codice di test.
Occorre quindi saper capire quando il prezzo dei test sia ripagato dai benefici e quando no. La mia opinione è che la creazione di test approfonditi per le interfacce grafiche non è quasi mai "economicamente" conveniente. Riprendo qui alcuni esempi che ho portato in una discussione nata con Matteo Vaccari sulla lista dell'XP User group di Bergamo.

Qualche anno fa, penso fosse il 2003, assistetti ad una presentazione al Webbit nella quale Bruno Bossola mostrò come fosse possibile applicare il TDD alla realizzazione di interfacce Swing, andando a testare lo stato dei vari "model" dei componenti. Tornai a casa entusiasta e provai a mettere in pratica la lezione: fu un disastro! Questo per due motivi. In primo luogo non sono un programmatore valido come Bossola (e allora ero ancora molto meno esperto). Secondariamente lo sforzo per cercare di domare le idiosincrasie di Swing non portava alcun vantaggio. I problemi della GUI sono al 90% del tipo: "Se visualizzo la mia maschera a 800x600 anziché a 1024x768 i bottoni scompaiono", oppure "Se passo a 1280x1024 il carattere è così piccolo che non si legge una fava". Certo, il debugging di questi aspetti si può fare anche con il TDD, ma penso che il debugging umano sia insostituibile, più efficace e molto meno costoso.

Secondo esempio. All'XP UG di Milano tentammo di sviluppare l'UG-Aggregator, una mini applicazione web per inserire e visualizzare gli eventi dei vari XP-UG. Questa applicazione non aveva alcun tipo di logica significativa, ma noi, essendo agilisti DOC, dovevamo scrivere i test! Ci venne quindi l'idea di testare la struttura dell'HTML prodotto, per vedere che ci fossero determinati tag con attributi che dovevano identificarne il contenuto. Il risultato fu circa il seguente, correggimi se sbaglio: tempo per scrivere il codice 1, tempo per scrivere il test 2, tempo per debuggare il test (e non il codice) che non funzionava 4. (OK ho un po' esagerato, ma penso che la mia ricostruzione non sia troppo lontana dalla realtà). Questo a mio avviso è un esempio di programma senza logica per cui il TDD può non essere efficace. Inoltre in questa situazione modificammo non solo la struttura interna dell'applicazione per renderla più testabile, ma anche il suo comportamento. Questa ritengo sia una "puzza" del processo di test!

In questo senso mi ha confortato l'esempio di TDD presentato nell'ultima riunione dell'XP User Group di Bergamo da Alessandro melchiori e Emanuele DelBono. Partendo dai test è stata abbozzata una banale applicazione Windows secondo il paradigma Model - View - Presenter. Ebbene, tutto il codice risultava coperto da test, ad eccezione della parte di view!
(Un unico neo nella presentazione dei due amici bresciani: tutto in C#!!!)

1. Scaricare ed installare
   Pstools
2. Avviare psexec \\nome_o_ip > /u dominio\utente cmd
3. Da una installazione già esistente di VNC 4, copiare il file winvnc4.exe in una cartella del PC di destinazione (ad esempio c:\programmi\vnc).
4. Sempre da una installazione già esistente di VNC 4, dopo aver configurato l'istanza server con la password desiderata, esportare la chiave di registro HKEY_LOCAL_MACHINE\SOFTWARE\RealVNC in un file vnc.reg. Copiare quindi tale file sulla macchina di destinazione
5. Nel propmt remoto sulla macchina di destinazione digitare
   regedit /c /s "percorso\vnc.reg"
6. Dal propmt remoto sulla macchina di destinazione avviare winvnc4.exe -register
7. Dal propmt remoto sulla macchina di destinazione avviare winvnc4.exe -start

Quando un PC con sistema operativo Windows non riesce a partire, sarebbe utile avere un CD, dal quale effettuare il boot, che contenesse qualche strumento di diagnostica. Ecco come crearne uno contenente Spybot.
Continue reading ‘Come creare un boot CD contenente Spybot’ »

Nel ripristinare un database su una diversa macchina Windows con IBM DB2 ho avuto i seguenti problemi. Riporto qui le soluzioni come promemoria.
Continue reading ‘Problemi nel restore di un database in DB2 su Windows’ »

Su iniziativa di Lorenzo Bolzani, nasce lo Scala User Group italiano. Era ora! Per il momento il gruppo gravita su Milano, speriamo comunque che cresca e dia buoni frutti.

Se fino a qualche anno fa l'incubo di chi aveva l'avventura di assistere ad una presentazione era costituito dalle trasparenze con un'enorme densità di microscopici caratteri, ora lo spauracchio maggiore è divenuto quello della presentazione pseudo-Zen. Non che le prime siano scomparse, ma le seconde costituiscono una minaccia molto più insidiosa.
In alcuni casi, infatti, le presentazioni che ammassano sullo schermo valanghe di dati potrebbero almeno divenire, una volta stampante, una sorta di riassunto di quanto ascoltato. (Sì, so benissimo che i Guru delle presentazioni lo sconsigliano, ma in quindici anni da spettatore ho sempre trovato molto comodo avere la stampa di quanto ho visto, e non di altro, per aiutarmi a richiamare i concetti sentiti dall'oratore).
Le nuove cool slides non hanno invece neppure questa utilità residuale. Si cerca di scimmiottare lo Zen della presentazione senza comprenderne uno degli aspetti fondamentali. Le immagini devono suscitare emozioni positive da associare ai concetti esposti per chiarirli, farli accettare e facilitarne la memorizzazione. Nello pseudo-Zen, invece, ci si scontra con due problemi. In primo luogo spesso non ci sono concetti, ma un puro compiacimento estetico. Secondariamente il collegamento, emotivo prima ancora che logico, tra l'immagine ed il contenuto risulta labile e poco efficace.