main index Breve sunto dal mio poderoso curriculum.

Studi: Laurea in Scienze dell'Informazione all'Università degli Studi di Salerno (1997) con tesi di ricerca applicata (linguaggi visuali e programmazione object oriented).

Esperienza:

Libero professionista dal 1998 ad oggi.

Ambiente: Linux; principalmente C, C++, Ruby.

Attitudini: networking, sicurezza, protocolli, telerilevamento.

Hobby: fotografia, Arduino, mattoncini LEGO.

Alcune mie personali fonti di ispirazione e di shopping: hackaday, ycombinator, codinghorror, bunniestudios, newelementary, ioccc, adafruit, sparkfun.


Detesto i curriculum. Il curriculum è un tentativo di spiegare ad uno sconosciuto le proprie capacità. Lo sconosciuto è tipicamente uno che deve marcare caselline Excel "va bene / non va bene".

Aggiungo qui sotto qualche episodio personale che non si può scrivere in un curriculum.

Il primo giorno che lavorai presso Telecom Italia, dal Collaudo lamentavano un'anomalia che aveva colto di sorpresa i colleghi di Sviluppo. Risolsi istantaneamente il problema: avevo visto da un "ls -l" di una collega che le dimensioni dei file di input erano 104857600 bytes e le feci subito chiamare il Collaudo per dire che erano stati splittati "a byte" anziché "a righe". Non tutti riconoscono a vista le potenze di due seguite da zeri: non tutti sanno che "104857600" significa "cento mega tondi tondi".

Quest'altro episodio avvenne presso una grossa banca che aveva chiesto di riscrivere in "C pulito" una procedura di conversione dati che girava su una macchina Solaris che non potevano dismettere perché i sorgenti originali si erano persi nella notte dei tempi (eh, sì, succede anche nelle migliori famiglie). Passò il collaudo ma si bloccò misteriosamente al momento della consegna. Era ora di pranzo: chiesi un'ora di tempo per analizzare il problema e scoprii dei campi in più che non erano presenti nelle specifiche. Patch al volo, specifiche e documento di collaudo corretti a penna, pranzo saltato ma scadenza rispettata e cliente sazio e soddisfatto. Non so quante volte nella vita possa capitare di uscire da una banca sommerso dai complimenti di direttori e tecnici.

Una volta un tecnico del cliente era venuto a farmi un cazziatone perché di quando in quando la mia procedura che riceveva dati da un host Siemens si fermava senza motivo. Proprio nel momento in cui cominciava quel cazziatone, mentre stava scorrendo furiosamente a video una galassia di righe di log, con la coda dell'occhio ne colsi una che mi sembrava strana e chiesi a bruciapelo: "ma cosa significa DRUCKER-DURCH-qualcosa?" Invece del cazziatone si sentì un ululato: "noooo!" Avevo dimostrato che l'errore era lato host.

Non sono un teorico ma a volte mi è capitato di dover spiegare a qualche Project Manager la differenza tra complessità polinomiale ed esponenziale. Un'altra volta ho salvato la pelle a un collega spiegandogli la ricerca binaria. Una volta mi sono lamentato che se certi campi non erano presenti nel flusso, io non ero in grado di estrarre dal flusso i campi che non sono presenti nel flusso. Mi hanno spesso chiesto come facevo a capire protocolli e indirizzi ed eventuale crittografia guardando solo per un attimo tutti quei numeretti esadecimali di Wireshark. Spesso ho dovuto spiegare gli operatori binari bit a bit per far capire come trattare velocemente gli indirizzi IP (che tipicamente venivano maneggiati come... stringhe!)

Una volta, in un datacenter, installando e facendo hardening, ho annotato passo-passo tutte le operazioni spiegando per ognuna il motivo per cui preferivo evitare le alternative. È così che nasce la documentazione: altro che il lunedì mattina col Word "mettiamoci a scrivere una bella documentazione con tutti i fronzoli possibili del Word".

Ho recuperato dei dati intuendo a vista di pagine esadecimali dove cominciava la partizione. Ho risolto bug esoterici soppesando per un attimo a occhio le parentesi. Ho scritto procedure in Perl senza averlo mai studiato. Ho scritto procedure in Ruby più veloci di quelle in C e Java dei colleghi. In un caso scrissi in assembler x86 un intero driver per stampante perché le macchine su cui dovevo ricevere i dati non potevano utilizzare altro canale che i flussi di stampa dall'emulazione terminale 3270 (ero giovane: non lo rifarei).

La cosa peggiore che può capitare a chi fa il mio mestiere, peggio dell'avere dei sottoposti incapaci, peggio dell'avere specifiche fumose e variabili nel tempo, è quella di avere dei capi incapaci che pensano tipicamente di risolvere tre quarti dei problemi con due soli strumenti: il metter fretta a chi sta lavorando ed il comprare server con dischi più capienti. Un buon tecnico può diventare un buon commerciale, ma non viceversa.

Avendoci smanettato talvolta fino alla frustrazione, ho sviluppato una specie di sesto senso, una particolare forma di intuito che non si può descrivere in un curriculum. È come se notassi i pacchetti che transitano su un cavo ethernet. È come se vedessi cosa succede a smazzare troppo spesso quell'interrupt, è come se sentissi l'odore dei registri "sporchi" e non salvati, o la "stanchezza" del controller disco inutilmente stressato da qualche procedura scritta coi piedi. Intuisco di chi è la colpa di un SEGV senza neppure aprire gdb; mi accorgo quando sta per piovere una valanga di swapping, sento la puzza dell'interprete Java là dove bastava uno scriptino awk, percepisco a naso che tre dei quattro processori sono fermi a girarsi i pollici, sento addirittura i disturbi al segnale wifi (che ci crediate o no, a volte basta spegnere un neon per far cadere una connessione).

E una volta, infuriato per il disservizio, ho ripristinato una fibra 100 megabit Fastweb strattonandola, evitando così di dover far intervenire i verticalisti. Il cliente, ignaro dell'accaduto, tutto contento ha elogiato la mia "professionalità".

No, queste cose non si possono scrivere nel curriculum. Anziché mandare un curriculum, dovrei mandare i miei colleghi ed ex colleghi a raccontare qualche aneddoto su di me. Anche se si soffermerebbero su aneddoti più divertenti, come quando presi bonariamente in giro uno dicendo: "hai davvero modificato il kernel quando avresti potuto usare inotify?" (con chi invece usa il disco o il database come se fosse RAM ci vado giù in modo un po' più scurrile).


Alcuni errori che mi hanno insegnato molto.

Molti anni fa ho cancellato un'intera directory di miei vecchi software giovanili di cui non avevo altri backup. Attimi di tragedia e ululati vari. Lezioni imparate in un sol colpo: mai usare root per compiti non amministrativi; mai rimanere senza almeno due backup freschi di ogni cosa di valore lavorativo o affettivo; mai lasciare materiale sotto /tmp.

Una volta c'era un problemino sulla riconfigurazione automatica del firewall attivata da un port knocking. Per non scomodare la collega che l'aveva scritta, avevo cominciato a correggere e migliorare la procedura, ma ogni mattone che spostavo ne cadevano tre. Dopo un paio di giorni, stanco di essere ancora a metà strada per risolvere un banale problemino mi sono arreso e ho chiesto il suo aiuto. Lezione appresa: quando si mette mano a codice scritto da altri, si sa quando si comincia ma non si sa quando si finisce. Il novanta per cento delle volte che ho preferito riscrivere da solo i pezzi di codice di cui a prima vista non mi fidavo, ho rispettato le date di consegna. Non è l'attitudine del "not invented here": è solo l'invincibile diffidenza verso codice scritto in fretta e furia.

Ho comprato hardware per uso personale scegliendo il più potente, veloce e capiente... nel momento in cui non ne avevo bisogno. Per di più in estate. Pagando in lire che ricordo ancora con bruciore. Lezione appresa: l'hardware si compra solo quando serve e commisurato a quel che serve.

Una volta, giovanissimo, persi qualche giorno a sviluppare in C una procedura che sarebbe stato meglio implementare come uno script. Fu una fatica immane. Lezione appresa: la pedanteria accademica talvolta è un male.

Una volta, in uno dei primi lavori, non riuscendo ad agganciare tutti gli ACK/NAK di risposta del server, scrissi la mia procedura in modo sincrono. Un'intera nottata a regime e non perse neppure un pacchetto. Ma l'ingegnere mi tirò le orecchie: una sincronizzazione "a treno" non sarà sempre così fortunata. Fui costretto a riscriverla daccapo - e fu un bene: in oltre dieci anni si fermò una sola volta. Lezione appresa: la pedanteria accademica spesso non è un male.

Anche a me è capitato, sotto pressione, di consegnare un software collaudato poco e in fretta, ottenendo guai e scatafasci nel giorno stesso in cui sarebbe dovuto gioiosamente entrare in esercizio. Lezione appresa: la pedanteria nei collaudi è sempre un bene. Altra lezione appresa: preventivare oltre al tempo di sviluppo anche adeguato tempo di collaudo e adeguato tempo per tuning e correzioni di ciò che emerge dal collaudo. Deprecabile vizietto tutto italiano da combattere con tutte le forze possibili: "ci vogliono X giorni per lo sviluppo, dunque consegneremo tra X giorni".

Scrivere software è un'arte poetica: richiede più creatività che dedizione. Altrimenti si finisce a mettere insieme versi in rima solo per sfangare la deadline...

Alcuni suggerimenti per far fallire un progetto:

--- continua... ---


Google
 
Web www.alfonsomartone.itb.it

Click here for index page.

send e-mail - continua (next page)