In questo articolo viene completata la descrizione del modello di comunicazione per il rover planetario El Dorado e vengono affrontate alcune tematiche legate allo sviluppo software in generale, inerenti la sostenibilità dei processi. Non mancano, ovviamente, le consuete note di colore legate al mondo nipponico.

Nei miei racconti precedenti ho descritto alcuni episodi salienti della mia avventura giapponese. La straordinarietà dell’ambiente mi ha garantito un flusso continuo di novità, ma allo stesso tempo, nell’arco di tre mesi, ho anche avuto modo di sviluppare una sorta di routine. La routine è un meccanismo psicologico fondamentale, che permette di dare un ordine alla nostra esistenza: troppa routine, e la vita diventa una noia mortale, troppo poca, e la vita diventa una corsa iperstressante senza scopo nè meta. Vorrei dedicare questo episodio del mio diario di viaggio a descrivere gli elementi ricorrenti della mia vita da gaijin.

Il risveglio

Come ho già descritto nel quarto episodio del mio diario, nel Paese del Sol Levante il Sole si leva un filino troppo presto per i nostri standard. Per ragioni storico-politiche, il Giappone condivide il fuso orario con la Corea, e non utilizza l’ora legale. Rispetto ai nostri standard, le giornate tipo sono spostate di due ore indietro, e pertanto in estate la luce inizia tra le 4 e le 5 di mattina e sparisce alle 7 di sera. Per quanto uno si impegni, serrando le tende e cacciandosi il cuscino sopra la testa, è pressochè impossibile continuare a dormire dopo le 7 di mattina.

Non avendo cucina nè frigo, non potevo prepararmi il caffè e avevo dei limiti su ciò che potevo tenere in casa. In genere tenevo un po’ di frutta, mele e banane, per cominciare la giornata. Senza neanche avere la possibilità di sgranchirmi le gambe , mi infilavo nel mio microbagno Yamaha per l’igiene mattutina.

Prima di partire, compravo qualcosa da bere nel distributore al piano terra del mio edificio, quindi prendevo la bici e andavo verso l’Università di Tohoku. La Facoltà di Ingnegneria di Sendai è costruita in cima a una collina, servita da una strada ripida che non è consigliabile percorrere in bici. A seconda che piovesse o meno, facevo l’ultima parte del tragitto in autobus o a piedi: questo esercizio giornaliero, mezz’ora di bici più venti minuti di “arrampicata”, unito a una alimentazione frugale e decisamente sana, mi ha aiutato a perdere 12 chili, nonostante le paste di sfoglia artigianali del Boook Cafe, con le quali mi riprendevo dalla fatica.

L’arrivo in ufficio

Arrivato in laboratorio attorno alle 8:30, trovavo invariabilmente qualcuno che dormiva in ufficio, a volte sulla scrivania, altre disteso per terra. Questa scena, piuttosto comune in Giappone, rappresenta una pratica non solo tollerata, ma addirittura socialmente incoraggiata. In Giappone l’individualismo non viene incoraggiato: l’individuo si realizza come parte del gruppo, si tratti di una famiglia, di un clan o un’azienda, con l’azienda che solitamente ricopre il posto più elevato nella gerarchia di valori. La dedizione verso l’azienda si manifesta principalmente in un modo: trascorrendo la maggior parte del proprio tempo sul posto di lavoro. Quando uno dorme sulla scrivania in ufficio, è segno che ha passato la notte al lavoro, e pertanto è degno di rispetto e ammirazione. Questo atteggiamento, portato avanti con la massima onestà e convinzione dai Giapponesi, ha però un lato oscuro: la cultura giapponese tende infatti a premiare lo sforzo, e in particolare l’esibizione di sforzo, allo stesso livello del risultato. Quale potrà essere la effettiva produttività di un uomo che dorme tre ore per notte è per di più in condizioni scomode? E come si deve valutare qualcuno che ottiene buoni risultati in maniera efficiente, senza esibizione di sforzo? Questi sono argomenti che in Giappone non è opportuno sollevare, dato che si scontrano con uno dei capisaldi su cui si regge la loro organizzazione sociale.

La fuga dall’ufficio

La visita all’ufficio era una tappa indispensabile per controllare la posta e fare altre cose in rete. Come ho già spiegato, in Giappone non si è mai sviluppata la cultura del wi-fi che oramai è un fatto assodato in USA e in gran parte dell’Europa, e questo limitava enormemente il mio raggio di azione per attività che dipendessero dall’accesso a Internet. Inoltre, la natura del mio lavoro richiedeva che trascorressi parte del mio tempo a contatto con l’hardware del laboratorio.

Prima ancora di iniziare lo sviluppo software, ho creato una serie di strumenti e tecniche che mi permettessero di lavorare offline, senza la necessità di avere accesso a Internet o al rover. Queste tecniche si riconducono ad una pratica molto importante nello sviluppo di software: la separazione tra l’ambiente di sviluppo e quello di produzione. Mantenere una separazione netta tra l’ambiente di sviluppo e di produzione, documentando le caratteristiche dell’uno e dell’altro e i passaggi necessari al deployment, è una pratica estremamente importante nello sviluppo di software di una certa complessità.

Lato Ground Station

Il software di navigazione, che ho già introdotto negli articoli precedenti, è stato sviluppato in Java su PC. La natura di Java, un linguaggio interpretato a livello di bytecode che viene eseguito su una virtual machine, offre molte facilitazioni nella creazione di software realmente portabile, che può essere trasferito da una macchina all’altra con tutto ciò che è necessario alla sua esecuzione.

D’altra parte, un software di navigazione e controllo per un rover lunare richiede, per essere eseguito, la presenza fisica del rover in questione, giusto? Non proprio. A livello tecnico, la dipendenza dall’hardware è spesso una questione largamente sopravvalutata. L’interfaccia utente di Kaizen 2010 comunica con l’hardware attraverso un programma di rete, che utilizza un protocollo text based sopra TCP/IP. Per testare l’interfaccia grafica, è stato sufficiente creare un semplice programma di rete che utilizzasse lo stesso protocollo del rover. Il programma è così semplice che ho deciso di trascriverlo per esteso:

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.FileReader;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.net.Socket;
 
public class ElDoradoScaffolding {
 
       public static void main(String argv[]) {
             try {
                    Socket client = new Socket("127.0.0.1", 5007);
                    BufferedReader in 
                                = new BufferedReader(new InputStreamReader(
                                                     client.getInputStream()));
                    BufferedWriter out 
                                = new BufferedWriter(new OutputStreamWriter(
                                                     client.getOutputStream()));
                    BufferedReader lineReader 
                                = new BufferedReader(new FileReader("TelemetryLog-In.txt"));
                    while (true) {
                           String line = lineReader.readLine();
                           if (line == null) {
                                  break;
                           }
                           line = line.substring(line.indexOf(" ")+1);
                           out.write(line);
                           out.newLine();
                           out.flush();
                    }
                    lineReader.close();
                    Thread.sleep(1200000);
                    in.close();
                    out.close();
                    client.close();
             } catch (Exception ioe) {
                    ioe.printStackTrace();
             }
       }
}

Questo programma apre una connessione con il client grafico usando la porta 5007, quindi apre un file di testo contenente il log di una esecuzione precedente, e lo invia al rover una riga per volta. Fine.

Scaffolding

Il programma in questione è un esempio di quello che in unit testing si chiama “scaffolding”. Nel mondo reale, lo scaffolding è l’impalcatura che sorregge un edificio durante lavori di costruzione. L’impalcatura è necessaria perchè durante la costruzione un edificio non è fisicamente in grado di reggersi da solo. Allo stesso modo, uno scaffolding permette di creare un ambiente di supporto per una unità software che presenta delle dipendenze. L’unità software in questione può essere una classe, un componente composto da dieci o più classi, un programma o un’intera macchina, come in questo caso.

Oltre a permettermi di testare il mio software nell’ambiente confortevole del Boook Cafe, lo scaffolding mi consentiva di replicare più e più volte una condizione di test che nel mondo reale richedeva un’ora per essere creata. La creazione di una mappa di elevazione di una certa complessità richiedeva decine di rilevamenti, da effettuare muovendo il rover in lungo e in largo per decine di metri attraverso le varie stanze del laboratorio universitario. L’interfaccia di Kaizen 2010 registrava in automatico il file di log di ogni sessione: in seguito mi bastava dare in pasto il file di log allo scaffolding, e la telemetria raccolta in un’ora di attività veniva processata in pochi secondi, restituendomi uno stato che mi permetteva di effettuare dei test significativi alle funzioni di tracciamento dell’interfaccia grafica.

Software lato rover

Nella mia prima settimana a Sendai, avevo studiato il software di sistema del rover. Come avevo detto a Yoshida, urtando involontariamente certe convenzioni sociali che non permettono una critica così diretta a quanto fatto da altri precedentemente, non ero molto d’accordo con il modo in cui il l’architettura di sistema era stata sviluppata. D’altra parte, il sistema alla fine dei conti funzionava, e pertanto avevo deciso di trattarlo come una black box. Un po’ come un kebab di dubbia provenienza: è buono finchè lo mangi, ma cosa c’è dentro è meglio non saperlo. Per permettere la comunicazione tra il rover e l’interfaccia grafica, ho sviluppato un componente di rete analogo a quello presente nella ground station. Il modulo si interfacciava con la logica di controllo del rover accedendo ad una struttura dati condivisa, leggendo lo stato corrente e impostando le direttive di moto.

Per poter sviluppare questo modulo off line, ho nuovamente creato uno scaffolding. Ma in questo caso, ho introdotto una ulteriore tecnica per semplificare il deploy. L’hardware di controllo del rover era una motherboard ITX con sistema operativo Linux, privo di schermo, mouse e tastiera. I ragazzi del laboratorio erano soliti lavorarci sopra attraverso una connessione SSH, utilizzando strumenti a riga di comando come l’editor VIM e il compilatore GCC. Questo genere di approccio è terribilmente lento e inefficente, ed ero sorpreso del fatto che nessuno avesse pensato a una delle molte alternative possibili. Sembrava che ci fosse una sorta di superstizione verso qualunque tecnologia di sviluppo sofware che avesse meno di 30 anni, e mi ci volle un po’ prima di riuscire a dimostrare la validità di uno strumento di sviluppo come NetBeans.

NetBeans, pasta sfoglia e caffè

NetBeans è un ambiente di sviluppo integrato che dovrebbe essere familiare ai lettori di MokaByte, dato che è de facto l’ambiente di sviluppo standard per Java. Attraverso estensioni, NetBeans può supportare decine di altri linguaggi, incluso C e C++. Il modulo per lo sviluppo in C e C++ supporta due funzionalità molto interessanti: losviluppo cross platform e quello remoto. Sviluppo cross-platform significa che è possibile scrivere e compilare software destinato a un’altra piattaforma. Ad esempio è possibile sviluppare sotto Windows software per Linux e viceversa, utilizzando diversi profili di compilazione e runtime.

Sotto Windows, ho creato un profilo che mi permetteva di compilare e eseguire localmente il sofware Linux del rover, utilizzando il runtime Cygwin come ambiente di esecuzione. Cygwin è un runtime Posix per Windows, che permette di compilare e eseguire programmi scritti per Linux. La distribuzione ufficiale supporta un gran numero di librerie, garantendo un supporto quasi universale.

Attraverso un a serie di moduli-scaffolding, ho potuto sviluppare il software nel confortevole ambiente del Boook Cafe. A fine giornata, quando volevo testare i miei progressi, tornavo in laboratorio, accendevo il rover, e quindi impostavo su NetBeans il profilo relativo alla piattaforma remota. Quando si avvia una compilazione remota, NetBeans copia in automatico i sorgenti sulla piattaforma remota, e quindi esegue la compilazione. Sempre dall’interfaccia di NetBeans, è possibile avviare l’esecuzione remota, e seguire l’output della console in locale.

Come correggere qualunque bug

Durante la mia permanenza all’Università di Tohoku, mi feci una reputazione per la mia rapidità nella stesura del codice. Una delle ragioni era il fatto che avevo separato l’aspetto progettuale dalla implementazione. Avendo definito a priori i requisiti del sofware, come ho descritto negli ultimi due aricoli, avevo trasformato la stesura del codice in una attività “meccanica”, dagli esiti facilmente prevedibili. Una seconda ragione era l’aver svilluppato una indipendenza tra l’ambiente di sviluppo e testing, e quello di produzione, come ho descritto a inizio di questo articolo, con il risultato di sveltire e automatizzare gran parte del testing. Ma c’era qualcosa di “leggendario” nel fatto che, apparentemente, io non passassi alcun tempo a correggere fastidiosi bug. La verità era diversa, ovviamente. Il mio codice era, alla prima stesura, soggetto a bugs come il codice di chiunque altro. La differenza era che io avevo imparato a non trascorre il mio tempo con loro, con i bug.

Vi siete mai domandati cosa sia un bug? Sul piano fenomenologico, un bug è una imperfezione nel codice, che causa una esecuzione fuori dai parametri operativi. Il software è una creatura strana. Ammesso che non ci siano errori nel compilatore, un computer esegue sempre con precisione quello che un programma gli chiede di fare. Un bug è insomma un esempio di errore sistematico: il software di per se’ non contiene difetti, si limita a eseguire correttamente una sequenza di operazioni errata. Alla fin dei conti, basta analizzare la sequenza e correggere l’errore, no? Be’, questa è la teoria che tutti conosciamo.

Lo Zen e l’arte della correzione dei bug

Ma allora perchè i bug ci fanno perdere così tanto tempo? La ragione è che, sul piano operativo, un bug non è nient’altro che un’emozione. Un “incidente di esecuzione” diventa la causa scatenante di una forma di frustrazione, di un senso di impotenza che in letteratura prende il nome di learned hoplesness o “disperazione appresa”. Frustrati dal fatto di ottenere un risultato inatteso, entriamo in uno stato emotivo di “disperazione” che ci impedisce di vedere la soluzione, che il più delle volte abbiamo proprio sotto il naso.

Sarà capitato a molti, almeno una volta, di non riuscire a dormire. Quando vi alzate dal letto, e andate a guardare la televisione per vedere se vi viene sonno, l’unica cosa che danno sono repliche di vecchi programmi RAI. Poi provate ad andare in cucina a guardare dentro al frigo per vedere se vi viene fame, e ovviamente non trovate niente di interessante. Allora tornate a guardare la televisione, e di nuovo ripassate tutto il bouquet di SKY, per vedere se c’è qualcosa di diverso. Poi, dopo un po’, tornate in cucina a guardare nel frigo, come a vedere se per caso qualcosa sia miracolosamente comparso nel frattempo. E malgrado vi rendiate perfettamente conto della situazione, ripetete la stessa scena fino al mattino, perchè in verità ciò che non è cambiato è il vostro stato d’animo, la noia, che vi spinge a ripetere le stesse cose all’infinito. Se però decidete di interrompere questo circolo vizioso, andando magari a fare una passeggiata all’aria aperta, al ritorno questa sensazione si è magicamente dissolta, e siete liberi finalmente di dormire il “sonno dei giusti”.

Se volete correggere un qualunque bug, la prima cosa sensata da fare è interrompere quello che state facendo. Alzatevi, fate un giro, prendete una boccata d’aria, parlate con un amico, fatevi una risata, portate a spasso il cane. Quando vi rendete conto di esservi liberati da quella sensazione di frustrazione, provate a spostarvi fisicamente in un altro luogo. Con un notebook e una connessione wi-fi, non è una cosa difficile da fare. Sembra incredibile, ma una volta cambiato stato d’animo, e liberi dai condizionamenti legati all’ambiente, invariabilmente il bug salta agli occhi, e soprendendoci per la sua ovvietà.

Sotto gli occhi divertiti dei miei colleghi orientali, passai la mia estate spostandomi ripetutamente tra l’ufficio, il laboratorio, il corridoio, il Boook Cafe, la panchina sul viale e un piccolo bosco di abeti vicino alla mensa. Cambiando luogo e stato d’animo, ero sempre in grado di mantenere elevato il livello di attenzione, e di risolvere i numerosi problemi che invariabilmente emergevano durante lo sviluppo.

La fine della giornata

La mia giornata lavorativa terminava attorno alle 7 di sera. Messo alla prova da una giornata iperstimolante, parlando in inglese con qualcuno, in spagnolo con qualcun altro, in italiano al telefono con le mie bambine, in “engrish” con i ragazzi del laboratorio, in C con El Dorado e in Java con il mio PC, vivevo con particolare sollievo il fatto di trovarmi finalmente da solo, in silenzio per un po’. Passeggiando da solo attraverso strade debolmente illuminate, guardavo la Luna e pensavo allo straordinario viaggio che El Dorado compirà un giorno.

Conclusioni

E anche questa volta abbiamo terminato. Oltre a completare il discorso sul modello di comunicazione, ho voluto dilungarmi sul discorso delle routine quotidiane e della correzione dei bug perche’ ritengo che sempre più spesso sia difficile separare lo sviluppo software dalle componenti umane ed emozionali che in esso pesano tante volte anche più dei meri aspetti tecnologici (e questo sembrano dirci anche molte metodologie agili che attualmente vanno per la maggiore e che sottolineano sempre la sostenibilità del processo e il benessere degli sviluppatori). Questa lunga serie si avvia verso la conclusione, ma ci sono ancora alcuni temi da trattare, e lo faremo il prossimo mese.

Nel frattempo, a livello personale, anche grazie a questa esperienza che sto raccontando sulle pagine di MokaByte, ho ricevuto una positiva notizia che sembra prefigurare un interessante sviluppo professionale. Sono in attesa di conferma di un paio di dettagli e, casomai, ne parlerò su queste pagine.