Per diversi anni, il motore sotto il cofano del mio blog è stato Wordpress, da me installato e manutenuto su un server dedicato. Ma con il passare del tempo, quella piattaforma ha tradito, secondo me, lo spirito originario ed è diventato un CMS mastodontico, lento e impegnativo dal punto di vista della gestione e della sicurezza. Tutto ciò è decisamente troppo per un blog, sia in termini economici che di tempo.

Quello che avrei preferito era un sistema snello, essenziale, senza database e che non richiedesse manutenzione, ma allo stesso tempo che fosse flessibile, economico e soprattutto che si integrasse perfettamente con i tool che utilizzo per le analisi dei dati.

Così, dopo aver messo insieme tutti i pezzi sono arrivato all’architettura che potete vedere schematizzata qui in basso. Personalmente ritengo che sia un’ottima scelta per i blog a tema tecnico-scientifici: è elegante, flessibile e, prima di ogni altra cosa, praticamente a costo zero.

Schema architetturale di questo sito

My personal Dev Box

Schema architetturale di questo sito - Dev Box

Il primo blocco dell’architettura è la mia macchina locale di sviluppo, un Apple Macintosh. Sono in molti, tra quelli che fanno il mio mestiere a usare una macchina Apple, perché OSX è la sintesi perfetta di un sistema operativo con una splendida interfaccia grafica, ma sotto cui pulsa un cuore Unix che è uno strumento inestimabile per chi si trova ad analizzare dati. Il setup della postazione, per l’appunto, è fatto tutto a riga di comando utilizzando brew, di modo che il setup della macchina richieda il minimo intervento da parte dell’utente e possa essere replicato alla bisogna. Il tutto è racchiuso in questo shell script.

Su tale macchina, tra le altre cose, trova posto R, che è il linguaggio che prediligo per fare Social Network Analysis (e anche tutto il resto, a dire il vero) e il suo IDE di sviluppo ideale RStudio, più tutti i package che mi servono per le analisi tra cui non mancano praticamente mai igraph e tidyverse.

Per il comparto grafico, mi piace utilizzare Inkscape, un software di grafica vettoriale open source molto maturo. Lo uso per generare diagrammi e icone che poi utilizzo nel blog dopo averli salvati in formato SVG.

I post (e le pagine) del blog sono creati direttamente in RStudio sotto forma di file RMarkdown, un dialetto Markdown che consente di inframmezzare testo e markup con blocchi eseguibili scritti in R. In questo modo, ho tutto ciò che riguarda un articolo, sia il testo che il codice per condurne le analisi ad esso pertinenti (compresa la generazione di grafici e plot) in un unico file. L’estensione di questi file è .Rmd e, credetemi, sono una bomba.

Questo mi consente di migliorare l’authoring e la revisione degli articoli, perché elimina la necessità di copiare gli output degli script in R (risultati, tabelle, grafici,…) dalla visto di output di RStudio all’articolo in draft e viceversa.

Naturalmente il codice R deve essere eseguito e i file .Rmd renderizzati in un formato comprensibile al web server, per poter essere pubblicati.

A questo ci pensa knitr, un sofisticato motore di rendering di markup che può analizzare i file RMarkdown e renderizzarli in diversi formati di uscita, come HTML, PDF, ecc. Per la verità, knitr è pensato come motore di generazione di report, ma è flessibile abbastanza da poter essere utilizzato anche per produrre pagine per un blog, scegliendo il giusto formato di output.

Non solo, knitr è distribuito come package R, quindi la compilazione dei file Rmd può essere fatta direttamente in RStudio.

A titolo di esempio di come funziona il tutto, questa stessa pagina è stata generata a partire da un file RMarkdown e quello che segue è il pezzo di codice R che knitr ha eseguito, generando il file SVG con il grafico riportato più in basso.

par(mar = c(4, 4, .1, .1), bg = 'transparent')
plot(cars, pch = 19, col = 'red', cex = .5)

Grafico a dispersione del dataset Cars

Come formato di output di knitr ho impostato .Md, cioè un file markdown standard. Tra poco sarà chiaro il perché.

Ultimo elemento presente nella mia configurazione locale è il package R blogdown, dello stesso autore di knitr, il vulcanico data scientist Yihui Xie. Senza scendere in dettagli tecnici, questo package aggiunge a RStudio tutta una serie di add-in utili per facilitare la creazione di file .Rmd finalizzati ad essere pubblicati su di un blog e offre una batteria di script per facilitare la creazione e la gestione del blog direttamente da RStudio (caratteristiche che però io ho deciso di non usare).

Tutti i file prodotti da knitr e da Inkscape (.Md, .svg, ma anche i file sorgenti .Rmd, immagini, ecc.) e i file di configurazione della piattaforma di blogging (che vedremo tra un istante) sono versionati tramite git su un repository Github.

Per ciò che concerne il comparto grafico, non dovrò preoccuparmi di device presenti e futuri, di risoluzione e di immagini sgranate. Utilizzare Inkscape per creare i diagrammi e avere istruito knitr a generare tutti i grafici provenienti da R in formato SVG, cioè vettoriali, mi terrà al sicuro per decenni. L’unica accortezza è quella di sincerarmi che le (poche) immagini PNG e JPEG siano retina-ready.

Github Server

Schema architetturale del blog - Github

Ho sempre pensato che fosse stupido che un blog, che tutto sommato è un sito “quasi statico” (essendo aggiornato molto di rado), fosse servito attraverso CMS pensati per siti dinamici (come e-commerce, social network, forum, ecc.). D’altra parte, non è pensabile, nel 2018, aprire Dreamweaver e crearsi un sito in HTML da zero.

Così, per questo blog, ho scelto di usare Jekyll, un CMS molto leggero scritto in ruby, un po’ hard-core in effetti, sicuramente pensato per chi sa il fatto suo. Ha tutte le funzioni che un CMS moderno deve avere, una serie di plugin essenziali ma molto robusti e una caratteristica unica nel suo genere.

Jekyll non si installa sul server.

Il suo funzionamento è semplice: lanciato il suo eseguibile in una directory che ospita un sito Jekyll (con i suoi file di configurazione, il tema, i plugin, ecc.), questi si preoccuperà di staticizzarlo. In altre parole, di generare tutte le pagine HTML a partire da file Markdown che rappresentanto post e pagine (ecco spiegato perché ho configurato knitr in modo da fornirmi questi file in uscita), di generare i file di archivio e l’home page, di spostare tutte le immagini nelle sottodirectory di competenza e così via.

Una volta caricata la versione statica del sito su un server Web, per esempio su Amazon S3, avremmo finito. Basterebbe anche un server Web economico, in effetti, perché servire un sito statico non richiede molte risorse.

Ad ogni aggiornamento del sito avrei avuto, tuttavia, bisogno di rigenerare manualmente la sua versione statica per poi caricalo sul server web remoto, sempre a mano. Aveva tutta l’aria di essere una attività dannatamente noiosa.

Con Github, però, è stato possibile adottare una soluzione più elegante.

Github offre, infatti, un servizio chiamato Github Pages a corredo dei repository che è stato pensato per fornire agli sviluppatori uno spazio web per la documentazione dei codici sorgenti da essi prodotti. Interi siti, volendo.

Poiché questo servizio supporta Jekyll, è sufficiente un commit su un repository Github opportunamente configurato questo viene automaticamente rigenerato dall’istanza Jekyll in esecuzione sui server di Github Pages e, se non ci sono stati errori nel processo, pubblicato sui loro server web. E quindi online.

Tutto in automatico. E tutto gratis.

Github non è, per la verità, l’unica scelta per questo tipo di servizio. Ma tutte le alternative che ho vagliato, tra cui Travis CI, sono pensate per siti più grandi e complessi e richiedevano un maggiore impegno per la messa in opera degli script di build & deploy, che, a differenza di Github, qui vanno scritti dall’utente. Questa versatilità è utile, per esempio se si preferisce che il deploy sia fatto su server che non siano quelli di Github Pages, magari su soluzioni a pagamento più performanti. Questo blog, tuttavia, non ha i volumi di traffico tali da giustificare questo lavoro, così sono rimasto su Github e ho risparmiato tempo e soldi.

Cloudflare

Logo di Cloudflare

Per quanto affidabile, Github Pages è pur sempre un servizio gratuito e, si sa, i servizi gratuiti, prima o poi, si rompono.

Fortunatamente ho scoperto una serie di bei prodotti, sempre gratuiti, offerti da Cloudflare che risolvono egregiamente parecchi problemi di performance e uptime.

Il motivo più ovvio per rivolgersi a Cloudflare è per il pannello di gestione del DNS, attraverso il quale ho potuto far puntare il nome a dominio di questo blog sul server di Github Pages.

Ma subito sotto, è possibile abilitare un notevole layer di caching che, nella versione gratuita, garantisce un miglioramento delle performance nei file statici del sito. Ma, e qui sta il bello, grazie a Jekyll il blog è completamente statico e questo significa sfruttare il caching in tutta la sua potenza (su questo blog, grazie a Cloudflare ho ottenuto una diminuzione del tempo di risposta del sito di quasi circa il 75%).

Per finire, avrete notato che questo blog è servito tramite https.

Anche questo è un servizio messo a disposizione da Cloudflare, che si preoccupa di emettere (sempre gratis) un certificato SSL per i siti dei suoi utenti e di forzare, impostando il loro proxy, tutte le connessioni su protocollo sicuro. Sia chiaro, è un certificato condiviso, ma se solo penso a quanto costava avere un sito in https solo 3 anni fa mi vengono i brividi!

Analytics e Privacy

European General Data Processing Regulation

Avrete notato che su questo sito non vi è alcuna cookie policy, né tanto meno la noiosa barra di presa visione che affligge la navigazione di noi europei da qualche anno. Non è una svista; ci tengo alla privacy dei miei visitatori così come tengo alla mia.

Su questo sito raccolgo dei dati di traffico attraverso Google Analytics. Non posso non farlo; cercare di capire qualcosa dai numeri è il mio mestiere. Ma lo faccio in modo rispettoso e dannatamente rigido, al punto che non ho bisogno di documentare le condizioni perché non c’è niente da dire:

  • Il sito supporta la direttiva Do Not Track. Quasi nessun sito lo fa, perché non è obbligatoria, ma i browser moderni la implementano tutti. Non c’è bisogno di impazzire stilando cookie policy o facendo comparire inutili popup: se non vuoi essere tracciato mentre navigi su questo sito, abilita la direttiva dalle impostazioni del browser e non lo sarai. Fine.
  • L’indirizzo IP non è salvato su Google Analytics. Per default lo è, anche se non visibile in chiaro, e il Regolamento Generale per la Protezione dei Dati (o GDPR) ancora non ha chiarito completamente come gli indirizzi IP debbano essere trattati. Io, però, ho preferito disabilitarlo perché diciamoci la verità non serve a niente. L’unica volta che ne ho avuto bisogno è stato per stilare un report su mappa geografica, costruita geolocalizzando gli IP. Inutile in senso assoluto, figuriamoci in un blog che, per ragioni linguistiche, è visitato praticamente solo da utenti italiani.
  • E per finire, come avrete visto, non ci sono banner su questo sito e questo significa che non ci sono cookie di profilazione.

Chi ba bisogno di una cookie policy adesso?

Get involved

L’intera architettura, il blog, il suo contenuto, hanno una caratteristica in comune: sono open.

Tutti i codici sorgenti, non solo dell’installazione di Jekyll ma anche tutti gli articoli, inclusi i codici R sono disponibili sul repository su Github di cui abbiamo parlato e sono rilasciati su licenza MIT, che è una licenza molto permissiva.

Questo blog funziona, insomma, come un progetto open source in cui tutti vengono ascoltati e possono portare il proprio punto di vista.

Credo che i blog a carattere scientifico, e questo in modo particolare, abbiano solo da guadagnare da un approccio libero e collaborativo.

Questo significa che se doveste trovare un’inesattezza in un articolo, qualcosa che non torna, un bug, un concetto che dovrebbe essere espresso meglio, una scemenza cosmica o, ancora meglio, volete pubblicare qualcosa, anche un intero articolo, non tenetevi la cosa per voi.

Intanto potreste segnalarmi cosa secondo voi non va.

Ma ancora meglio, potreste fare il fork del repository, modificare ciò che ritenete giusto e pubblicare qui ciò che avete scritto attraverso una pull request. O usarlo per i vostri scopi, nel caso fossero diversi.

Io trovo che sia una cosa fantastica. Voi no?