Blog

Ieri ho visto il portatile di mia mamma cadere da un tavolino e finire sul cemento, aperto a 180°, a faccia in giù.

La mia reazione a questo evento traumatico si è articolata in tre fasi:

• Occazzocazzocazzo! — nel pensare all’enorme quantità di documenti la cui unica copia è salvata proprio su quel portatile, nonostante continui a raccomandarmi di tenere un backup almeno dei dati più importanti;
• Presto, fare una copia di tutto! — nello scoprire con stupore che la macchina in questione non si era spenta. Ironia della sorte, avevo a portata di mano un disco esterno, perché avevo intenzione di fare io stesso un backup, più tardi quello stesso pomeriggio;
• apt-get install hdapsd — sulla Priya, il mio adorato ThinkPad, che in quel momento se ne stava pigramente accoccolata sul tavolino di fianco.

Rimanendo in tema di backup: ieri non trovavo più Serenity, la mia chiavina Lexar Firefly (il nome è assolutamente non casuale). Dopo il momento di panico iniziale, ho elencato mentalmente il contenuto della chiavina, e mi sono reso conto che l’unica cosa che ci avevo rimesso era l’oggetto fisico, visto che i file, quando non si trattava di roba facilmente reperibile su Internet, erano tutti seconde o terze copie. La chiavina alla fine era nella tasca degli altri pantaloni.

Insomma, date retta a uno che c’è passato: non aspettate il prossimo 31 marzo, fate un backup dei vostri documenti più importanti ora.

Ieri sul treno sono finito a chiaccherare con due ragazze americane. Ho portato avanti la conversazione, a lungo, senza ripetere ossessivamente meme presi dall’Internet e usando svariati sinonimi della parola “awesome”.

È bello vedere che, nonostante l’esposizione continua e prolungata a tutto ciò che è stupido e sbagliato, ho ancora qualcosa che assomiglia ad un cervello mio.

Un po’ per burla, un po’ per sincera curiosità, ho installato Emacs sul mio computer.

Non sono rimasto sorpreso quando mi sono reso conto che l’applicazione compare sia nella categoria Accessories che nella categoria Programming: più che altro, mi ha stupito che manchi da tutte le altre.

Oggi mi è stato chiesto di configurare una chiavina Internet Tre su un portatile con Ubuntu 10.04. Mi ero preparato al peggio (ho avuto a che fare con una chiavina simile un po’ di tempo fa, non era stata un’esperienza piacevole), ma la mia preparazione non copriva in alcun modo quello che ho visto.

Appena inserita la chiavina, questa viene riconosciuta come unità ottica: trucco standard per dispositivi di questo tipo, che hanno una piccola memoria flash interna contenente i driver, la quale viene nascosta al sistema operativo una volta che i driver in questione sono stati installati.

Dentro la finta unità ottica ci sono una manciata di file, tra i quali spiccano due directory dal nome piuttosto interessante: Linux e Linux Driver. Interessante, dicevo, soprattutto perché sulla scatola non si accenna in alcun modo al supporto per il pinguino…

La directory Linux Driver contiene un tarball, quindi lascio perdere per il momento e guardo dentro l’altra: i file chiamati autorun.sh e install_linux sembrano essere molto promettenti.

Ovviamente a questo punto mi scontro con il fatto che nessuno dei due file è marcato come eseguibile, e non si possono cambiare i permessi in un filesystem read–only, quindi copio tutto nella home ed eseguo install_linux come root (autorun.sh è solo un piccolo wrapper).

Succede qualcosa! Lo script mi chiede dove installare il programma, proponendo una directory sotto /usr/local. Mi sembra il posto migliore dove relegare dei loschi eseguibili di dubbia qualità, quindi accetto. A questo punto salta fuori un xterm, sul quale scorrono tutta una serie di scritte – scompatta cose in /usr/src? Cerca di compilare un modulo del kernel? Sta usando in qualche modo ndiswrapper? Troppo veloce per capirlo – che si fermano pochi secondi dopo, lasciando una scritta rossa che mi suggerisce di installare make, gcc e gli header del kernel.

Torno in cima all’xterm, cercando di capire cosa diavolo abbia cercato di fare quello script, e ho appena iniziato a leggere quando compare una finestra, grande, con davanti una più piccola: quest’ultima i chiede il codice PIN, ed entrambe sembrano uscite da Windows XP, decorazioni comprese.

Inserisco il PIN, pigio “Connetti”, e dopo pochi istanti si apre il browser. Si è effettivamente connesso.

Faccio un giro veloce in /usr/local, e trovo 47MB di librerie varie, compresa una copia delle Qt, più tutta una serie di eseguibili, sia in formato 32bit che 64bit, più altri file binari divisi in directory che hanno il nome di distribuzioni. Ubuntu e Debian brillano nella loro assenza.

Conclusione: la chiavina funziona. Non so come faccia. Non credo di volerlo sapere. Quello che posso fare è sperare in un futuro in cui i produttori di hardware, invece di pagare persone per stare chiuse in uno scantinato a scrivere in totale segretezza loschi driver per Linux, paghino li stessi tizi per mantenere quei driver all’interno del kernel, e lascino perdere gli orrendi programmini personalizzati per passare a Network Manager, eventualmente contribuendo allo sviluppo delle funzionalità che ritengono necessarie.

Oggi ho passato una mezza giornata a rifattorizzare il mio codice.

Sposta una classe di qua, un metodo di là, aggiusta questo e quello in modo che i campi siano pubblici solo quando è strettamente necessario e che non ci sia né troppo stato all’interno dell’oggetto né troppi parametri nelle chiamate ai metodi.

Mentre facevo questo lavoro, spesso meccanico e quasi sempre poco appagante, che ha portato il mio programma a smettere di funzionare almeno una decina di volte, maledivo me stesso per non aver seguito un design migliore fin dal principio.

Poi ho realizzato.

Una delle cose positive del lavorare quotidianamente nell’ambiente del Software Libero è che, con l’andare del tempo, acquisisci automaticamente alcune buone abitudini, come quella di utilizzare sempre un VCS, quella di scrivere codice portabile, quella di utilizzare un build system decente, quella di documentare almeno un po’ il tuo lavoro. Lavori, insomma, partendo dal presupposto che qualcuno prima o poi possa voler mettere mano al tuo codice, e cerchi di fare sì che la sua esperienza non si riveli un incubo.

Tra le altre cose, questo significa anche utilizzare un buon design. Quindi, istintivamente, quando mi sono messo al lavoro su quel progetto sono partito seguendo il miglior design che sono stato in grado di sviluppare con le conoscenze che avevo in quel momento. Il quale poi si è rivelato una mezza schifezza.

Il punto chiave è proprio il fatto che, quando ho iniziato, avevo solamente una vaga idea di quello che avrei dovuto fare per raggiungere il mio scopo: mano a mano che proseguivo ho cominciato ad aggiungere librerie, molte delle quali non avevo mai usato, ho provato vari approcci che si sono rivelati poco furbi, e in generale ho riscritto più volte praticamente ogni riga del programma. Molti di questi cambiamenti mi hanno costretto a rivedere parte della mia idea iniziale.

Arrivato a quel punto, le alternative erano due: proseguire con l’implementazione, ormai quasi completa ma figlia di un design cresciuto organicamente e disordinatamente, oppure creare un nuovo design e riorganizzare il tutto. Ho scelto la strada più scomoda, ma non me ne pento.

E ho smesso pure di maledirmi da solo, dal momento che ho capito che non sarei mai riuscito a sviluppare il nuovo, migliore design se non avessi prima implementato quasi interamente l’applicazione, cosa che (ovviamente) mi ha fatto capire molto meglio il problema che stavo cercando di risolvere.

Insomma, come dice il saggio: build one to throw away.