In occasione del Capodanno Pisano, il 25 marzo, è stato possibile visitare le mura della città, un camminamento lungo, attualmente, oltre 3 kilometri. Salendo dalla Torre Piezometrica presso la ex Marzotto mi sono trovato immediatamente sopra il Dipartimento di Fisica (e quello di Informatica al piano superiore) e non ho resistito a fotografarlo da questa inconsueta angolazione. Ecco la foto:
Ho finalmente colmato una lacuna: confesso che fino a pochi giorni fa non avevo mai usato LaTeX. Pur avendo presentato una tesina universitaria sull’ideatore di TeX, Donald Knuth, da cui LaTeX deriva, non mi ero mai cimentato nella redazione di documenti. Eppure si tratta di un linguaggio di markup e neanche dei più complicati.
Data la mia proverbiale incostanza, ho deciso di affrontare la cosa in modo strutturato, seguendo un corso su Udemy, una delle ormai numerose piattaforme MOOC. Certamente avrei potuto trovare tutorial simili (se non gli stessi) anche su Youtube ma ho preferito avere lo sprone delle lezioni in sequenza e il traguardo di un, sia pure inutile, attestato di completamento. Per di più, il corso in questione è anche a pagamento, cosa rara per le piattaforme MOOC (a parte Udemy, appunto). Per questi motivi ma anche per la durata breve del corso, sono arrivato al termine imparando almeno le basi di Latex.
La breve durata è stata sicuramente il fattore determinante del successo. In passato mi ero dedicato a corsi online sulla piattaforma Coursera, corsi gratuiti ma decisamente lunghi che prevedevano delle prove intermedie da superare e una sorta di esame finale. Tutte le volte, pur arrivando al termine con successo, completare il corso era stata una fatica.
Adesso, preso dall’entusiasmo per questa nuova piattaforma, ho già in programma un altro corso più specifico rispetto alla mia attività di ricerca con l’obiettivo di imparare a creare simulazioni con il metodo Monte Carlo usando il linguaggio di programmazione R.
Quanto a Latex, se non trovo un’occasione per redigere almeno un documento serio nel prossimo periodo, il rischio di dimenticare quanto appreso si preannuncia decisamente alto.
Qualche giorno fa (i miei post sono sempre un po’ in ritardo) i gestori di Hypotheses, la piattaforma che ospita questo blog, mi hanno comunicato che “Genealogy Cruncher” è stato inserito nel catalogo dei Carnets de recherche di OpenEdition.
Certamente il mio blog non darà una spinta significativa in avanti alla ricerca né brilla per originalità di contributi ma questo evento rappresenta, almeno per me, il riconoscimento dello sforzo, condotto con onestà intellettuale, di tenere traccia di un anomalo percorso accademico aderendo alle intenzioni del progetto OpenEdition.
Adesso, quindi, “Genealogy Cruncher” dispone di una sua scheda all’indirizzo http://www.openedition.org/17450 e diviene ricercabile all’interno di OpenEdition.
Uno stimolo in più a produrre contenuti utili con maggior frequenza.
La fine del 2016 è stata un momento decisamente intenso: l’arrivo della piccola prima e il trasloco nella nuova abitazione poi, hanno messo me e mia moglie a dura (ma piacevole) prova. Il trasloco in particolare è stato frenetico e gli scatoloni continuano a dominare il panorama domestico. Nel riordinare alcuni oggetti fragili, diligentemente imballati, a (vana) difesa dalla maldestrìa dei traslocatori, in carta di giornale, mi è capitato tra le mani un articolo del quotidiano locale, a data 18 luglio 2016, dall’occhieggiante titolo “Così ci arrampichiamo sull’albero genealogico”. Sin dalle prime righe appariva evidente il tenore da articolo estivo, tipico di quando i giornali hanno meno contenuti e incaricano qualcuno dei cronisti (in questo caso la giornalista Ileana Reali) di scrivere un pezzo su un argomento di costume, ma sono comunque arrivato in fondo alla lettura. L’articolo spiegava in breve come tentare di ricostruire il proprio albero genealogico con i consueti mezzi: i parenti, internet, gli archivi.
In sostanza un onesto articolo sulla genealogia familiare. Quello che mi ha invece interessato e fatto riflettere è stata la figura a corredo dell’articolo, un disegno realizzato da una maestra, Roberta Bancale, che raffigura sulla sinistra un albero spoglio a cui una bambina appende tre cartellini, “babbo”, “mamma”, “io” e, sulla destra, lo stesso albero con foglie e fiori. Mi ha ricordato il modo di procedere nella realizzazione della base dati di Hochadelsdorf: i rami ci sono tutti e sono i codici Sosa presenti nella base dati (dovrò decidermi prima o poi a scrivere qualcosa sul sistema Sosa-Stradonitz); quello che, in parte, manca sono le foglie e i fiori ovvero i soggetti giusti al posto giusto. L’opera (apparentemente infinita) di completamento che sto portando avanti assomiglia alla bambina che appende i cartellini in attesa che l’albero fiorisca. In questo momento anche la mia ricerca sta affrontando un lungo e freddo inverno ma confido in una rigogliosa primavera, che porti finalmente qualche fiore al progetto, e in una estate ricca dei tanto attesi frutti.
Concludo con una citazione della storica francese Christiane Klapisch Zuber, riportata in testa al citato articolo.
“L’albero durante i secoli ha rappresentato quel grande corpo che è un lignaggio, una discendenza. Come l’albero, una famiglia nasce, si sviluppa, si ramifica, si secca. Le rappresentazioni della parentela hanno utilizzato fin da tempi molto antichi questa metafora che si è poi fissata in una immagine: l’albero genealogico”.
Come già anticipato nel post precedente, ho spostato (o meglio copiato) la base dati del progetto su Azure ed ho cominciato ad usare i servizi cloud di Microsoft. Al termine del primo mese di utilizzo posso fare un primo bilancio di costi, qualità e usabilità della piattaforma.
Sono sempre stato un po’ scettico su Azure sia a causa di una prima non positiva esperienza quando il servizio era ancora agli esordi e quindi non esattamente intuitivo nell’utilizzo, sia per la paura di una tariffazione oscura ed incontrollabile.
A distanza di qualche anno da questa prima esperienza, Azure ha raggiunto una completezza e chiarezza di servizio, supportata da una interfaccia utente intuitiva e potente, tale che l’utilizzo risulta agevole fin dai primi approcci.
Le diffidenze verso la tariffazione sono state vinte grazie alla sottoscrizione DreamSpark ottenuta tramite l’email (da studente) dell’Università che consente l’utilizzo gratuito di diversi servizi. In realtà, con la sottoscrizione DreamSpark si fa ben poco, soprattutto a livello di database, ma è servita come chiave di ingresso nel mondo di Azure. Appena mi sono reso conto che il servizio poteva essermi utile, ho cercato di espandere le possibilità di utilizzo e mi sono ricordato che come sviluppatore Microsoft, tramite il programma Dev Essentials, potevo avere diritto, per un anno, ad un credito mensile pari a 25 euro. Restava da verificare cosa fosse possibile fare con 25 euro/mese.
Il grafico, estratto dalla dashboard del mio account Azure, mostra il consumo di credito nel primo mese ed appare evidente che non ho esaurito il credito malgrado l’uso intensivo e gli errori di configurazione dati dall’inesperienza.
Come prima cosa ho creato un database SQLServer analogo a quello locale del progetto. Ho scelto una configurazione con un numero di DTU (che sono le unità di elaborazione dei database Azure) non troppo basso perché dovevo trasferire qualche milione di righe solo per creare la base dati e la sottoscrizione DreamSpark, con solo 5 DTU, era andata immediatamente in saturazione. Ho scelto la soluzione da 10 DTU che si è rivelata sufficiente alle operazioni necessarie al trasferimento dei dati ma anche all’elaborazione delle interrogazioni. Azure inoltre, in base all’utilizzo del database, suggerisce ed applica ottimizzazioni alle tabelle e alle query.
Ho usato il database per alcuni giorni notando che il consumo di credito era abbastanza irrisorio e che l’utile proiezione del grafico preannunciava che avrei terminato il mese con oltre metà del credito disponibile.
Ho deciso di creare quindi anche una macchina virtuale da usare collegato in Remote Desktop per accedere al database da dispositivi privi di software specifico. Le macchine virtuali generiche Windows 10 sono riservate ai sottoscrittori MSDN ma è sempre possibile creare una macchina con Visual Studio. Il sistema operativo, in questi casi, è una versione server di Windows, in particolare Windows Server 2012 R2. Qui ho commesso un errore: nel creare la macchina virtuale, il sistema suggerisce due configurazioni abbastanza carrozzate in termini di RAM e processore ma con tariffe alte. Confidando in un utilizzo saltuario, ho scelto una di queste senza notare il link “mostra tutte”. Nel grafico, questa scelta corrisponde alla drastica e rapida riduzione del credito. Dopo aver notato che, malgrado un uso veramente minimo, il credito calava vertiginosamente, ho distrutto e ricreato la macchina virtuale usando un diverso piano tariffario, riducendo la RAM a 1.75GB e usando un processore mono core. Il grafico del consumo, a quel punto, ha ripreso un andamento più rassicurante. La cosa positiva da notare è che molte delle operazioni di creazione di servizi (siano essi database o macchine virtuali) è intuitiva e veloce.
Una sola accortezza è necessaria nell’uso delle macchine virtuali di Azure: non basta spegnerle per ridurre quasi a zero il consumo, vanno deallocate. In pratica, oltre a spegnere la macchina occorre spegnerla anche dalla piattaforma e poi deallocarla premendo nuovamente sul pulsante arresta della propria area di gestione. In alternativa è possibile configurarsi uno script PowerShell da lanciare dalla propria dashboard. Come stima grossolana, un’ora di utilizzo di una macchina virtuale di queste dimensioni costa circa 0.20 euro.
Dal punto di vista della qualità del servizio c’è poco da dire, Azure funziona alla grande e fornisce quasi out of the box moltissimi servizi. Per il progetto che sto portando avanti, ho configurato un database replica di quello ufficiale e una macchina per lo sviluppo e l’interrogazione della base dati in pochissimo tempo e con una spesa abbordabile. Inoltre non devo preoccuparmi di configurazioni del sistema, di hardware (e relativi guasti) e, soprattutto, di backup.
In conclusione, grazie alla sottoscrizione Dev Essentials, godrò per un anno di un ambiente di lavoro potente, raggiungibile da ovunque e sicuro. Al termine della sottoscrizione, molto probabilmente, deciderò di stanziare un fondo per l’uso della piattaforma, magari limando ancora un poco le risorse per contenere ulteriormente le spese anche se sono convinto che la comodità di un sistema come quello che ho configurato su Azure non abbia prezzo.
L’arrivo di mia figlia ha rivoluzionato in positivo, tra le tante cose, anche i tempi e gli spazi della mia ricerca. L’ora quotidiana dedicata al progetto, in genere dalle 6 alle 7 dei giorni feriali, è adesso dedicata alla preparazione dei biberon, al cambio dei pannolini o, se va bene, al recupero di qualche momento prezioso di sonno.
Ho deciso quindi di cambiare l’approccio e questo mi ha permesso di sperimentare strumenti interessanti distribuiti sul cloud. L’esigenza è stata quella di avere i dati sempre disponibili in modo da poter lavorare in qualunque momento e da qualunque postazione. E’ stata quindi l’occasione per sperimentare i servizi di Microsoft Azure che da tempo mi incuriosivano ma verso i quali nutrivo sempre una certa diffidenza. L’account DreamSpark ottenuto tramite la email dell’Università non mi consentiva di fare molto a causa delle sue limitazioni. Per fortuna, il programma Dev Essentials fornisce agli sviluppatori un credito mensile di 25 euro, sufficiente a creare un database abbastanza grande da ospitare i dati del progetto. Ho così creato una copia della base dati su Azure in modo da averla sempre disponibile. Per il momento, storage e uso non intensivo di un database di circa 500MB mi costano circa 0.35 euro al giorno, abbondantemente dentro i limiti del credito concessomi.
L’interrogazione della base dati avviene attraverso i medesimi strumenti usati per la versione locale (ovvero SQLServer Management Studio) ma adesso ho il vantaggio di poter lavorare in mobilità che significa durante la pausa pranzo o nei tempi morti di altre attività. Per questo ho istallato anche una app sullo smartphone (SQL Server Metro) anche se l’utilizzo è limitato a qualche interrogazione di controllo dati.
In realtà lo strumento che avrei voluto usare in mobilità sarebbe dovuto essere il netbook convertibile Asus VivoTab ma mi sono scontrato con le grosse limitazioni del sistema operativo Windows RT. L’unica app (a pagamento!) disponibile per questo sistema che possa interfacciarsi con SQL Server non funziona con l’ultima versione di Azure SQL Server e l’ho scoperto a mie spese. Con questa versione di SQL Server non è possibile neanche utilizzare il management online, funzionante fino alla precedente versione. Proverò il servizio Azure RemoteApp sperando di rimanere nei limiti del credito, ammesso che funzioni. E’ un vero peccato perché con queste giornate di caldo, su una panchina durante la pausa pranzo, avrei lavorato veramente bene!
Comunque sia, aver decentralizzato i dati copiandoli nel cloud mi sta dando una maggiore libertà di gestione in termini di luogo e tempo di lavoro oltre a fornirmi una copia sicura di backup (oltre a quella su dispositivo rimovibile). Come spesso accade, soprattutto a me, una apparente (e in questo caso piacevole) limitazione è motivo per apprendere cose nuove, sperimentare, tentare con tenacia di superare i limiti del mezzo tecnologico. Una sfida nella sfida che rende tutto molto più avvincente.
Edit (09/11/2016):
Azure RemoteApp non è più supportato, l’unica alternativa valida è stata creare una macchina virtuale su Azure con istallato SQL Server Management Studio ed accedere a quella in Desktop Remoto.
Questa estate, sotto l’ombrellone, osservavo i miei nipoti giocare assieme, i figli di mia sorella con quelli di mia cognata, come se fossero cugini. Poi si sono aggiunti i nipoti dell’altra mia sorella (in attesa di un bambino), che vivono a Londra e passano al mare solo poche settimane. Osservandoli riflettevo sul ruolo degli zii che, pur non essendo parenti in senso genealogico, creano legami tra i vari rami della famiglia. Mi è venuto in mente il concetto della forza dei legami deboli espresso da Mark Granovetter nel 1973 in riferimento alle reti sociali. Gli zii sono un legame debole che tuttavia consente la connessione tra rami distanti di una stessa famiglia o tra famiglie diverse.
Poi a settembre è arrivata mia figlia che, come un anello mancante, ha riunito tutti i nipoti in una catena continua di cugini. Credo che il prossimo anno, sotto l’ombrellone, avrò ben altro da fare che studiare i legami deboli.
Mercoledi 17 Agosto 2016 è morto Leo van de Pas, ideatore e curatore del sito genealogics.org una delle più vaste e attendibili banche dati di genealogie disponibile in rete. Un lavoro titanico, come ho avuto modo di sottolineare più volte, messo a disposizione degli studiosi, condotto con rigore scientifico ed in costante aggiornamento. Con la morte di van de Pas il sito rimane attivo anche se in “modalità manutenzione” ovvero non sarà soggetto ad aggiornamenti ma solo alla correzione di eventuali errori.
Il progetto Hochadelsdorf deve moltissimo a questa base dati che costituisce la fonte principale (anche se non l’unica) dei dati che stiamo elaborando. Per questo motivo, ritengo giusto rendere onore a questo studioso e al lavoro che ha fatto. Grazie Leo!
Grazie al tweet di un amico (@ilmusetti) ho potuto leggere questo bel racconto di “fantascienza” di Emmanuela Carbé: Alta Marea. Mi ha incuriosito, fin dalle prime righe, la descrizione di un futuro, sia pure cupo, delle Digital Humanities con tratti che tuttavia non si allontano molto da una visione della conoscenza, della ricerca e della formazione di tipo utilitaristico che già da oggi sembra minacciare il nostro sistema scolastico. Mi sono sempre piaciuti i romanzi che descrivono il futuro, a cominciare da quelli di William Gibson, Bruce Sterling, Philip K. Dick. Molti tentano di immaginare come si modificherà il nostro mondo partendo dall’osservazione del presente ma solo pochi riescono ad essere profetici. Ci sono tratti di una attualità disarmante in alcuni romanzi di Gibson scritti 30 anni fa, quando il web doveva ancora nascere.
Il racconto della Carbé è inquietante (nel senso costruttivo del termine) perché, pur descrivendo un mondo che non esiste, descrive un mondo per il quale i presupposti ci sono tutti. E’ questo essere un futuro così vicino che lo rende inquietante. Non ci sono macchine volanti ma un’alta velocità con stazioni sotterranee (Bologna vi dice niente?), un trasporto potenziato su certe direttrici (e senza soste intermedie) e penalizzato su altre (con tempi di percorrenza ben diversi). Non ci sono strutture supreme di controllo ma c’è la forzatura politically correct delle tradizioni culturali e uno Stato che promulga regole risibili affinché il livello di conoscenza delle persone (e soprattutto dei giovani) sia mantenuto basso e tutto concorra ad un “progresso” puramente economico. Direi che ce ne è abbastanza per vederci un po’ del nostro mondo, del nostro Paese.
Mi è piaciuta però la descrizione del lavoro svolto dall’area “Memoria Umanistica Digitale” dove i testi non solo tornano a nuova vita mediante il digitale ma vengono integrati con strumenti di analisi. Se poi, per avere il finanziamento, si devono aggiungere anche i cosiddetti “contenuti extra” non mi sembra un gran male.
Quando sembrava che il lavoro di disambiguazione della base dati fosse concluso, un nuovo processo di analisi basato questa volta non sulle coppie ma sugli “orfani” (soggetti con genitori sconosciuti) ha messo in luce una serie consistente di buchi nelle genealogie. In pratica alcuni soggetti, e non pochi, hanno i genitori noti nella maggior parte delle occorrenze nel database ma non in tutte. Queste occorrenze nelle quali il soggetto risulta figlio di ignoti (anche se i genitori sono conosciuti) crea dunque una serie di interruzioni negli alberi e soprattutto una mancata corrispondenza tra soggetti. La causa sembrerebbe essere l’integrazione di alcuni alberi con dati provenienti da altre fonti ma quello che conta, adesso, è trovare un algoritmo in grado di rimettere a posto i genitori.
Il lungo silenzio su queste pagine è dovuto all’enorme lavoro di disambiguazione effettuato sulla base dati di Hochadelsdorf. Per disambiguazione intendo l’individuazione di soggetti che, pur essendo la stessa persona, compaiono con nomi diversi nella base dati. Il fenomeno è dovuto alla provenienza dei soggetti da fonti diverse o più semplicemente a grafie diverse dello stesso nome. Risolutiva, in questa poderosa caccia all’intruso, è stata l’ideazione di un processo di analisi che si basa non sui singoli individui ma sulle coppie. Associando ciascun soggetto al suo o ai suoi coniuge/i è stato più agevole scovare i falsi doppi e ricondurli ad una grafia unica. Il lavoro manuale è stato considerevole ma l’estrazione automatica di questo tracciato di controllo ha fatto sì che potessimo procedere per approssimazioni successive fino alla completa (o almeno ragionevolmente tale) bonifica della base dati. L’intera operazione ha richiesto oltre un anno di lavoro anche se c’è da dire che, per me, non è certo un lavoro a tempo pieno e non è stato facile individuare di tempi adeguati per essere portato a termine. L’esito positivo dell’ultimo controllo effettuato mi ha fatto tirare un sospiro di sollievo anche se sono consapevole che ci sono ancora molte fasi da affrontare prima che la base dati sia veramente adatta allo scopo della ricerca che ci siamo posti.
E’ ufficiale, mercoledi 9 marzo alle ore 14.15 nell’Aula Seminari Est del Dipartimento di Informatica terrò il seminario dal titolo “Alla ricerca dell’antenato comune”. Come anticipato in questo post, passerò in rassegna i vari studi sulla ricerca del MRCA concludendo con alcuni dei risultati e molte delle prospettive future del Progetto Hochadelsdorf. Non mancherò di postare su questo blog le slides della presentazione.
Edit (10/03/2016):
Come promesso, ecco le slides della presentazione. Sul sito del Laboratorio di Cultura Digitale è invece possibile ascoltare il seminario per intero.
Cara Kitty,
da qualche tempo mi ha presa la passione per gli alberi genealogici delle famiglie reali e sono giunta alla conclusione che, una volta cominciate queste ricerche, bisogna sempre risalire più indietro nel tempo, e si fanno scoperte sempre più interessanti.
Anna Frank, Diario, giovedì 27 gennaio 1944 (trad. Arrigo Vita)
Qualche settimana fa sono stato contattato dalla giornalista Alessia Smaniotto, responsabile della comunicazione per il progetto OpenEdition Italia (l’infrastruttura che sviluppa Hypotheses.org e che ospita questo blog), con lo scopo di raccogliere materiale per un breve articolo di presentazione dei blog italiani attualmente attivi su Hypotheses.org. Genealogy Cruncher è stato uno dei blog prescelti ed ho avuto occasione di riflettere sulla genesi, sulle finalità e sul ruolo, in un panorama più ampio, di quanto ho scritto fino ad ora e scriverò in seguito in questo pubblico spazio.
Il contatto è stato fortunoso perché i filtri antispam, per un eccesso di zelo, avevano pensato bene di mettere la mail della Smaniotto nella posta indesiderata e solo il caso ha voluto che io andassi a curiosare nel bidone della spazzatura, cosa che faccio di rado ma che può riservare, a volte, delle sorprese.
Così, dopo un breve scambio di email, ho risposto alle domande e le risposte non solo hanno contribuito alla stesura dell’articolo principale ma sono state pubblicate interamente in un altro articolo esclusivamente dedicato a questo blog.
I links a cui è possibile leggere i due articoli sono:
Cinque storie di blogger italiani su Hypotheses.org
Il blogging al servizio della ricerca sulle genealogie della nobiltà europea
Se comunico solo adesso in questa sede l’uscita dei due articoli è solamente perché, nell’ultimo periodo, il progetto Hochadelsdorf ha assorbito tutte le mie energie. La normalizzazione della base dati tesa ad uniformare i soggetti univoci presenti con due diversi nomi è stata una operazione lunga e complessa ma assolutamente necessaria. Prosegue al momento il lavoro sulla identificazione dei MRCAs (Most Recent Common Ancestors) che dovrebbe costituire una parte importante di un futuro articolo sull’argomento.
According to Wikipedia, “Scientists include theoreticians who mainly develop new models to explain existing data and experimentalists who mainly test models by making measurements – though in practice the division between these activities is not clear-cut, and many scientists perform both.” The domain-specific language that many scientists use to define their models is mathematics, and since the early days of computing science, the holy grail has been to close the semantic gap between scientific models and executable code as much as possible. It is becoming increasingly clear that all scientists are practicing applied mathematics, and some scientists, such as theoretical physicists, are behaviorally indistinguishable from pure mathematicians. The more we can make programming look like mathematics, the more helpful we make it to scientists and engineers.
Erik Meijer, prefazione a D. Syme, A. Granicz, A. Cisternino “Expert F#”, Apress 2007