Grab The Blaster di Alessio Biancalana

Jekyll e GitHub Pages, come impostare correttamente il proprio dominio

Io.

Guardate questo volto. È il mio, ed è il volto di un uomo distrutto durante un weekend in cui pur avendo degli impegni ha fatto nottata a migrare il blog ad un nuovo CMS. In realtà la questione è un po' meno semplice di così, e mi serve per introdurre un argomento importante per chi ha intenzione di migrare il proprio sito a Jekyll mantenendo inalterata la funzionalità globale (compresa soprattutto quella social).

Cominciamo dal principio: poco prima della Blogfest (quest'anno Festa della Rete) ho migrato il mio blog a Jekyll, dopodiché tutto contentone ho sfornato un post con alcuni consigli, mantenendo comunque nel mio product backlog (volendo usare termini da fuffarolo Agile) la reintroduzione dei commenti e delle funzionalità legate alla Graph API di Facebook: solo durante il weekend mi sono reso conto che proprio da quel punto di vista avevo spaccato tutto. A Facebook infatti non piace per niente l'impostazione dei record A consigliata da GitHub, quindi se usate GitHub Pages per servire le vostre pagine e volete che l'entity debugger vi sorrida, dovete per prima cosa utilizzare un CNAME per la root del vostro dominio. Ovviamente io sono fortunatissimo... e quindi OVH non supporta tutto questo.

Ora, quello che accade è che possiamo trovarci davanti a due eventalità pessime: la prima è quella che è successa a me, ovvero che il provider non fornisca nessuno strumento per assegnare un CNAME al proprio dominio; la seconda è quasi peggiore, ovvero che il provider da cui abbiamo registrato il dominio fornisca si una maniera anche agevole per assegnare all'apex domain un CNAME, ma gestisca molto molto molto male la cosa.

Prima di buttarmi in un angolo con della birra a fare l'alcolista, ho greppato l'internet per un po' e in preda alla disperazione più totale CloudFlare si è presentato a me come un servizio circonfuso di luce. Tramite CloudFlare infatti non solo possiamo avvalerci di una CDN notevole, ma possiamo anche (chiaramente) scegliere di non curarci di questo e abilitare solo le caratteristiche di base, gratuitamente, che ci permettono di gestire il DNS del nostro dominio supportando tutto quello che manca invece al nostro provider di servizi.

Se vogliamo quindi ospitare il nostro sito su GitHub Pages, ci basterà iscriverci a CloudFlare e invece che inserire un record A puntare un CNAME dal nostro dominio al nostro sottodominio di GitHub (nel mio caso, dottorblaster.github.io). Successivamente - e questa è la parte peggiore - dobbiamo togliere la delegazione dei DNS al nostro provider e dobbiamo impostare i DNS di CloudFlare per il nostro dominio. Questo può essere fatto direttamente da qualsiasi pannello di controllo, ma da quando l'avremo fatto ci vorranno dalle ventiquattro alle settantadue ore perché le modifiche abbiano effetto. Per quanto riguarda questo passo ho avuto un'esperienza terribile perché per circa una ventina di ore i DNS hanno continuato a sfarfallare tra il vecchio e il nuovo dominio, causando anche dei malfunzionamenti a tutto il cucuzzaro.

Una volta fatto tutto e atteso quanto dovuto, apriamo un terminale e verifichiamo che tutto stia funzionando a dovere:

blaster@boromir ~ $ dig dottorblaster.it

; <<>> DiG 9.8.3-P1 <<>> dottorblaster.it
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12044
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dottorblaster.it.      IN  A

;; ANSWER SECTION:
dottorblaster.it.   239 IN  A   104.28.3.118
dottorblaster.it.   239 IN  A   104.28.2.118

;; Query time: 5379 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Sep 18 14:07:04 2014
;; MSG SIZE  rcvd: 66

Ora che il vostro CNAME record sul dominio "nudo" non rompe l'Internet, leggetevi una comoda spiegazione dell'implementazione di questa feature da parte di CloudFlare, totalmente RFC-compliant. Perché ho scritto tutto questo? Perché se avessi saputo tutte queste cose in anticipo, probabilmente Angelo, che mi ha scattato quella foto, avrebbe avuto non dico un soggetto migliore, ma quantomeno un soggetto meno sfatto, con gli occhi meno pesti.

Photo courtesy of Angelo Ghigi

OS X, ottenere una lista dei processi in ascolto da terminale

lsof OSX

A volte su OS X di Apple ci aspettiamo che la command line sia uguale a quella che abbiamo su Linux, ma non è decisamente il caso. Per esempio, uno dei casi lampanti è il voler verificare le porte aperte e i processi in ascolto sulle porte: mentre su Linux potremmo sbrogliarcela decisamente bene usando netstat, su un Mac siamo costretti a usare lsof, che è una utility piuttosto carina.

Mi appunto qui il comando per non perdermelo ancora (ché tanto poi c'è San Google):

$ lsof -i | grep LISTEN | grep "TCP \*:" | sort

Se poi vogliamo buttare un occhio a quali processi hanno una connessione aperta (stabilita), allora possiamo utilizzare quest'altro comando:

$ lsof -i | grep ESTABLISHED | sort

Take care :-) Personalmente, non vedo l'ora di tornare a Linux, ma al momento sono costretto ad un Mac. Non è manco malaccio ma... volete mettere?

Image courtesy of Simon Ganiere

Addio WordPress, benvenuto Jekyll

Jekyll e GitHub Pages

Doveva succedere, dato che da ben un anno valutavo questa opzione. Così, dopo svariati anni di utilizzo di WordPress per questo blog, ho migrato tutto a una piattaforma nuova, più performante, leggermente più scarna e decisamente più affidabile (per me, magari non per altri): ho abbandonato WordPress per passare a Jekyll.

E non credo che tornerei indietro, a conti fatti.

La migrazione editoriale

Come tutti quelli che passano a Jekyll, anche io sento l'impellente bisogno di raccontare questo piccolo episodio di IT della mia vita, perché mi è servito a comprendere che non avevo bisogno di parecchie cose le quali mi erano fornite dal mio CMS, e allo stesso tempo mi ha fatto rendere conto di quanto negli anni il materiale che ho scritto si sia accumulato. Tanta, tanta roba.

Per importare i post dentro Jekyll, nonostante vengano forniti in rete tantissimi tool sotto forma di plugin, di script e di blob, ho preferito dare una chance alla banalissima soluzione scritta in Ruby e fornita direttamente dai ragazzi di GitHub/Jekyll - quindi sono andato sulla documentazione ufficiale, e ho convertito la oscena istruzione multiriga di Ruby in un piccolo script, che ha funzionato perfettamente al primo colpo. I tag sono stati correttamente mantenuti in ogni post, così come le categorie e anche tutti i commenti (che non ho il coraggio di strippare né di parsare a mano, quindi per ora lascerò tutto così schiantato nei file di markdown). Per mostrare effettivamente i commenti uso Disqus, che è totalmente slegato da tutto questo.

#!/usr/bin/ruby

require "jekyll-import";

JekyllImport::Importers::WordPress.run({
  "dbname"   => "home_",
  "user"     => "alvise",
  "password" => "sbrebbro",
  "host"     => "dottorblaster.it",
  "socket"   => "",
  "table_prefix"   => "wp_",
  "clean_entities" => false,
  "comments"       => true,
  "categories"     => true,
  "tags"           => true,
  "more_excerpt"   => true,
  "more_anchor"    => true,
  "status"         => ["publish"]
})

Il flusso di scrittura non è molto diverso da quello che adottavo in precedenza: apro il mio editor di testo, scrivo il mio file in Markdown (perché, ricordiamolo, Markdown regna), e successivamente se prima mi servivo di funzionalità built-in in Sublime Text o in Byword per pubblicare quello che avevo scritto, adesso mi basta fare commit del mio post e fare push sul repository Git che ospita il blog. L'istanza di Jekyll remota si occupa di accogliere le modifiche, rigenerare il sito, e rifare il deploy.

La fase di editing è veramente semplice: essendo tutto ciò che importa scritto in Markdown, non devo fare altro che modificare quello che mi interessa in Sublime Text (in genere), agendo su parti di testo o specifici parametri, non dovendo avere a che fare con interfacce web che hanno bisogno di caricarsi ogni volta. Per sviluppare parti del sito che richiedono modifiche massicce (quindi non per modifiche piccole) posso con due comandi avviare un'istanza locale che rispecchia quello che vedrei online. Jekyll, in poche parole, per l'aspetto editoriale è un generatore di siti statici che non sta in mezzo ai piedi come farebbe un CMS, permettendo ai power user una maggiore flessibilità e soprattutto, secondo me, dei tempi di scrittura minori, non dovendo avere a che fare con tutto il peso di una web UI.

La migrazione tecnica

L'aspetto editoriale l'ho gestito con qualche script e il fido Sublime Text al fianco. L'aspetto tecnico invece ha avuto bisogno di qualche riga di Javascript, e soprattutto un po' di olio di gomito col quale non ho ancora terminato (ho colto l'occasione per scrivermi dei tool in Go che non riuserò mai, ma era per fare esercizio). Alla fine è stato più semplice di quanto avessi effettivamente stimato nelle prime progettazioni del blog, anche perché con Jekyll ho preso la mano dopo poco (e non è la prima volta che lo uso). Per quanto riguarda quindi gli aspetti tecnici della migrazione di un blog a Jekyll (o la scrittura da zero) il meglio che posso fare è condividere la lista dei link del materiale che ho usato per questo piccolo giochetto articolato in tre serate post-lavoro e un lunedì mattina passato in treno:

Di seguito, riporto anche qualche impressione che ho avuto durante questo processo:

  • Non è così semplice come ti aspetteresti: i developer di Jekyll ti vendono il pacchetto come già pronto, ma al 90% hai bisogno di metterci le mani e sporcartele parecchio. Persino quello che loro definiscono come una banale istruzione Ruby ha richiesto la modifica di alcuni parametri, e per quanto Jekyll sia pensato per power user del blogging, e power user del computer in generale (di Unix... :-D) comunque mi ha dato fastidio l'atteggiamento un po' facilone, in alcuni punti, del docset.
  • I temi fanno cagare, o meglio, non esistono: se volete cambiare layout, dato che la logica è spostata tutta nel generatore di pagine statiche, dovete modificare praticamente tutto quanto. Probabilmente è un difetto mio, nel senso che avendo usato WordPress per una vita, non sono abituato a modificare cose nella root del sito - allo stesso modo però è pure vero che tutta la gestione delle modifiche e della versione del proprio layout è affidata alla testa del blogger (che di fatto diventa uno sviluppatore frontend) e al suo branching model. E facciamo pure un tenero saluto a tutti i casini mentali e pragmatici che questo comporta.
  • Rispetto a WordPress, tutto questo è di una semplicità abissale e persino chi non conosce una mazza assoluta di Ruby può arrivare in cinque minuti, se si impegna, a fare il deploy di un blog con Jekyll.

La bellezza di GitHub Pages

In tutto ciò, ho voluto semplificare anche la parte di web hosting al massimo. Per questo motivo, ho dato il tutto in braccio a GitHub e ho lasciato che trasformasse il mio blog da puro codice alla realtà attraverso il meccanismo di deploy automatico di GitHub Pages. In questo modo, tempo qualche secondo, ogni volta che pusho una modifica sul mio repository git, Pages avvia per me il rebuild automatico di tutto. Mi era stato suggerito di utilizzare dei plugin per fare alcune cose che adesso sono costretto a fare a manina, ed ero anche tendenzialmente favorevole all'idea, anche se poi ho pensato che avrei dovuto tenermi committata anche tutta la directory _site e generare tutto ogni volta a mano. Il che, decisamente, non è quello che voglio.

Oltre tutto, con GitHub Pages, mi scordo totalmente delle limitazioni di traffico che può avere un server normale, mettendo dietro al mio blog una meravigliosa infrastruttura che non comprende solo una serie di macchine carrozzate in maniera invidiabile (e gratuitamente, ecco), ma anche una CDN che si fà carico di ottimizzare i tempi di distribuzione dei contenuti in tutto il mondo... cosa che quantomeno risolve in maniera eccellente il caricamento del sito in Italia da un server statunitense. :-P

"E Octopress?"

Octopress è un overkill nel 90% dei casi. Aggiunge codice Ruby al codice Ruby di Jekyll per fare relativamente poco, il che significa che per me, che sto cercando di ridurre la complessità di WordPress a uno zero assoluto (circa), anche no. Pure perché, una volta scritto per bene il template di Jekyll, non riesco a capire a cosa possa servire dato che GitHub Pages fa già il deploy da sé.

Insomma, tutto è bene ciò che finisce bene: mi scuso con chi aspettava qualcosa pubblicato da me in questi giorni, ma ho preferito dare la massima priorità a questo lavoro in modo da sbrogliarmi prima possibile.

GitLab 7.2 - feature, feature e ancora feature

GitLab Explore page

GitLab sembra aver messo il turbo. Di rientro dalle ferie infatti, aprendo il feed reader che ormai gridava vendetta per la quantità di elementi non letti che avevo, ho visto che proprio ieri è stata rilasciata la versione 7.2 di questo software open source che ho iniziato a usare ormai in ambito di produzione, e che sinceramente trovo di una bellezza (si può dire di un programma che è bello?) disarmante. Ci sono un bel po’ di novità in GitLab 7.2, e arrivano tutte a stretto giro rispetto al mio post dell’altra volta, il che mi ha sorpreso notevolmente. Il changelog è fitto di migliorie per così dire estetiche, ma bando alle ciance, andiamo a vedere cosa ci aspetta con questo aggiornamento:

  • Le etichette: adesso le etichette possono essere colorate :-) Se ne facciamo largo uso, sicuramente ci perderemo in mezzo a un bazilione di label diverse assegnate alle nostre issue di progetto. Finalmente è possibile colorare queste etichette, e colorarle non solo di una palette predefinita ma anche di colori personalizzati. Dato che mi sta molto a cuore l’issue management, considero cambiamenti come questo irrisori dal punto di vista teorico, ma ingenti dal punto di vista pratico visto che permettono un colpo d’occhio decisamente più efficace sullo stato di avanzamento dei lavori.
  • Le Star: In azienda si usano diversi strumenti per il networking tra dipendenti. Di fatto, col tempo, la Star di GitHub è diventato oltre che un’aggiunta al proprio elenco di bookmark, anche un importante elemento di social networking dato che ha emulato il Like di Facebook. Circa. GitHub se n’è accorto, e per stilare GitHub Explore (ovvero l’interessantissima newsletter che mandano ogni settimana agli iscritti - e voi dovreste iscrivervi, che domande) usa proprio delle metriche parametrizzate sul numero di star che un progetto riceve - oltre che i fork e tante altre cose. GitLab 7.2 può fare la stessa cosa, finalmente, quindi per gli utenti è possibile “starrare” i repository di altre persone oltre che forkarli. Hell yeah!
  • Diff unfolding: Questa è una novità molto interessante. Di solito nel diff che ci mostra GitLab le parti nascoste non possono essere visualizzate. Vediamo quindi solo ciò che è inerente il contesto delle rimozioni e delle aggiunte ad ogni file. GitLab 7.2 introduce invece la possibilità di clickare sui puntini di sospensione visualizzati sull’interfaccia web del tra i commit, permettendoci di visualizzare ulteriori parti non cambiate del file, fino ad arrivare a visualizzare tutto, senza esclusioni di sorta. Molto, molto bene - ed è, credo, anche la feature tecnicamente più rilevante di questa versione.
  • Pagina Explore rivista: La pagina Explore, che sarebbe quella pagina web dove vengono visualizzati tutti i progetti pubblici della vostra installazione di GitLab, è stata completamente rivisitata in favore di un design più moderno, pulito e meno “brandizzato”, se vogliamo. Sono molto soddisfatto di questa pagina personalmente; mi auguro che anche altre parti dell’interfaccia vengano riviste (magari non quelle relative alla dashboard) per rispecchiare questo design.

Aggiornamento

Beh, abbiamo spolpato abbastanza il changelog - il resto sono caratteristiche della versione Enterprise, o che non mi interessano (:-D). Quello che invece rimane è l’aggiornamento: siccome è il mio primo aggiornamento di GitLab, “recensisco” (e vi mostro in breve) la procedura adesso; pensavo a qualcosa di più complicato, invece per aggiornare la vostra installazione di GitLab 7.1 a GitLab 7.2 basta dare i semplici comandi di seguito.

Per prima cosa, creiamo un backup:

$ sudo gitlab-rake gitlab:backup:create

Dopodiché, andiamo a interrompere le operazioni dei servizi che ci intralcerebbero, scarichiamo il pacchetto, e installiamo la nuova versione:

$ sudo gitlab-ctl stop unicorn
$ sudo gitlab-ctl stop sidekiq
$ wget https://downloads-packages.s3.amazonaws.com/debian-7.6/gitlab_7.2.0-omnibus-1_amd64.deb
$ sudo dpkg -i gitlab_7.2.0-omnibus-1_amd64.deb
$ sudo gitlab-ctl reconfigure
$ sudo gitlab-ctl restart

Gli ultimi due comandi lanceranno la riconfigurazione e la migrazione a GitLab 7.2.

La parte divertente

Già che ci siamo vi racconto anche un aneddoto interessante: non fate gitlab-ctl stop, per nessuna ragione al mondo, oppure arresterete anche Redis e PostgreSQL (o quello che usate come database) - che è quello che ho fatto io al posto di stoppare solo Unicorn e Sidekiq. Il risultato è stato che gitlab-reconfigure ha fallito la migrazione del database, e mi sono dovuto andare a cercare come lanciarla a mano (senza trovare nulla: quello che vedete sotto è un comando inventato sul momento che per puro caso era veramente quello. :-D

Per lanciare manualmente la migrazione del database della vostra installazione di GitLab, aprite una shell e date questo comando:

$ sudo gitlab-rake db:migrate

Tutto andrà a posto, come nei finali delle migliori fiabe.

Buon lavoro a tutti :-)

Stakeholder dell'innovazione, tra pubblico e privato

Google Law

Siamo nella situazione prevista da Lawrence Lessig nel suo Code. Le leggi le fa il software. La sfiducia nella politica impedisce di ritenere possibile e sensato un intervento democratico.

Luca De Biase fa un degno punto della situazione correlando alcuni fatti di questi giorni, e correlandoli piuttosto bene. Ci sono però alcune precisazioni da fare, e qualche bastonata da dare a chi dovrebbe fare di più ma rimane evidentemente impantanato nel proprio operato.

Perché è vero che le leggi in questo momento le sta facendo il software - o meglio, chi sta dietro a un preciso software - però c'è sempre da dire che le leggi hanno il compito di regolare e in parecchi casi coadiuvare il rapporto tra individui e tra enti; e se i software, per così dire, hanno potere legislativo in questo tavolo è solo perché dovrebbero esserci altri stakeholder immersi in questa trattativa, in questo caso (per l'Italia) drammaticamente assenti.

Dove sono i nostri digital champion? Dove sono le istituzioni, quelle vere? Non sono dell'opinione di Luca, in Parlamento abbiamo diverse figure competenti in materia; è che probabilmente non vengono indirizzate queste competenze nella maniera giusta. Infine, un grosso plauso al concetto del mettere in piedi un'infrastruttura in cui tutti possano muoversi nella norma, senza daneggiare nessuno, e senza il bisogno di costruire la Google Nation. Che sennò poi c'andiamo a rimettere.

Digital champion italiani, vi si aspetta al varco, metteteli voi i paletti ché nessun altro è qualificato per farlo.

Photo courtesy of Daniel Mitsuo