Il CNR è anche questo: un po’ di codice


XKCD, Good code.

Per concludere nel miglior modo possibile questa serie di articoli (qui la prima e la seconda parte), cosa ci può essere di meglio di un po’ di codice?

Estrarre il testo da un file PDF

Cominciamo dallo script in R, pdf2csv.R, che estrae il testo da un file PDF, (che in questo caso specifico ho usato per estrarre i dati dalla domanda di partecipazione ad un concorso precedente). Qui sotto trovate l’immagine dello script, realizzata con Carbon (perché così è molto più bello), su GitHub c’è il sorgente vero e proprio, per chi voglia provare ad usarlo.

Per eseguire lo script è necessario aver installato sul proprio computer, non importa se è un Mac o un PC con Linux o Windows, l’ambiente R (in questo momento è disponibile la versione 4.0.3), meglio ancora se accompagnato da RStudio Desktop, che è di gran lunga il migliore sistema integrato di sviluppo (IDE) che abbia mai usato, oltre che uno strumento efficacissimo per affacciarsi all’uso di R.

Il codice è molto semplificato, ho tolto tutto ciò che non è strettamente necessario a far funzionare lo script. La chiave di tutto è la libreria pdftools per R. Di librerie per estrarre dati dai file PDF ne ho provate moltissime, sia per R che per Python, ma pdftools le batte tutte per potenza, semplicità e velocità. Ci sono dei tool che convertono un PDF in testo al ritmo di una pagina al minuto, pdftools riesce a convertire (molto bene, peraltro) un file di 400 pagine come questo in appena 5-6 secondi. C’è altro da aggiungere?

Lo script può essere utilizzato dalla linea di comando (per capirci, dal Terminale), lasciandolo esattamente com’è ed eseguendo il comando pdf2csv.R seguito dal nome dal file da convertire (se il nome del file contiene degli spazi va scritto fra virgolette),

    ./pdf2csv.R file-da-convertire.pdf

che produrrà due file .csv contenenti il testo estratto dal file PDF. Il primo, con lo stesso nome del file di partenza, ha le righe numerate e cerca di riprodurre per quanto è possibile il layout del file originale. Nel secondo, salvato con il suffisso -clean, mancano i numeri di linea e vengono rimossi tutti gli spazi in eccesso, rendendolo più adatto ad una analisi automatica, in particolare quando il testo si estende per tutta la pagina (il primo file, invece, è molto più utile quando il testo è organizzato in colonne).

Prima di usare per la prima volta pdf2csv.R bisogna renderlo eseguibile tramite il comando chmod (ne ho già scritto diffusamente qui).

    chmod u+x pdf2csv.R

In alternativa si può lanciare lo script tramite il comando Rscript installato con R, senza che sia necessario renderlo eseguibile.

    Rscript ./pdf2csv.R file-da-convertire.pdf

È preferibile che il file PDF da convertire si trovi nella stessa cartella di pdf2csv.R. In caso contrario il testo estratto viene comunque salvato nella cartella dove si trova la script (ve l’avevo detto che lo script era molto semplificato!).

Per eseguire pdf2csv.R all’interno di RStudio bisogna commentare la linea 12 (basta aggiungere un # all’inizio della riga) e attivare la riga 14 o 15 (ma solo da una delle due) togliendo il # iniziale. Se si attiva la riga 14, si deve anche modificare la stringa file-da-convertire.pdf, sostituendola con il nome del file da convertire. Se invece si attiva la riga numero 15, al momento dell’esecuzione dello script comparirà una finestra grafica da cui selezionare il file PDF desiderato.

Nel repository su GitHub di questo articolo ho inserito dei file PDF di complessità crescente con cui fare qualche prova, fra cui un documento di quasi 1000 pagine (un vecchio manuale di riferimento del formato PDF, potevo scegliere qualcosa di diverso?), che può essere utile per valutare la velocità di conversione dello script. Non è necessario farlo a mano, il tempo di esecuzione di un qualunque programma o script si può misurare in modo preciso dal Terminale anteponendo il comando di sistema time, come mostrato qui sotto.1

    time ./pdf2csv.R PDFReference.pdf

Come piccola chicca finale, ho aggiunto al repository su GitHub un file PDF contenente del testo (apparentemente) nascosto, provate a convertirlo e vi accorgerete di quanto sia banale recuperare il testo completo.

Generare automaticamente dei documenti con AWK

Tirar fuori il testo contenuto in un file PDF è quasi sempre solo il primo passo del lavoro, perché quello che vogliamo veramente è filtrare il contenuto del documento mantenendo solo le informazioni che ci interessano. Nel caso specifico, io avevo bisogno di selezionare dalla domanda di concorso precedente solo i dati relativi ad una specifica tipologia di attività (ad esempio tutti gli articoli scientifici pubblicati), salvandoli in un file ad hoc. E, già che c’ero, volevo anche costruire anche una tabella LaTeX per ciascun articolo. Una cosa abbastanza facile da fare con AWK.

Di AWK ho già parlato tempo fa e non mi ripeterò, dirò solo che è un linguaggio ideale per analizzare un file di testo una riga alla volta, verificando se si presentano determinate condizioni ed eseguendo le operazioni programmate corrispondenti.

Nonostante i suoi tanti pregi, AWK ha una limitazione piuttosto seria: per come è strutturato, AWK deve per forza di cose esaminare tutto il file senza poter tornare indietro, e quindi è piuttosto difficile fargli eseguire delle operazioni basate su condizioni multiple complesse. È molto meglio (quando è possibile) scrivere più script AWK, da eseguire in sequenza sullo stesso file di partenza o sull’output generato dallo script precedente, piuttosto che cercare di combattere con le limitazioni del linguaggio, complicando a dismisura il codice.

In una prima versione di questo articolo avevo pensato di utilizzare un breve estratto della mia domanda di concorso precedente per descrivere il funzionamento degli script in AWK. Ma mentre scrivevo mi sono accorto che il discorso sarebbe stato così specifico da essere quasi inutile. Ho preferito quindi di preparare un piccolo file PDF tratto dagli ultimi post pubblicati su Melabit, con l’intestazione in YAML2 di ciascun post seguita dalla prima frase del testo in Markdown e, quando c’è, dal link all’immagine iniziale. L’ho scelto perché la struttura di questo file assomiglia moltissimo a quella della mia domanda di concorso ma, allo stesso tempo, può essere uno schema di partenza applicabile a casi più generali.

Questo file PDF può essere considerato come la stampa di un piccolo _database_ di informazioni correlate, dove ogni post è un _record_, suddiviso a sua volta nei vari _campi_, rappresentati dalle righe di intestazione e dalla frase di testo.

Il file PDF si chiama Melabit ultimi post.pdf e, come gli altri file PDF, è disponibile nel repository su GitHub di questo articolo. Se lo aprite con Anteprima, noterete subito che ci sono delle righe vuote che separano chiaramente un post (nel linguaggio dei database, un record) dall’altro. Ma convertendo il file in testo,

    ./pdf2csv.R "Melabit ultimi post.pdf"

(le virgolette sono necessarie perché il nome del file contiene degli spazi), le righe vuote scompaiono e le uniche interruzioni presenti nei due file CSV prodotti dallo script di conversione corrispondono al cambio pagina. Non so se questo sia un baco o una caratteristica voluta di pdftools, ma sta di fatto che è una particolarità con la quale dobbiamo fare i conti se vogliamo analizzare il testo con AWK.

Sembra una sciocchezza, ma senza le giuste interruzioni non è immediato riconoscere la fine di un record prima di iniziare ad esaminare quello successivo, in modo da chiudere correttamente la tabella LaTeX corrispondente al record appena esaminato e ad aprire quella relativa al record successivo. Inoltre, mentre in questo caso specifico la struttura del file PDF è volutamente molto semplice e ripetibile, nella maggior parte dei casi reali il documento da cui estrarre i dati può contenere informazioni strutturate in modi diversi, i campi da analizzare possono essere distribuiti in modo irregolare o mancare del tutto e ci possono essere incongruenze nella loro denominazione. Gestire tutti i casi possibili con un unico script lo renderebbe rapidamente troppo complesso.

Molto meglio affrontare il problema un pezzetto alla volta, utilizzando uno script specifico per ciascun tipo di informazione da estrarre (io ho avuto bisogno di 6 script AWK per eseguire tutto il lavoro di esportazione dei dati, o meglio quasi tutto il lavoro, perché per i casi meno frequenti ho preferito il buon vecchio copia-incolla manuale). In fondo è la stessa logica di Unix, che mette a disposizione un gran numero di strumenti semplici che messi insieme, come tanti mattoncini Lego, riescono a fare cose incredibili.

Un primo script, addblanklines.awk, può servire per inserire nel file CSV di partenza una riga vuota prima di ogni record (una cosa piuttosto semplice da fare in questo caso, dato che ogni post inizia sempre con la stringa “layout: post”). Lo script, appena quindici linee di codice, lo trovate “in bella” nell’immagine qui sotto (ma anche in questo caso il sorgente è su GitHub).

Bastano solo due linee di codice, la #4 e la #9, per aggiungere le righe vuote al posto giusto. Ma già che ci siamo, è conveniente dare anche una ripulita al file CSV togliendo le righe inutili, come quelle che contengono il numero di pagina o la stringa --- che segna l’inizio e la fine dell’intestazione in YAML (linee #5 e #12). Eseguendo lo script sul file CSV originale, si ottiene un nuovo file CSV con i vari record ben separati uno dall’altro.

    ./addblanklines.awk "Melabit ultimi post-clean.csv" > file-con-righe-vuote.csv

Fatto questo, il passo successivo è semplice. Basta scansionare il file CSV appena generato, file-con-righe-vuote.csv, in cerca della stringa target layout: post e, ogni volta che se ne trova una, generare una nuova tabella LaTeX riempiendola con i dati tratti dalle voci (o più propriamente campi) successive. Il codice del secondo script, cvs2table.awk, è visibile nell’immagine qui sotto (mentre il sorgente è sempre su GitHub).

Lo script è relativamente lungo, sono più di 80 linee di codice, compresi commenti e righe vuote, ma una gran parte serve per implementare la funzione (linee #3-25) che riarrangia le informazioni presenti su più linee consecutive del file CSV in modo che vengano stampate su un’unica riga, e per generare la struttura di base del documento LaTeX (linee #35-42 e #83).

Tolte queste, il resto del codice è semplice, si tratta più che altro di scrivere le stringe giuste al momento giusto e di tenere conto dei casi in cui le informazioni si estendono su più linee consecutive (come succede ad esempio alle linee #61-62 e #66-73). Non entrerò nei dettagli di come funziona lo script, questo non è un corso di AWK (né tantomeno di R), basterà per ora dire che è scritto in modo da essere facilmente adattato a gestire esigenze analoghe. Per usarlo, si deve eseguire lo script usando come file di input file-con-righe-vuote.csv e salvando il risultato dell’elaborazione in un file LaTeX, che qui sotto ho chiamato (con la mia solita scarsa fantasia) lista-articoli.tex.

    ./cvs2table.awk file-con-righe-vuote.csv > lista-articoli.tex

Mettere tutto insieme

Proviamo allora ad eseguire tutti insieme gli script presentati in questo articolo, in modo da ottenere il risultato finale desiderato. Dobbiamo prima di tutto convertire il file PDF in CSV con

    ./pdf2csv.R "Melabit ultimi post.pdf"

che genera automaticamente il file “Melabit ultimi post-clean.csv”. Fatto questo, si eseguono in sequenza i due script AWK, salvando l’output del primo in un file intermedio.

    ./addblanklines.awk "Melabit ultimi post-clean.csv" > file-con-righe-vuote.csv
    ./cvs2table.awk file-con-righe-vuote.csv > lista-articoli.tex

Il risultato finale è un file LaTeX ben ordinato con una tabella per ogni articolo, come quello mostrato nella figura qui sotto la cui regolarità, messa in evidenza dai colori delle parole chiave, fa pensare ad uno spartito musicale.

Ma ha senso creare un file intermedio solo per trasferire l’output del primo script al secondo? Molto meglio usare il meccanismo di piping tipico in Unix, con il quale si può trasferire automaticamente il risultato dell’esecuzione di un comando all’ingresso di quello successivo, collegandoli con il carattere | (pipe)?3 Con il piping, i due comandi AWK precedenti possono essere eseguiti uno dopo l’altro in questo modo,

    ./addblanklines.awk "Melabit ultimi post-clean.csv" | ./cvs2table.awk > lista-articoli.tex

evitando l’uso di un file intermedio. In questo caso non fa molta differenza, ma quando si devono trattare file molto grossi, il piping è molto più efficiente (con i velocissimi dischi SSD odierni non ce ne accorgiamo più, ma ai tempi dei dischi meccanici la scrittura di grossi file sul disco era un vero collo di bottiglia) e, cosa che non guasta mai, evita di intasare il disco rigido con un gran numero di file inutili.

E poi il piping è un meccanismo intrinsecamente elegante, che non a caso è stato adottato anche in alcuni linguaggi di programmazione odierni, come si può vedere nello script R mostrato nella prima parte di questo articolo (linee #24-25 e #35-37), dove il simbolo | usato in Unix è sostituito dalla strana combinazione di caratteri %>%, piuttosto fastidiosa da scrivere con una tastiera italiana (io almeno sbaglio sempre qualcosa).

Conclusioni

Chi ha l’occhio allenato si accorgerà facilmente che il file LaTeX risultante contiene alcuni errori piuttosto evidenti. Li ho lasciati apposta non solo per non complicare ulteriormente il codice, ma anche per mostrare quanto sia complicato il lavoro di estrazione automatica dei dati da file strutturati in modo non perfettamente regolare. Non è certo un caso che in questo campo ci sia una grossa attività di ricerca che prova a superare gli ostacoli e a rendere il tutto il più semplice e il più efficiente possibile.


  1. Il comando time è presente di default nei sistemi operativi Unix come Linux e macOS. Su Windows time non esiste, ma si possono usare degli strumenti equivalenti
  2. YAML è un linguaggio di markup particolarmente adatto per definire dei file di configurazione e, in generale, per rappresentare informazioni strutturate in modo semplice e leggibile, molto più facile da usare di strumenti più noti come XML e JSON. 
  3. Il piping è uno dei meccanismi principali che rendono Unix una specie di Lego informatico. 
Tagged with: , , , , , , , , ,
Pubblicato su programmazione

Il CNR è anche questo: concorsi in LaTeX

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,1 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.2


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.3 Chissà se la commissione che lo giudicherà sarà dello stesso avviso.


  1. Una cosa più che ragionevole, visto che un file PDF è molto più difficile da manipolare del corrispettivo in Word. 
  2. 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. 
  3. Ammetto che arrivare a 271 o a 314 pagine sarebbe stato meglio, ma ci proverò la prossima volta. 
Tagged with: , , , , , , ,
Pubblicato su scienza

Il CNR è anche questo: concorsi senza frontiere

Lo so, è da un mese che non pubblico niente sul blog. Non che mi manchino gli spunti, tutt’altro, la lista di cose da scrivere si allunga ogni giorno di più. Ma è dall’inizio di agosto che mi trovo ad affrontare una scadenza importante dopo l’altra, e appena ne supero una eccone un’altra ancora più pressante. Dopo giornate come quelle delle ultime settimane, è difficile mettersi di nuovo alla scrivania la sera per aggiornare il blog.

Ma il mondo deve sapere… 😂😂😂😂😂 e quindi quello che segue è il racconto (lungo!) di cosa ha significato affrontare la scadenza più importante di tutte, che purtroppo è stata anche la più fastidiosa e frustante. Una gara contro il tempo che mi faceva pensare alle prove assurde di Giochi senza frontiere, ma senza la goliardia e il buonumore degli originali.1

La storia interesserà, giustamente, solo a pochissimi frequentatori del blog. Tutti gli altri faranno bene a saltare direttamente alla seconda parte, deve racconto come ho affrontato questa prova con l’aiuto degli strumenti di cui parlo spesso in questo blog, LaTeX, R, script da Terminale, sistemi di controllo di versione.

Perché non è detto che uno debba imparare a programmare solo per fare delle cose serie. Anche riuscire a cavarsela meglio con le rotture di cabasisi di tutti i giorni può essere un’ottima scusa.


Tutto è cominciato ai primi di agosto, quando il CNR ha pensato bene di pubblicare i bandi di concorso ex Articolo 15 (dall’articolo del contratto che li prevede), per i passaggi di livello di ricercatori e tecnologi.2 Erano dieci anni che non uscivano dei concorsi di questo tipo (che dovrebbero invece avere una cadenza biennale), cosa potevano scegliere i nostri ineffabili vertici se non il mese di agosto per pubblicare i bandi?

Estate rovinata. Perché partecipare ad un concorso per passare ad un livello superiore non è uno scherzo e può richiedere mesi di lavoro.

Lo so per esperienza. Nel 2013 partecipai ad un altro concorso (di tipologia differente) per passare a dirigente di ricerca, il livello più alto nel cursus honorum della ricerca italiana. Il bando (ovviamente!) uscì a luglio con scadenza a settembre ma poi, a causa del cattivo funzionamento della piattaforma web messa su in fretta e furia per gestire quel concorso, la scadenza venne rimandata più volte fino a novembre. Il motivo principale era la scarsa affidabilità della piattaforma web, che era tanto sovraccarica da andare continuamente in crash, cancellando senza pietà tutte le informazioni non ancora salvate. Mi ricordo ancora le alzatacce alle 4 del mattino, l’unico momento buono per inserire sulla piattaforma le informazioni tratte dalle centinaia di documenti richiesti per partecipare al concorso.3


Negli ultimi anni la piattaforma web è migliorata moltissimo e rappresenta ormai un archivio molto dettagliato dei documenti già presentati dai miei colleghi e da me ai vari concorsi a cui abbiamo partecipato nel frattempo. Un archivio che potrebbe essere molto utile per semplificare la partecipazione ai nuovi concorsi istituiti dal CNR.

E invece cosa pensano i soloni che ci governano e che, un pezzo dopo l’altro, stanno smontando quello che era uno dei migliori enti di ricerca multidisciplinari del mondo? Di abolire per questo concorso agostano la piattaforma web e di richiedere invece la compilazione di un modello di documento in Word (lo trovate in miniatura anche qui sotto), nel quale inserire tutte le migliaia di informazioni che costituiscono il cosiddetto curriculum professionale di ciascun partecipante al concorso. Aggiungendo danno al danno, i soloni suddetti non prevedono alcuno strumento per esportare le informazioni già inserite nella piattaforma online, costringendoci di fatto a ricominciare tutto da zero.


Il curriculum professionale è solo un lontano parente del normale curriculum vitae (CV), nel quale si condensano anni ed anni di lavoro in poche pagine leggibili. Qui si tratta invece di un dettagliatissimo e minuziosissimo elenco di tutto ciò che costituisce l’attività scientifica di un ricercatore: gli articoli pubblicati sulle riviste scientifiche o sugli atti delle conferenze, i libri o i capitoli di libri, i software sviluppati, i brevetti, i progetti, le attività di docenza, la partecipazione a commissioni tecnico-scientifiche e molto altro.4 Sono i cosiddetti titoli, ciascuno dei quali va inserito nel curriculum professionale in base alla sua fattispecie (un termine di estrazione giuridica che in questo contesto è improprio e che nel seguito sostituirò con tipologia).

Traduco per i non iniziati al gergo burocratico dell’ente. Per il CNR una fattispecie rappresenta un tipo specifico di attività svolta: un articolo scientifico è una fattispecie, un libro o capitolo di libro è un’altra fattispecie, i brevetti, i software, i progetti, gli incarichi, le docenze sono ulteriori fattispecie diverse, così come lo sono moltissime altre attività tecnico-scientifiche svolte nel corso della propria carriera.

Per confondere ancora di più le idee, tutte le attività di stampo più propriamente scientifico, e quindi gli articoli, i libri o i capitoli di libri, i brevetti, i software, vengono definite anche Prodotti della Ricerca, e sono suddivise a loro volta in fattispecie differenti (che naturalmente variano di concorso in concorso). Ciascun Prodotto della Ricerca, e più in generale ciascuna attività tecnico-scientifica svolta, rappresenta un titolo professionale, e va inserito in una tabella del curriculum professionale specifica per la sua fattispecie.

Se tutto ciò vi fa girare la testa, pensate a me che ho dovuto cercare di spiegarlo!

Inserire un nuovo Prodotto della Ricerca nell’orribile modello Word fornito dall’amministrazione non è uno scherzo: si deve selezionare la tipologia (o se preferite la fattispecie) giusta, duplicare la tabella originale vuota relativa alla tipologia scelta oppure una tabella già compilata, e infine (si fa per dire) inserire una ad una con molta pazienza le informazioni richieste. Alcune sono ovvie, come il titolo e gli autori di un lavoro scientifico. Altre sono piuttosto complicate da reperire, come l’indice di classificazione della rivista e il famigerato impact factor,5 informazioni che bisogna cercare consultando i siti web delle riviste oppure degli appositi database online, alcuni aperti a tutti, altri proprietari e a pagamento (sono carissimi, ma per queste inutili sciocchezze il CNR è sempre pronto a sprecare soldi). Infine ci sono le informazioni di cui non si capisce bene il senso, come il codice identificativo della rivista (ISSN) o peggio ancora il campo Altre informazioni, nel quale ognuno mette quello che gli pare.

E tutto ciò va fatto per ogni singolo Prodotto della Ricerca. I ricercatori più anziani come me, con una carriera ormai più che trentennale alle spalle e centinaia di prodotti della ricerca, partendo da zero hanno bisogno di parecchi giorni per inserire tutti questi titoli.


Ma questa è solo la prima parte della storia, quella che riguarda la produzione scientifica vera e propria e che va sotto l’ombrello di Categoria A. La seconda parte del modello Word se vogliamo è molto, molto peggio. Si tratta della Categoria B, quella che raccoglie tutte la attività di contorno alla ricerca vera e propria, le attività didattiche, quelle di diffusione della cultura scientifica, i premi, le partecipazioni ad organismi tecnici o scientifici, le responsabilità varie e soprattutto le partecipazioni ai progetti di ricerca.

Che è ciò che interessa davvero alla nostra amministrazione.

Perché i progetti di ricerca portano soldi, tanti soldi. I soldi che lo Stato non da più (il finanziamento ordinario copre ormai solo gli stipendi dei dipendenti), per cui se vuoi fare qualcosa devi partecipare a dei progetti di ricerca. Non importa quali, non importa se sono attinenti o no al tuo filone scientifico, non importa se sono davvero utili al progresso scientifico, o perlomeno alla società. L’unica cosa davvero importante è che i progetti portino soldi, perché sono quelli che fanno andare avanti la baracca. Nonché, attraverso rapine sempre più pesanti ai finanziamenti faticosamente acquisiti (preparare un progetto di ricerca è una faticaccia), permettono alla sede amministrativa centrale di prosperare alla grande, senza mai dare nessun supporto a questa faticosa attività di autofinanziamento.

Ormai sei un bravo scienziato se riesci ad acquisire finanziamenti, altrimenti sei uno sfigato qualunque. Potrai anche avere titoli scientifici inappuntabili, ma se non porti soldi puoi sognarti di vincere un concorso al CNR. Lo pensa l’amministrazione, ma lo pensano (purtroppo!) anche tanti colleghi rampanti, quelli che pesano le persone in base al denaro che hanno saputo conquistarsi, e che avrebbero fatto meglio a fare i broker piuttosto che i ricercatori.

Non a caso sono proprio i progetti a fare la parte del leone nella Categoria B del curriculum professionale. I progetti riguardano le prime due fattispecie della Categoria B e la varietà e quantità di informazioni richiesta è decisamente maggiore rispetto a tutte le altre tipologie: da dove sono arrivati i soldi, quanto ha introitato il progetto complessivo, quanto ha introitato il gruppo del CNR (Unità Operativa) di cui fa parte il candidato, quali erano gli obiettivi del progetto, quali risultati ha ottenuto, quanto è durato. E per come sono strutturati i progetti di ricerca, queste informazioni sono sparse su molteplici documenti, da cercare uno ad uno sul proprio computer o magari sulle copie cartacee di venti-trent’anni fa (per quei fortunati o previdenti che le hanno conservate), per cui compilare la tabella di un singolo progetto di ricerca può richiedere ore di lavoro. Un vero incubo!


Ma c’è una cosa che accomuna tutta la Categoria B del curriculum professionale. La richiesta ossessiva di pezze d’appoggio per qualunque cosa si sia fatta nella propria vita professionale: numeri di protocollo, delibere, decreti, provvedimenti.

Una richiesta ragionevole per le attività più importanti, come ad esempio gli insegnamenti universitari, che devono necessariamente essere autorizzati con apposite delibere. Molto meno ragionevole per altre attività normalissime per un ricercatore, come far parte del comitato organizzatore di una conferenza o di qualche commissione tecnico-scientifica, incarichi che vengono assegnati quasi sempre con una semplice email o che compaiono solo su un sito web che spesso viene disattivato al termine della conferenza.6

Come ha scritto benissimo un collega, “È stato davvero penoso vedere persone di valore doversi instupidire nella rincorsa del numero di protocollo, del quartile più alto, della dichiarazione del direttore o del responsabile del progetto, del link che non c’è più, e nel mentre erano costantemente infastidite da notizie che continuavano a ribaltare le modalità di compilazione di schede inutilmente minuziose: il numero progressivo, le fattispecie, le annualità. Un vilipendio di energie intellettuali, uno spreco di tempo e denaro, un alt irragionevole e su tutta la linea alle attività di ricerca, un’efficace distrazione da altri temi importanti legati al futuro della ricerca e del suo esercizio (es. PNR). Impegno per altro richiesto e pilotato con un bando uscito a ridosso della chiusura estiva imposta dall’Ente, tale da fagocitarsi una buona parte delle ferie”.

Non potrei essere più d’accordo.

(Continua…)


  1. Alzi la mano chi se li ricorda. Giochi senza frontiere sono stati per tantissimi anni il gioco dell’estate per eccellenza, quello in cui concorrenti provenienti da ogni angolo dell’Europa si affrontavano in gare improbabili nelle quali dovevano evitare di essere travolti da una valanga mentre sciavano sulla sabbia, tirare via l’acqua di un lago con un bicchiere attaccato ad una canna da pesca o cercare di rimanere in equilibrio su una enorme palla di polistirolo. L’inventore di queste prove era un vero genio dell’assurdo. La dirigenza del CNR cerca continuamente di copiare da lui, ma non ha la stessa stoffa. 
  2. I tecnologi del CNR sono una figura professionale anomale. In teoria dovrebbero essere coloro che gestiscono i grossi laboratori sperimentali, le infrastrutture di rete e così via. In pratica ormai, per ragioni troppo complesse da spiegare qui, una gran parte di tecnologi svolge compiti di tipo amministrativo, snaturando di fatto il ruolo. Per questo motivo, quando nel seguito parlerò dei ricercatori, mi riferirò sempre anche ai (pochi) tecnologi ancora degni di questo nome. 
  3. Ci sono voluti due o tre anni per concludere l’iter di quel concorso, che naturalmente non ho vinto, anche se in una delle due graduatorie mi sono classificato piuttosto bene. La graduatoria era quella meno attinente al mio percorso professionale, ma queste sono le stranezze della burocrazia italiana, accoppiate alla, diciamo così, ostilità di uno dei commissari dell’altra graduatoria. 
  4. Si può diventare direttore di un Istituto del CNR, direttore di Dipartimento e perfino Direttore Generale presentando un normalissimo curriculum vitae di 10-20 pagine, ma non ne bastano 200 per partecipare ad un concorso da dirigente di ricerca. 
  5. La discussione di cos’è l’impact factor e perché lo definisco famigerato porterebbe troppo lontano dal nucleo principale dell’articolo. 
  6. Più di una volta ho dovuto ricorrere al beneamato Internet Archive per cercare di reperire queste informazioni. 
Tagged with: , , , , ,
Pubblicato su scienza

Tech porn

Da ragazzo, oltre che su Playboy, sbavavo su immagini come questa, e sognavo di poter usare un giorno uno di questi strumenti complicatissimi.


Foto ArsTechnica.

Oggi continuo a sbavare ogni volta che vedo un laboratorio perfetto come quello Apple qui sotto, una vera goduria per i miei occhi da nerd.


Foto Apple.

Quello che ho avuto a disposizione è stato invece questo. Tutto sommato non male, soprattutto perché l’ho costruito pezzo pezzo io stesso in anni ed anni di lavoro, insieme ad un paio di collaboratori più giovani.

Però l’ordine e la perfezione tecnica del laboratorio Apple… beh, quella la invidio senza vergogna. Gli ingegneri di Apple non hanno bisogno di tenere su certi strumenti (piuttosto costosi, peraltro) con i cataloghi e le scatole di cartone!

Tagged with: , ,
Pubblicato su scienza

Il (mio) gioco dell’estate

Non sono un gran giocatore, però mi piace giocare con l’iPad la sera prima di dormire oppure in vacanza in estate. Niente di complicato, i giochi con troppe regole mi annoiano, ancora di più lo fanno i platform, dove devi ripetere sempre gli stessi movimenti nella sequenza corretta.

Per fortuna su iOS c’è un’ampia scelta per tutti i gusti e ogni anno sono riuscito a trovare il gioco che mi ha accompagnato per tutte le vacanze, il mio personale “gioco dell’estate”.

Quest’anno è toccato a Colorzzle, il tipico casual game da fare quando si hanno cinque minuti liberi, abbastanza complicato da essere interessante, ma non troppo da scoraggiare alle prime difficoltà. Graficamente è molto bello, non arriva ai vertici di Monument Valley, ma si difende degnamente. E poi costa solo un caffé ed è senza pubblicitò, una cosa che sta diventando sempre più rara.

Peccato solo che sia davvero troppo corto, solo 106 livelli. Quella che vedete qui sotto è la soluzione dell’ultimo livello (che secondo me non è il più difficile).

Ma non avevo detto che il mio gioco per l’estate mi accompagna per tutte le vacanze? In effetti, finora le mie vacanze di quest’anno sono durate più o meno come Colorzzle…

Tagged with: , , ,
Pubblicato su software
Informativa
Questo sito utilizza cookie di terze parti per inviarti pubblicità e servizi in linea con le tue preferenze. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie, clicca qui. Scorrendo questa pagina, cliccando su un link o su qualunque altro elemento o proseguendo la navigazione in altra maniera, acconsenti all'uso dei cookie.
Follow MelaBit on WordPress.com
Categorie
Archivi
%d blogger hanno fatto clic su Mi Piace per questo: