Git on Melabit

Antigravity: l'LLM lo fa meglio

Mon, 16 Mar 2026 18:00:00 +0000

Nelle ultime settimane ho scritto delle mie esperienze con Antigravity, o meglio con gli agenti (più o meno) intelligenti integrati in questo editor. I risultati sono stati contrastanti: a volte gli agenti si sono dimostrati molto efficaci, alleviando con precisione alcuni compiti complessi o ripetitivi, in altri casi non hanno combinato niente di buono facendo solo perdere una montagna di tempo.

Programmare male con l’LLM

Fra tutti gli impieghi più o meno utili degli LLM, uno dei più controversi è l’idea che chiunque possa usare un LLM per programmare, anche quando di programmazione non se ne sa una cippa. È il cosidetto vibe coding, un concetto che si può riassumere così: “vedo cose, dico cose, copio e incollo cose, e nella maggior parte dei casi funziona”. Non è una citazione da Nanni Moretti, lo dice Andrej Karpathy, uno dei fondatori di OpenAI.

Ora, mettendo da parte le tante questioni relative alla sicurezza, alla manutenibilità di codice prodotto senza sapere bene cosa fa, alla deriva verso la media che implica che la qualità del codice prodotto dall’IA tenderà inevitabilmente a crollare, basta sperimentare un po’ in prima persona, anche con progetti semplici, per accorgersi che l’idea del coding per tutti non funziona, e che se vuoi ottenere qualcosa di buono dall’IA devi sapere bene cosa vuoi e come lo vuoi.

Ci ho provato io stesso a fare vibe coding: ho chiesto a Gemini di scrivere un driver per una videocamera Arducam, spiegandogli solo le cose indispensabili a aspettando che facesse tutto da solo.¹

Questo approccio però non ha funzionato. Ci sono volute ore ed ore di lavoro, di errori, di risposte inconcludenti, di correzioni e di consigli per raggiungere un risultato accettabile.

E questo solo perché a un certo punto ho buttato alle ortiche l’idea di far fare tutto a Gemini e gli ho dato dei consigli su come procedere. Senza quelli sarebbe stato solo un sacco di tempo buttato via inutilmente.

Anche Mimmo ha provato, in modo del tutto indipendente da me, a far scrivere a Lumo un programma in Micropython per gestire la mia Arducam Mini 5MP Plus con il Pico. E anche Lumo, che è senza dubbio uno dei migliori chatbot in circolazione, non ce l’ha fatta da solo.

– Immagine generata da Google Gemini.

Programmare meglio con lo stesso LLM

Tutto questo però non significa che un LLM non possa essere prezioso quando si programma, basta solo usarlo come si deve. Bisogna spiegargli per filo e per segno cosa deve fare, mettergli a disposizione tutto il materiale che gli serve per lavorare, e piazzargli dei paletti entro cui deve muoversi.

In poche parole, bisogna trattarlo come un tesista o una stagista, con poca esperienza ma tanta voglia di imparare.

Sono bastati infatti due prompt scritti con criterio, il primo che definiva la struttura delle directory del progetto e istruiva l’agente ad usare fin dall’inizio git per il controllo di versione del codice e uv per installare i pacchetti Python che gli sarebbero potuti servire,

Prompt

Start a new project and name it project13-pico-camera5mp-reprise.

Read the AGENTS.md file that defines your basic behaviour.

Create a new directory with this name and initialize an empty git repository using git init Use uv for managing Python packages. All the code must stay in the code directory, with no subdirectories within it. This project does not need a data directory and the output directory must be renamed as images.

e il secondo che conteneva tutto quello che mi è venuto in mente per aiutarlo a lavorare,

Prompt

I have a Rasperry Pi Pico 2W connected to a Arducam 5MP Plus OV5642 Mini Module Camera Shield (https://www.arducam.com/arducam-5mp-plus-spi-cam-arduino-ov5642.html).

I have connected the camera to the Pico using the standard layout found in the documentation:

Camera	CS	MOSI	MISO	SCK	GND	VCC	SDA	SCL
Pico	GP5	GP3	GP4	GP2	GND	3V3	GP8	GP9

The main documentation for the camera can be found at these links:

The code to drive this camera with the Pico is written in C (i.e., for Arduino) and CircuitPython, and can be found here: https://github.com/ArduCAM/PICO_SPI_CAM. You can download all the files you need from this repository. In particular, the files for CircuitPython are in the Python directory:

Arducam.py, which contains the functions to drive the camera,
OV5642_reg.py which, as far as I have understood, defines the resolutions allowed when taking pictures, and
boot.py , but I don’t know what it does. In the same directory there is also the script ArduCAM_Mini_5MP_Plus_VideoStreaming.py which sends the video captured by the camera to a Windows application and that is of no use here.

Please write a basic CircuitPython script that uses the functions defined in Arducam.py to test that the camera works and can take photos.

per permettere a Gemini 3 Flash di generare rapidamente uno script in CircuitPython che gira direttamente sul Pico e che fa tutto quello che gli è stato chiesto.

In verità, la primissima versione dello script non funzionava, ma è bastato a Gemini modificare una sola riga del driver Arducam.py fornito dal produttore per mettere tutto a posto (ha tolto uno zero al valore della frequenza).²

– La linea evidenziata in azzurro indica l’unica modifica effettuata da Gemini al file Arducam.py; a sinistra il file originale, a destra quello modificato da Gemini.

Tutti gli altri file forniti dal produttore sono rimasti intatti.

Alla prova dei fatti, il driver del produttore funzionava benissimo con il Pico e Gemini si è limitato ad imparare ad usarlo per scrivere lo script che cattura l’immagine direttamente dal microcontroller (una cosa che con un po’ di pazienza avrei potuto fare anch’io).

Guidare l’LLM o lasciarlo fare da solo?

La differenza rispetto al vibe coding della volta scorsa è abissale.

In quel caso Gemini aveva lavorato furiosamente per ore, combinando dei tali casini da costringermi a riavviare per ben due volte il Mac. E nel frattempo si era convinto (e mi aveva convinto) che il driver Arducam.py fosse incompatibile con Il Pico e l’aveva riscritto da zero, buttando via una libreria essenziale per interloquire con la videocamera (quella indicata dalla freccia rossa),

– Modifiche alle prime righe del file Arducam.py; a sinistra il file originale, a destra come appare lo stesso file dopo le modifiche di Gemini. La freccia indica una libreria importante che viene rimossa di peso da Gemini.

e togliendo senza nessun motivo, e senza nemmeno un guadagno reale in termini di efficienza o di funzionalità (anzi!), la maggior parte delle funzioni definite nello stesso file (si noti nell’immagine qui sotto la differenza nella lunghezza del codice originale, a sinistra, rispetto a quello modificato, a destra).

– Modifiche al file Arducam.py. I rettangoli rossi mettono in evidenza la differenza fra il numero di righe del codice originale (a sinistra) e di quello modificato da Gemini (a destra).

E non contento di tutto ciò, aveva pure stravolto il file OV5642_reg.py contenente i dati di configurazione della videocamera, adducendo dei presunti problemi di memoria. Problemi che evidentemente non esistevano, visto che in questo secondo esperimento tutto è filato liscio usando il file originale del produttore.

– Modifiche al file OV5642_reg.py, contenente i dati di configurazione della videocamera. La configurazione originale (a sinistra) è stata totalmente stravolta da Gemini (a destra).

E Arduino?

Arrivato a questo punto era inevitabile che chiedessi a Gemini di generare anche il driver per Arduino, usando le stesse informazioni che gli avevo già fornito per CircuitPython.

Questa volta Gemini ha penato di più, ma soprattutto perché gli avevo imposto di effettuare solo delle modifiche minime alle librerie originali Arducam. Un vincolo che questa volta era impossibile da soddisfare, perché queste librerie non supportano nativamente il Raspberry Pi Pico.

Risposta

Researching Arducam Library Compatibility I’ve thoroughly inspected both the original ArduCAM library and the Arducam_mini library. Neither version contains native support for the RP2040/RP2350 (Pico) architecture. Specifically, both libraries are missing the necessary definitions for regtype, regsize, cbi, and sbi for this platform, which is the root cause of the compilation errors.

Una volta allentato questo vincolo le cose sono filate lisce e in poco tempo anche il driver modificato ad hoc per il Pico ed il relativo programma di acquisizione delle immagini erano pronti.

Gratis o a pagamento?

C’è chi sostiene che i modelli a pagamento sono molto meglio di quelli gratuiti. Di conseguenza, i miei problemi con il vibe coding sarebbero scomparsi se avessi pagato per usare Gemini o Claude.

Non è proprio così. Nel corso delle prove ho usato prevalentemente la versione gratuita di Gemini, proprio per verificare cosa succedeva all’utente non professionale che voleva provare a giocare un po’ con questi strumenti. Ma quando finivano i token sono passato alla versione a pagamento di Gemini fornita dall’università, e non ho mai notato differenze significative. Su Claude non posso dire niente, perché dover pagare 200 dollari al mese per usarlo in modo serio non ha senso per chi, come il sottoscritto, non è un programmatore professionista.

Ho notato però che Claude Opus e Claude Sonnet si sono sempre dimostrati molto più bravi di Gemini a risolvere i problemi che si presentavano nel corso dello sviluppo del codice. Ma poiché li ho utilizzati sempre a lavoro inoltrato, potrebbero solo essere stati facilitati da quello che Gemini aveva già fatto.

Conclusioni

È inutile dire che sia questo esperimento che quello precedente non hanno nulla di scientifico. Per essere tale, dovrei almeno utilizzare tipi diversi di microcontroller e di moduli collegati, stabilire un set di prompt ben definito e misurare in qualche modo come cambia la risposta dell’agente di turno al variare delle condizioni sperimentali.

Ma nonostante questo, l’esperimento ha un pregio: è riproducibile. Chiunque, con una spesa ridotta, può provare a ripeterlo usando lo stesso hardware e gli stessi prompt, in modo do verificare di persona se quello che ho trovato io è corretto o no.³

Una cosa che gli apostoli del vibe coding da decine di milioni di letture evitano sempre accuratamente di proporre. I loro articoli sono pieni di certezze e di previsioni roboanti, ma mancano sempre di fornire il sia pur minimo appiglio che permetta di verificare i loro claim.

Nessuno, oggi, può ancora negare che gli LLM possano essere di grande aiuto durante la programmazione, ma è difficile credere che riescano davvero a farlo senza nessun intervento umano. E questo almeno finché gli apostoli di cui sopra non si degneranno di fornirci dati chiari e ripetibili a supporto delle loro affermazioni.

Pur sapendo qualcosa di programmazione, non avevo la minima idea di come si potesse sviluppare un driver e non avevo nessuna voglia di passare dei giorni a studiare come si fa. ↩︎
Tecnicamente questo file è una libreria di funzioni, ma i microcontroller non hanno un sistema operativo e quindi queste funzioni accedono direttamente all’hardware, proprio come fanno i driver che controllano i componenti di un computer. Di conseguenza, in questo caso i termini libreria e driver sono interscambiabili. ↩︎
Dico spesa ridotta ma ormai la penuria di componenti elettronici ha fatto impazzire i prezzi del Pico e ancor di più della Arducam Mini 5MP Plus. Quest’ultima, dai 40 euro di pochi mesi fa ora si trova su Amazon o AliExpress a più del triplo. Per fortuna alcuni rivenditori mantengono (almeno per ora) dei prezzi più onesti. ↩︎

Effetto Dory

Mon, 09 Mar 2026 18:00:00 +0000

Lo so che gli LLM hanno poca memoria, ma non avrei mai immaginato di doverne subire così in fretta le conseguenze.

– Immagine generata da Google Gemini.

Nota per il lettore. Questo articolo è un complemento di quello precedente, Antigravity: un driver scritto dall’IA e andrebbe letto dopo il primo. Ma ecco un breve riassunto per i più pigri.

Non sapendo come fare a scrivere un driver per una videocamera SPI collegata ad un Raspberry Pi Pico, ho chiesto aiuto a Gemini 3 Flash, lavorando interamente dentro Antigravity. Dopo parecchie ore di lavoro, l’agente è riuscito a scrivere un programma funzionante in Arduino. A questo punto ho fatto un errore fatale, chiedendogli ancora di più, ma senza prendere delle precauzioni.

Premessa

Il codice funzionante generato con tanta fatica da Gemini 3 Flash prevedeva che il Pico facesse da interfaccia fra il mio Mac Mini e la videocamera SPI.¹ Sul Mac, uno script in Python comandava la cattura di una immagine, mentre l’acquisizione vera e propria veniva eseguita dal Pico tramite un programma per Arduino (uno sketch, nel gergo della piattaforma), che è fondamentalmente codice C/C++ adattato all’uso con i microcontrollori.

Comandare tutto da computer va benissimo per le prime prove, ma è molto scomodo quando si prevede di usare un dispositivo di questo genere per delle attività sul campo.

Catture automatiche

Allora ho chiesto a Gemini di modificare il codice in modo da effettuare automaticamente la cattura dell’immagine ogni N minuti oppure premendo un pulsante, inviando poi l’immagine ad un computer tramite Wi-Fi.²

Prompt

[...] However, this means that I need to use a Pico for the capture and another computer, even a Raspberry Pi Zero for commanding the capture process. Would it be possible to do everything on the Pico, eg press a button and perform the capture or via a timed process (defined in the .ino file itself) every N minutes (but there should be a mechanism that sends the images to a computer connected by WiFi, avoiding to fill the pico storage space).

Gemini si mette subito al lavoro, sempre continuando ad usare Arduino. Dovrebbe essere un programma molto semplice da realizzare ma, per quanto Gemini ci provi, non funziona mai. Dopo molti tentativi infruttuosi mi scoccio e gli chiedo di ritornare all’ultima versione funzionante del programma.

Tornare sui propri passi

E qui Gemini sbatte contro un muro imprevisto perché, nonostante la mia guida e i miei continui suggerimenti, non c’è assolutamente verso di riuscirci.

Stupidamente non avevo pensato di tenere traccia delle varie versioni del codice man mano che veniva generato, e questa è solo ed esclusivamente colpa mia.

Ma d’altre parte, pur essendo ben consapevole che i modelli linguistici di grandi dimensioni (LLM, Large Language Model) mentre lavorano hanno una memoria che sembra quella della pesciolina Dory, non avrei mai immaginato che questi sistemi ultrasofisticati non fossero neanche in grado di ricostruire a posteriori ciò che hanno fatto, pur avendo a disposizione decine e decine di file implementation_plan.md, task.md e walkthrough.md, che descrivono per filo e per segno tutti i passaggi precedenti (li ho contati, solo per questo progetto Antigravity ha generato più di 250 file diversi).

Tornare sui propri passi è una cosa che invece strumenti come git e i suoi predecessori, tutti privi di una qualunque forma di intelligenza che non sia quella dei suoi creatori, sono in grado di fare benissimo da più di cinquant’anni. Magari chi sviluppa questi agenti tanto intelligenti potrebbe farci un pensierino, no?

Epilogo

Alla fine, testardamente e basandomi sulle mie note,³ sono riuscito a far ripetere a Gemini tutto quello che aveva già fatto. Ci ha messo delle ore, ha ripetuto pari pari tutti gli errori della volta precedente, ma alla fine il codice ricostruito funziona di nuovo correttamente.

Già che c’ero, gli ho fatto rifare tutto anche per CircuitPython, e anche questo port ha richiesto molte altre ore di lavoro e di errori. E, prima di arrivarci, Gemini ha creato dei problemi talmente gravi che macOS ha dovuto disabilitare la comunicazione delle porte USB con il Pico, costringendomi a riavviare per un paio di volte il Mac.

Inutile dire che questa volta gli ho fatto tenere traccia di ogni passaggio con git e ho messo pure tutto il codice su GitHub, non si sa mai.

Uno dei prossimi passi sarà (spero) MicroPython, ma questa è ancora un’altra storia.

Perché Arduino fa tanta fatica, pur se è una piattaforma di sviluppo per microcontroller molto più matura di MicroPython e CircuitPython? Perché, per il modello di videocamera che ho scelto, Arducam non supporta il Raspberry Pi Pico ma solo i Raspberry Pi classici (quelli con il sistema operativo, per intenderci, come il Rasperry Pi 4, 5 e lo Zero), nonché tutti i microcontroller Arduino e ESP286. ↩︎
Lo so che l’inglese non è un gran che, è più un flusso di pensieri che un discorso organico. Ma ci sono dettagli che mi vengono in mente mentre scrivo, e preferisco buttarli giù così alla bell’e meglio piuttosto che perdere il filo delle idee. ↩︎
Non ripeterò mai abbastanza quanto sia importante tenere delle note scritte di quello che si fa. All’inizio sembra solo una perdita di tempo, mentre invece è il modo migliore per evitare di perderlo in futuro. ↩︎

Il CNR è anche questo: concorsi in LaTeX

Sun, 08 Nov 2020 06:00:00 +0000

Nella puntata precedente ho raccontato della mia corsa contro il tempo dell’estate, una prova assurda come quelle di Giochi senza frontiere, ma senza allegria.

Inutile però dilungarsi ancora in dettagli poco comprensibili ai non addetti ai lavori. Meglio parlare invece di cosa ho fatto io per superare questa prova, cercando di sfruttare quel poco che so di LaTeX e di programmazione.

Perché, l’ho già detto ma mi ripeto, qualche nozione di programmazione può aiutare a cavarsela meglio con le tante rotture di cabasisi che dobbiamo affrontare ogni giorno.

Se c’è una cosa sulla quale sin dal primo momento non ho avuto il minimo dubbio, è che non avrei usato Word per preparare il curriculum professionale. Word non mi piace, si sa, ma in questa scelta non c’era nessuna prevenzione, era solo un modo per preservare la mia salute mentale.

Word ha grosse difficoltà a gestire strutture complesse come le tabelle. Una, due, tre, dieci tabelle vanno ancora bene, ma qui si trattava di creare centinaia e centinaia di tabelle diverse, una per ogni titolo – articolo, progetto, software, brevetto, insegnamento, incarico – inserito nel curriculum professionale. Dopo un po’ Word sarebbe letteralmente impazzito nel maneggiare tutte quelle tabelle, facendomi perdere un sacco di tempo prezioso.

Con LaTeX il problema non si pone. Un documento LaTeX è un normale file di testo e il fatto che contenga tabelle, liste o semplici paragrafi non fa molta differenza, sono solo delle porzioni di testo strutturate in modo diverso. Il peggio che può capitare è che il compilatore LaTeX impieghi qualche secondo in più a convertire il documento LaTeX in PDF.

Il fatto che i documenti LaTeX siano dei file di testo mi permetteva anche di generare automaticamente le tabelle relative a ciascun titolo inserito nel curriculum professionale, una cosa impossibile da fare con Word e che ha velocizzato moltissimo tutto il lavoro.

Già perché, non l’ho detto prima, il curriculum professionale andava sì scritto in Word, ma poi la sottomissione andava fatta in PDF,¹ utilizzando (ci credete?) la piattaforma online per i concorsi dismessa così improvvidamente. In pratica il modello in Word fornito dall’amministrazione serviva solo come indicazione di massima di come dovesse essere organizzato il curriculum, ma niente impediva di utilizzare altri strumenti. L’unica cosa davvero importante è che il layout del file PDF corrispondesse a quello previsto dall’amministrazione.

Riprodurre in LaTeX il modello originale in Word non è stato difficile: la classe memoir è molto flessibile ed è particolarmente adatta a produrre tutti quei documenti che escono dai canoni classici di LaTeX, mentre i package geometry, booktabs, multirow e titlesec permettono di regolare finemente i dettagli del documento finale.

Sia chiaro, preparare un modello di documento LaTeX partendo da zero non è mai facile, a meno di non essere dei veri esperti. Per fortuna avevo già fatto delle cose simili in passato e mi è bastato modificare qualche dettaglio per ottenere quello che mi serviva.²

Il modello LaTeX era però il problema minore, ciò che importava davvero era riuscire a riutilizzare il più possibile il lavoro fatto in passato. Come già detto nel post precedente, i soloni che ci governano non avevano previsto nessuna possibilità di esportare i dati già presenti sulla piattaforma online. L’unica possibilità era quella di partire dal curriculum in PDF preparato per un concorso precedente (del 2013, ben sette anni fa).

Per fortuna ho una certa esperienza nell’estrazione di dati dai documenti PDF, un problema molto attuale dato che tante istituzioni, non solo nazionali ma anche internazionali, sono molto restie a condividere i loro dati in formati standard utilizzabili da chi, come me, si occupa di estrarre informazioni dalle serie temporali di misure. Quando va bene il meglio che si riesce ad ottenere sono dei file PDF contenenti delle tabelle mal strutturate, che bisogna ingegnarsi a convertire in formati usabili per le analisi. Mi è bastato quindi adattare uno script in R sviluppato per altri scopi per riuscire a convertire la domanda in PDF in un file CSV ben ordinato.

Partendo dal file CSV e con qualche semplice script in AWK (un’altro tool di base di cui non potrei mai fare a meno) è stato quasi un gioco da ragazzi estrarre i dati relativi ai titoli già presentati in quel concorso, salvandoli in file differenti in base alla tipologia in modo che poi fosse più semplice aggiungere uno ad uno i titoli mancanti (dal 2013 ad oggi ce ne sono state di novità!). Il modello LaTeX si occupava poi di importare questi file nella sequenza corretta producendo il curriculum completo.

Già che c’ero, con gli stessi script potevo anche costruire automaticamente le tabelle LaTeX dove incasellare ciascun titolo. È una cosa più difficile da spiegare che da fare, ma che ha rappresentato un vantaggio incomparabile rispetto a creare le tabelle una ad una con Word.

Devo ammettere che gli script AWK non erano perfetti, purtroppo me ne sono accorto solo dopo aver iniziato il lavoro di inserimento dei nuovi titoli. Ma dato che questi script mi servivano solo una volta, ho preferito correggere a mano gli errori piuttosto che perdere altro tempo a perfezionarli.

Lavorare con file diversi per ciascuna tipologia (o fattispecie, il termine preferito dai nostri vertici amministrativi) aveva un altro grosso vantaggio. Avendo separato il modello LaTeX, che gestiva l’aspetto generale del curriculum professionale, dai dati riportati nei diversi file, potevo velocizzare parecchio la fase di (diciamo così) debugging del documento finale. In altre parole, se lavoravo sugli articoli scientifici scritti nel corso della mia carriera, potevo importare nel modello generale LaTeX solo il file relativo, lasciando fuori tutto ciò che riguardava le altre attività svolte. Analogamente per le altre tipologie di documenti. Sembra una cosa da niente, ma quando si passano le giornate ad inserire i dati di decine di nuovi documenti, avere a disposizione un file PDF più snello e poter controllare più rapidamente di non aver fatto errori e di non aver dimenticato niente può davvero fare la differenza.

Un altro aspetto chiave dell’usare LaTeX al posto di Word è stato il fatto di poter numerare a piacere le singole tabelle. Su questo la confusione era massima. Il principio generale era chiaro, i vari titoli delle Categorie A e B andavano inseriti rispettando un ordine temporale inverso, dal più recente al più vecchio, assegnando un numero progressivo a ciascuna tabella. Quello che non era affatto chiaro era il come.

Modello di curriculum professionale: titoli della Categoria A.

Modello di curriculum professionale: titoli della Categoria B.

C’era chi affermava che si dovessero numerare progressivamente i documenti della Categoria A, gli ormai famosi Prodotti della Ricerca, indipendentemente dalla loro tipologia ma tendendo conto solo della data, ricominciando la numerazione dal principio una volta passati ai titoli della Categoria B, dove invece i titoli andavano raggruppati in base alla tipologia. Altri pensavano che fosse preferibile raggruppare tutti i titoli della Categoria A per tipologia (prima tutti gli articoli, poi i capitoli di libri e gli atti di congressi, poi i brevetti, e così via), ordinandoli dal più recente al più vecchio e numerandoli progressivamente, continuando la numerazione con gli stessi criteri una volta passati alla Categoria B. Altri volevano numerare anche le tipologie, un po’ come si fa con i capitoli di un libro tecnico. Insomma, ogni partecipante al concorso aveva la sua idea.

Come ha scritto qualcuno in un gruppo WhatsApp, “le migliori menti del Paese non riuscivano a interpretare le istruzioni del bando di concorso”. Non so se al CNR ci siano davvero le migliori menti del Paese, ma è evidente che tutta questa confusione derivava dalla difficoltà di interpretare un gergo burocratico astruso e inconsistente, incomprensibile per chi è abituato per professione ad essere preciso e rigoroso. A ciò si aggiungeva un motivo più banale, il timore di fare degli errori nella stesura del curriculum e di essere penalizzati per questo dalle commissioni di valutazione.

Io non avevo scelta. Avendo raggruppato tutti i miei titoli in file differenti in base alla tipologia e importando i file uno dopo l’altro nel modello generale LaTeX, non potevo fare altro che numerare tutti i titoli della stessa tipologia in base alla data (dal più recente al più vecchio), proseguendo la numerazione una volta passato ad un’altra tipologia e continuando a numerare progressivamente allo stesso modo anche i titoli della Categoria B.

Mi sembrava anche la cosa più logica da fare, perché questo ordinamento facilitava il lavoro della commissione, che così trovava raggruppati prima tutti gli articoli scientifici (che sono senza ombra di dubbio i titoli più importanti per un ricercatore), poi tutti i capitoli di libri o gli atti di congresso, poi i brevetti, e così via. Se l’ordinamento primario per tipologia era previsto esplicitamente per la Categoria B, perché non fare lo stesso anche per la Categoria A? Se poi alla commissione non piacerà, pazienza!

Inutile dire che ho usato git – il sistema di controllo delle versioni che è ormai uno standard di fatto nel mondo dello sviluppo – per gestire le revisioni di tutti i file che mi servivano per produrre il curriculum professionale finale: il modello generale in LaTeX, gli script in R e AWK e tutti i file CSV e LaTeX generati dagli script.

Con il sistema di controllo delle versioni potevo aggiornare i vari file LaTeX dei titoli sapendo di poter tornare indietro anche in caso di errori troppo gravi per essere recuperati a colpi di undo. Per fare un esempio, a un certo punto mi sono accorto che avrei dovuto scambiare due righe in tutte le tabelle del file relativo agli articoli (si veda la figura qui sotto). Con un buon editor di testo è una cosa che si fa in cinque minuti, ma sapere di poter usare git anche per annullare ogni singola modifica è una cosa che si apprezza solo dopo essersi spupazzati una ad una un migliaio di righe di codice LaTeX.

Interfaccia grafica di git con la quale è possibile accettare o annullare ogni singola modifica ad un file.

Git è troppo complicato? Può darsi, ma un sistema di controllo delle versioni è come un backup, finché va tutto bene non si capisce a cosa serva, ma quando si presenta un problema si ringrazia il cielo di averlo usato.

Guardando a ritroso mi accorgo che la preparazione di questo curriculum professionale è stata in parte un lavoro di programmazione, tutto sommato abbastanza divertente, seguita da una lunga e noiosissima fase di inserimento dei nuovi dati e di controllo che tutto fosse a posto, una cosa che sembrava non dovesse finire mai. Lavorando una decina di ore al giorno ho impiegato quasi un mese per completare il lavoro, un pelo in anticipo rispetto alla scadenza prevista. Uno spreco di tempo assurdo per quello che dovrebbe essere un evento normalissimo nella vita professionale di chi fa questo mestiere.

La versione finale del mio curriculum ha 248 pagine, un numero che per un matematico (o un programmatore) ha un certo significato.³ Chissà se la commissione che lo giudicherà sarà dello stesso avviso.

(Continua…)

Una cosa più che ragionevole, visto che un file PDF è molto più difficile da manipolare del corrispettivo in Word. ↩︎
Detto fra parentesi, se c’è interesse per l’argomento, potrei scrivere dei post specifici su LaTeX e dintorni, toccando non solo le basi ma anche argomenti più avanzati come questo. ↩︎
Ammetto che arrivare a 271 o a 314 pagine sarebbe stato meglio, ma ci proverò la prossima volta. ↩︎