Ovviamente l’intento del post è ironico…

Hollywood? No, davvero

Non sono una una macchina nè permetterò mai che una di esse mi renda un suo schiavo: paragonarmi ad un computer o preannunciarmi che prima o poi mi trasformerò in esso “se continuo così” è ridicolo. Idem lanciarsi in improponibili previsioni in merito, anche se Hollywood la pensa ben diversamente sul filone uomo-macchina (cfr. Matrix, Terminator).

Io sono un informatico e, per la gizilionesima volta, l’informatica non coincide affatto e solamente con progettare ed usare computer:

“What would we like our children – the general public of the future — to learn about computer science in schools? We need to do away with the myth that computer science is about computers. Computer science is no more about computers than astronomy is about telescopes, biology is about microscopes or chemistry is about beakers and test tubes. Science is not about tools, it is about how we use them and what we find out when we do.” (M. R. Fellows e I. Parberry, poi ripresa da Edsger W. Dijkstra)

Aggiustare i computer è un effetto collaterale del conoscere quello strumento, non lo scopo dell’esistenza professionale di un informatico e, probabilmente, neppure quella di un tecnico dell’assistenza IT. Il fatto che io sappia “usare un computer” non implica che debba (ri)conoscere istantaneamente qualunque sistema elettronico. Nè che lo sappia usare od aggiustare con la stessa disinvoltura di un protagonista di un film d’azione, che utilizza qualunque arma gli capiti a tiro, incluse quelle aliene (cfr. Independence Day).

Non sono un “(piccolo) mago del computer” perchè di magia non ce n’è. Di nuovo, semplicemente conosco gli strumenti scientifici e tecnologici del mestiere e ne ho fatto una professione:

“Any sufficiently advanced technology is indistinguishable from magic.” (Tre leggi di Clarke)

Analogamente, nonostante le perssime abitudini umane ad antropomorfizzare ogni cosa (cfr. pallone Wilson in Cast Away), i PC sono essenzialmente oggetti, entitità inorganiche, non viventi e non sperimentano sensazioni e sentimenti. Quindi non odiano gli incauti padroni, nonostante i guai che questi ultimi possono provocare. Al massimo siamo noi informatici a non raccapezzarci dei danni da sistemare in seguito a qualche “Incontro ravvicinato” utente-macchina e a sperimentare biechi sentimenti di vendetta nei riguardi dei bipedi-carnefici.

Questione di etichette…

Quanto ai modi per definirci, geek e nerd, ormai “mainstream” come termini, non sono sinonimi di informatico, anche se esiste una certa correlazione causale fra queste etichette. Se anche mi riconoscessi in esse, nell’accezione negativa intendo, non chiederei comunque la solidarietà o la commiserazione del prossimo: non sono un cucciolo di cane maltrattato dalla società nè un Quasimodo rinchiuso in una torre di una cattedrale virtuale.

Non sono più fissato di molte altre persone che parlano ossessivamente dei loro problemi, delle loro fortune, delle loro famiglie, dei loro hobby ed interessi. Anzi, non mi capacito proprio del perchè parlare senza sosta di argomenti come la famigerata combo donne-calcio-motori sia considerato “normale”, mentre interessarsi di computer sia considerato innaturale, anche se magari non ne si parla mai in pubblico.

Come tutte le categorie professionali, anche gli informatici indugiano in battute pietose e comunque comprensibili solamente dai propri “pari”. Avete mai sentito battute in slang fra studenti di medicina? Stessa cosa. Con problemi con i familiari analoghi ai “nostri”.

Di professione sono programmatore, perchè mi piace ed anche per camparci, ma non so fare e non faccio solo quello. Non basta fare o sentirsi programmatori per definirsi anche informatici, anche se certamente la cosa aiuta. Di certo non sono un “softwarista“: amo forgiare neologismi, ma non ne userei mai uno così orribile, riduttivo, impreciso, per descrivere chi io sia.

Chi mi fa notare che scrivere codice sia un gioco da ragazzi, un lavoro facile, evidentemente non conosce bene questo mondo. Vero, non tutti i progetti sono così difficili, ma generalmente scrivere codice è una fase operativa avanzata rispetto ad altre, come la progettazione, dove iniziano i mal di testa.

“In fact, my main conclusion after spending ten years of my life working on the TEX project is that software is hard. It’s harder than anything else I’ve ever had to do. (Donal Knuth)”

A chi mi fa notare che programmare, in fondo, non sia un “lavoro” o che sia perfino sovrapagato (in Italia!?!) rispetto ad altre mansioni, spesso più “manuali”, mi viene da sorridere. Detto ciò, considerato che lavorare nell’informatica non è come accedere in una casta chiusa, non vedo perchè chi ha preparazione e know-how non possa ambire in alto, anche econonomicamente. Come per tutte le altre professioni, del resto. Ennesima variante di un classico aforisma d’esempio (altra variante):

Do You Know Where To Hit The Hammer?

A company has developed the latest and greatest monster widget maker. They’ve sent out invitations for the grand reveal to the world’s press and major business players. 15 minutes before the coming out party is to start, with the grandstands bursting at the seams, television cameras trained on the dignitaries and company executives, and the place at full-tilt frenzy, the widget maker shuts down. No amount of fiddling by the operators could get the machine fired up. In a panic the company president remembers that the chief engineer of the machine had retired the week before. The president gets the engineer on the phone and pleads for him to come in and get the machine working. The engineer says he’ll fix it but he’s charging $10,000. The president readily agrees.

5 minutes later the engineer shows up. He looks over the machine, taking special note of several areas on the machine. He then takes a hammer out of his bag and hits one of the spots with a might whack! The machine immediately springs to life, producing widgets like there’s no tomorrow. The engineer puts the hammer back in his bag, walks up to the president and says “That will be $10,000″. The president looks at him and screams “$10,000??? You spent two minutes here just to hit it with a hammer!!!!”. The engineer pointedly looks at the president and says “I threw in the hammer hit for free. The $10,000 was for knowing where to hit it.”.

Che ne pensate?

“Avete consigli su come approcciare lo studio di un’applicazione legacy su cui dovrete lavorare ed effettuare modifiche, considerando che si tratta di un’infinita schiera di file salvati in n+1 cartelle, che si includono a vicenda, senza uno straccio di documentazione né commenti esplicativi?”

Domanda molto interessante, a cui vorrei rispondere ora, seppur brevemente…

L’approccio al problema

A chi non è mai capitata una cosa del genere, ossia avere a che fare con codice di terzi, magari legacy? Ovviamente la risposta è banale – tutti! – e, salvo rari casi, il compito non è mai una passeggiata.

Il problema non è solo metterci le mani, quanto capirlo e comprenderlo per poi decidere il da farsi.

Questo tipo di strategia però non sempre è possibile ed è abbastanza normale dover ottenere in fretta dei risultati – quindi modificare direttamente quel codice! – senza avere il tempo di effettuare un’ispezione accurata. Un po’ come buttarsi a scrivere un nuovo programma senza neppure avere un’idea di fondo di quello che dovrà fare e soprattutto come dovrà farlo.

Esiste poi una sorta di atteggiamento spocchioso e terribilmente comune nei programmatori che si approcciano al lavoro di terzi ed è quello di partire prevenuti nei confronti degli altri, salvo poi peggiorare facilmente nel giudizio man mano che va avanti nella lettura: al minimo errore individuato – reale o presunto che sia -, al minimo commento incompleto o inesatto, alla minima imprecisione nell’indentazione, ecco che iniziano i mugugni del programmatore di turno verso “chi ha fatto quello scempio“.

Le motivazioni di questo tipo di atteggiamento sono le più disparate: dal “io queste cose le so fare meglio” fino al diventare una buona scusa per giustificare ulteriori ritardi (“è talmente ingarbugliato che in pratica lo sto riscrivendo!”).

Per esperienza, direi di concedere al codice altrui ed al suo autore il beneficio del dubbio, almeno finchè non si è conclusa un’attenta e relativamente lunga fase di ispezione. Di rimando, mai fidarsi ciecamente delle impressioni di un programmatore alle prese con codice non suo, almeno finchè non si è sporcato le mani davvero, in profondità. Anche perchè, finchè un dev non arriva ad un certo livello di intimità con del codice, di norma non può sapere quanto ne dovrà cambiare: in altre parole, a seconda del singolo progetto e a fronte anche di migliaia e migliaia di potenziali righe di codice da visionare, quelle effettivamente da modificare potrebbero essere molto poche. Un conto sono valutazioni oneste, frutto di indagini serie e prolungate nel codice altrui, un conto sono supposizioni ed illazioni “spannometriche”, emesse in fretta e furia e, tavolta, anche con una certa malizia di fondo.

Di certo leggere poche righe di codice e, senza nemmeno averle capite, decidere di riprogettare il codice da zero è una scelta radicale e spesso controproducente: posso capire quando il codice altrui fa veramente pietà e non c’è modo per manutenerlo, ma il capriccio di volerlo rifare a tutti i costi no. Non c’è sindrome “Not Invented Here” (NIH) o volontà di dimostrarsi più bravi che tenga.

Il problema: approcciare l’ignoto

Il problema più grosso con il codice è l’ignoto. L’ignoto è codice altrui, che vedete per la prima volta, e perfino codice che voi stessi avete scritto anni prima e che non avete più toccato da eoni.

È un ammasso minaccioso di righe che dovete comprendere prima ancora di poterle modificare. Naturale quindi che, impaurito, qualcuno si ribelli a questa situazione e, piuttosto di affrontarla, opti per ripartire da zero. Inoltre, come direbbe Sposlky:

It’s harder to read code than to write it.

Da questo punto di vista i programmatori sono l’esempio per antonomasia di persone che non sono mai contente fino in fondo e che bisogna in qualche modo controllare: è normale che un dev arrivi ad un certo punto del suo lavoro e pensi/provi insistentemente a ripartire da capo – un errore generalmente gravissimo! -, figuriamoci se il codice iniziale l’ha scritto qualcun altro.

Prima regola per affrontare l’ignoto: non andare in panico, non tirare i remi in barca prima di averlo affrontato e possibilmente compreso, anche solo parzialmente. Sono le fasi iniziali quelle critiche: l’autocontrollo è essenziale. Non appena si comincia a capire qualcosa, la paura passa di colpo, automagicamente.

Un approccio personale

Dopo aver sconfitto il demone della riscrittura from scratch, è fondamentale circoscrivere ed analizzare l’ignoto. Ognuno di noi sviluppa col tempo le sue personali strategie per raggiungere i suoi scopi.

Il mio è relativamente semplice ed è sintetizzabile in analizza, circoscrivi e migliora, ripeti.

1. Analizza

Analizzare il codice significa volerlo capire con un certo livello di dettaglio. Se le dimensioni del codice e dell’eventuale documentazione a corredo sono contenute, apro il codice in un IDE e provo a capire da solo.

Molto più spesso uso invece Doxygen, che considero alla stregua di un coltellino svizzero. Da Wikipedia:

“Doxygen è una applicazione per la generazione automatica della documentazione a partire dal codice sorgente di un generico software. È un progetto open source rilasciato sotto licenza GPL, scritto per la maggior parte da Dimitri van Heesch a partire dal 1997.

Doxygen è un sistema multipiattaforma (Windows, Mac OS, Linux, ecc.) ed opera con i linguaggi C++, C, Java, Objective C, Python, IDL (versioni CORBA e Microsoft), Fortran, PHP, C#, e D. Nell’ambito del C++, è compatibile con le estensioni Qt.

È il sistema di documentazione di gran lunga più utilizzato nei grandi progetti open source in C++. Due esempi per tutti, sono l’adozione di doxygen da parte di ACE e KDE. In Java invece, la posizione leader viene meno, in virtù della presenza del concorrente Javadoc.

Il sistema estrae la documentazione dai commenti inseriti nel codice sorgente e dalla dichiarazione delle strutture dati.”

Non solo è utile per creare documentazione partendo dal codice, documentato tramite opportuni tag, ma è estremamente efficace nell’estrarre anche altro.

Ad esempio, recentemente ho deciso di dare un’occhiata al codice di Doom 3 di ID Software, rilasciato finalmente sotto licenza GPL e pubblicato sul sito GitHub in questo repository pubblico.

Non è certamente un progetto-giocattolo ed infatti richiede una buona competenza tecnica per maneggiarlo, nonostante sia generalmente ben scritto (in realtà avrei alcune riserve da programmatore a programmatore – vedi sezione precedente -, ma non è la sede giusta per farlo).

Capirci qualcosa non è quindi stato molto facile, ma Doxygen si è nuovamente rivelato utilissimo per esplorare il codice cercando di capire come è stato strutturato – non sempre l’organizzazione dei file è intuitiva nè i programmatori-autori lasciano spesso file di spiegazione esaustivi sull’argomento -.

Premesso che non volevo studiare il codice a fondo, ma solamente dargli un’occhiata rapida, ma con Doxygen questa “passeggiata” mi è diventata decisamente più godibile.

Usare Doxygen poi è veramente facile: basta installarlo, lanciare l’interfaccia grafica (GUI), configurare pochi parametri e fa tutto lui. Se poi avete installato anche la suite Graphviz, potrete attivare l’opzione per ottenere i diagrammi , anche simil-UML, con dot.

Un breve riassunto, step-by-step:

1. Configurazione iniziale in Doxygen: nome progetto, directory di lavoro, eccetera	2. Configurazione della generazione dei diagrammi
3. Abilitazione della ricerca ricorsiva nelle sottodirectory di quella dove risiede il codice da analizzare	4. Avvio del programma (Run)
5. Completamento operazioni	6. Apertura dei risultati in un browser: si notino i diagrammi di ereditarietà e di collaborazione fra classi

Dopo un’oretta buona di processamento – il codice è relativamente complesso e denso di informazioni estraibili – ho quindi potuto leggere i risultati direttamente in un browser. Trovo molto comodo che sia possibile includere nella documentazione generata da Doxygen anche i sorgenti stessi. In un colpo si riesce a:

• osservare il progetto nella sua interezza, a dispetto del suo essere eventualmente sparpagliato in mille file in mille directory diverse;
• esplorarlo in vari modi: per classe, namespace, e così via,
• leggerlo in un modo esteticamente piacevole: Doxygen uniforma tutto, alla faccia dei file/sorgenti scritti in modo diverso;
• analizzarlo in modo efficiente: viva gli hyperlink per passare da un file ad un altro, da una funzione all’altra senza perdere tempo e con la possibilità di usare il tast “Indietro” del browser!.

Inoltre Doxygen stesso è efficiente nel senso che se modificate un file, di norma non rigenererà da zero la documentazione, ma solo la porzione di essa che è toccata dai cambiamenti nel codice.

2. Circoscrivi e migliora

Ogni progetto di una certa taglia è il frutto del lavoro di uno o più individui nel corso del tempo. Il risultato è che raramente il suo codice appare ed è omogeneo.

Realisticamente, soprattutto per programmi con una certa anzianità, ci si trova con una pletora di file, ognuno col suo codice scritto in modo “particolare“: non di rado capita di trovare differenze abissali fra un file ed un altro nello stesso progetto.

In C e C++ si parla di compilazione per unità singole per indicare il modo con cui avviene normalmente la compilazione, ossia file per file. In sostanza, al netto del significato reale, ogni file sorgente fa storia a sè durante quella fase. Avviene la stessa cosa anche in fase di scrittura: file diversi fanno storia a sè. Uno stesso programmatore nel tempo può cambiare in modo considerevole il suo stile di scrittura, al punto da non riuscire a identificare come suo del codice che ha sviluppato molto tempo prima. Hic sunt leones…

Dopo aver capito cosa fa grossomodo un progetto si passa all’analisi per “sottosistemi”, se è possibile individuarne dei limiti: di solito i file sorgenti nei progetti di una certa dimensione sono raggruppati in qualche modo, per agevolare lo sviluppo e la manutenzione di parti logicamente legate.

Ad esempio tutto quello che riguarda l’accesso ad un filesystem potrebbe essere stato posto in una directory fs oppure tutti i file potrebbero risiedere nell’unica directory con gli altri sorgenti ma essere rapidamente individuabili da un prefisso fs nel nome. Nel caso invece tutto fosse alla rinfusa, nuovamente, Doxygen torna utile per capire le interrelazioni fra file e funzioni.

A quel punto, in perfetto stile divide et impera, si può approcciare l’ignoto dedicandosi ad un “sottosistema” per volta, cercando di comprenderne la struttura ed il ruolo per poi modificarlo se è il caso.

Durante questa fase, se è il caso, di solito provo anche a ridurre il numero di file, per renderlo maneggiabile: detesto maneggiare una miriade di piccolissimi file ognuno con una classe di pochissime righe (una certa filosofia nel mondo Java sembra favorire questo approccio). Per cui si procede con una riorganizzazione per passi dei file e poi al refactoring del codice vero e proprio.

L’idea è capire cosa fa un pezzettino del programma ignoto e, compreso, ridurne le dimensioni per rendere le successive modifiche più efficienti. Accorpare e semplificare sono le due parole magiche:

“La perfezione è raggiunta non quando non c’è più niente da aggiungere, ma quando non c’è più niente da togliere. (Antoine de Saint-Exupéry)

Durante questa fase, procedendo per passi piccoli ma decisi, vale la pena uniformare il codice, ossia applicare e riapplicare un manuale di stile e delle coding convention, precisi e predeterminati.

A questo punto il trucco si ripete, ossia si riparte dall’analisi e si continua finchè l’ignoto diventa qualcosa di compatto, manutenibile ed assolutamente non spaventoso.

Che ne pensate?

Alcuni dei consigli sono emersi qua e là, nei miei post passati, ma ho notato di aver trascurato del tutto un “fattore di crescita professionale” molto importante, che mi si è rivelato utilissimo: i “modelli di riferimento“.

Modello?

È indubbio che esistano tanti modelli di programmatori quanti sono i programmatori stessi ma, come è lecito aspettarsi, non tutti sono altrettanto efficaci e, di conseguenza, non tutti meritano di essere seguiti. Così come avviene, del resto, per i modelli di sviluppo software.

Non è una semplice questione di conoscenza: un programmatore da prendere come esempio, come “modello di riferimento“, non è semplicemente qualcuno che ne sa più di noi.

È piuttosto qualcuno che ha le idee sufficientemente chiare per svolgere un determinato compito in modo ordinato, preciso e se possibile anche elegante.

Se poi la sua conoscenza è estremamente vasta ed è perfino in grado di insegnarla in modo comprensibile a terzi, tanto meglio. Tuttavia non è una condizione imprescindibile per essere un “modello valido“.

Un modello non è necessariamente (anche) un buon maestro

Esattamente: un modello non è per forza un docente, professore, … ma chiunque può esserlo o diventarlo nell’atto di svolgere qualcosa.

Ad esempio, una decina e più di anni fa, all’inizio della mia carriera universitaria, ricordo di aver visto il codice C per un progetto d’esame, scritto da un mio compagno di università che all’epoca era certamente già ben più esperto di me.

L’esercizio da svolgere non era particolarmente complicato ma lui lo aveva svolto in modo terribilmente elegante: gli spazi dove servivano, tutte le parentesi al loro posto, i commenti dove e solo se servivano, eccetera.

Era così ben scritto che riuscivo a capire al volo cosa facevano alcune funzioni della libreria C, all’epoca a me ignota in molti punti, libreria che non è mai stata celebre per la sua chiarezza e “intuitività“.

Man mano che leggevo quel codice continuavo a ripetermi:

“Wow! Questo sì che sa come si fanno le cose bene!”

Quel giorno ho imparato il concetto di “stile” nella programmazione, per giunta nella sua accezione positiva. Non un libro, non un docente chiamato ad insegnarmi a programmare, ma uno studente come me ed attraverso il suo codice ben scritto.

Quel giorno trovai un modello da seguire, a cui ispirarmi e per giunta senza che questi ne fosse a conoscenza.

Quel giorno formulai quest’altra semplice (banale?) euristica:

“Se qualcosa ti fa esclamare più di due volte ‘Wow!’ mentre la osservi, allora è fatta dannatamente bene, almeno in parte!”

Come ho avuto modo di scrivere più volte, non sono un guru e quel poco che so lo devo all’aiuto, diretto ed indiretto, di molte persone. Non potendole ringraziare una ad una – anche se lo meriterebbero – le ringrazio tutte in blocco, “ecumenicamente”.

Non esiste un modello unico ed universalmente valido di programmatore!

Sono convinto che ogni programmatore deve e può crearsi una sua “personalità programmativa“, magari costruita a partire da più modelli validi di riferimento.

In altre parole il programmatore alle prime armi può crescere professionalmente in fretta se impara ad individuare ed a seguire modelli validi, che può trovare quotidianamente e senza che debba sussistere per forza un legame esplicito tipo maestro-discepolo. Possono bastare anche le sole opere, debitamente osservate ed analizzate, come nel mio caso.

Seguire non è copiare spudoratamente, piuttosto assimilare solo le parti che si ritengono davvero buone, perfino da più persone contemporaneamente. Il risultato è appunto una “personalità programmativa” in cui si annidano le esperienze altrui.

Ricordo quando, sempre in università eoni or sono, impararai a progettare e strutturare un sito in certo modo, semplicemente osservando alcuni miei amici intenti a scriverne uno ed a discutere fra di loro sul da farsi: non scambiai nemmeno una parola sull’argomento con loro, però in qualche modo furono miei maestri e io un loro padawan.

Non esistono solo “casi di successo”

Sulla strada per diventare buoni programmatori si trova di tutto, comprese soluzioni eccellenti e in opposizione. A quel punto entrano in gioco altri fattori come ad esempio il proprio “gusto“.

Quando mi son trovato in una situazione del genere, cioè dovendo scegliere fra più opzioni contrapposte (es: due programmatori-modelli che risolvono un problema in modo diametralmente opposto e/o mutualmente esclusivo fra di loro), ho optato per quella più semplice, anche solo apparentemente: il “rasoio di Occam” rappresenta anche un’ottima euristica per scegliere.

Spesso, come è logico supporre, mi è capitato di tornare sui miei passi, ossia rivedere e scartare – a fatica – alcune mie “fissazioni”.

Una soluzione che si è rivelata buona una volta non significa che lo sarà anche in futuro. Idem per le persone.

Fidarsi ciecamente di qualcosa o qualcuno o, peggio, rifiutare a priori il resto è un sintomo di fanatismo, da rifuggire. Il mondo cambia e insieme a nuovi problemi emergono anche nuove soluzioni: rimanere ancorati, cristallizati a qualcosa o qualcuno è rischioso e quindi sconsigliabile.

Ad esempio, per tornare con i piedi per terra, detesto profondamente l’lo stile di indentazione K&R perchè ritengo che rovini l’ordine ed ostacoli la leggibilità del codice rispetto ad altri stili come l’Allman. Eppure, osservando il codice scritto da persone competenti, mi sono ricreduto. Inoltre ci sono casi in cui bisogna compattare il codice il più possibile, ad esempio pubblicando il codice su delle riviste. Ho quindi imparato a tollerarla.

Migliorare!

L’idea alla base è provare a riflettere non solo sul cosa imparare, ma anche sul come: come accrescere le proprie conoscenze, come migliorarsi, come diventare più efficienti, eccetera.

Questa è la parte inizialmente più difficile ma è anche quella che sul medio-lungo termine garantisce i risultati migliori.

Saper individuare e seguire dei modelli validi è un buon modo per favorire questa crescita personale e professionale.

Che ne pensate?

Kranzberg’s laws of technology

1. Technology is neither good nor bad; nor is it neutral.
2. Invention is the mother of necessity.
3. Technology comes in packages, big and small.
4. Although technology might be a prime element in many public issues, nontechnical factors take precedence in technology-policy decisions.
5. All history is relevant, but the history of technology is the most relevant.
6. Technology is a very human activity – and so is the history of technology.

Sulle prime ho riso, poi ho riflettuto, quindi ho convenuto con il loro autore.

1. “La tecnologia non è buona nè cattiva; ma neppure neutrale”

Interessante come punto di vista: la tecnologia risolve bisogno – reale o creato – e per quanto possa essere apparentemente neutra in sè, gli effetti non lo sono.

Verrebbe da citare Alfred Nobel, inventore della dinamite e ideatore del celeberrimo premio che porta il suo nome: grande invenzione ma che a seconda di come viene impiegata ha avuto e ha effetti positivi o negativi, certamente non neutri.

Curiosamente la storia è fatta di scoperte ed invenzioni nate per scopi militari e poi impiegate successivamente anche per usi civili. Di sicuro ogni invenzione spinge avanti il progresso e non si può più tornare indietro, fare finta cioè che non sia mai esistita.

2. “L’invenzione è la madre della necessità”

Questa frase ad effetto mi piace molto e suona ambigua. Personalmente la interpreto come un “l’invenzione crea il bisogno“, nel senso che molte invenzioni moderne nascono col preciso intento di creare nuovi bisogni e quindi spingere l’acquisto dei frutti derivanti da esse. La necessità intesa quindi in senso consumistico.

In realtà, la storia insegna, l’invenzione spesso appare come scoperta casuale e non voluta di ricerche con altri fini. L’esempio prediletto dagli spammer: il Viagra,

“inizialmente studiato per la cura dell’angina pectoris”

In altri casi l’invenzione è invece la risposta a qualche problema specifico o a qualche “prurito” personale:

“Every good work of software starts by scratching a developer’s personal itch.” (The Cathedral and the Bazaar, E.S. Raymond)

3. “La tecnologia arriva in pacchetti, grandi e piccoli”

Altra frase ad effetto, dai molti significati.

Perchè una tecnologia si diffonda, deve essere possibile innanzitutto imbrigliarla, controllarla, trasformarla in qualcosa di pratico e riproducibile, dosarla, inscatolarla per poterla infine vendere in base a qualche criterio, incluso certamente quello dimensionale.

Un’altra interpretazione, abbastanza banale, è relativa al fatto che spesso i primi prodotti di una tecnologia che compaiono sul mercato sono relativamente grossi (es: primi cellulari e, volendo, perfino l’ENIAC!) e man mano vengono miniaturizzati, arrivando a stare quindi in pacchetti molto piccoli e maneggevoli.

Infine, come non citare i pacchetti intesi come unità di trasporto di informazioni, quindi le moderne reti di telecomunicazioni di cui Internet è certamente l’emblema.

Chissà quante altre interpretazioni sono possibili partendo da questa frase…

4. “Anche se la tecnologia potrebbe essere un elemento primario in molte discussioni pubbliche, fattori non-tecnici prendono il sopravvento nelle decisioni che riguardano l’uso della tecnologia”

Dato che gli effetti della tecnologia non sono mai neutri, è ovvio che il suo uso vada discusso ed opportunamente regolamentato. Quindi molti altri fattori non-tecnici hanno pressochè spesso il sopravvento su di essa:

Kranzberg’s Six Laws of Technology, a Metaphor, and a Story

“Fourth Law: [...] many complicated sociocultural factors, especially human elements, are involved, even in what might seem to be ‘purely technical’ decisions.” “Technologically ‘sweet’ solutions do not always triumph over political and social forces.”

Un recente esempio “scientifico”:

US Government tries to restrict publication of details on avian flu virus that spreads among mammals

Although avian flu viruses have infected humans in the past (often with lethal effect), so far, these infections have come directly from birds. Over this past summer, however, researchers presented disturbing results at a scientific meeting. By growing the avian H5N1 virus in mammals for several generations, they had evolved a strain that can spread among mammals (ferrets, in this case) simply through the air. Additionally, researchers identified the mutations that enabled the virus to do so–the kind of information that would be enough to allow any competent molecular biologist to create an exact duplicate.

Like any scientists, these ones want to publish their results, but that’s where things are getting messy. The US National Science Advisory Board for Biosecurity has asked both Nature and Science to “delete details regarding both scientific methodology and specific viral mutations before publishing.” The journals recognize why the NSABB is concerned, but they also both feel that responsible researchers will need to know these details if they’re to effectively study the risk of an H5N1 pandemic.

Currently, both have issued statements that they’re considering the requests, but haven’t yet decided how to proceed.

In questo caso l’aspetto scientifico, che di norma anticipa un eventuale sviluppo tecnologico, scatena reazioni pubbliche che arrivano addirittura alla richiesta di censura (che sempre un grosso errore: cfr. effetto Streisand). Oltre a instillare dubbi sul buon senso di una tale ricerca:

“Serviva davvero mutare il virus o lo scopo era semplicemente ottenere una pubblicazione su una rivista peer-reviewed di prestigio?”

Ogni invenzione, ogni “breakthough” tecnologico comporta qualche sconvolgimento, non necessariamente negativo per tutti.

La Rete, si dice da tempo ad esempio, sta uccidendo l’editoria “classica” e si discute di come arginare questo fenomeno, addirittura a colpi di leggi e leggine. Ma se si valuta nel complesso umano, la sua sola esistenza ha portato anche molti effetti positivi, incluso l’avvicinare un certo grado di istruzione a persone che altrimenti ne resterebbero totalmente privi.

5. “Tutta la storia è rilevante, ma la storia della tecnologia è la più rilevante”

Il fatto che uno storico, in seguito storico della tecnologia, emetta questo giudizio non mi sorprende più di tanto: si potrebbe dire che tira l’acqua al suo mulino. Però, a ben vedere, ogni aspetto umano è toccato da benefici “tecnologici”, frutto di innovazioni vere e proprie. Perfino negli aspetti umanistici fiori fior di letterati, poeti, scultori e artisti hanno innovato, ossia spinto più in alto l’asticella del progresso.

Tuttavia, la Storia raccontata e studiata a scuola tende più a parlare di fatti, date e persone che non a focalizzarsi sul progresso in quanto tale. Non che sia un male, ma ogni tanto è bello scoprire le “innovazioni”, perfino quelle più strane. Ricordo con piacere quando da giovincello mi fu spiegato che fu Napoleone a imporci, fra le varie cose e per editto, che i cimiteri fossero collocati fuori dalle mura cittadine (anche) per motivi igienico-sanitari oltreché politici-ideologici.

Non credo che la storia della tecnologia avrà mai il suo spazio a scuola, però condivido la sua importanza fondamentale per il genere umano.

6. “La tecnologia è un’attivà veramente umana – e così pure lo è la storia della tecnologia”

Esiste una specie di velato e sotterraneo disprezzo reciproco fra i propugnatori della scienze e quelli delle discipline umanistiche. I primi reclamano il progresso come loro bottino di guerra, mentre i secondi la cultura. In realtà tutte queste cose non sono altro che attività umane, spesso intimamente legate le une alle altre al punto che se esiste un confine che le separa, esso è certamente molto labile.

In tutto ciò la tecnologia è un esempio delle capacità del genere umano, qualcosa che ci distingue dalle altre specie animali e ci ha garantito anche la supremazia a livello planetario.

Di rimando, studiare la storia della tecnologia è importante per capire la storia umana e, forse, per favorirne nuovi impulsi. Non a caso su Slashdot è apparso recentemente questo articolo:

Want To Get Kids Interested In Programming? Teach Them Computer History

“With poor IT teaching putting kids off pursuing a career in the computing it is time to look for a new approach. Taking kids back to the time of computing pioneers like John Von Neumann and the first machines — the likes of the Z3, the Eniac and the Colossus — would both inspire them and help get over the fundamentals about how computers work, argues silicon.com.”

Che ne pensate?

Forse una particolare forma di intelligenza? Forse la coordinazione nell’uso degli strumenti di input? Forse la tenacia nell’imparare e nel contempo piegarsi poco a poco al modo di funzionare di una macchina?

Dipende da caso a caso ma, dovendo generalizzare, credo che nessuna di queste caratteristiche sia più importante della mancanza di possibilità e di volontà di osare.

Sani errori di gioventù

Ricordo benissimo quando intorno ai 16 anni, insieme a Windows 95 OSR2, comparve la misteriosa FAT32. Non sapevo cosa fosse realmente, non ne capivo necessità ed uso, ma volevo provarla a tutti i costi.

Tentai quindi la conversione da FAT16 a FAT32 del disco di sistema con il programma fornito dal sistema operativo, ma qualcosa andò storto. Problema: quello era anche il PC di mio papà. Follia giovanile è anche fare qualcosa senza sapere come e perchè: non avevo idea dell’importanza dei dati personali e quindi del rischio di comprometterli o perderli per una “stupida prova“, invasiva e distruttiva.

Le conseguenze furono migliori delle attese, nonostante la sacrosanta furia genitoriale nei miei confronti: un amico di mio papà, il nostro esperto locale di PC, salvò capra e cavoli, recuperando i dati con chissà-quale-strumento e tutto tornò a posto, seppure ancora con la FAT16.

Ovviamente non finì lì il discorso: ci riprovai, fallendo miseramente per la seconda volta.

Questa volta però, invece di darmi per vinto e nella speranza di evitare danni ben più gravi, cercai in tutto quello che avevo – all’epoca la documentazione erano per lo più le riviste specializzate con CD allegato – e riuscii in pieno nel mio intento: ora avevo un disco formattato in FAT32.

Quel giorno andai a letto spossato ma felice. Per evitare guai seri – la reiterazione di un misfatto li induce -, stavolta avevo dovuto imparare cosa fosse davvero un filesystem, cosa differenziasse la FAT32 dalla FAT16, cosa fosse e come usare Partition Magic.

Cosa è ed a cosa serve una sandbox

Ripensando a quanti danni e quanti rischi mi sono accollato per imparare sporcandomi le mani – non crederete certo che mi sia limitato alla FAT32, vero? -, non mi sento di condannarmi. Affatto.

Col senno di poi, tuttavia, mi accorgo solo ora di quanto ho rischiato. Quando commisi quegli errori, i PC erano ancora molto costosi in proporzione al resto dei beni sul mercato ed io, nel corso del tempo, avevo messo a rischio stipendi interi dei miei genitori senza neppure saperlo.

Sostanzialmente avevo fatto di un sistema in produzione la mia personale sandbox, la mia scatola della sabbia con i giochi in cui sperimentare liberamente.

Un grave errore di valutazione il mio, senza però il quale, probabilmente, non avrei proseguito nella mia carriera informatica. Chi non risica, non rosica…

Gran parte dei programmatori che conosco si sono ritrovati nella mia stessa situazione, spesso fin dall’infanzia. L’unica differenza sta nella precocità con cui hanno avuto accesso all’informatica, quindi alle rispettive famiglie: chi ha (avuto) genitori che lavoravano nell’informatica, ha potuto sperimentare prima. Nel mio caso, pur avendo giocato con i PC fin dalle elementari a scuola, ho scelto l’informatica come “stile di vita” solamente quando ho potuto veramente esplorarla da solo, con tutti i guai del caso. Per questo, pur storcendo il naso quando penso alla FAT32 come filesystem “vecchiotto”, mi viene quasi da ringraziarlo, quale che sia una persona in carne ed ossa che mi ha fatto un grosso favore tanti e tanti anni fa.

Qui sta il punto: nell’epoca dei dispositivi iperpotenti, tanto da gestire virtual machine come bazzecole, perchè non insegnare l’informatica in modo “sandboxed”?

Un’umile proposta

Nel mio piccolo ho avuto anche qualche esperienza come insegnante di informatica, tanto per enti pubblici che per privati. Ebbene, lo confesso, non mi sono quasi mai attenuto ai libri o alle “linee guida” imposti dai miei committenti dei corsi perchè l’unico modo per insegnare l’informatica alle persone alle prime armi è liberarle dal rischio e farle sperimentare a piacere.

Un paio di lustri fa, rifiutai una proposta di regolarissimo lavoro part-time come insegnante di informatica di base presso una delle varie aziende di formazione del circondario. Concluso il “training” plurigiornaliero ed appena prima di firmare per “entrare in servizio”, optai per salutare tutti ed andarmene. Non era tanto il dover vestirmi in giacca e cravatta a darmi fastidio (beh, forse un po’ sì: avevo vent’anni!), quanto il dettarmi per filo e per segno cosa dovevo dire e cosa dovevo omettere. Lo scopo “fra le righe”, mai esplicitamente dichiarato, era ovviamente costringere le persone a ripetere il corso più in là. Per mia fortuna me ne accorsi in tempo e fuggii a gambe levate. Rispetto alle mie esperienze successive posso ora dire che quello fu di certo un caso isolato, come “modo di formare” le persone intendo. Nondimeno, ripensandoci di tanto in tanto, mi compiaccio di quella mia “fuga”.

Chi ha mai insegnato ad usare un PC a qualcuno – cosa ben diversa da “insegnare l’informatica di base“! – sa benissimo che il primo contatto con “la bestia elettronica” può essere micidiale. Anche l’essere umano che si sente un guru nel suo campo tende ad accusare il colpo, spesso in modo drammaturgico al limite del tragicomico:

“… come è possibile!? Ci riesce anche la zia Peppina e io no!?”

Qui si inserisce la mia banalissima proposta: perchè non un corso di informatica dentro una virtual machine? Una bella sandbox sicura in cui l’utente può sbagliare quanto gli pare e piace.

Perfino Wikipedia ha la sua bella pagina-sandbox in cui gli utenti possono sbizzarrirsi e provare in totale sicurezza.

Da Wikipedia: In informatica il termine macchina virtuale (VM) indica un software che crea un ambiente virtuale che emula il comportamento di una macchina fisica ed in cui alcune applicazioni possono essere eseguite come se interagissero con tale macchina. [...] Gli usi possibili sono: la simulazione di piattaforme hardware ancora in fase di progettazione (è questo uno degli usi originari) l’emulazione di un sistema operativo diverso da quello realmente installato sul proprio hardware al solo scopo di utilizzare applicazioni sviluppate solo per quello emulato e non per il proprio operazioni di “consolidamento”. Passare cioè da avere x server fisici per x servizi, all’avere un unico server fisico con x istanze del sistema operativo, ognuna delle quali istanze può eseguire uno o più servizi. Ebbene, io aggiungerei un quarto punto: “didattica sandboxed”

Potete sostituire le virtual machine con qualunque altro strumento che garantisca la certezza, reale o presunta, che si possa operare esattamente “come a casa”, potendo perfino distruggere tutto per imparare.

Uno degli aspetti più atroci per uno studente è la non ripetitibilità in solitaria delle nozioni acquisite. In altre parole: si sta attenti, ci si segna tutto per filo e per segno, ma arrivati a casa non si riesce a ripetere da soli quello che si è visto e fatto a lezione. Argh! Disperazione e rovina! Per evitare quella debacle didattica, un primo buon passo può essere il fornire gli stessi strumenti (metodo scientifico docet): l’adattamento o per meglio dire la capacità di uno studente di ripetere qualcosa in un contesto diverso (come può esserlo il PC di casa, diverso nell’HW e nel SO da quello usato a lezione) non è cosa immediata per tutti. Per questo una virtual machine “moderna” (ossia corredata da un’interfaccia grafica semplicata), usabile, clonabile, letteralmente trasportabile e (ri)usabile a casa rappresenta un buon strumento didattico. Come un libro che si usa a lezione e altrove. Di certo è meglio che costringere gli utenti a portare il loro PC “buono” da casa e rischiare di comprometterlo.

Libertà di sperimentazione è l’unico modo per entusiasmare le persone e quindi spingerle ad imparare con le loro stesse mani. Ripudio l’idea dell’insegnante come miserrimo enunciatore e verificatore di nozioni preconfezionate: preferisco l’idea (romantica?) di insegnante come catalizzatore, come casella “Via!” del Monopoli.

Dopotutto, se pensate ai vostri trascorsi scolastici, quali insegnanti ricordate in modo pienamente positivo? Per estensione, non avete forse ricordi spensierati e gioiosi di qualcuno che vi consentiva di provare qualcosa in assoluta libertà e neppure vi sgridava nel caso commetteste qualche errore? Quanto siete migliorati grazie a quei momenti?

Liberate il vostro utente, concedetegli di sbagliare e lui imparerà da solo. Fornite linee guida per non farsi male, non ordini da eseguire. Dategli una sandbox per farsi le ossa e lui vi ringrazierà.

Che ne pensate?

Zawinski’s Law of Software Envelopment

“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”

Una mia personale revisitazione generica di quella legge:

JP’s Law on Software Expansion

“Every software attempts to expand until it can even make coffee. Just before reaching that goal, someone else complains about that huge mess and will start a new tiny replacement project.”

Un buon software è spesso il frutto di un buon compromesso circa il numero di funzionalità incluse e “maneggiabili” da un utente medio.

Quello che molti sviluppatori non digeriscono proprio o fanno finta di ignorare è che l’utente medio si stanca in fretta di trovare sempre nuove funzionalità da imparare nelle sempre nuove versioni di programmi che utilizza: presto o tardi quel tipo di utente si ancorerà a vita ad una specifica release di un dato programma, rifiutando qualunque upgrade, oppure inizierà a cercare qualcosa di alternativo, che soddisfi tutte le sue necessità, ma senza farlo ammattire.

Capisco anche che il marketing spinga costantemente per poter disporre e vendere nuovi prodotti con nuove fantasmagoriche funzionalità, tuttavia questo non coincide necessariamente (o non coincide affatto) con il “Bene” del cliente.

Quante funzionalità può avere uno spreadsheet come Excel, quante ne conoscete e quante ne usate davvero? (Perfino voi cultori di questo genere di programma!)

Mi rendo conto che dare la colpa solamente al marketing sia un’ottima scusante, ma il problema è che noi stessi, gli sviluppatori, siamo i primi responsabili dell’espansione del software: se intravediamo la possibilità di aggiungere qualcosa ad un nostro progetto perchè ci piace o perchè sentiamo che ci serve, è molto probabile che l’aggiungeremo comunque, anche se non è fondamentale.

Arriviamo ad un punto essenziale: il bravo sviluppatore sa dire e sa dirsi no. Sa resistere cioè alle richieste che provengono dall’esterno per aggiungere questo e quest’altro (spesso non necessari se non “per fare numero” sulle brochure) ma sa soprattutto controllare il suo impeto creativo.

Non si tratta semplicemente di negare qualcosa ad un power user (ed uno sviluppatore lo è per definizione!) o un utente alle prime armi, si tratta di bilanciare un prodotto perchè sia usabile da entrambi e senza che nessuno dei due prenda il sopravvento come pubblico-target (a meno di software specifico, ovviamente).

Anzi, diciamocelo, se il software che viene progettato non è pensato per un uso iperspecialistico, dovendo scegliere, è meglio dire no al power user. Tanto quel tipo di utente ha sempre qualcosa di cui lamentarsi, ha sempre qualcosa di cui avverte la mancanza e che vi rinfaccerà alla prima occasione. Se poi è così bravo, magari modificherà o ricrereerà comunque da zero il vostro progetto, a suo uso e consumo. Per cui, perchè inseguire questo tipo di cliente difficile?

I power user – per quanto possa dar loro fastidio ribadirlo – sono numericamente poca cosa rispetto alla restante massa di utenti. Costituiscono certamente una minoranza forte e combattiva, è vero, ma non per questo devono averla sempre vinta.

Nel mondo FOSS è anche peggio…

Il mondo FOSS è una fucina di talento, un porto in cui le persone vanno e vengono, un ambito in cui il software non sta mai fermo. I progetti più importanti lo sono anche e soprattutto in virtù delle comunità che ruotano loro intorno; in ciascuna di esse si annida ogni genere di sviluppatore, da quello che spinge per fare il caffè istantaneo a quello che invece tende a frenare sistematicamente ogni novità.

Prima o poi, passo immancabile, tutti i progetti di successo si trovano alle strette fra “progressisti” e “conservatori” e l’esito di un tale scontro varia a seconda di molti fattori. Il vero problema, tuttavia, sono le frammentazioni del software a seguito di diverbi più o meno espliciti sull’evoluzione dei progetti FOSS.

Prendiamo un “caso storico”, il browser Epiphany:

Epiphany è la naturale evoluzione di Galeon (un progetto amministrato da Marco Pesenti Gritti) che aveva come obiettivo lo sviluppo di un programma che fungesse solo da browser. Il passaggio alla versione 2 delle librerie GTK+ ha portato molte novità (e incompatibilità), così si è optato per la riscrittura da zero del programma: Galeon è stato gradualmente inglobato in Epiphany.

Wikipedia inglese è più esplicita:

“Epiphany is an open source web browser for the GNOME desktop environment. The browser is a descendant of Galeon and was created after developer disagreements about Galeon’s growing complexity.”

Questo è solo un esempio di un vastissimo elenco. L’ultimo in ordine di tempo è il progetto Razor-Qt, l’ennesimo desktop environment, nato leggero, che sembra una reimplementazione di KDE 2/3.

Sul fronte GNOME, il fork di GNOME2, MATE, è invece un buon esempio di progetto nato come prosecuzione di qualcosa di dichiarato deprecato (GNOME2, appunto). Dal sito della distribuzione Mint, a sua volta una derivata di Ubuntu:

“MATE is a fork of Gnome 2 which is compatible with Gnome 3″

Non proseguirò oltre negli esempi. Mi soffermerò però sul punto che reputo essenziale: un software rimane vivo se viene seguito e migliorato costantemente.

“Migliorare” però non è solo “espandere”. Continuare ad aggiungere feature non è fare del bene nè al software (“più roba c’è, più roba si può rompere”) nè agli utenti (“più roba c’è, più gli utenti si romperanno di usarlo”).

Migliorare è prima di ogni altra cosa semplificare, agevolare l’utente medio, magari nascondendo ma non rimuovendo le funzionalità avanzate per i power user. In questo non mi piace nè l’approccio di KDE, zeppo di opzioni e parametri di configurazione anche per le quisquilie più superflue, nè quello di GNOME, troppo zelante nel levare tutto quello che – a sua detta – potrebbe confondere l’utente.

La virtù, al solito sta nel mezzo: un sistema semplice ma estendibile (es: tramite plugin) può far felici tutti i tipi di utenti. Si dà il minimo che l’utente medio può usare, ma anche ai rompisc… ehm… power user la possibilità di personalizzarsi e perfino riprogettarsi il software a loro uso e consumo, senza infastidire il resto del mondo.

Questo è un modo semplice per estendere il software senza renderlo eccessivamente carico fin dall’inizio e, possibilmente, senza spingere qualcuno a reinventarlo da capo.

La fluidità e l’impeto del variegato mondo FOSS sono indubbiamente la riprova che come modello funziona e funziona invero molto bene. Sono però convinto che la frammentazione di questo mondo – e relativa dispersione delle energie – sia una cosa estremamente negativa. Diciamolo, è un effetto collaterale estremamente spiacevole, spesso motivato da egoismo, rancore, pigrizia, … o da qualcos’altro, come la sindrome NIH. Come può sorgere qualcosa di positivo da un tale tipo di atteggiamento?

Che ne pensate! ^^

“Esiste una differenza sostanziale fra il modo con cui ci hanno copiato il ‘made in Italy’. Prendi i cinesi: loro ci copiano e basta, puntano all’imitazione e la qualità non è così importante. I giapponesi invece copiano per migliorare.”

Ora, questa frase ha almeno ventanni, nel senso che risale al periodo in cui mio papà lavorava per una celebre (allora) ditta italiana che produceva bambole, poi scomparsa più per smania di outsourcing che non per un qualche problema aziendale (così sostiene lui, conti e prodotti alla mano).

Sia chiaro: l’intento di questo post non è polemico nè tantomeno razzista (orrore!). Ho citato i nomi di due popolazioni, quella cinese e quella giapponese, ma in un contesto composto di stereotipi, ossia di presunti celebri “copiatori”. Un po’ come quando fanno con noi italiani, appioppandoci pizza e mandolino. Non è giusto, sono d’accordo, ma nascondere i nomi avrebbe reso il discorso un po’ troppo generico per i miei gusti.

In questo post non parlerò di outsourcing quanto vorrei riallacciarmi alla sopracitata frase, ossia al “modo di copiare“.

Sono certo che in essa vi sia una buona dose di risentimento verso chi “ha rubato il lavoro” ma, a sentire mio papà, era la qualità finale che proprio non gli andava giù: spostare la produzione ci può stare, ma darla in mano a qualcuno che fa il lavoro al posto tuo, ma lo fa male seppur a prezzi inferiori, è una situazione imbarazzante ed umiliante.

Imbarazzante per il buon nome della ditta che ci (ri)mette il marchio, umiliante per chi viene sostituito e non si capacita di esserlo stato per colpa di qualcuno che lavora peggio e che “costa meno“.

Cosa ho imparato

Io sono uno sviluppatore di software, non un ragioniere come mio papà, eppure non passa il tempo che non mi ritrovi in quelle parole. Non per gli stereotipi (anche se motivati dall’andamento dalla ditta dove lui ha lavorato), ma per il discorso fra le righe.

Il mercato lo fa chi investe, chi innova, chi si espone e rischia, chi ha un po’ di fortuna (o un surrogato). Il resto del mondo può provare a fare altrettanto, ma molto spesso si può accontentare di ispirarsi o “copiare” quel che può. Ossia imitare l’imitabile, possibilmente evitando di finire vittima di qualche battaglia sui brevetti, magari intentata da qualche “patent troll” di professione.

Un esempio di “reimplementazioni” (eufemismo) di prodotti esistenti è costituito dai cosiddetti cloni: In computing, a clone is a hardware or software system that is designed to mimic another system. Compatibility with the original system is usually the explicit purpose of cloning hardware or low-level software such as operating systems (e.g. AROS and MorphOS are intended to be compatible with AmigaOS). Application software can be cloned simply by providing similar functionality (all word processors have the same basic purpose), but may also be designed to support specific file formats (e.g., OpenOffice.org is intended to supplant Microsoft Office). Clones are created for various reasons, including competition, standardization, and availability across platforms.

Il passo dopo non è da tutti e separa chi copia e basta da chi vuole emrgere: copiare e migliorare, per mantenersi competitivi. Una specie di partita a guardie e ladri dove qualcuno ti copia ma poi si differenzia – e magari si salva pure dal punto di vista legale – apportando dei miglioramenti.

Condividere le conoscenze è una cosa estremamente positiva e spesso anche necessaria quando si lavora con altre persone o con altre aziende. Attenzione però a chi ed a come si forniscono informazioni. Da un articolo recente di The Register: Global arms and aerospace colossus BAE Systems this week released a high-profile audit into its internal ethics and served it up with a big slice of humble pie as it promised to be a better corporate citizen in future. But even as BAE sought to draw a veil over previous alleged indiscretions, it emerged that US officials have speculated that BAE, collaborating with US firms to build the supersonic, stealthed Joint Strike Fighter (JSF), could have allowed secret American military technology to move overseas, raising the possibility that the UK could benefit from expensive American research and development – even perhaps sell it around the world. [...]

Parlare di copie significa chiamare in causa “processi” più o meno legali: si va dalla copia spudorata, magari ottenuta rubando segreti industriale, al reverse engineering brutale o quello più o meno legale (es: clean room design).

Per un esempio di furto di segreti industrali e relativa copia spudorata vi consiglio l’eccellente libro “Sticky Fingers: Managing the Global Risk of Economic Espionage“: veramente un bel libro. Se vi affascina il mondo della “competitive intelligence” più spinta, ne trovate un breve spezzone nel bel film “The Corporation“, in cui parla un professionista di quel settore, Marc Barry. Se vi interessa infine un esempio cinematografico di “copia e miglioramento”, potete trovarlo nel film di fantascienza “Paycheck“, tratto da una storia di Dick, precisamente nel lavoro quotidiano del protagonista: “In the near future, Michael Jennings is a reverse engineer; he analyzes his clients’ competitors’ technology and recreates it, often adding improvements beyond the original specifications. [...]“

Restando nel mondo informatico …

Un esempio famoso è il progetto Hadoop:

“Apache Hadoop is a software framework that supports data-intensive distributed applications under a free license. It enables applications to work with thousands of nodes and petabytes of data. Hadoop was inspired by Google’s MapReduce and Google File System (GFS) papers.”

Un progetto che è nato come reimplementazione di un’idea e pian piano ha preso piede e supporto: l’elenco delle ditte che lo supportano è lungo. Di qualche giorno fa la notizia che anche Microsoft ha iniziato ad impiegarlo e permetterne l’uso nella sua piattaforma cloud, Azure. C’è addirittura chi dice che ormai sia meglio dell’originale da cui trae spunto.

Notate il trucco: rendere le “copie” OpenSource oppure parteciparne allo sviluppo sembra un buon modo per poter copiare, poi estendere/migliorare ed infine guadagnarci, spendendo il giusto e senza esporsi troppo a livello legale.

Chi dice che l’OpenSource fa male al capitalismo? (Sarcasmo)

Morale della fiaba

Con tutto ciò non sto invitando nessuno a copiare il lavoro di nessun altro, sia chiaro. Tuttavia, nel caso questa fosse la vostra scelta, vi invito a non fermarvi alla copia più o meno spudorata, ma a perfezionarla. Se proprio copia deve essere, almeno qualcosa di vostro e di nuovo, mettetecelo.

Rubare le idee di un altro è un atto ingiusto e reprensibile, ma buttarlo fuori dal mercato perchè una reimplementazione delle sue idee costa meno è pure un atto ignobile, di cui vergognarsi. A prescindere da quello che sostiene una certa teoria capitalistica.

Salire sulle spalle dei giganti per un giretto non previsto è un conto, approfittarne spudoratamente facendosi accompagnare ovunque (cioè una copia spudorata ripetuta sistematicamente nel tempo) è un’altra cosa.

Che ne pensate?

Ovviamente, penso non serva uno studio per capirne la portata, mettere in dubbio un acquisto può equivalere a mettere in discussione il raziocinio dell’acquirente.

Come se sbagliare un acquisto fosse una prova della stupidità di una persona…

Indagando sugli acquisti

Non sono uno psicologo nè il marketing è il mio campo, però non credo serva una terza laurea in queste discipline per osservare ed interpretare le reazioni delle persone intorno a noi quando si prova a discutere di acquisti.

Indipendentemente dallo spirito con cui si tratta l’argomento, critico-indagatore o neutro che sia, è facile osservare che l’acquirente di turno tende a mettersi sulla difensiva a priori, soprattutto quando gli acquisti non sono esattamente economici o appaiono insoliti rispetto alle sue scelte abituali.

Ovviamente mi metto nel novero, nel senso che in questo non sono diverso da nessuno: il marketing sa il fatto suo (cfr. bel post “Why We Buy: How to Avoid 10 Costly Cognitive Biases”).

Ad esempio, dovendo parlare di qualcosa appena comprato, si mette le mani avanti fin da subito con frasi come:

“Era in offerta!”,
“L’ho trovato in Rete a poco!” o
“Ho risparmiato un anno intero per togliermi questo sfizio!“

In alternativa lo si compara subito con qualcos’altro, magari ben più costoso e/o meno “potente”, in modo da salvarsi “per comparazione“.

C’è addirittura chi mente sul prezzo di acquisto, abbassandolo, pur di passare per un genio-dell’acquisto-ipescontato o per non farsi sbeffeggiare: salvo i ricchi io-compro-solo-cose-al-top-nei-negozi-al-top-e-mi-bullo-di-questo, il resto del mondo detesta spendere di più per lo stesso oggetto comprato dal vicino.

Tutta questa serie di trucchetti mentali, ho scoperto recentemente, rientra nella cosiddetta razionalizzazione post-aquisto (“Post-purchase rationalization”).

No, non è una malattia!

Da Wikipedia:

“Post-purchase rationalization is a cognitive bias whereby someone who purchases an expensive product or service overlooks any faults or defects in order to justify their purchase. It is a special case of choice-supportive bias.”

A sua volta, il pregiudizio a supporto delle scelte (choice-supportive bias) è così definito su Wikipedia:

“In cognitive science, choice-supportive bias is the tendency to retroactively ascribe positive attributes to an option one has selected. It is a cognitive bias.”

Sostanzialmente si medita seriamente sull’acquisto dopo averlo compiuto, cercando scuse per giustificarlo prima con sè stessi e poi, nel caso, a terzi. Penso sia chiaro che una spesa “insolita” urti prima noi stessi. Da Wikipedia:

“Cognitive dissonance is a discomfort caused by holding conflicting ideas simultaneously. The theory of cognitive dissonance proposes that people have a motivational drive to reduce dissonance. They do this by changing their attitudes, beliefs, and actions. Dissonance is also reduced by justifying, blaming, and denying. [...]

Experience can clash with expectations as, for example, with buyer’s remorse following the purchase of an expensive item. In a state of dissonance, people may feel surprise, dread, guilt, anger, or embarrassment. People are biased to think of their choices as correct, despite any contrary evidence. This bias gives dissonance theory its predictive power, shedding light on otherwise puzzling irrational and destructive behavior.”

Se poi nel frattempo dovessero emergere anche problemi, le “riflessioni interiori” aumentano. Come accettare lo smacco di qualcosa che, a caro prezzo, non ci soddisfa del tutto? Come accettare che il nostro costoso acquisto abbia dei difetti?

Gli esempi di sprecano: quello più comune è il vestito di un certo livello, magari più costoso del nostro “solito” vestito, che probabilmente indosseremo una sola volta o che “per magia” ci sta male appena varchiamo l’uscio del negozio.

Camerini con specchi dimagranti, le donne protestano Gran Bretagna palcoscenico di una singolare protesta: le donne inglesi infatti si sarebbero accorte (solo ora, vien da dire) che nei negozi di diverse catene di abbigliamento sono utilizzati strategici specchi dimagranti che traggono in inganno le clienti e le invogliano a comprare. [...] hanno scoperto che, in effetti, diverse note catene di abbigliamento usano il trucco dello specchio magico. Ma come hanno fatto a capirlo? Molto semplice: mettendo davanti allo specchio sospetto un CD, l’immagine riflessa era ovale.

Di esempi ne possiamo fare all’infinito. Quelli più tragicomici, probabilmente, sono quelli che riguardano i “fissati” delle varie marche: in quel caso l’elemento-brand amplifica ogni cosa.

I fanatici

Non vorrei dover citare nuovamente l’antenna-gate dell’iPhone 4, ma – viva la preterizione! – è troppo gustoso e recente come fatto che proprio non mi riesce di trattenermi.

Non mi interessa il fatto tecnico in sè. Quello che veramente mi ha tramortito – al limite del tipo di risata definita dall’acronimo LMAO – sono state le “arrampicate sugli specchi” di alcuni acquirenti per “giustificare” il bug, l’acquisto e quindi sè stessi. Curiosa questa sorta di “catena di responsabilità“: dall’oggetto costoso alla persona in carne ed ossa che l’ha comprato.

Ho sentito e letto di tutto. Da chi sparava ad alzo zero contro la concorrenza asiatica (se avete pensato qualcosa come “i soliti comunisti sud-coreani!”, la battuta è divertente ma geograficamente e politicamente errata), a chi minimizzava il problema dicendo di non averlo ancora incontrato o che si trattasse di una “leggenda urbana”, chi reagiva d’impeto con vari improperi verso gli intervistatori, eccetera.

Esattamente come i politici che cercano di dirottare le domande scomode sugli avversari: quando iniziano con “e voi allora, che…” o con “non accetto lezioni da …” sostanzialmente stanno ammettendo le colpe, ma non apertamente.

Il “consumatore” che diventa “difensore” di una marca specifica, penso rappresenti l’azimut del marketing per la marca stessa: più una persona diventa un “fan” dei prodotti di una qualche ditta, più “ci mette la faccia”, più ne prenderà a cuore la difesa.

The science of fanboyism

“We’ve all encountered them. They lurk in Internet message boards, comment threads, and chatrooms. Addressing anyone and everyone, they type up lengthy tirades with Cheeto-stained fingers, extolling the virtues of their product or brand of choice. They angrily accuse even the most impartial reviewers of taking handouts from reviled competitors of a beloved company, and they casually and systematically dismiss any evidence that might conflict with their worldview.

They’re known in our parlance as fanboys.”

Non è solo una questione di marche

Non vorrei passare per un saputello. Come ho detto, io stesso sono incline e vittima di questo meccanismo di razionalizzazione sugli acquisti. In realtà, credo, lo stesso discorso esuli da quell’aspetto commerciale, ossia interessi le scelte compiute.

Scegliere è in qualche modo esporsi. Tanto tempo fa, quando ho attraversato il mio momento da fissato del FOSS, mi ero spinto ben oltre quello che avrei voluto e dovuto fare: quando ci si fissa con qualcosa, si finisce ad eccedere nella sua difesa e, di riflesso, nella propria.

Curiosamente il FOSS non è un “brand” in senso stretto, ma è più una filosofia di vita, forse. Tuttavia molti dei suoi difensori lo fanno sembrare tale. Per non parlare dei veri “brand”, che lo usano come un elemento di marketing. Un po’ come la green economy: è una bella cosa, piace e suona bene, alleggerisce un poco la coscienza, fa presa sui “cuori” del pubblico – inclusi gli ambientalisti, incredibile! – e, cosa non da poco, è un marchio che in questo momento tira molto. In questi casi, dove è il limite fra il promuovere il rispetto dell’ambiente ed il marketing di un prodotto?

Schierarsi mette in moto qualcosa attorno a noi che va oltre noi stessi: in breve, mi ero costruito la nomea di “Pinguino”, un fatto che di per sè stesso non mi ha mai dato fastidio. Il problema è che quando qualcuno ti appioppa un’etichetta e tu non fai nulla per levartela di dosso (o, peggio, incoraggi chi hai davanti a farlo), finisce che ogni tua opinione, oggettiva o meno, viene interpretata come soggetta ad un ovvio pregiudizio di fondo. Un po’ come chiedere un parere politico a qualcuno che ha in tasca la tessera di un partito.

Di più: la gente di aspetta che tu risponda sempre allo stesso modo. Se nel tempo rivedi la tua posizione, ammorbidendola o stravolgendola, passi automaticamente nella categoria “voltagabbana” e perfino “ingrato”.

Sostanzialmente sto dicendo che se sei un “fanboy” di qualcosa o la gente attorno a te ti percepisce come tale, è facilissimo finire in una spirale sempre più stretta in cui, ad un tratto, ti accorgi che stai “svolgendo una parte” da cui è difficile uscire. La spirale può portarti a dire cose che non ti saresti mai sognato di dire e quindi, per non rimetterci la faccia, difendere ad oltranza l’indifendibile. Non è facile cambiare idea “pubblicamente”, perchè la cosa ha un impatto non indiffferente anche sul piano sociale.

Nel tempo, non ho paura di dirlo, ho ammorbidito molto la mia visione sul software commerciale. In parte perchè faccio parte di quel mondo – non sono ipocrita -, in parte perchè nel frattempo ho parlato con un bel po’ di persone e ho capito che “ammettere di aver ecceduto” non equivale a dichiararsi incapaci di intendere e di volere.

La stessa cosa negli acquisti: siccome ho imparato che nel prezzo di un bene concorrono alcune voci che non sono funzione della somma dei costi per realizzarlo e promuoverlo, non esito a condannare me stesso quando compro qualcosa di cui non ho davvero bisogno o per il quale potevo spendere di meno.

Credo che questo tentativo, per quanto di minima portata, sia un buon modo per cominciare a spezzare il vantaggio strategico del marketing su di me. Non funziona sempre, ma alcune piccole soddisfazioni me le sono tolte: di tanto in tanto il ricordo del rimorso dell’ultimo incauto acquisto razionalizzato mi spinge ad evitarne di nuovi con troppa facilità.

Non voglio sentirmi nuovamente a disagio per un acquisto di cui non posso essere soddisfatto al 100%.

Che ne pensate?

In questo post vorrei chiarire qualche punto che mi sta decisamente a cuore.

1. Cosa è una metodologia in soldoni?

Una metodologia è prima di tutto un modo rigoroso di fare le cose. Medesimo discorso parlando di filosofia o di modelli di sviluppo: cambiano i termini – spesso usati un po’ a casaccio, come fossero sinonimi perfetti -, ma il succo è quello.

Quando uno sviluppatore si ferma per un attimo e cerca di riassumere cosa ha imparato fin lì, quali sono gli aspetti migliori e ripetibili del suo lavoro, quali sono i passi che sistematicamente ripercorre, ecco che sta già riflettendo sul suo personale modo di operare. Di più: se riesce ad individuare un filo conduttore, un pattern comportamentale ricorrente, probabilmente sta già avvicinandosi alla sua personalissima metodologia.

Detto questo possiamo aprire il discorso anche alle numerosissime e più o meno rigorose nonchè famose metodologie di sviluppo (es: metodologie agili) che riempiono libri e paper a profusione.

O forse no: non importa quale metodologia uno segua. L’importante è che scelga quella più adatta a lui e, nel caso non esista già, crearla. L’importante è estrarre il modo di fare le cose per ripeterle in modo sistematico, senza forzarsi a farlo o perchè “qualcuno ha detto di fare così“.

Se ci si forza a fare le cose sempre allo stesso modo, anche quando non serve, si finisce poi a voler usare il proverbiale “martello” ovunque:

Law of the instrument (A. Maslow): “It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

2. Sceglierne una non equivale ad escludere le altre

Voglio qui ora affermare, in modo esplicito e diretto, un semplice concetto: non esiste una singola metodologia di sviluppo o un metodo/modello/filosofia/quello-che-vi-pare che vada bene a chiunque ed in tutti i contesti.

Questo fatto lapalissiano evidentemente tanto lapalissiano non è: viene spesso dimenticato con l’ovvia conseguenza delle continue guerre di religione fra i fautori di questa e quella metodologia che, al pari dei tifosi di una squadra di calcio, stravedono solo per la loro fazione, ed escludono le altre a priori.

In ambito informatico, voler essere troppo ortodossi nel rispettare alla lettera una qualche metodologia è come decidere di farsi dettare, punto per punto, il proprio lavoro: ho conosciuto persone che, trovatesi bene lavorando in un certo modo, lo impongono a loro stessi e a chiunque abbia la malaugurata idea di porsi loro di fronte.

Per questo genere di persona non esiste provare, sperimentare altro: trovata la loro scelta, quella è e quella rimarrà, almeno che non succeda qualcosa di grave (ma davvero grave), tale da costringerle al cambiamento. Una variazione estrema nonchè rischiosissima del celebre motto:

Squadra che vince non si cambia.

Mai farsi ingabbiare da un insieme di regole troppo stringenti, mai accettare un “lavaggio del cervello” metodologico in nome di qualche presunto e duraturo beneficio. Basta davvero poco per passare dall’ortodossia nel rispettare un metodo al puro fanatismo e quindi alle guerre di religione.

3. Non esiste una scelta assolutamente ottima

Non esiste una scelta ottima perchè i vari lavori, per quanto possano assomigliarsi, non sono mai esattamente uguali: il fatto che l’applicazione di un metodo in un certo contesto si sia rivelata una scelta azzeccata, non dovrebbe renderla l’Unica Opzione. Al massimo, dovrebbe renderla una delle opzioni favorite nel futuro.

Questo perchè nessuna metodologia, o metodo o filosofia è la migliore ed universalmente applicabile con successo: diffidate da chi vi promette la Luna se seguirete questa o quella metodologia. Nell’ambito della crittografia si parlerebbe di snake oil, con lo stesso medesimo significato: “prodotto truffaldino o fasullo“.

Analogamente non esiste – e probabilmente non esisterà mai – qualcosa in grado di aumentare automagicamente ed enormemente la produttività (qualunque cosa essa sia) o l’efficienza di un lavoro semplicemente applicandola.

No Silver Bullet (F. Brooks): “There is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity.”

Il solito esempio personale

La mia posizione, circa le varie metodologie di sviluppo più famose è di scetticismo a priori (cfr. recensione di un libro sulla metodologia agile Scrum).

Forse perchè è naturale aspettarsi che chi ti vende qualcosa – ad esempio un libro – tenda ad esaltare i vantaggi della materia trattata e a dimenticarsi degli aspetti negativi o a diminuirne l’importanza.

La mia strategia sulle varie metodologie col tempo è divenuta sincretica: fusione delle parti che reputo migliori, prese da ciascuna di esse. Nel caso di contrapposizione fra concetti – capita spesso che due metodologie si scontrino più o meno apertamente su determinati aspetti -, compio una scelta esclusiva.

Ad esempio mi piacciono singoli aspetti di Scrum, dell’Extreme Programming, del Tracer-Bullet Development, eccetera. Tuttavia rifiuto di adottarne una – ed una soltanto – in nome della flessibilità di impiego nell’assemblarne una mia.

In “Lord of War“, uno dei miei film preferiti, ad un tratto comprare questa bellissima frase: “Ogni fazione in Africa si attribuisce questi nobili nomi: Libertà, Patriottismo, Repubblica Democratica. Credo che loro non ammetterebbero mai quello che sono in realtà, i peggiori oppressori degli ultimi oppressori. Spesso le maggiori atrocità avvengono quando entrambe le parti in lotta si proclamano combattenti per la libertà.” Credo che lo stesso tipo di ragionamento si possa applicare anche ad un discreto numero di metodologie “mainstream”: molte di esse parlano apertamente di flessibilità d’uso, di rifiuto dei fanatismi, di “libertà” del programmatore, eccetera. Salvo poi indicarti – ooops! – schemi ultraprecisi da seguire e a prova di “eretico”, “consigli” più o meno velati sui libri da comprare, training “ufficiali” da frequentare (ovviamente tutti a caro prezzo), certificazioni da ottenere, eccetera, eccetera. Non di rado da una metodologia si dipartono poi nel tempo varie “scuole di pensiero”, ognuna con i suoi pseudo-dogmi, i suoi pseudo-guru di riferimento, spesso “discepoli” del o dei “fondatori”. Non di rado, infine, si aprono “guerre di religione” fra gli “adepti” delle varie metodologie.

Il pair programming, ad esempio, sulla carta è un modo di scrivere e debuggare il codice molto interessante e probabilmente anche utile.

Tuttavia, salvo rari casi (mentoring?), è difficile pensare di adottarlo in pianta stabile, tantomeno dimostrarne in modo incontrovertibile l’efficienza/efficacia: sembra di sentire quella barzelletta sui carabinieri, che fanno sempre le cose in due ed uno si limita ad osservare o supervisionare.

Bear programming (B. W. Kernighan e R. Pike): “Another effective technique is to explain your code to someone else. This will often cause you to explain the bug to yourself. Sometimes it takes no more than a few sentences, followed by an embarrassed “Never mind, I see what’s wrong. Sorry to bother you.” This works remarkably well; you can even use non-programmers as listeners. One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor.”

Credo che il punto principale sia proprio quello: è fondamentale imparare quanto più possibile di tutto, per scegliere al momento opportuno quale strada percorrere, ma fra più opzioni, non una sola. Il trucco sta nell’infischiarsene bellamente se su un dato libro di un certo autore su una data metodologia viene detto che, se non la si segue tutta ed in modo rigoroso, accadranno le “peggio cose“.

La mia personale strategia, alla base del mio sopra-citato “sincretismo metodologico”, è quello che gli anglofoni definiscono cherry-picking, ossia prendere qui e là le idee che reputo migliori e confezionare qualcosa di nuovo. Mi sono perfino capitati diversi casi in cui ho adottato una certa strategia o metodologia per poi ritrovarmi ad usarne una “opposta” in un altro progetto.

Questo vale anche per le coding convention. Esempio classico, “metodologico” per come opero io: detesto lo stile di indentazione K&R e nei progetti che seguo io, se posso, lo evito. Ma dovendo estendere del codice altrui già esistente e/o dovendo scrivere del codice in un linguaggio in cui è la norma, allora me ne faccio una ragione perchè reputo la consistenza del codice più importante dell’aspetto esteriore o dei miei gusti. Questa regolina fa parte della la mia personalissima “scala dei valori” nonchè del mio modo di fare.

Detto questo, possiamo aprire il discorso sogni.

Skunkworks

Ogni sviluppatore presto o tardi si “invaghisce” professionalmente di qualcosa o di qualcuno, diventandone una sorta di “fan”. Il mio modello/non-modello preferito nonchè sogno-ultimo-definitivo si chiama Skunk Works:

Skunk Works is an official trademark for the Lockheed Martin Advanced Development Programs (formerly Lockheed Advanced Development Projects).

The designation “skunk works”, or “skunkworks”, is widely used in business, engineering, and technical fields to describe a group within an organization given a high degree of autonomy and unhampered by bureaucracy, tasked with working on advanced or secret projects.

Perchè? Semplice: chiunque sia stato in grado di produrre l’SR71 “Blackbird”, il mio aereo militare preferito fin da quando ero bambino (nonchè base dell’aereo degli X-Men), sa il fatto suo. E i tizi in questione hanno progettato gran parte degli aerei militari più “spettacolari” in circolazione, per cui conoscono davvero bene il loro mestiere.

Sia chiaro: non sono mai stato un “guerrafondaio” e nemmeno un amante delle armi. Tuttavia, da tecnico, non posso non rimanere affascinato dai continui e ben foraggiati progressi della tecnologia bellica. Non a caso il “Blackbird” non era un caccia ma un ricognitore strategico statunitense, capace di una velocità di Mach 3+.

Anzi, sono così bravi nel loro ambito che ormai il nome del loro dipartimento è diventato l’emblema del loro modo di lavorare e viceversa:

“A skunkworks project is one typically developed by a small and loosely structured group of people who research and develop a project primarily for the sake of radical innovation. [...]

A skunkworks project often operates with a high degree of autonomy and unhampered by bureaucracy, tasked with working on advanced or secret projects. These projects are often undertaken in secret with the understanding that if the development is successful then the product will be designed later according to the usual process.”

Innovazione radicale al limite del dovere alla segretezza, autonomia e poca burocrazia: credo sia il sogno di qualunque sviluppatore. Lo è anche il diventare un simbolo di efficienza, ovviamente.

Come dite? Non è un modello ma una filosofia o un contesto operativo o una metodologia? Beh, a dispetto della scelta della terminologia che si può impiegare per definirlo, “skunkworks” continua ad essere il mio punto di riferimento “onirico” ad alto livello, su cui poi innestare tutto il resto.

Che ne pensate?

Il trucco più banale è che la documentazione “viva” parallelamente a ciò a cui si riferisce: un conto è doverla scrivere a lavoro concluso, un conto è farlo pian piano, a lavoro in corso.

Inoltre, per esperienza, fare le cose a lavoro concluso coincide spesso col doverle fare di fretta, all’ultimo momento utile. O, peggio, a distanza di qualche tempo, il che espone il documentante a dover ricostruire mentalmente e poi mettere nero su bianco quello che ha fatto.

A parte tutto questo, abbastanza logico e banale, vorrei sottolineare un paio di cose.

Documentare è dimostrare

Dal momento che, per ragioni pratiche, la documentazione viene generalmente scritta di pari passo con il relativo lavoro, essa appare come dimostrazione chiara ed accessibile del lavoro stesso: nessuna persona seria si sogna di scrivere di aver fatto qualcosa quando in realtà non l’ha compiuta; piuttosto scriverà meno, per omissione deliberata o per dimenticanza, non di più.

Corollario: la documentazione, se scritta in modo comprensibile, è l’equivalente di un “reperto” valido ed intellegibile per la “corte”-committente. Il codice di per sè stesso non è pressoché mai una prova accettabile, almeno fintanto che non lo si manda in esecuzione e si verifica che faccia tutto quello che dovrebbe fare.

Una buona documentazione è una valida autocertificazione del vostro operato.

Istantanea della situazione attuale

Se la documentazione viene scritta ed aggiornata di pari passo col lavoro, essa riflette esplicitamente lo stato di avanzamento lavori.

Nessuno vieta di mantenersi una traccia delle novità introdotte nel tempo (changelog), in modo da poter ricostruire i vari momenti di lavori (e le feauture inserite) anche e soprattutto in un secondo momento. Tuttavia, a differenza di un documento di specifica, non è utile nè elegante accludere l’eventuale changelog direttamente nella documentazione stessa.

Il cliente-medio non ha tempo nè voglia di spulciare in profondità anche quel tipo di informazione-extra – le novità introdotte a partire da una data versione -, per cui quello che deve ottenere deve essere sempre e solo l’ultima versione nota della documentazione, senza indicazioni di revisione o altro. Questo non significa però che, fornendo al committente una nuova e completa edizione della documentazione, non gli si possano anche indicare, magari in un altro piccolo documento (mail?) le singole novità rispetto alla versione precedente (riassumere le modifiche rispetto a più di una versione fa rispetto a quella attuale, diventa improponibile e via via sempre più inutile).

Nuovamente, la documentazione ed il suo eventuale changelog possono servire come prova chiare ed esibibile.

D’altra parte è ben difficile ricostruire la storia di un progetto partendo dal log dei commit di un versioning/revision control come Subversion o Git: nei sistemi come SVN ci finisce di tutto, soprattutto dettagli di basso livello (es: modifiche al codice) che poco hanno a che spartire con la documentazione di più alto livello.

Un conto è la documentazione del codice, un conto è la documentazione del progetto. Non confondete i livelli altrimenti correrete il rischio di porgere una mela a chi vi chiede una pera.

Il primo, vero utente della documentazione

Non ho stime o percentuali da riportare – supposto ne esistano – ma non mi pare proprio che la documentazione goda di grande successo presso il pubblico/utente finale (eufemismo): quante volte avete (abbiamo) comprato qualcosa e avete (abbiamo) deciso di usarlo subito, senza guardare la documentazione? Diciamocelo: il manuale viene letto quando le cose stanno già andando male o quando le cose non sono abbastanza facili ed intuitive da essere usate.

Sarò eretico: così come nella mia testa ogni nuova legge che uno Stato introduce è una sconfitta per la porzione di genere umano che esso amministra, incapace di stare a suo posto senza imposizioni dall’alto, ritengo che costringere l’utente medio a dover leggere un manuale per poter compiere azioni ragionevolmente banali con un prodotto sia uno scorno alla sua intelligenza ed ad una serie di “paroline magiche” come usabilità, accessibilità, eccetera. Detto questo e a prescindere dalla credenza popolare – che tende a fare di tutta l’erba un fascio – non tutto è sempre così intrinsecamente facile da non necessitare di un manuale per essere utilizzato, soprattutto quando c’è in gioco la vita di qualcuno. Continuare a semplificare le cose con la speranza di renderle alla portata di tutti può significare ridurre o limitare certe funzionalità, scontentando un po’ tutti.

Trovandomi recentemente a dover cambiare la batteria ad una bilancia elettronica da cucina da circa 30€, tutto mi sarei aspettato tranne il dover premere un’astrusa combinazione di tasti prima e dopo la sostituzione fisica della batteria per avviare la complicata fase di ricalibratura dello strumento. Fra l’altro una combinazione di tasti degna del peggiore dei videogiochi sulla piazza. A quel punto il manuale utente, che alla fine mi sono rassegnato a consultare, ha certificato, qualora ve ne fosse il dubbio, l’incontestabile imbecillità di chi ha pensato quell’assurda procedura.

Col software è la stessa cosa. Ditemi quante persone conoscete che hanno iniziato ad usare il computer avendo prima letto, almeno in parte, un qualche manuale. Probabilmente risponderete 1 o 2 in tutta la vostra vita e questi individui rientrano nella categoria paranoide al limite del mi-muovo-solo-se-ben-informato-perchè-se-no-lo-rompo per cui non contano ai fini statistici.

Per cui, non potendo comunque evitare di scrivere la documentazione, la domanda che ogni persona si dovrebbe porre è: chi è il suo primo pubblico e quale dovrebbe essere il suo scopo essenziale?

Rispondere è facile: il primo utente e pubblico è lo sviluppatore stesso ed il suo scopo è levarlo d’impiccio dalle emergenze del cliente.

Invece di perdersi in parole e parole per spiegare fin da subito, nei più infimi ed inutili dettagli, ogni singola funzionalità integrata, che nessuno ragionevolmente userà mai, basta spiegare al meglio come risolvere i problemi (troubleshooting) più comuni, come effettuare operazioni particolari o avanzate, come contattare il supporto e/o a chi rivolgersi in caso di necessità. Questi gli aspetti prioritari, poi ovviamente tutti gli altri.

La documentazione prolissa, al pari di quella sintetica e precisa, con tutta probabilità verrà ignorata fino a quando non sarà davvero necessario. Tuttavia, visto il momento più probabile in cui verrà effettivamente utilizzata nonchè la fretta di arrivare ad una piena soluzione, la documentazione asciutta ed accurata farà la differenza. Ed i clienti saranno immediatamente felici, evitando di dovervi ripetutamente infastidire: un effetto collaterale, normalmente molto piacevole, dell’essere contenti di essere riusciti a risolvere un problema da soli.

Date il giusto peso ai contenuti della documentazione in base all’uso più probabile. Non pensiate che la documentazione sia completa perchè descrive un po’ di tutto: concentratevi e date al cliente quello che gli può ragionevolmente servire. Se il cliente è in grado di risolvere i problemi più comuni dei vostri prodotti da solo, in fretta e senza impazzire a dover cercare informazioni in un mastodontico manuale utente, risparmierete “automagicamente” un sacco di tempo e di soldi: la documentazione come kit di automedicazione per il cliente. Fissate quello che la vostra documentazione-modello deve avere e revisionate questo modello nel tempo, rispetto a quello che i vostri clienti richiedono con maggior frequenza. Partendo dal presupposto che, come direbbe Platt “Il tuo utente non sei tu” voi non siete i destinatari finali della documentazione, però siete i primi a poterne beneficiare. Se la documentazione è a posto, potete rapidamente rimandare i clienti ad essa: la documentazione come kit di autodifesa per voi stessi. Come si dice in questi casi: RTFM! (Ecco, magari non proprio con questi termini ma con parole più “tranquille”, ma il senso fra le righe è quello).

Che ne pensate?

L’esempio più semplice sono le strutture C, che compaiono qui e là, con campi marcati deliberatamente “reserved for future use“. L’idea di fondo, tuttavia, è ubiqua, direi quasi quotidiana per tutti: ogni volta che qualcuno individua un possibile reimpiego di un programma, ecco che nel codice ne compare per magia altro, che al momento non serve.

Esiste ma non viene (ancora) usato: rispetto allo scopo originale, è puro dead code a livello semantico. Viene messo come segnaposto, come warning esplicito, per ricordarsi di quell’uso futuro e ancora non meglio precisato.

Talvolta ci si imbatte in campi di strutture marcati come “reserved for future use” ed impiegati solamente come riempitivi non utilizzati (filler/padding), per arrivare ad occupare una data dimensione di spazio oppure per rispettare qualche vincolo di allineamento. In sostanza si tratta di spazio al momento sprecato, per cui marcarlo come “non usato” o come “riservato per usi futuri” sembrerebbe voler dire la stesa cosa. In realtà c’è una differenza abissale perchè la seconda variante suona come un preciso messaggio di avvertimento agli incauti programmatori utilizzatori: “Al momento non lo usiamo, ma questo non significa che puoi e devi usarlo tu. Gira al largo, bellimbusto!” In questo post mi riferisco invece a codice che contiene deliberatamente altro codice, al momento inutile, lasciato come un post-it sul frigorifero, in modo da annunciare a chi passa improbabili estensioni future. Lo stesso vale per quello che ruota intorno al codice, ad esempio la documentazione.

Non è uno sbaglio di per sè, ma aggiungere fin da subito del codice per qualcosa che verrà è una scommessa col futuro che difficilmente può essere vinta.

Per esperienza, pur mettendoci tutto l’impegno e la passione del caso, devo ammettere che questo tipo di strategia non mi ha mai dato soddisfazione: 99 casi su 100, è più facile rifare qualcosa da zero, magari riusando del codice o dei piccolo moduli autocontenuti da qualcosa di esistente, che intestardirsi ad estendere qualcosa di grosso e particolareggiato. Già è spesso difficile arrivare alla fine di un progetto, con continui cambiamenti nei requisiti e nelle funzionalità offerte, figuriamoci predisporre un prodotto per un futuro e completo “retargeting“.

Non sto parlando certo di videogiochi, di “modding” e men che meno “total conversion”, che alla fine producono ancora videogiochi, quindi mantengono lo stesso target: parlo di prodotti customizzati per un dato cliente ed estesi, reinventati per altri tipi di clienti.

Pre-estendere qualcosa senza sapere come o perchè è come sparare a caso. Inoltre significa accettare l’idea di avere un piede in due scarpe ed una non si sa bene dov’è finita.

Un approccio migliore: l’architettura a plugin

Credo che l’approccio migliore sia progettare la struttura portante del codice per essere estesa, non inserire già dei riferimenti ai futuri usi.

Cioè, se state scrivendo un programma che supporta diversi formati di file, è meglio pensare a come inserirne altri, in un secondo momento, non cominciare ad aggiungere già del codice per supportarne un altro (presunto) paio.

Progettare un sistema modulare, magari con un’architettura a plugin, è un ottimo esempio di strategia per aggiungere funzionalità a del codice pre-esistente, senza doverlo per forza riaprire se si tratta di un sistema a caricamento dinamico, a runtime. Da Wikipedia:

“Il plugin in campo informatico, è un programma non autonomo che interagisce con un altro programma per ampliarne le funzioni. Ad esempio, un plugin per un software di grafica permette l’utilizzo di nuove funzioni non presenti nel software principale.

La capacità di un software di supportare i plugin è generalmente un’ottima caratteristica, perché rende possibile l’ampliamento e la personalizzazione delle sue funzioni da parte di terzi, in maniera relativamente semplice e veloce.

Ciò favorisce da un lato la minore obsolescenza del software e dall’altro la maggior diffusione, tanto più sono numerosi e funzionali i plugin scritti per uno specifico programma o secondo uno standard specifico: ne è un esempio il successo commerciale dei software di produzione audio di Steinberg, legato alla larga diffusione dei plugin musicali in standard VST.

Per facilitare il compito agli sviluppatori di terze parti che intendono realizzare dei plugin, l’azienda produttrice del software o ideatrice dello standard distribuisce – spesso gratuitamente – dei sistemi detti Kit di Sviluppo Software (Software Development Kit o SDK), che racchiudono funzionalità, esempi e documentazione per lo sviluppatore.”

Durante il periodo della “rivoluzione MP3″ iniziata con Napster, il lettore software per antonomasia era WinAMP, tuttora esistente. Nel 1998 fu riscritto per supportare un’architettura a plugin che permettesse a terzi di estenderlo a piacere. Fu un imponente successo: ovunque comparvero plugin per aggiungere questo e quello a quel programma, aumentandone usi e quindi diffusione. Ad agevolare il tutto, un buon kit si sviluppo, una buona documentazione e perfino un libro-manuale, “MP3 Power! With Winamp“. Il bello è che WinAMP non è mai stato un progetto OpenSource ma freeware e poi shareware, quindi codice chiuso. Se ben pensato, un’architettura a plugin permette anche a programmi proprietari di essere estesi da terzi senza dover rivelare nulla dell’interno (black box). Nuovamente: le interfacce sono e fanno la differenza.

Perchè impiegarli?

L’approccio a plugin generalmente è un buon modo per costringersi a strutturare bene le cose, anche se un domani non li si userà davvero per estenderli.

Tuttavia modellare le cose a plugin non è sempre indicato – non tutti i programmi si prestano o necessitano davvero di questo tipo di soluzione – e può facilmente rivelarsi un overkill/overhead notevole, almeno nei primi momenti di vita di un software.

Molti prodotti famosi – lo stesso Winamp è un esempio – nascono come monolitici o modulari (librerie statiche e dinamiche) ma comunque intrinsecamente statici e solo successivamente, in una major release successiva (v2.0+), riscritti per includere il supporto ai plugin.

Ho detto riscritti e non semplicemente rivisti, perchè l’architettura a plugin è profondamente invasiva e permea/tocca tutto il software, che deve essere adeguato per supportarla. Il tutto, se fatto tardi, diventa facilmente costoso in termini di tempo e risorse da impiegare.

Se dovete scrivere un programma ed immaginate fin da subito una o più espansioni successive, valutate bene se è il caso includere immediatamente un’architettura a plugin. Il tutto per tenervi aperta una porta verso sviluppi futuri, senza però sacrificare le funzionalità attuali e senza aggiungere dell’inutile codice segnaposto.

Diventa quindi e prima di tutto un discorso di interfacce, di moduli pensati “decoupled“, ossia indipendenti, rimpiazzabili ed estendibili a piacere. Le interfacce sono tutto: se sono ben pensate, definite, modellate, sapranno servirvi in modi ed in tempi che non sospettate. Inoltre, come ben indicato da Wikipedia, si può arrivare addirittura a veri e propri standard.

Un esempio di “standard” per plugin è rappresentato da NPAPI, un sistema di creazione di plugin multipiattaforma per il “vecchio” browser Netscape. Da Wikipedia: La NPAPI (o Netscape Plugin Application Programming Interface) è un’architettura multipiattaforma per i plugin utilizzata da molti browser web. Sviluppata inizialmente per la famiglia di browser Netscape, a partire da Netscape Navigator 2.0, è stata implementata in seguito in altri browser, tra cui Mozilla Application Suite, Mozilla Firefox, Safari, Opera, Konqueror ed alcune versioni di Microsoft Internet Explorer. Il suo successo può essere in parte attribuito alla sua semplicità. Un plugin dichiara di gestire alcuni tipi MIME (ad esempio “audio/mp3″) mediante le informazioni sui file presentati. Quando il browser incontra tale tipo di contenuti carica il plugin associato, delimita lo spazio all’interno dell’area di visualizzazione da assegnare al plugin, e infine vi trasferisce dati. Al plugin viene, quindi, assegnato il compito di gestire i dati nel modo più opportuno, sia esso visivo, audio o qualunque altra cosa. In questo modo, un plugin viene eseguito nella propria parte di pagina, a differenza dei browser precedenti, che dovevano lanciare un’applicazione esterna per gestire i tipi di contenuto a loro ignoti. L’API richiede che ogni plugin implementi e pubblichi un numero abbastanza piccolo di funzioni. Si tratta approssimativamente 15 funzioni in totale per l’inizializzazione, la creazione, la distruzione e il posizionamento dei plugin. La NPAPI supporta anche lo scripting, la stampa, la visualizzazione a schermo intero, i plugin windowless e lo streaming dei contenuti. Non è un caso che questo “standard“, semplice e ben definito, sia sopravvissuto a tutte le traversie della società che l’ha prodotto, Netscape, e sia tuttora usato con successo anche da altre aziende e a dispetto della sua età.

Per quanto una strutturazione a plugin sia ottima per permettere estensioni di terzi, non fate l’errore di credere che siano adatti ed applicabili solo a quel caso: potete benissimo sfruttarli anche e solo per un uso interno! Vi basta non rilasciare la documentazione delle interfacce all’esterno e solo voi godrete della possibilità di usarli.

Che ne pensate?

Quando si sente un tipo di affermazione come questa è normale restare perplessi, almeno sulle prime: è come se un maestro ammettesse candidamente alla sua classe di aver letto ed imparato una lezione giusto pochi minuti prima di spiegarla. Scioccante, sincero, sublime.

A tratti è la stessa cosa che capita anche a me quando scrivo un post…

Provocare l’ispirazione

Più volte mi è stato chiesto come produca i post ossia da dove provenga l’originale ispirazione ideatrice. Come per molte altre persone – pressochè tutte? – la mia ispirazione si origina da qualcosa che mi colpisce durante la settimana. Di solito, quando arriva, mi appunto giusto un’idea di titolo – o più di un appunto, se la settimana è particolarmente propizia -, che poi estendo durante il weekend, fino ad arrivare al post del lunedì.

Eppure, come molti seri scrittori – io non lo sono, sia chiaro! – sperimentano, non basta aspettare l’evento-manna dal Cielo settimanale: si arriva facilmente a prolungati momenti di “vuoto”, il cosiddetto e temuto “blocco dello scrittore“. Anzi, tantopiù si cerca qualcosa da cui ricavare un pezzo, tanto più si rimane incastrati dalla mancanza di argomenti utili ed interessanti da sviscerare. Sembra quasi che più cerchi l’ispirazione, più essa si nasconde, si volatilizza.

Nella mia modesta esperienza di gestione di un blog ho imparato a non forzare la mano, tentando di scrivere un post su qualcosa nato più per necessità (di avere il post del lunedì) che per convinzione (di avere un argomento valido). In altre parole ammetto la possibilità che prima o poi rimarrò senza un post per una o più settimane: come una nave a vela che non si sposta senza un alito di vento e che attende che quest’ultimo riprenda a spirare, prima o poi. Accettare di poter rimanere “a secco” ha un che di rilassante e toglie le basi al vero problema connesso al “blocco dello scrittore”: il panico, illogico ed immotivato, di sentirsi bloccati indefinitamente, ossia di non riuscire più a riprendersi. A differenza di uno scrittore professionista, io non vivo di e per questo blog, per cui posso permettermi qualche rallentamento e perfino di smettere di scrivere da un giorno all’altro, senza preavviso alcuno. Questa è libertà.

Col passare del tempo e, soprattutto, riflettendo sulle parole del Dodo, ho scoperto e notato che il suo discorso si può applicare con profitto anche allo scrivere i post: scrivere i post può essere il frutto dell’imparare e viceversa.

Il meccanismo e semplice: si può forzare l’ispirazione imparando qualcosa di utile e provando a descriverlo in un post, ad un pubblico teoricamente più ampio e meno definito rispetto al caso di una “classe” che segue le parole del suo docente.

Dico di più: scrivere qualcosa con l’intento di spiegare qualcosa a qualcuno – e quindi non solo per un mero egoismo intellettuale – spinge a fare le cose in modo migliore: si impara meglio per descriverlo meglio.

Ciò rappresenta uno stimolo incredibile, qualcosa che va ben oltre il sentirsi in qualche modo obbligati a produrre il solito, ennesimo post settimanale: si impara per poter scrivere e si scrive per poter imparare.

Se il risultato è decente, a questo punto, il gioco vale ampiamente la candela.

Appunti di vita vissuta

Questo blog non è affatto un diario, anche se molte delle cose che leggete hanno una precisa collocazione temporale (di solito le lascio decantare per un po’, ma non sempre) e delle cause precise che mi hanno spinto a scrivere.

Lo confesso: non mi piace scrivere perchè sono intimamente pigro, ma quando sono ispirato posso tirare avanti per ore e ore senza rallentamenti o ripercussioni psicofisiche di sorta. Forse è proprio il fatto che non mi sforzo, che mi sento libero di scrivere o non scrivere, a facilitarmi il compito: dove c’è l’obbligo, la passione, l’entusiasmo ed il divertimento scemano.

Col tempo ho imparato a non cercare l’idea ma a provocarla, lasciandomi incuriosire da quello che mi accade intorno. Ho imparato a segnarmi da qualche parte quello che di nuovo e di curioso trovo ogni giorno e poi, col trucco del blog, fare leva ed impararlo in modo migliore, come se dovessi davvero esporlo ad un pubblico che si aspetta da me delle delucidazioni, che pende dalle mie labbra.

Un ottimo ed eccellente artificio mentale per battere la pigrizia, per spingersi ad approfondire qualcosa, per provare a migliorare un poco il proprio stile di scrittura, per progredire a livello professionale ed umano. Un esercizio di stile che, escluso il tempo e lo sforzo da impiegare in modo abbastanza costante, ha solo dei vantaggi.

Il mio professore di linguaggi di programmazione all’Università – e non solo lui a dire il vero – soleva ripeterci che l’unico modo per imparare davvero un dato linguaggio è scrivere codice su codice, non limitarsi ad impararne le relative nozioni, pedissequamente lette su un libro dedicato, col solo scopo di superare un esame.

Beh, credo che il discorso non valga solamente per i linguaggi di programmazione, ma sia generalizzabile a qualunque linguaggio, incluso quello naturale: più uno si sforza di scrivere, più migliorerà (repetita iuvant), anche solo per inerzia. O così voglio sperare che sia.

Che ne pensate?

In termini ironici è la legge di Murphy che si concretizza di colpo, nel momento peggiore. In termini lavorativi può invece significare una strigliata o addirittura il licenziamento in tronco di qualcuno, anche se non ne ha colpe.

Sfortunatamente evitare del tutto questi eventi è al di fuori della portata umana: si può ridurre il rischio di molto, ma non rimuoverlo del tutto.

Con i termini “effetto demo” mi riferisco a quello che gli anglofoni definiscono propriamente “technical difficulties” (problemi tecnici). La traduzione letterale in inglese, “demo effect” si riferisce infatti a ben altro, ossia alle competizioni fra programmatori appartenenti alla cosiddetta demoscene.

Un’atroce, spiacevole esperienza in pubblico

Mi piace molto questa definizione:

effetto demo loc.
– Una prova ontologica dell’esistenza di Dio. Non vi è nulla di strano nel vedere una persona che non riesce a ripetere un’azione per lui abituale in presenza di personaggi importanti: si sa che l’emozione gioca brutti scherzi. Un programma, però, non dovrebbe provare alcuna emozione. Eppure tutti coloro che hanno dovuto fare una demo sanno che il mattino della presentazione sicuramente qualcosa non funzionerà, nonostante non si sia modificato nulla. Come mai?

L’effetto demo è il terrore di ogni persona che deve presentare qualcosa a qualcuno, sia esso un collega, un capo, un cliente, un fornitore, un passante sconosciuto. È quell’evento che si verifica quando, pur avendo provato e riprovato tutto mille volte, qualcosa inaspettatamente cede e vi ritrovate, follemente imbarazzati, a:

1. tentare di sistemare il problema sui due piedi, nel giro di pochi istanti, spesso senza riuscirci e davanti alla platea che vi scruta perplessa e/o rumoreggia;
2. tentare di spiegare alla platea cosa è successo;
3. elemosinare la pietà del pubblico, magari alleggerendo la tensione con qualche battuta;
4. cedere all’impossibilità pratica di sistemare il problema e proseguire “a voce”.

Esistono infinite variazioni sul tema, ma il risultato pratico è che, senza un colpo di reni scenografico, la presentazione fallisce. Sopratutto se entra in scena il panico o si avvicina a spron battuto il momento di andare a mangiare un boccone o di bersi un caffè.

1. Quello che si può fare prima

Non sono un esperto di presentazioni però ho avuto il piacere di osservarne alcuni, di persona o via Internet, per cui prendete quello che scrivo con le molle.

Il bello di Internet è che vi si trova di tutto: c’è così tanto materiale che spesso non serve conoscere qualcuno di persona per conoscerne le opere e le idee.

Un buon presentatore prepara tutto e lo ricontrolla mille volte: situazioni particolari a parte – es: ritardi -, non arriva all’ultimo momento utile per allestire al volo la presentazione.

Ad essere onesti, ho visto persone farlo, ma evidentemente non erano persone alle prime armi: preparavano il materiale e nel frattempo iniziavano subito a presentare, per non perdere tempo. La cosa che mi ha colpito è che erano in grado di mantenere il pubblico coinvolto su di loro, sulle loro parole, e non su quello che stavano frettolosamente montando. Il tutto senza fermarsi, senza dover interrompere il discorso per cercare qualcosa o qualcuno (forse è questo il perchè il pubblico rimane concentrato).

Ogni cosa deve andare bene. C’è chi si porta un sistema ridontato/ridondante in valigia: non un doppio portatile, ma tutti i suoi cavi doppi, alimentatori universali, dischi esterni di backup a profusione (cfr. “Avoiding Technical Difficulties in Presentations“). Il tipo di persona che se, nonostante tutto, non ha qualcosa, potete stare tranquilli che la prossima volta non mancherà di portarne almeno un paio.

Se anche l’organizzazione fornisce e spergiura sulla qualità del materiale, il bravo speaker, notorio paranoico forgiato dal fuoco di mille presentazioni, si porta comunque le sue cose da casa e preferisce usare quelle perchè si fida solamente delle cose su cui ha il controllo.

2. Quello che si può fare durante

Nonostante tutti gli accorgimenti possibili ed immaginabili, non c’è verso di sfuggire all’effetto demo. Perfino gente collaudata come il compianto Jobs, un’autorità incontestata delle presentazioni in pubblico, si è trovata a fronteggiare questo problema più di una volta.

Memorabile, ad esempio, quando ha “convinto” la platea a spegnere gli hotspot Wifi per consentirgli di proseguire con la demo di FaceTime.

Osservate bene questo video: non capita tutti i giorni una richiesta di quel genere proveniente dallo speaker. Una sala piena zeppa di connessioni wireless – decisamente troppe per poter presentare senza interferenze e crash – e Jobs che “velatamente” (una specie di “o così o ce ne andiamo a casa: scegliete voi!”) ordina al pubblico di spegnerle e, per giunta, di guardarsi attorno per controllare che tutti lo facciano davvero. Poi, un paio di battute, giusto per alleggerire la tensione.

Si sentono le persone ridere e poi eseguire l’ordine: l’oratore ha superato l’impasse dell’effetto demo, senza andare in panico, addirittura interagendo con la platea. La richiesta insolita e l’autorità/autorevolezza trasmessa da Jobs hanno fatto la magia, capovolgendo la situazione da sfavorevole-ma-comunque-sotto-controllo a risolta-senza-panico-e-col-sorriso-sulle-labbra.

Ad un evento negativo durante una presentazione, sia essa a poche o a molte persone, si reagisce prontamente:

• senza perdere tempo a spiegare nel dettaglio cosa è successo al pubblico (errore madornale, anche se il pubblico è in grado di capire le spiegazioni);
• senza spiegare i passi che si intendono intraprendere per risolvere il problema (perdita di tempo: “fallo e basta, se puoi!”);
• senza buttarla sull’(auto)ironico o piangersi addosso per l’accaduto;
• senza cercare la solidarietà del pubblico;
• senza fermare lo show, invocare l’aiuto – spesso tardivo – di qualcun altro;
• senza infuriarsi, imprecare, manifestare eccessivo fastidio per la situazione;
• senza lasciar trasparire sul suo volto o con i suoi atteggiamenti la benchè minima goccia di panico.

Jobs ha reagito cercando la collaborazione del suo pubblico, anzi ha sostanzialmente ordinato loro cosa fare: queste, fra lo stupito ed il divertito, hanno ceduto all’autorità che-sembrava-sapere-benissimo-cosa-fare, senza farne una tragedia ed in maniera composta. Dopotutto, erano lì per lui, in un rapporto di dipendenza esplicita, tipo pubblico-adorante-pende-dalle-labbra-del-suo-speaker: non avrebbe dovuto approfittarne, vista la necessità?

Il “pro” non si lascia spaventare facilmente dagli eventi e, piuttosto di dare forfait, impone le sue condizioni per proseguire.

Probabilmente, avendo il tempo, si poteva arrivare a soluzioni meno invasive, ma il tempo è tiranno. O si reagisce prontamente oppure è la fine, nel senso che immancabilmente le persone (e la stampa nel caso di Jobs!) fisseranno nella loro memoria l’incidente tecnico, vanificando lo scopo della presentazione stessa. Esattamente come durante certi matrimoni, che tutti i partecipanti ricordano distintamente come perfetti fino al momento che è successo…

Tutto ciò è certamente un buon modo per contenere il danno e, anzi, volgerlo a proprio favore, coinvolgendo il pubblico. Esattamente come certi cantanti che, durante un concerto, fanno cantare il pubblico e intanto tirano il fiato: il bello è che poi il pubblico è contento e non pensano minimamente al perchè quei cantanti agiscono in quel modo.

Potete star certi che Jobs, finita quella presentazione, avrà dato immediate indicazioni per evitare questa situazione nei successivi keynote. Poi, sappiamo benissimo cosa è successo dopo (RIP).

Sbagliando si impara (e la perfezione di raggiunge quando non ci sono più bug da correggere).

Che ne pensate?

Poco dopo, la solita comitiva di ciclisti della domenica transitava in mezzo alla strada e non sull’enorme ed immacolata pista ciclabile a lato della carreggiata.

Cosa si può imparare da queste situazioni? Riformulo:

Cosa può un programmatore imparare da queste situazioni “urbane”?

Si può sempre imparare, da qualunque cosa

Sarà che sono un informatico e ho una certa deformazione professionale – anche nell’osservare le cose -, ma le due situazioni sopra descritte risultano in qualche modo istruttive, perfino nel campo del software.

Passati i 30 secondi di furia nei confronti di quelle persone (che, sul momento, avrei definito incivili senza battere ciglio), ho provato ad analizzare il contesto, le cause e gli effetti di questa “debacle urbana“. Volevo capire cosa è andato storto.

Caso di studio #1: il sottopassaggio (e le funzionalità nuove, più complicate delle precedenti)

Da buon pignolo-paranoico, ho deciso di ispezionare quel sottopassaggio: decisamente ben fatto – almeno all’apparenza -, con due lunghe rampe senza scalini (cioè senza barriere architettoniche), prima e dopo il sottopassaggio vero e proprio.

Sfortunatamente questo piccolo gioiello ha una grave mancanza: costringe le persone, normodotate e non, ad allungare il percorso di un fattore 2.5x. Attraversare la strada, rischioso che sia, richiede una camminata di 6 metri mentre percorrere tutto il sottopassaggio ne richiede quasi 15: per sfruttarlo, bisogna percorre una stradina chiusa, laterale alla strada, protetta da barriere e muri.

Insomma il percorso è più lungo ed anche rigorosamente preimpostato: quello che è certo – almeno questo! – è che una volta lì dentro, si sbuca da uno dei due lati in modo perfettamente sicuro.

Poco importa che questo sottopassaggio sia stato costruito per evitare nuovi incidenti mortali – ennesimo caso di opera pubblica prodotta dopo una lunga serie di mesti eventi -, le persone lo ignorano sistematicamente, rischiando l’attraversamento in nome del risparmio di tempo.

Chiamatela pure pigrizia se vi pare, ma la pigrizia in questo caso nasconde un discorso geometrico, energetico, economico ed altro ancora: mettere a disposizione qualcosa di migliore non garantisce il successo, ossia che poi verrà usata davvero, soprattutto se non c’è vantaggio pratico tangibile per il beneficiario.

Nel mondo informatico, digitale, vale la stessa cosa, sia per gli utenti che per i programmatori.

Così come una persona – magari una che ha problemi a deambulare – sceglierà la strada più corta, nel mondo informatico, uno sviluppatore sceglierà la soluzione più rapida per arrivare alla soluzione.

Se questo significa continuare a usare puntatori, puntatori a funzioni, API documentate poco o non documentate affatto, funzioni standard del C intrinsecamente insicure come la strcpy, e chissà quale altra worst practice, non ha la minima importanza. Soprattutto se, per quanto insicura, è stata usata fino a quel momento e con profitto.

Le API non sufficientemente documentate sono fra le cause più note della “programmazione per permutazione”, che è l’esatto opposto della programmazione accorta, disciplinata ed affidabile. Da Wikipedia: “Programming by permutation, sometimes called ‘programming by accident’, is an approach to software development wherein a programming problem is solved by iteratively making small changes (permutations) and testing each change to see if it behaves as expected. This approach sometimes seems attractive when the programmer does not fully understand the code and believes that one or more small modifications may result in code that is correct. [...] Programmers are often compelled to program by permutation when an API is insufficiently documented. This lack of clarity drives others to copy and paste from reference code which is assumed to be correct, but was itself written as a result of programming by permutation.” In modo del tutto similare, ribadisco quanto affermato in un precedente post: il “trial and error” non è una metodologia di sviluppo!

Nel caso degli utenti, si potrebbe citare il meccanismo di sicurezza noto come User Account Control, inserito in Vista e poi rivisto e migliorato in 7. Da Wikipedia:

“User Account Control (UAC – Controllo Account Utente) è un modulo di protezione introdotto da Microsoft in Windows Vista, che gestisce i permessi dei singoli utenti del computer in modo da impedire l’esecuzione di software dannoso o il danneggiamento di dati o componenti del sistema. Uno dei principali difetti delle precedenti versioni dei sistemi Windows era infatti legato alla sicurezza ed al problema della esecuzione di molti processi ed applicazioni in modalità “amministratore di sistema”.

[...]

Molte critiche si sono levate circa il numero eccessivo di segnalazioni, ovvero di richieste di intervento da parte dell’utente, che rendono tale soluzione poco pratica: diversamente da altri sistemi operativi, le scelte operate non vengono memorizzate e questo implica che continuamente l’utente viene bersagliato dalle richieste di conferma, che alla fine perdono significato.”

Tradotto: alla fine gli utenti o provano a disattivare in blocco questa funzionalità oppure si limitano ad accettare pedissequamente tutte le notifiche e richieste di conferma, maledicendo il giorno in cui è stata introdotta questa feature.

Come opporsi a questo inghippo? Due sono le chiavi di successo perchè qualcosa sia davvero usata:

1. sia (più) facile da usare;
2. garantisca un uso e prestazioni in linea con le soluzioni rimpiazzate.

Se poi si riesce a rendere anche più sicure – e la sicurezza di norma porta un qualche overhead, che non sia però l’UAC – tanto meglio: l’utente-medio ed il programmatore-medio tendono generalmente a dare la priorità alle prime due caratteristiche ed a ignorare – se non costretti – tutto il resto. Salvo poi farsi male ed imprecare contro chi non li ha debitamente protetti.

Sta al programmatore l’onere di fornire al suo cliente (utente o altro programmatore che sia) qualcosa che sia usabile con profitto ed intrinsecamente sicuro.

Se, in nome di un presunto livello di sicurezza superiore, complicate le cose, l’utente ignorerà il vostro sforzo e tirerà dritto sulla strada vecchia, nota e collaudata. Anche se, nei fatti, è più rischiosa.

Caso di studio #2: la pista ciclabile (e le funzionalità inserite di fretta, per “gola” o perchè ritenute “facili”)

Il caso della pista ciclabile è del tutto simile a quella del sottopassaggio ma con una differenza: la pista ciclabile è di norma una specie di corsia preferenziale che, per quanto sia spesso condivisa con i pedoni, di solito corre parallela alla strada vera e propria. In altre parole: non è il sottopassaggio che allunga e spesso di molto il percorso.

Ebbene, ho discusso con ed ascoltato diversi ciclisti lamentarsi delle piste ciclabili e sul perchè non le adoperano. In certi casi ho udito motivazioni francamente ridicole, sul genere:

“Sulle piste ciclabili ci sono spesso i pedoni che mi danno fastidio ed io devo mantenere un certo tempo!”

In altri casi ho dovuto ammettere un discreto fondo di verità. Ad esempio:

“Per accaparrarsi i fondi europei, hanno ricavato la pista ciclabile dal preesistente marciapiede. Il risultato è che, in 1 chilometro di ‘nuova’ pista ciclabile, ci sono tantissimi sali-scendi, buche, paletti, attraversamenti, perfino dossi! Ed è un continuo intralciare e discutere con i pedoni, non certo meno sbadati di noi ciclisti nel muoversi.”

Un’API o una feature inserita di fretta, con l’idea di sfruttare al volo un’occasione e perciò non pianificata in modo accorto, è prima di tutto un nuovo costo aggiuntivo e poi, sul medio-lungo periodo, rischia di diventare un’inutile zavorra, anche solo per il doverla supportare a lungo (chi ha detto: rotatorie inutili, mal progettate e mal realizzate?).

Le cose si devono fare se c’è una reale necessità e sempre con criterio, non solo per la fretta del guadagno sul breve periodo (es: “i fondi europei”). In ogni caso la priorità va alle esigenze di chi paga e che poi sfrutterà le novità introdotte.

Il caso delle piste ciclabili, “ricavate” da strade e non “progettate“, si riflette nell’inserimento frettoloso di nuove feature che, appoggiandosi ed agganciandosi al codice preesistente, possono intralciarlo, rallentarlo o addirittura bloccarlo.

Pensate alle piste ciclabili ottenute trasformando strade a doppia corsia in sensi unici: in certi casi, per poche biciclette al giorno (o, per essere più precisi, per lucrare i finanziamenti) si è complicato il traffico di interi quartieri. Salvo poi dover correre ai ripari e dover ripristinare, almeno in parte, i vecchi percorsi.

Quanti sono i programmi avete visto e/o usate che, da una versione all’altra, hanno cominciato ad aver problemi dopo l’inserimento dell’ennesima inutile funzionalità che, probabilmente, nessuno davvero userà?

Sto ancora aspettando un clone di Calc.exe cloud-oriented…

Medesimo discorso per le aggiunte apparentemente alla portata e quindi ritenute “facili e poco costose”: il fatto che qualcosa sia facile da implementare ed inserire non implica che lo si debba fare davvero e per forza: ogni nuova feature ha un costo in qualche modo calcolabile, più tutta una serie di costi addizionali, spesso non facilmente preventivabili (cfr. bellissimo post “How many Microsoft employees does it take to change a lightbulb?” di Eric Lippert).

Ogni programmatore ogni giorno si sveglia e sa che prima o poi dovrà scontrarsi con l’ennesimo cliente che, pur non avendo le conoscenze basilari per farlo, stimerà come “facile” l’aggiunta di questa o quella nuova funzionalità. Ogni programmatore ogni giorno si sveglia e sa anche che qualcuno, interposto fra lui ed il cliente, darà comunque ragione a quest’ultimo. Non importa quello che dice il tuo cervello, la buona creanza, la logica, la televisione, … o anche la persona interposta: l’importante è che il cliente, prima di decidere, sia debitamente informato da te cosa comporterà e quanto costerà davvero aggiungere quella sua “bazzecola”. Se poi deciderà di proseguire, almeno non potrà obiettare nulla sul tuo operato, al momento di saldare il conto.

Caso di studio #3 (bonus track): la nuova via, più sicura, ma ignota ai più

Uno degli aspetti estremamente importanti tanto della vita reale quanto di quella informatica è che non basta creare qualcosa di nuovo in sostituzione di qualcos’altro, ma bisogna anche pubblicizzarlo adeguatamente.

Tempo fa, recandomi in montagna con i miei genitori per le vacanze estive, ricordo di aver trovato e seguito sul nostro percorso abituale una deviazione opzionale, seguita da una nuova lunga galleria: era una scorciatoia vera e propria, che ci ha fatto risparmiare un bel po’ di tempo rispetto al percorso “canonico”.

Per quanto una galleria sia un single point of failure (SPOF) notevole nel caso di incidenti, quella istanza era migliore sotto tutti i punti di vista. Anche solo per il fatto di risparmiare ai conducenti – noi! – qualche chilometro di strada impervia, con tornanti e strapiombi nel mezzo del nulla e per questo non particolarmente entusiasmanti.

Inoltre, a conti fatti, quella galleria – pur con i limiti di velocità del caso – garantiva un’andatura costante, che si traduceva in un risparmio di tempo e carburante notevole rispetto alla soluzione precedente. Insomma, l’equivalente di aggiungere un nuovo “fast path” nel proprio codice.

Qui arriva il bello. Il problema, a mio modo di vedere, non è (solo) l’aver lasciato aperta anche l’altra strada, quella vecchia e terribilmente insicura, ma il non preoccuparsi di avvertire dell’esistenza di un’alternativa sicura, rapida, migliore: non uno straccio di cartello chiaro a segnalarne la presenza.

Creare una soluzione nuova e migliore vale zero se poi non si informano le persone della sua esistenza. Magari evidenziandola, anche se a scapito di una vecchia.

Appurato che non si può chiudere una strada da un giorno all’altro – immancabilmente c’è sempre qualcuno che ci abita in quei posti sperduti ed usa quelle strade per tornare a casa – il passo successivo alla pubblicità sarebbe la fase di incentivo+disincentivo: incentivo ad usare la strada nuova e/o disincentivo ad usare quella vecchia.

Per esempio basterebbe risistemare i cartelli già esistenti in modo da spingere l’ignaro automobilista (ignaro del posto, ovviamente, e solamente in transito) a prendere la strada migliore: occhio non vede, cuore non duole.

Tralasciando anche gli evidenti costi di manutenzione doppi – che sicuramente gonfiano il portafogli di qualcuno -, questo atteggiamento è l’equivalente reale del limitarsi a creare l’ennesimo set di API che fa più o meno le stesse cose di quelli precedenti.

Alla fine continuare a supportare tutto diventa insostenibile e si arriva alla fatidica decisione di “deprecare” qualcosa, ossia marchiarlo come vecchio e superato. A quel punto è buona prassi aggiungere qualche controllo addizionale d’utilizzo, in modo che l’utente/programmatore sia informato non appena prova ad usarla. È un po’ come avvertire l’utente del precipizio qualche metro prima che ci finisca dentro: magari è tardi, ma non troppo tardi.

Basta un “warning” in un compilatore a scoraggiare un programmatore da usare qualcosa di vecchio, deprecato ed insicuro? La mia esperienza dice di no. Troppi messaggi di warning ed il programmatore farà come qualunque utente alle prese con l’UAC di vista: se ne infischierà, magari cercando il modo di disabilitarli. Esattamente come avviene con i copri-pacchetti per le sigarette, che “risparmiano” al fumatore la visione dei giganteschi avvertimenti come il celebre “Nuoce gravemente alla salute”. Potete inventarvi sempre nuovi modi per avvertire qualcuno. Ma se risultate troppo insistenti – o l’”obiettivo” vi riterrà tali – i vostri messaggi cadranno inascoltati. Mai sottostimare l’ingegno di qualcuno che si sente “stressato” dai vostri ripetuti messaggi d’allarme.

Arriviamo al punto cruciale: se si fa qualcosa a fin di bene – e lo si può dimostrare -, perchè mantenere la soluzione vecchia ad libitum?

Perchè non pubblicizzare il tutto in modo che l’utente – che contrariamente a quanto si dice non è del tutto scemo – si decida ad abbandonare appena può la strada vecchia per la nuova (e nonostante il celebre proverbio insegni l’opposto)?

Perchè non fornire date certe per forzare il cambiamento? Non come quelle, “ballerine”, del digitale terrestre: conosco gente che, all’ennesimo annuncio dello spostamento della data dello switch off, ha optato per attendere l’evento reale.

Ogni decisione, draconiana o meno che sia, va portata in porto nei tempi previsti ed annunciati. Altrimenti, dopo un po’, nessuno crede più a chi grida “Al lupo, al lupo!”…

Lasciare più soluzioni aperte, pur deprecandone alcune, oltre a confondere l’utente, significa accettare che qualcuno possa continuare a rifiutarsi di passare al nuovo. E tanto prima o poi protesterà comunque: i seguaci del “si fa all’ultimo momento utile!” sono sempre in agguato.

Posso capire il discorso retrocompatibilità, che per certe aziende è fonte di reddito ma è anche una causa di staticità e di perduranti problemi.

Sono dell’idea che se una nuova soluzione serve ad impedire danni enormi, va introdotta subito, senza esitazioni e senza “periodi di grazia” per le soluzioni precedenti.

Lo smart pointer “auto_ptr” dello standard C++98/03. Lo standard nuovo, C++11, lo ha definito deprecato, sostituendolo con smart pointer migliori e (più) sicuri da usare. Marcare come deprecata una funzionalità esistente – per quanto sia un buon esempio di “pubblicità” proveniente da una fonte autorevole – significa da un lato garantire un certo livello di (retro)compatibilità, dall’altra permettere ancora l’uso di qualcosa di insicuro e/o superato, che continuerà comunque a comparire sui libri come il non-plus-ultra e per chissà quanto tempo ancora. Se poi si rimanda ad un “futuro standard” la rimozione definitiva di quel qualcosa e fra una versione e l’altra dello standard passano 5 o perfino 10 anni…

Deprecare qualcosa è come abbassare la velocità massima consentita su una strada invece di precipitarsi a coprirne le vistose buche. Apprezzo il fatto che qualcuno mi avverta di un pericolo concreto, ma se mi impedisse a priori di rischiare gradirei di più. Sbaglio?

Che ne pensate?

Avendoci già provato a suo tempo – con esito positivo -, ho confermato questa possibilità, osservando però che l’utilità pratica, a mio giudizio, è scarsa o nulla:

“… il 99% delle guide sul C++ sconsiglia di usare le eccezioni (cfr. post), figurati reimplementarle in C”

Questo però non significa che non si possano fare altre cose interessanti con quelle due funzioni. Così, mi sono ripromesso di mostrargli un altro uso di quelle due “chiamate”. Ed ecco qui l’esempio-risultato.

Costruire un generatore in C

Prima di tutto, giusto per evitare equivoci, è bene precisare a che tipo di generatore mi stia riferendo. Da Wikipedia:

In computer science, a generator is a special routine that can be used to control the iteration behaviour of a loop. A generator is very similar to a function that returns an array, in that a generator has parameters, can be called, and generates a sequence of values.

However, instead of building an array containing all the values and returning them all at once, a generator yields the values one at a time, which requires less memory and allows the caller to get started processing the first few values immediately.

In short, a generator looks like a function but behaves like an iterator. Generators can be implemented in terms of more expressive control flow constructs, such as coroutines or first-class continuations.

Detto ciò, lo scopo di questi post è semplice: voglio costruire qualcosa a cui, data una lista, chiedo via via tutti gli elementi, uno per volta. Quel qualcosa, una funzione, deve tuttavia essere in grado di fornire l’elemento successivo rispetto a quello della richiesta precedente.

Nulla di particolarmente complicato di per sè – un paio di variabili dichiarati statici e via -, ma quello che volevo tentare di emulare – o anche solo avvicinare negli effetti – è la yield del C#. Questa istruzione fa da sola tutto quello che ci si aspetta. Prendiamo l’esempio di Wikipedia in C# 2+:

// Method that takes an iterable input (possibly an array)
// and returns all even numbers.
public static IEnumerable<int> GetEven(IEnumerable<int> numbers) {
    foreach (int i in numbers) {
        if ((i % 2) == 0) {
            yield return i;
        }
    }
}

La funzione GetEven riceve una lista (tipo enumerato) di numeri e restituisce il primo elemento pari rispetto all’ultima invocazione. Il meccanismo per cui, trovato un elemento pari nella lista, la funzione torna subito per poi riprendere la ricerca da quel punto nel caso di un’invocazione successiva della funzione è gestita dal compilatore attraverso l’istruzione yield.

In pratica appena prima di ritornare un numero, il compilatore C# in automatico salva dove è arrivato cosicché può riprendere da lì in un secondo momento.

Ecco, lo scopo di questo esempio didattico, è ottenere qualcosa di simile in C++ attraverso il duo setjmp/longjmp “ereditato” dal C.

Qualche spiegazione

L’idea chiave è banale: con la setjmp salviamo il punto dove saltare e con la longjmp ri-saltiamo “dove c’eravamo lasciati alla puntata precedente”.

La realizzazione è un filo più complessa nel senso che il codice che gestisce i salti è racchiuso in una funzione templated, stlNext, adatta ad essere usata su container STL diversi, come vector e deque. Lo spostamento vero e proprio in avanti fra gli elementi viene effettuato attraverso un iteratore costante (giusto per non usare indici e rendere le cose più interessanti).

Per verificare la bontà del meccanismo, un’altra piccola funzione templated di test, printAllElements, itera su tutti gli elementi di un container, fino ad arrivare alla fine, in cui verrà lanciata l’eccezione standard out_of_range.

Potete verificare i salti osservando come l’assegnamento iniziale del riferimento al container input (“[assignment]” verrà stampato sullo standard output) avviene solamente la prima volta che la funzione stlNext viene invocata su quel container.

Per rendere le cose più divertenti, ho aggiunto la possibilità di resettare (cioè ripartire dall’inizio o quasi) stlNext, impostando a true l’omonimo parametro-flag.

Come ho già detto, questo codice va considerato come un puro esempio didattico. Non lo userei mai nè francamente ne vedo l’utilità, avendo fra l’altro già a disposizione gli iteratori nel caso dei container STL. Ero in vena di sperimentare e ho sperimentato, fine della traccia.

In questo post ho parlato di generatori realizzati salvando l’”ambiente” (stack) con la setjmp per poi ritornarci con la longjmp. Questo è il concetto-chiave delle continuazioni: In informatica, una continuazione (continuation in inglese) è un modo per rappresentare lo stato di esecuzione di un programma (vedi anche Stack) ad un punto dato. Molti linguaggi hanno un costrutto che permette di salvare lo stato corrente di esecuzione per poi riprendere l’esecuzione a partire da questo stato in un momento successivo. Tuttavia, non ho voluto indicare esplicitamente questo post come “esempio di continuazione” perchè c’è chi sostiene che quel duo di chiamate C sia troppo semplice e limitato per ottenerne una “seria”, al contrario della ben più potente famiglia di chiamate C di cui fa parte setcontext: setcontext is one of a family of C library functions (the others being getcontext, makecontext and swapcontext) used for context control. The setcontext family allows the implementation in C of advanced control flow patterns such as iterators, fibers, and coroutines. They may be viewed as an advanced version of setjmp/longjmp; whereas the latter allows only a single non-local jump up the stack, setcontext allows the creation of multiple cooperative threads of control, each with its own stack. Altri invece sostengono che setjmp/longjmp bastino già a creare delle continuation, addirittura per emulare in C la Call-with-current-continuation (call/cc) dei linguaggi funzionali come Scheme. Non volendo generare nè partecipare a flamewar sull’argomento, lascio a voi la scelta sulla terminologia che ritenete più corretta e adatta a questo post-esempio.

Il codice

/**
 *	FILE     : CppGeneratorTest.cpp
 *	AUTHOR   : Gian Paolo "JP" Ghilardi (http://rejex.wordpress.com)
 *	LICENSE  : released under the terms of GPL v2.0 ("only")
 *	COMPILE  : g++ -Wall -pedantic CppGeneratorTest.cpp -o CppGeneratorTest
 *	PURPOSE  : simple example showing how to create a sort of generator [1]
 *             in C++ and test it against some standard STL containers
 *
 *	TESTED ON:
 *	- Linux Debian 6.0.3 32-bit, GCC 4.4.5
 *	- Linux Ubuntu 11.10 64-bit, GCC 4.6.1 & Clang++ 2.9
 *	- Windows 7,  x86 32-bit, GCC 4.6.1 & MS VSC++ 2010 SP1 (Release Mode)
 *	- Windows XP, x86 32-bit, GCC 4.6.1 & MS VSC++ 2010 SP1 (Release Mode)
 *
 *	REFERENCES:
 *	[1]: http://en.wikipedia.org/wiki/Generator_%28computer_science%29#C.23
 *	[2]: http://msdn.microsoft.com/en-us/library/9k7k7cf0.aspx
 *	[3]: http://www.sgi.com/tech/stl/Container.html
 *	[4]: http://www.cplusplus.com/reference/clibrary/csetjmp/
 *	[5]: http://www.cplusplus.com/reference/clibrary/csetjmp/longjmp/
 *	[6]: http://www.cplusplus.com/reference/std/stdexcept/out_of_range/
 *	[7]: http://www.cprogramming.com/tutorial/templated_functions.html
 */

#include <csetjmp> // [3, 4]
#include <cstdlib>
#include <iostream>
#include <stdexcept>
#include <string>
#include <deque>
#include <vector>

using namespace std;

template<typename T>
static typename T::value_type stlNext(const T& input, bool reset = false)
{
	static jmp_buf env;
	static int val = -1;

	if(val != -1) // Jump to first saved point (if already set)
	{
		cout << "[jumping]" << endl;
		longjmp(env, 0);
	}

	static typename T::const_iterator iter = input.begin();
	cout << "[assignment]" << endl;

	val = setjmp(env); // Save calling environment for jumps (jump point)
	if(reset == true)  // Handle reset (rewind) request
	{
		cout << "[re-assignment]" << endl;
		iter = input.begin();
	}

	if(iter != input.end()) // Check if we've reached the last jump point
	{
		cout << "[returning next iter]: ";
		return *(iter++);
	}
	else
		throw out_of_range("[ok: last element reached]");
}

template <typename T>
static void printAllElements(T& input, bool reset = false)
{
	  try
	  {
		  while(true)
		  {
			  // Fetching the next element from the generator
			  // Note: using template function type inference (no <>) [7]
			  cout << stlNext(input, reset) << endl;
			  reset = false; // (Just once!)
		  }
	  }
	  catch (out_of_range& oor)
	  {
	      cerr << "Out of Range error: " << oor.what() << endl;
	  }
}

int main (int argc, char ** argv)
{
	cout <<
		"\nC++ GENERATOR EXAMPLE:\n"
		"Simple C example showing how to create/fake\n"
		"a generator in C++ via setjmp/longjmp\n" << endl;

	vector<int> v1;
	for(int i=0; i<10; i++)
	  v1.push_back(i);

	cout << "[Test #1 - int vector]: " << endl;
	printAllElements(v1);

	vector<string> v2;
	v2.push_back("A");
	v2.push_back("B");
	v2.push_back("C");
	cout << "\n[Test #2 - string vector]: " << endl;
	printAllElements(v2);

	v2.push_back("E");
	v2.push_back("F");
	v2.push_back("G");
	cout << "\n[Test #3 inserts and rewind of previous vector]: " << endl;
	printAllElements(v2, true);

	deque<string> d1;
	d1.push_back("H");
	d1.push_back("I");
	d1.push_back("L");
	cout << "\n[Test #4 - string deque]: " << endl;
	printAllElements(d1);

	cout << "\n[end]" << endl;

	return EXIT_SUCCESS;
}

Il codice dal vivo

A dispetto degli avvertimenti sulle diverse implementazioni di setjmp/longjmp, dichiarate spesso come incompatibili, ho testato il codice su diverse piattaforme, ottenendo lo stesso comportamento atteso.

Di seguito uno screenshot del codice, compilato con G++ 4.6.1 e con Clang++ 2.9, in esecuzione sulla recentissima Ubuntu 11.10 64-bit.

Che ne pensate?

Si tratta di un fatto singolare perchè – ebbene sì, oso dirlo! – Ritchie ha rappresentato e rappresenta per il mondo, con le sue invenzioni, una figura non meno importante di Jobs.

D’accordo, non ha avuto lo stesso impatto come persona pubblica del fondatore di Apple: non lo si è mai visto presentare un keynote nè si ha notizia di suoi discorsi pubblici particolarmente ispirati, in stile Jobs. Tuttavia, da informatico, devo togliermi il cappello in segno di rispetto nei suoi confronti. Kudos!

Sto forse esagerando?

Reperto #1: il linguaggio C

Richie è uno dei padri del C, il linguaggio con cui gira il mondo dalla fine degli anni ’70. A dispetto dei difetti – e ne ha un bel po’ – questo linguaggio sopravvive tuttora, anzi è vivo e vegeto, al punto che il comitato apposito dell’ISO sta lavorando al prossimo standard, soprannominato C1X.

In un mondo informatico frammentato ed in perenne cambiamento, è un fatto decisamente inusuale un ciclo di vita così lungo. Degno di nota anche che, a differenza di altri linguaggi vetusti come il COBOL, il C sia così tuttora così usato da comparire al secondo posto fra quelli più usati nella classifica mensile redatta da Tiobe.

Per non parlare della discendenza di questo linguaggio: molti linguaggi sono nati prendendo spunto da esso, almeno inizialmente. Curioso che i primi 6 linguaggi di quella classifica – la fetta più significativa di questo mercato! – siano proprio il C stesso più alcuni derivati, ossia Java, C++, C#, ObjC e PHP.

Prendete ora un qualunque vostro gadget elettronico: ci sono altissime probabilità che il firmware, ossia il programma essenziale al suo funzionamento, sia stato scritto in C. Idem una buona parte dell’eventuale sistema operativo e delle librerie software di basso livello per poter pilotare quel dispositivo.

Checché se ne dica, nel mondo embedded il C domina ancora, indisturbato, con buona pace tanto dei suoi limiti, dei suoi difetti progettuali e di tutte le persone che continuano a detestarlo, senza per altro riuscire a rimpiazzarlo. Citando Ritchie:

“C is quirky, flawed, and an enormous success.”

E ancora:

“For infrastructure technology, C will be hard to displace.”

Non è più cool da tempo (lo è mai stato?), non ha funzionalità o caratteristiche “moderne” come la garbage collection, ha una sintassi contorta che facilita gli errori, ha librerie incoerenti con funzioni dotate di interfacce deliranti, ma nonostante questo fa egregiamente il suo lavoro.

E lo fa dannatamente in fretta, a differenza di molti linguaggi moderni, pieni di feature e per questo estremamente lenti in fase di esecuzione. Per non parlare del livello di portabilità di codice raggiungibile con esso, ossia la possibilità di trasportare il codice, adattandolo e ricompilandolo, fra piattaforme diverse.

All’utente finale non importa minimamente con cosa e come un oggetto funzioni, però almeno noi informatici dobbiamo riconoscere al C – ed ai suoi autori – i suoi meriti storici ed attuali. Anche se poi lo abbiamo detestato e siamo passati ad altri linguaggi.

Siamo una società informatica ancora basata sul C, almeno in parte.

Il mio rapporto col C non è stato così conflittuale come lo è stato per la maggior parte delle persone che conosco. Anzi, ammetto di aver perfino apprezzato le migliorie introdotte con lo standard C99. I miei unici due “nei” sono legati al libro qui a fianco, il Kerninghan & Ritchie (“K&R“), ed allo stile di indentazione omonimo, nato con quest’opera. Nel caso del libro, ricordo di aver trovato diversi errori macroscopici man mano che lo leggevo: chiesi lumi al mio professore, il quale lo bollò come “blasfemo”, rimandandomi allo standard (che per altro il K&R diceva di riflettere). Per quanto concerne l’indentazione, ho sempre detestato lo stile introdotto da quel libro, l’omonimo stile K&R, preferendogli il più “simmetrico” Allman. Nonostante ciò, il mio rispetto verso il C ed i suoi autori, Ritchie incluso, permane.

Reperto #2: il sistema operativo UNIX

Con il linguaggio C, Ritchie ed i suoi colleghi, hanno (ri)scritto UNIX, il sistema operativo che volente o nolente continua a comparire qui e là, nelle fattezze di questo o quel discendente-clone.

Non mi va di decantarne le lodi, magari facendo copia & incolla della sua storia da Wikipedia, ma voglio sottolineare che Linux ed una parte di MacOSX sono sostanzialmente dei discendenti (e rappresentanti di quella famiglia di cui Unix è il capostipite), evoluti e modificati quanto volete, ma pur sempre dei discendenti sotto vari aspetti.

Sì, il vostro iPhone o cellulare con Android (che è Linux), sotto sotto, ha qualcosa a che fare con UNIX. Per non parlare del linguaggio con cui questi sistemi operativi sono scritti: assembly, C e poi quello volete (C++, Java, ObjC…).

Mi verrebbe da citare anche Xenix, lo Unix di Microsoft, ma finiremmo a parlare di protostoria, per cui soprassediamo.

Quello che mi è sempre piaciuto della filosofia UNIX, tramandata nei suoi successori, è la sua semplicità di fondo. Citando ancora una volta Ritchie:

“UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity.”

Da Wikipedia:

In 1994 Mike Gancarz (a member of the team that designed the X Window System), drew on his own experience with Unix, as well as discussions with fellow programmers and people in other fields who depended on Unix, to produce The UNIX Philosophy which sums it up in 9 paramount precepts:

1. Small is beautiful.
2. Make each program do one thing well.
3. Build a prototype as soon as possible.
4. Choose portability over efficiency.
5. Store data in flat text files.
6. Use software leverage to your advantage.
7. Use shell scripts to increase leverage and portability.
8. Avoid captive user interfaces.
9. Make every program a filter.

Questa è la saggezza informatica lasciataci in eredità dagli autori di UNIX.

Il valore di una morte

Premetto che è giusto piangere ogni singola persona per tutto ciò che essa ha o non ha fatto.

Tuttavia, solo ora che è morto Ritchie e a pochi giorni da quella di Jobs, mi rendo conto che neppure da morti siamo uguali. Di più: nel caso di figure in qualche modo pubbliche, non esiste proprio gara fra chi appare e chi, pur non apparendo, cambia il mondo.

Jobs era l’uomo-immagine della sua azienda, un’azienda dinamica che continua a far notizia e che, vista l’esposizione mediatica dovuta al lutto – sapientemente gestita -, probabilmente ora incrementerà ulteriormente le sue vendite (come è avvenuto dopo la morte di Michael Jackson).

La morte di Ritchie – triste dirlo – non fa notizia, almeno all’infuori di un certo ambito informatico e nonostante il progresso recato dalle sue invenzioni.

E’ lo stesso discorso che capita con le band: nel 99% dei casi, pensando ad una band, ci si ricorda del suo frontman – normalmente il cantante – ma non degli altri componenti. Ennesimo caso di supremazia del frontend.

Detto questo, umanamente e professionalmente parlando, mi sarei aspettato un saluto pubblico a Ritchie un po’ più intenso. Non parlo di cordoglio e commozione pubblica al limite del pianto di massa, come è successo con Jobs (ribadisco: ognuno è liberissimo di piangere chi vuole e come vuole), ma nemmeno le poche stringate righe che sono apparse qui e là come funghi, per giunta (temo) prese ed incollate da qualche sito come Wikipedia.

Sono onesto: non mi aspettavo nulla di più dai siti dei quotidiani nazionali, ma qualche riga in più dai cosiddetti “siti di tecnologia” francamente sì.

Con, ovviamente, tutte le eccezioni del caso, come l’articolo “What Can We Learn From Dennis Ritchie?” di Techcrunch o quello intitolato “Dennis Ritchie: The Shoulders Steve Jobs Stood On” di Wired: due letture estremamente consigliabili.

Che ne pensate?

Ricordo con tristezza quando nel 2002 apparve la notizia su Slashdot della morte di Dijkstra. Ai più il suo nome non dirà nulla, ma non a chi ha studiato algoritmi.

Non so chi fosse davvero – a quanto pare, neanche lui passava sempre per un simpaticone – però durante gli studi ne avevo visto e apprezzato l’opera, per cui ero felice di “averlo conosciuto“, seppur in modo effimero e mediato.

Potrei proseguire a lungo negli esempi (es: Ritchie, uno dei padri del C, scomparso l’altroieri e Petri, inventore delle reti che portano il suo nome), ma il punto chiave è che capisco perfettamente e non sottovaluto affermazioni come:

“Jobs ha cambiato la mia vita!“

Soprattutto se queste affermazioni provengono da persone che sono riuscite ad affacciarsi ed a destreggiarsi finalmente nel mondo informatico attraverso i prodotti di Apple.

Quello che però non mi piace troppo – eufemismo – è la sistematica santificazione o condanna mediatica del defunto Jobs.

Pietas ed oltre

Esiste una plurisecolare e collaudatissima regola non scritta che impone rispetto verso i defunti, qualcosa secondo cui almeno (almeno!) nel periodo dei funerali, non si dovrebbe parlare male del compianto, chiunque esso sia stato e qualunque azione abbia mai commesso.

Qualcuno ci vede un rispetto più verso il dolore dei congiunti che verso il morto in sè, però è una consuetudine tutto sommato ragionevole ed incoraggiabile.

Quello che invece non è accettabile, per una mera questione di eccesso, sono i corollari abituali per i defunti importanti: l’incensazione istantanea da un lato, la scarsità di sentimento o perfino l’inflessibile cattiveria nel ricordarli dall’altro.

Nella prima categoria annovero tranquillamente l’immenso baillamme santificatorio attorno alla dipartita di Jobs. Perfino persone che fino a qualche istante prima detestavano Jobs, senza nemmeno provare a nasconderlo pubblicamente, ora si strappano i vestiti in segno di rispetto verso il nemico caduto. Onore delle armi, direbbe qualcuno.

Credo esista però un limite preciso ed estremamente facile da superare oltre il quale si scade nella ruffianeria più becera. Esempio lampante:

“Per rispetto a Jobs rimandiamo la presentazione di questo o quel prodotto.”

Diciamo le cose come stanno: il mondo in qualche modo piange Jobs e qualunque presentazione di un prodotto concorrente passerebbe in secondo ordine. Peggio: qualcuno potrebbe arrivare a vedere in ogni azione di un competitor in questo periodo come uno scorno alla morte del capo di Apple ed a invocare una qualche attività di boicottaggio di massa (mai sfidare i fan di qualcosa o di qualcuno: se la prendono sul personale, è la fine!).

Detesto e provo un orrore viscerale per tutti questi tipi di atteggiamento ipocrita – anche se intuisco benissimo le motivazioni di fondo -, così come non capisco l’opposto, ossia il non riuscire a tapparsi la bocca per qualche giorno, prima di criticare un defunto, a torto o ragione che sia.

Mi riferisco alle frasi di Stallman, il padre del progetto GNU e del software libero, che ha scelto davvero il momento peggiore per esternare la sua personale opinione sulle azioni di Jobs.

Con la stampa sempre in attesa di trovare il cattivo di turno, che non sa trattenersi, basta mezza parola in più per essere male interpretato e finire sulla pubblica gogna.

Vediamo un attimo queste parole…

Dal sito ufficiale di RMS:

Steve Jobs, the pioneer of the computer as a jail made cool, designed to sever fools from their freedom, has died.

As Chicago Mayor Harold Washington said of the corrupt former Mayor Daley, “I’m not glad he’s dead, but I’m glad he’s gone.” Nobody deserves to have to die – not Jobs, not Mr. Bill, not even people guilty of bigger evils than theirs. But we all deserve the end of Jobs’ malign influence on people’s computing.

Unfortunately, that influence continues despite his absence. We can only hope his successors, as they attempt to carry on his legacy, will be less effective.

Tralasciando la discutibile scelta dei tempi ed il tono, a dire il vero non noto qualcosa di particolarmente sconvolgente in queste parole, considerando ovviamente l’autore di questa affermazione ed il fatto che per i bene informati non sia altro che un déjà vu.

Stallman, per quanto traspare dai suoi scritti, pare avere una visione fortemente ideologizzata della vita, dell’universo e di tutto quanto. O sei con lui o sei contro ed il metro di giudizio minimo in questo caso è come ti poni rispetto al “problema” della libertà del software. Perchè quello per lui è un grosso problema ed una fonte potenziale di Male. Volenti o nolenti, ognuno ha le sue priorità ed i suoi criteri di giudizio. Qualcuno, visto il soggetto in questione, ha perfino pensato di creare un sito umoristico in stile Chuck Norris, su di lui ed il suo pensiero.

Jobs nella testa di Stallman non ha mai giocato nella sua squadra del cuore, per cui non mi stupisco del tipo di affermazione-sentenza semplicemente perchè non è la prima volta che la emette.

Tuttavia, se devo trovare una qualche colpa in tutto questo e prima ancora di entrare nel merito delle affermazioni, è quella di aver esternato pubblicamente quello che molta gente si limita a pensare – e non dire! – di persone appena morte e con la quale non si era in ottimi rapporti.

Rimane il dubbio se sia meglio chi ogni giorno dice di te pesta e corna, ma al tuo funerale si traveste da agnellino in lutto, o chi osa affermare a caldo che non ti rimpiangerà per le tue azioni. La prima è ipocrisia ed insincerità, la seconda è sincerità al limite della più totale mancanza di tatto.

Una bella gara, non c’è che dire…

Come la penso

Dal punto di vista di questo lutto globale, mi colloco nella scia di Gremellini, giornalista con cui per altro mi trovo spesso in questa situazione:

Steve Jobs era un genio, non un santo. Invece i siti e i giornali di tutto il mondo grondano di allusioni celestiali e riferimenti a Buddha e a Gesù, francamente eccessivi. Sono sicuro che lui si accontenterebbe di essere paragonato a Leonardo: un altro che ha cambiato il mondo nutrendosi di conoscenze spirituali per iniziati. Il discorso di Jobs all’università di Stanford – «La morte è la migliore invenzione della vita» – non smette di commuovermi, ma devo riconoscere di averlo già letto da qualche parte: in qualsiasi testo ispirato di new (e old) age. [...]

Anche la “sua” celebre frase “Stay hungry, stay foolish” in realtà non è sua (grazie all’amico Samuele per avermelo ricordato), ma è una citazione dal messaggio di addio di una rivista degli anni 70, tale Whole Earth Catalog, fra l’altro esplicitamente indicata da Jobs nel suo famoso discorso di Stanford.

Se proprio vogliamo, potremmo dire che, in puro stile Jobs, ha perfezionato quella frase, riportandola in auge, rendendola celebre e probabilmente imperitura.

Ma non è l’autore ed è bene dirlo, se no si rischia un effetto simile a quanto prodotto da Fiorello quando mise in musica la poesia San Martino di Carducci: gli studenti dell’epoca in cui comparve la canzone, intervistati dai soliti TG, erano certi che Fiorello ne fosse l’autore, vanificando d’un colpo il senso ed il significato che il poeta, il vero autore, voleva trasmettere in quell’opera.

L’impatto di Jobs su di me …

Sia chiaro: riconosco a Jobs di aver semplificato l’accesso al mondo informatico a tante persone, riconosco il suo immenso potere-Jedi sulle folle noto come Reality Distortion Field, riconosco la sua dote eccezionale dal punto di vista delle scelte estetiche e nel saper vendere la sua arte a carissimo prezzo a schiere di adoranti acquirenti, ma non altro. Sono ovviamente triste per la sua morte ma, umanamente parlando, non mi ha toccato nel profondo.

Ok, non è del tutto esatto: il già-citato discorso-testamento del 2005 a Stanford mi è piaciuto molto. Ricordo con piacere quando lo vidi nel 2005, su suggerimento di un amico in Università, e di come ora, come un buon vino invecchiato, mi sembri migliorato.

A parte quello però, null’altro. Chissà, magari mi colpirà ora, in modo più profondo, tramite la sua annunciata biografia autorizzata e postuma – che verrà data alle stampe a breve -, così come fecero a suo tempo quella di Linus Torvalds, “Just For Fun“, e quella su Stallman, “Free As in Freedom“. Lo spero vivamente.

A voler ben vedere e ricordare, confesso di aver riso più volte, da informatico, delle mirabolanti feature introdotte da Apple e presentate da lui in persona nel corso del tempo. Ad esempio il meraviglioso, fantasmagorico multitasking nell’iOS 4. Ricordo di aver pensato in quel frangente:

Jobs è un genio! È riuscito a spacciare per nuovo, moderno, trendy ed irrinunciabile per l’utente comune qualcosa di intangibile, che concettualmente è nato negli anni ’70 e funzionava già su macchine che erano ordini di grandezza meno performanti di un iPhone!

Questo fa di me un bieco oppositore di Jobs e della sua fruttosa creatura?

Non credo: per quasi 6 anni la mia macchina principale è stato un PowerBook G4 Alu e mi sono trovato benissimo, al punto che a volte lo rimpiango ancora. Ma non mi riesce di venerare il capo dell’azienda che l’ha prodotto, come se fosse davvero un “guru di una setta quotata in Borsa” (cit. sempre da Gremellini). Mio limite? Ovvio che sì!

… e quello di Stallman

Pur non condividendo affatto la cosa, non mi stupisco però che qualcuno, dimentico delle basilari consuetudini sociali, osi lanciare strali anche nel periodo di grazia che segue un lutto, per giunta così mass-mediatico.

Dico di più: per quanto non abbia apprezzato affatto la tempistica con cui Stallman ha “salutato” a suo modo Jobs, per quanto mi trovi spesso sconcertato dall’uomo-Stallman, dovendo scegliere fra i due, sceglierei comunque quest’ultimo senza battere ciglio, per rispetto di quello che fa e continua a fare nonostante i suoi modi socialmente grezzi e reprensibili.

Sarà che sono un informatico (lato programmazione) e non ho una naturale predisposizione verso l’estetica, ma fra la libertà d’uso propugnata da RMS e la perfezione estetica di cui Jobs era una sorte di profeta laico, scelgo la prima.

Ripudio apertamente i bordi taglienti dell’ideologia fondamentalista libertaria di Stallman, ma so leggere fra le righe e so cosa significhi essere liberi di scegliere, senza restrizioni, ricondividendo quanto ci è stato dato come se si trattasse di un prestito.

Se oggi c’è Linux e lo posso usare così è perchè un certo Linus Torvalds ha scelto di rilasciare il suo kernel con una licenza, la GPL, che è stata creata dal Progetto GNU di Stallman. E con Linux molto, molto altro software.

Se ora, da utente finale, ho tanta scelta di software libero ed OpenSource di qualità decente – perfino dentro i prodotti Apple – è perchè quel qualcuno taaaanto tempo fa ha intrapreso quella strada. Il cruccio di Stallman è quello che le persone continuino a soffermarsi sugli effetti pratici della sua filosofia, ossia poter usare software a titolo gratuito, e non cosa significhi poter disporre di software libero. A occhio e croce, questa cosa lo manda in bestia.

Detto questo, c’era davvero qualcuno che si aspettasse che un tipo di persona come è Stallman, riponesse in un angolo, anche solo per un attimo, i suoi ideali per assecondare la diplomazia imposta dalla pietas? Beata ingenuità. Nel caso specifico di RMS, era perfino lecito aspettarsi un suo qualche epitaffio polemico, epitaffio che, come un orologio svizzero, è arrivato puntualmente.

Che ne pensate?

Uno di questi, in particolare, riguarda l’emulazione dei namespace in questo linguaggio.

I namespace

Tanto per cominciare, è bene definire cosa sia e a cosa serva un namespace. Da Wikipedia:

Un namespace, o in italiano spazio dei nomi, è – nella terminologia relativa all’informatica – una collezione di nomi di entità, definite dal programmatore, omogeneamente usate in uno o più file sorgente.

Lo scopo dei namespace è quello di evitare confusione ed equivoci nel caso siano necessarie molte entità con nomi simili, fornendo il modo di raggruppare i nomi per categorie: attualmente il concetto di namespace è presente esplicitamente nell’XML, nel linguaggio di programmazione C++ e nelle ultime versioni di PHP, ed implicitamente in altri linguaggi.

Perchè servono in JavaScript

JavaScript è un linguaggio estremamente potente ma il fatto che tutto sia visibile a tutti – tutto finisce in un grande calderone, ossia lo scope globale -, può diventare un problema.

Esempio canonico: si crea una funzione e, senza saperlo, questa va a sovrascriverne una omonima, già esistente, creando effetti terribilmente spiacevoli in fase di esecuzione.

Inoltre, per ragioni di opportunità e di qualità di codice, è bello poter compartimentare il proprio codice, suddividendolo in opportune librerie di classi pronte all’uso e “sicure“.

Arriviamo al problema: a differenza di altri linguaggi, il concetto di namespace in JavaScript non esiste in senso stretto. Tuttavia, il linguaggio è sufficientemente potente e flessibile da permettere di emularlo in modo intelligente usando, tanto per cambiare, le funzioni.

L’esempio: note implementative

Nell’esempio che vi riporto di seguito mostrerò come è possibile creare e gestire un namespace in modo sicuro, ossia evitando di buttare tutto nel calderone.

In particolare i due file “namespace-test-1.js” e “namespace-test-2.js” contengono la definizione di 2 classi – MyObject il primo, MyObject2 il secondo – che appartengono entrambi allo stesso namespace – “MyNamespace.Sub” – senza intromissioni e senza l’obbligo di caricare un file prima dell’altro: il primo dei due file caricati, crea il namespace anche per l’altro.

Per ottenere il namespace sfrutteremo delle semplici funzioni, le quali definiscono uno scope (ambito di visibilità) preciso e ristretto per le variabili e le funzioni contenute. Da StackOverflow:

Variables declared globally have a global scope. Variables declared within a function are scoped to that function, and shadow global variables of the same name.

In particolare, il trucco per ottenere un namespace “sicuro”, consiste nell’usare una Self-Executing Anonymous Function. Il nome è altisonante ma il concetto è semplicissimo: si crea una funzione-contenitore e la si esegue immediatamente, isolando quindi il suo contenuto dal resto del mondo. Da qui:

Another common technique that you can use to protect the global namespace is to use a Self-Executing Anonymous Function.

This is just a fancy term to refer to a function with no name that is immediately executed after it’s defined. The value of this technique is that you can create a wrapper around your code that protects it from the global namespace.

By using the most simple version of the Self-Executing Anonymous Function you can create code that is exclusively private.

Il mio esempietto, che riprende quello della pagina sopra-citata, è anch’esso basato e modellato sulla celebre libreria jQuery e lo si può notare nel modo in cui è possibile inizializzare gli oggetti, tramite un singolo parametro-mappa (propriamente un oggetto creato tramite literal notation) contenente le “opzioni” per il costruttore.

Nel momento in cui l’oggetto viene creato (cioè la funzione viene chiamata) questa mappa-parametro viene unita ad un’altra mappa (tramite la funzione $.extend() di jQuery), interna, contenente le opzioni di base, eventualmente sovrascrivendole.

In questo modo si ha la flessibilità del poter variare i nomi dei parametri partendo però da valori di default accettabili e senza dover inserire tonnellate di blocchi “if” per gestire tutti i parametri richiesti ma non inseriti dall’utente.

Inoltre, usare una mappa con i nomi dei campi definiti esplicitamente aumenta enormemente la leggibilità nella creazione degli oggetti.

Infine, sempre in stile jQuery, ogni oggetto creato ritorna un riferimento a sè stesso (return this), in modo da permettere il “chaining” delle funzioni/metodi.

L’esempio in dettaglio

L’esempio è abbastanza semplice ed è pensato a mo’ di template, ossia come base riciclabile all’infinito.

Nella funzione $(document).ready(), una sorta di main, del file index.html creo 4 oggetti, i primi 3 di tipo MyNamespace.Sub.MyObject mentre l’ultimo di tipo MyNamespace.Sub.MyObject2.

Un fatto abbastanza comodo è la possibilità di crearsi degli “alias” per accorciare la dichiarazione dei tipi, emulando quindi anche la parola chiave using di linguaggi come C# e C++.

Inizializzerò i primi 3 oggetti in modo diverso, sovrascrivendo a piacere i valori di default e poi invocando immediatamente per ciascuno la funzione che scriverà il contenuto delle opzioni in altrettanti tag span. L’ultimo oggetto invece viene invocato direttamente e non fa altro che riempiere un altro tag span.

Il codice

<!--
 FILE      : index.html
 AUTHOR    : Gian Paolo "JP" Ghilardi (http://rejex.wordpress.com)
 LICENSE   : released under the terms of GPL v2.0 ("only")
 PURPOSE   : showing how to create and use a namespace in JavaScript
 --> 
 <html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <!-- Basic jQuery library import -->
    	<script type="text/javascript" src="jquery-1.6.3.min.js"></script>
        <script type="text/javascript" src="namespace-test-1.js"></script>
        <script type="text/javascript" src="namespace-test-2.js"></script>
        <script type="text/javascript">
        // "Main" function, automatically called by browser when the page is fully loaded
        $(document).ready(function () {	
				
            // Create an alias (emulate C++/C# "using")
            var MyObject = MyNamespace.Sub.MyObject; 
			
            new MyObject // 1. Create an object via the alias
            ({
                target: $('#data-contents-1') // No data redefinition
            }).initialize();	
				
            // 2. Create an object via the full namespace "path"
            new MyNamespace.Sub.MyObject 
            ({
                a: "redefined!", // Redefine one of the defaults
                target: $('#data-contents-2')
            }).initialize();	
				
            // 3. Create (again) an object via the alias
            new MyObject 
            ({
                d: "augmented!!", // Add a new option
                target: $('#data-contents-3')
            }).initialize();	
				
            // 4. Create an object of the 2nd kind via the full namespace "path"				
            new MyNamespace.Sub.MyObject2('hello world!').fill('#data-contents-4');						
            });		
        </script>
        <title>JavaScript Namespace Test</title>
    </head>
    <body>
        <h1>Testing Namespace in JS:</h1>
        Contents of the 1st object: <span id='data-contents-1'></span><br>
        Contents of the 2nd object: <span id='data-contents-2'></span><br>
        Contents of the 3rd object: <span id='data-contents-3'></span><br>
        Contents of the 4th object: <span id='data-contents-4'></span>
    </body>
</html>

/**
 *	FILE      : namespace-test-1.js
 *	AUTHOR    : Gian Paolo "JP" Ghilardi (http://rejex.wordpress.com)
 *	LICENSE   : released under the terms of GPL v2.0 ("only")
 *	PURPOSE   : showing how to create and use a namespace in JavaScript
 *
 *	REFERENCES:
 *	[1]: http://stackoverflow.com/questions/881515/javascript-namespace-declaration/5947280#5947280
 *	[2]: http://enterprisejquery.com/2010/10/how-good-c-habits-can-encourage-bad-javascript-habits-part-1/
 *	[3]: http://api.jquery.com/jQuery.extend/
 *	[4]: http://javascript.crockford.com/private.html
 */

// Generate or append to MyNamespace namespace [1,2]
(function (MyNamespace, $) {

    MyNamespace.Sub = MyNamespace.Sub || {}; // Define a subnamespace Sub if it doesn't already exist

    // Inject the object class in the subnamespace Sub
    MyNamespace.Sub.MyObject = function (options) {

        /*********************
         * PRIVATE VARIABLES *
         *********************/

        var defaults = {
            target : $('body'),
            a: 'a',
            b: 'b',
            c: 'c'
        };

        /********************
         * PUBLIC VARIABLES *
         ********************/

        // Merge the options into the defaults to create the final data variable
        this.data = $.extend({}, defaults, options);

        /**********************
         * PRIVILEGED METHODS *
         **********************/

        // Initialize the object
        this.initialize = function () {
            var my = this.data;
            my.target.html(dumpObj(this));
        };
       
        /*******************
         * PRIVATE METHODS *
         *******************/

        // Dump the "data" variable contents [3]
        function dumpObj(self) {
            var my = self.data;
            var arr = [];
            $.each(my, function(key, val) {
                var next = key + ": ";
                next += $.isPlainObject(val) ? printObj(val) : val;
                arr.push( next );
            });
            return '{ ' +  arr.join(', ') + ' }';
        }
		
        return this;
    };

} (window.MyNamespace = window.MyNamespace || {}, jQuery)); // End of namespace [1,2]

/**
 *	FILE      : namespace-test-2.js
 *	AUTHOR    : Gian Paolo "JP" Ghilardi (http://rejex.wordpress.com)
 *	LICENSE   : released under the terms of GPL v2.0 ("only")
 *	PURPOSE   : showing how to create and use a namespace in JavaScript
 *
 *	REFERENCES:
 *	[1]: http://stackoverflow.com/questions/881515/javascript-namespace-declaration/5947280#5947280
 *	[2]: http://enterprisejquery.com/2010/10/how-good-c-habits-can-encourage-bad-javascript-habits-part-1/
 *	[3]: http://api.jquery.com/jQuery.extend/
 *	[4]: http://javascript.crockford.com/private.html
 */

// Generate or append to MyNamespace namespace [1,2]
(function (MyNamespace, $) {

    MyNamespace.Sub = MyNamespace.Sub || {}; // Define a subnamespace Sub if it doesn't already exist

    // Inject the object class in the subnamespace Sub
    MyNamespace.Sub.MyObject2 = function (message) {
		
       /**********************
        * PRIVILEGED METHODS *
        **********************/

        // Fill the input object with the message
        this.fill = function (objId) {
            $(objId).html(message);
        };
		
        return this;
    };

} (window.MyNamespace = window.MyNamespace || {}, jQuery)); // End of namespace [1,2]

Il codice dal vivo

Nonostante il continuo aumento di prestazioni di questo fatato mondo, non c’è corrispondenza con un aumento di prestazioni reale, concreto, visibile cioè dal lato utente. Riformulo: hardware e software vanno di pari passo e sussiste qualcosa tipo:

prestazioni(software * hardware) al tempo t = costante

Software bloat Vs Prestazioni

Penso sia naturale, dopotutto: più le “macchine” migliorano e più si possono aggiungere feature nel software, dimenticandosi o non dando troppa attenzione all’ottimizzazione del codice (“tanto i PC attuali ce la fanno lo stesso”). Questo è un esempio di software bloat istituzionalizzato:

Software bloat is a process whereby successive versions of a computer program include an increasing proportion of unnecessary features that are not used by end users, or generally use more system resources than necessary, while offering little or no benefit to its users.

Questo è dovuto anche alla necessità per le aziende produttrici di hardware e di software di presentare sul mercato sempre qualcosa di nuovo e non sempre le novità introdotte sono così utili, diciamo così.

Ad esempio, perchè per fare le stesse azioni che un utente-medio svolgeva su un PC con Windows XP e 256-512MB di RAM ora serve un PC con Vista/7 e 2+ GB di Ram? Cosa ci ha guadagnato davvero l’utente finale nel passaggio? Aero può da solo giustificare tutto questo? Ok, il sistema operativo sotto sotto è migliorato, ma dopo 6 mesi di uso relativamente intenso le prestazioni delle due piattaforme, vecchia e nuova, sono tristemente simili (cfr. vecchio post). Erro?

Spolsky in un celebre post, “Strategy Letter IV: Bloatware and the 80/20 Myth“, tratta questo concetto – il “bloatware” – dal lato economico, spiegando come tutto debba essere sempre preso in considerazione rispetto ai tempi di rilascio sul mercato, ossia tenendo bene in mente i costi via via ridotti e le prestazioni via via in aumento dei PC.

Tuttavia, concordando anche con Spolsky sugli aspetti economici del suo ragionamento, non mi viene da concordare con lui sugli effetti pratici: perchè comprando un hardware nuovo con del software nuovo, io, utente, devo pagare anche questa tassa occulta sulle prestazioni?

Dal desktop al web il discorso non cambia

Osservando questo “problema” dal punto di vista del web, la situazione si ripropone pari pari. Mi riferisco al fatto che una discreta quantità di siti sembrano pensati e testati per lo stesso tipo di hardware e software con cui sono stati sviluppati. O non vengono affatto testati.

Mai considerare la propria macchina di sviluppo come indicativa per i test. Di solito uno sviluppatore sceglie per sè una macchina adeguata al suo lavoro, personalizzata a suo uso e consumo e di solito ben diversa dal tipo di macchina dell'utente finale. Vista l’impossibilità pratica di disporre di più macchine diverse per i test, una batteria di virtual machine con differenti configurazioni – magari browser diversi, come fa John Resig, l’autore di jQuery – potrebbe rappresentare un onesto palliativo.

Per cui è facile imbattersi in siti relativamente ben fatti che però richiedono letteralmente megabyte di dati scaricati prima di vedere la sola homepage completa. Il discorso-scusa “tanto c’è la cache del browser” in questo caso non regge: se un utente visita per la prima volta il vostro sito la cache è ovviamente vuota.

Quantificare la pazienza dell’utente

Da utente dotato di un ASDL decente trovo fastidioso ben oltre l’accettabile attendere più di 10 secondi per riuscire a leggere qualcosa – qualunque cosa – in un sito. Trovo la cosa doppiamente irritante se ho atteso il caricamento di tonnellate di dati per poi scoprire che quel sito non fa il caso mio, un evento relativamente comune.

La pazienza dell’utente è quantificabile. La mia è pari a 30 secondi: se un sito ci mette più di quel tempo a caricare – e da bravo utente non mi interessa minimamente sapere il perchè – cambio sito.

Sono così stanco di queste futili attese quando navigo, che ormai ho sviluppato una strategia semplice e spesso efficiente. Quando ricerco qualcosa, apro almeno più siti-risultato in parallelo ossia in altrettanti tab del browser. Se il primo tab ci mette più di quei 30 secondi, lo chiudo da tastiera, passando automaticamente al secondo e così via. Se i tab finiscono torno da Google e cambio i termini di ricerca e riprendo da capo.

Non sopporto i rallentamenti nè tollero chi progetta siti senza tener in minimo conto che il tempo dell’utente è prezioso e non va sprecato costringendolo ad attendere il caricamento di inutili orpelli.

Un altro fattore di rallentamento: la creazione delle pagine dinamiche

Non c’è solo il tempo effettivo di ricezione e caricamento dei dati nel browser, non ci sono solo i ritardi di trasmissione sulla rete, ma nel calderone vanno inclusi i tempi di generazione delle pagine, ossia la composizione delle pagine dinamiche prima dell’invio all’utente.

Nel bellissimo post “Performance is a Feature“ di CodingHorror si parla proprio di questo:

“[Google found that] the page with 10 results took 0.4 seconds to generate. The page with 30 results took 0.9 seconds. Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.

In A/B tests, [Amazon] tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue.

I believe the converse of this is also true. That is, the faster your website is, the more people will use it. This follows logically if you think like an information omnivore: the faster you can load the page, the faster you can tell whether that page contains what you want. Therefore, you should always favor fast websites.

The opportunity cost for switching on the public internet is effectively nil, and whatever it is that you’re looking for, there are multiple websites that offer a similar experience.

So how do you distinguish yourself? You start by being, above all else, fast.“

Se ne deduce che io, con i miei “30 secondi di pazienza”, rientro nella classe di utenti tutto sommato pazienti. Voi in che classe di utenti vi ponete? Quanti secondi di “latenza” riuscite a tollerare prima di abbandonare un sito?

Curioso che in tutto questo l’aspetto dei contenuti sia secondario: i migliori contenuti che si possano trovare sulla Rete valgono poco se l’utente è già scappato, esasperato dalla lentezza complessiva del sito che li ospita.

Che ne pensate?

Naturalmente questo tipo di situazione si verifica anche nel mondo informatico e, nelle vesti delle “cose vecchie”, ritroviamo i sistemi legacy. Da Wikipedia:

Il sistema legacy (tradotto letteralmente “sistema eredità”) è un sistema informatico esistente o un’applicazione che continua ad essere usata poiché l’utente (tipicamente un’organizzazione) non vuole o non può rimpiazzarla.

Le ragioni che inducono a mantenere sistemi legacy sono soprattutto dovute ai costi sostenuti per la loro implementazione e ai costi da sostenere per la migrazione a nuovi sistemi. Molte persone usano questo termine per riferirsi a sistemi “antiquati” (ma spesso di gran lunga migliori di quelli di nuova concezione).

Con questo termine si indicano quindi i sistemi IT che utilizzano tecnologie meno recenti e per questo motivo sono molto difficili da interfacciare con i sistemi più recenti. Per tale interfacciamento si può ricorrere a sistemi middleware ma il costoso utilizzo di questi ultimi spesso decreta la sostituzione del legacy con tecnologie odierne.

Generalmente dei sistemi legacy si dicono peste e corna, spesso più per la foga di voler cambiare a tutti i costi qualcosa di ritenuto vecchio (e voler vendere un rimpiazzo) che non per una reale necessità.

Sistemi legacy e sviluppo

Da sviluppatore non sono immune al fascino dello speriementare costantemente cose nuove. Da sviluppatore con qualche anno di esperienza ho imparato a non disprezzare quel software che, seppur vecchio, ha contribuito a pagarmi lo stipendio.

Sviluppo è continuare a supportare i sistemi legacy, manutenerli (es: bugfix) ed eventualmente anche estenderli. Quando si inizia a lavorare presso qualcuno è normale doversi impratichire col codice già esistente ed è normale imbattersi in qualcosa che già presenta i segni del tipico sistema legacy oppure lo è già diventato. Non è solo una questione di questa o quella piattaforma, di questo o quel linguaggio di programmazione: prima o poi i componenti dei sistemi legacy, a loro volta legacy, escono di produzione, rendendo tutto più complicato.

C’è anche da dire che se una cosa funziona, non è necessario sostituirla. In altri casi è necessario farlo e sarebbe utile non aspettare l’ultimo momento, pena figur… situazioni spiacevoli come quella che accadde qualche anno fa in California (da Slashdot):

“Last week, California Governor Arnold Schwarzenegger ordered a pay cut, to minimum wage of $6.55/hr, for 200,000 state workers — because a state budget hadn’t been approved yet.

The state controller, who has opposed the pay cut on principle and legal grounds, now says the pay cut isn’t even feasible because the state’s payroll systems are so antiquated. He says it would take six months to go to minimum wage, and nine months more to restore salaries once a budget is passed.

The system is based on COBOL, according to the Sacramento Bee, and the state hasn’t yet found the funds or resources, in ten years of trying, to upgrade it.”

The article quotes a consultant on how hard it is to find COBOL programmers; he says you usually have to draw them out of retirement. Problem is, if there were any such folks on the employment rolls in California, Gov. Schwarzenegger fired them all last week, too.

Questo è un esempio di sistema legacy che, come spesso accade, probabilmente ha vissuto ben oltre quanto originariamente previsto (tutto ha una scadenza, anche se non è dichiarata esplicitamente), esattamente come per quei satelliti e sonde spaziali la cui durata di vita viene estesa arbitrariamente per ragioni di costi: finchè vanno, perchè non usarle?

Il problema è quando questo tipo di estensioni di vita arbitrarie toccano la vita delle persone.

Curioso che nel “fattaccio californiano” sopra-citato ritorni il solito problema-COBOL, un linguaggio di programmazione dato ingenuamente per morto troppe volte e troppe volte riemerso dal nulla. Una citazione tratta da Coding Horror dà un’idea di come i sistemi scritti in questo linguaggio tuttora siano importanti e rilevanti:

“The statistics that surround COBOL attest to its huge influence upon the business world.

There are over 220 billion lines of COBOL in existence, a figure which equates to around 80% of the world’s actively used code. There are estimated to be over a million COBOL programmers in the world today.

Most impressive perhaps, is that 200 times as many COBOL transactions take place each day than Google searches – a figure which puts the influence of Web 2.0 into stark perspective.“

Curioso anche che esso e molti sistemi costruiti con esso siano sopravvissuti ai loro programmatori originari, ormai in pensione da tempo e, in mancanza di nuove leve, riesumati a caro prezzo quando serve. Sempre dallo stesso articolo:

“Y2k was like a second gold rush for Cobol programmers who were seeing dwindling need for their skills. But six-and-a-half years later, there’s no savior in sight for this fading language.

At the same time, while there’s little curriculum coverage anymore at universities teaching computer science, “when you talk to practitioners, they’ll say there are applications in thousands of organizations that have to be maintained,” says Heikki Topi, chair of computer information services at Bentley College in Waltham, Mass., and a member of the education board for the Association for Computing Machinery.”

Sottostimare l’impatto di questi sistemi, anche come prospettiva di impiego è negare l’evidenza ed illudersi: non si tratta di qualcosa che morirà tanto presto. Si tratta di mercato di nicchia dal punto di vista professionale, ma non dal punto di vista della rilevanza industriale per cui saper trafficare con questi sistemi legacy, in certi casi, può risultare ben più redditizio di lavorare su cose nuove, moderne e che conoscono tutti.

Perfino per i neofiti della programmazione.

Esempio dall’esperienza

Durante la mia personale carriera professionale mi sono ritrovato a dover sviluppare e mantenere codice scritto in Visual Basic 5/6. Ho anche dovuto supportare ed estendere altro codice in quel linguaggio quando era già chiaro che Microsoft stava dedicandosi totalmente alla piattaforma .Net.

Nel mentre cercavamo un modo per “portare” il codice verso i più recenti VB.Net o C#, il codice legacy doveva continuare a funzionare: ossia dovevamo fornire supporto ed integrare tutte quelle funzionalità che non richiedessero qualcosa di troppo recente.

In alcuni casi aggiornare il programma equivaleva ad ammodernare la veste estetica: bastava cercare qualche libreria che fornisse un look moderno a certi widget (bottoni, listview, …) per togliere qualche anno all’applicazione di turno. Esattamente come fanno (o sostengono di fare) certe creme per la pelle.

Era chiaro tuttavia che, nonostante i trucchi estetici (doppio senso voluto), in poco tempo ci saremmo ritrovati nell’impossibilità pratica di continuare ad estendere quei programmi dal punto di vista delle feature mentre sviluppavamo i loro rimpiazzi. Tuttavia potevamo contare su un fatto, che spesso viene trascurato da molti programmatori: fornire software nuovo significa, nella maggior parte dei casi, imporre nuovi requisiti a livello di piattaforma per i clienti. Questo, a meno di dover presentare qualcosa in fretta e furia, permette di guadagnare tempo con i clienti, che normalmente si riservano un periodo sufficientemente lungo per decidere il da farsi.

Se la nuova versione di un software richiede un PC più potente per funzionare, visto che sfrutta questa o quella recente tecnologia, il cliente può tranquillamente non accettare questa imposizione. Non basta dire ad un cliente “funziona meglio!” per giustificare nuovi investimenti hardware e software: il cliente deve essere più che convinto della necessità non ulteriormente rimandabile di aggiornare qualcosa, altrimenti semplicemente non lo farà. Soprattutto se le presunte novità software servono a sostituirne dell’altro che, nonostante gli anni, continua a funzionare adeguatamente, per quello che serve al cliente.

Perchè abbia successo il software nuovo deve fare almeno tutto quello che faceva quello vecchio, possibilmente nello stesso modo esatto, ed anche di più. Di certo è ben difficile che un cliente cambi qualcosa senza vantaggi tangibili e senza una qualche garanzia di retrocompatibilità col passato. Quando dico “allo stesso modo”, intendo anche i bug! Ad esempio, parlando di Excel e di retrocompatibilità: Date problems Excel includes January 0, 1900 and February 29, 1900, incorrectly treating 1900 as a leap year. The bug originated from Lotus 1-2-3, and was purposely implemented in Excel for the purpose of backward compatibility. This legacy has later been carried over into Office Open XML file format.

Se le cose andranno male, sentirete spesso il cliente lamentarsi con frasi come: … ma io questa cosa la facevo in un altro modo col vecchio programma! O anche: La versione precedente era più facile da usare! Più questo genere di frase verrà ripetuta e più si farà strada nel cliente la volontà di ripristinare il vecchio sistema o programma. Finchè, stanco di ripetersi, lo farà davvero (o ci tenterà) e per giunta senza dirvi nulla! A buon intenditor…

Ricordo discussioni con amici che, in piena epoca Windows XP SP2+, si trovavano ancora alle prese con programmi per Windows 95, perchè il cliente di turno non ne voleva sapere di aggiornamenti. Fra l’altro aggiornare può significare fermare qualcosa fino alla fine dell’intervento. E se quel qualcosa è un impianto che sforna prodotti 24 ore su 24, ininterrottamente? Quanto costa aggiornare per aggiornare?

Io stesso mi sono trovato a dover fornire consulenza per come far funzionare programmi vecchi, progettati addirittura per il DOS e funzionanti in Windows95 (la sopra-citata retrocompatibilità), su sistemi più moderni, basati su Windows2000/XP.

In quel caso il problema non era il vetusto codice a 16bit con cui quei programmi erano stati scritti, quanto le nuove restrizioni di accesso e di uso per le periferiche (seriali e parallele) che non consentivano più ai programmi di fare i propri comodi, incontrollati. Dal sito di uno dei produttori di driver che fornivano una soluzione al problema:

“A problem that plagues Windows NT/2000 and Windows XP, is it’s strict control over I/O ports. Unlike Windows 95 & 98, Windows NT/2000/XP will cause an exception (Privileged Instruction) if an attempt is made to access a port that you are not privileged to talk too.

Actually it’s not Windows NT that does this, but any 386 or higher processor running in protected mode.”

Il mondo legacy come ambito professionale

Il software ed i sistemi possono essere anche legacy, ma i programmatori di certo non lo sono. Trovo normale, ma anche assolutamente controproducente sul lungo periodo, che il mondo dello sviluppo software si concentri solamente sul software nuovo. O dia questa impressione.

Non vedrei male corsi, anche universitari, dedicati a questo mondo. A dire il vero non mancano libri sull argomento (come questo, che prima o poi recensirò), ma sono infinitamente pochi rispetto alla massa che propugna solamente il nuovo.

Probabilmente scrivere nel proprio CV di essere degli “esperti nel trattare software legacy” non vi renderà più “trendy”. Però, per quanto mi riguarda, non lo considererei affatto come un demerito, semmai l’opposto: non tutti accettano di buon grado o sono portati ad aggiustare cose sviluppate da altri, magari anni or sono.

Con rispetto a quanto detto nel mio post precedente e in quello originario di Nando Pappalardo, mi verrebbe di suggerire ai web designer/developer la possibilità di ritagliarsi una fetta di mercato nella manutenzione (o anche refactoring/redesign se serve) di siti “legacy”, creati da altri. Non è facile da fare, anche per una questione di codice sorgente non sempre disponibile (anche legalmente), ma non sempre è davvero necessario rifare da zero un sito, perfino nel caso di progetti apparentemente disastrosi. Cioè, un professionista web, oltre a soluzioni “tutto-nuovo-di-zecca”, potrebbe proporne al cliente anche di meno radicali e costose, che magari riprendono il vecchio ma con come una serie di ritocchi qui e là per ammodernarlo. O perfino soluzioni di assistenza/manutenzione su qualcosa sviluppato da altri. Non è detto che sia sempre fattibile come cosa, ma è un’altra strategia su cui può valere la pena riflettere. Se è il caso e si può farci qualche soldo senza impazzire, perchè no?

Che ne pensate?