Jekyll on Melabit

Un anno di melabit.com

Wed, 31 Dec 2025 06:00:00 +0000

Il 2025 è stato un anno di svolta per questo piccolo blog. Abbandonare la comfort zone di Wordpress.com non è stato facile né tanto meno indolore, soprattutto quando ho scoperto che una volta messo online il sito in Jekyll era lento, troppo lento per essere usabile.

Per fortuna Hugo ha salvato la situazione, anche se ci sono ancora tanti dettagli da sistemare, primo fra tutti l’aspetto grafico del sito.

– Immagine generata da Google Gemini.

Anche gestire i post in due lingue diverse non è facile, ma ne vale la pena visto che i post in inglese permettono di raggiungere un bacino di utenti inimmaginabile scrivendo solo nella nostra lingua.

Il cruccio principale del nuovo sito e l’assenza o quasi di commenti ai post. Non so se è perché sono troppo complicati, troppo lunghi o entrambe le cose. Fatto sta che la scarsezza di commenti è davvero preoccupante. E questo nonostante ci sia un buon numero di visitatori e che in media il 5% passa 15 minuti o più sul sito. Magari alla fine sono troppo esausti per riuscire a commentare, chissà!

Inutile dire che l’IA sta ben lontana dalla scrittura dei testi, al massimo la uso per rivedere qualche termine tecnico di cui non mi ricordo l’equivalente in italiano (Tab è la mia bestia nera, ogni volta mi dimentiche che in italiano si dice Scheda e non Linguetta). A volte provo ad usarla per rendere qualche frase più scorrevole, ma quasi sempre è tempo perso, alla fine diventano così piatte che tanto vale non scriverle.

Ammetto, invece, che la base delle traduzioni la faccio fare all’IA. Mi serve più che altro per risparmiare tempo di battitura, anche se poi ci vuole un bel po’ per sistemare il risultato e rendere il testo tradotto più fluido e vivace.

Uso anche spesso l’IA per generare le immagini in testa ai post. In questo caso non ho scelta, se con la scrittura bene o male me la cavo, in disegno e grafica sono sempre stato il penultimo della classe, e solo perché l’ultimo era davvero terribile. Quindi vi faccio un favore. Ma, anche con il tanto celebrato Nano Banana di Google, c’è voluto del bello e del buono per convincerlo a generare l’immagine di questo post, con le scritte giuste, l’homepage vera e così via. Chi dice che Nano Banana è tanto intelligente da capire al volo quello che volete racconta balle.

Se tutto va bene il 2026 porterà qualche novità, non so bene in che ordine ma la revisione del tema grafico è di sicuro ai primi posti della lista.

Stay tuned! Nel frattempo, tanti auguri per il 2026, che sia un anno pieno di cose buone e di felicità per tutti!

Jeeeeeekyll? No, Hugo!

Sat, 24 May 2025 00:00:00 +0000

Mentre descrivevo come ero passato da Wordpress a Jekyll, sapevo già che avrei dovuto cambiare di nuovo.

Da un punto di vista tecnico, Jekyll è una piattaforma fantastica: è facile da programmare, ha una documentazione ineccepibile e funziona perfettamente durante la fase di sviluppo, quando il numero di pagine e di post di test è limitato. Ma, come ho sperimentato in prima persona, una volta che Jekyll si trova a dover gestire un sito vero con centinaia di post, le prestazioni calano drasticamente e i tempi di risposta aumentano in modo intollerabile (e piuttosto imbarazzante).

A fine anni ‘90 era normale aspettare diversi secondi prima di visualizzare una pagina web.¹ Ma oggi siamo abituati a pagine che si caricano immediatamente, e una attesa di tre, quattro secondi è inaccettabile.

Un prezzo troppo alto da pagare

Prima di iniziare a lavorare sul nuovo sito sapevo bene che Jekyll era lento, ma questa lentezza si riferiva sempre alla fase di generazione del sito, una operazione che si esegue di rado e può essere facilmente automatizzata. E in effetti è proprio così: durante lo sviluppo, con poche decine di post, rigeneravo il sito in 10-20 secondi, una cosa seccante ma non drammatica; ora ci vogliono 15 minuti per rigenerare l’intero melabit.com.

Quello che non sapevo era che anche il sito generato avrebbe sofferto dello stessa problema, come è diventato evidente non appena ho terminato la fase di sviluppo e ho iniziato a lavorare con tutti i post.

In quel momento ero ancora convinto che l’ottimizzazione del codice e delle immagini e un caching aggressivo avrebbe potuto attenuare il problema. E comunque ero andato troppo avanti per fermarmi. Ma dopo poco mi sono accorto che questa strategia non era sufficiente, e che ci voleva un ripensamento radicale. E ho cominciato a guardarmi attorno.

Alternative

I generatori di siti statici sono come le distribuzioni di Linux: abbondano e quasi sempre non si capisce il senso della loro esistenza. In questo momento, Jamstack ne elenca 366, mentre Static Site Generators arriva a quasi 500. La maggior parte è stata abbandonata, magari perché nessuno le utilizzava o perché lo sviluppatore non era interessato a continuarne lo sviluppo. Diciamo che quelle interessanti sono una decina o poco più.

Fra queste ho considerato (brevemente, lo ammetto) Bridgetown, che deriva da Jekyll e quindi, a prima vista, sembrava una evoluzione naturale. Ma poi mi sono accorto che lo usano in pochi, che i plugin sono scarsi e i temi ancora meno. E poi, se Bridgetown discende da Jekyll, non è che soffre dello stesso problema di lentezza? Meglio stare alla larga e tenersi l’originale.

Altro candidato era Middleman, sviluppato in Ruby come Jekyll, Ma Middleman è destinato a generare il classico sito web, e ci vuole una estensione specifica per fargli supportare le funzioni tipiche di un blog (liste di articoli, tassonomie, feed, commenti). E poi il linguaggio di templating è ERB (Embedded Ruby), che in sé è una scelta sensata dato che è integrato nello stesso Ruby, ma che per me significava dover reimparare tutto da zero.

Ve la faccio breve: alla fine dei conti l’unico candidato serio era… il solito Hugo.

Alla ricerca della velocità

Di Hugo avevo già scritto molti anni fa, trovandolo interessante, ma azzoppato da una documentazione che definire scarsa era un complimento.²

Però la qualità non è in discussione, non a caso Hugo, proprio come Jekyll, finisce sistematicamente in cima a tutte le classifiche che si prefiggono di valutare la qualità dei vari generatori di siti statici.

E poi Hugo ha un vero asso nella manica: è veloce, anzi è velocissimo.

Non so dire se Hugo sia davvero il più veloce framework al mondo per la costruzione di siti web, come sostiene lo slogan in cima alla sua home page. Ma ho verificato in prima persona che Hugo è in grado di generare questo sito in meno di un minuto, cioè 15 volte più rapidamente di Jekyll. E, quello che più conta, anche il sito generato risulta essere veloce e reattivo, proprio come ci si aspetta da un sito web moderno. Questo fa passare tutto il resto in secondo piano.

Hugo

E allora da oggi melabit.com passa ad Hugo, con una nuova grafica³ e cercando di mantenere tutte le funzioni della versione basata su Jekyll. Prima fra tutte il sistema di commenti basato su Comma, che dopo il trapianto ha funzionato praticamente al primo colpo.

I permalink sono cambiati e ora distinguono esplicitamente la lingua del post, che è una cosa più razionale. Anche il feed è cambiato, per ora è il vecchio RSS, prima o poi verificherò se è possibile aggiungere ATOM.

La funzione di ricerca per ora è basata su Google, e non funzionerà finché il sito non sarà indicizzato di nuovo. La paginazione va rivista, così come la logica che mostra il post in evidenza anche nella lista di tutti i post. Ma ci sarà tempo per sistemare questi dettagli.

Per formazione mentale mi piacerebbe entrare nei dettagli di come ho modificato Hugo e il tema grafico prescelto, ma temo di risultare noioso, soprattutto dopo tutti gli articoli, dettagliatissimi ma ormai praticamente inutili, scritti su Jekyll. Ci penserò un po’ su, nel frattempo se qualcuno è interessato a saperne di più può scriverlo nei commenti.

– Immagine generata da Google Gemini.

Però ci si poteva distrarre guardando le immagini comparire una riga alla volta sullo schermo… 😂 ↩︎
Rispetto ad allora non è cambiato molto. Uno dei pochi articoli che posso consigliare senza riserve è questo sulla gestione del contesto e delle variabili in Hugo. Una lettura molto tecnica, ma indispensabile per imparare le basi necessarie a modificare ed estendere Hugo. ↩︎
Che non mi fa impazzire, ma che per ora è il meglio che sono riuscito a fare. ↩︎

Da melabit a melabit: Jekyll e l'hosting

Tue, 18 Mar 2025 06:00:00 +0000

– Fonte: Scott Rodgerson su Unsplash.

Come promesso (o minacciato?) nell’ultimo articolo, quest’ultimo post è dedicato ad esplorare le opzioni disponibili per l’hosting di un sito web basato su Jekyll (o su qualsiasi altro generatore di siti statici) destinato ad ospitare il nostro blog personale (come quello che state leggendo), oppure il sito web di uno studio professionale o di una piccola azienda.

Tutto sommato potrei cavarmela in due righe, invitandovi a rileggere quello che avevo scritto 6-7 anni fa (qui e qui) ma sono passati tanti anni e una bella rinfrescata è d’obbligo.

Per chi volesse leggere le altre puntate dedicate alla mia transizione da Wordpress a Jekyll, ecco la lista completa degli articoli pubblicati:

Premessa

Non sono uno sviluppatore professionista, non so molto di sviluppo web e mi considero solo un dilettante per quanto riguarda la gestione di server e di reti.

Le considerazioni riportate qui sotto, quindi, sono solo delle riflessioni personali frutto di anni di esperienza e di sperimentazione nella gestione di sistemi di calcolo più o meno complessi e di servizi web ancora attivi o ormai defunti (più di uno, purtroppo). Mi auguro che le righe che seguono possano essere utili a chi sta valutando delle soluzioni simili, ma chi cerca delle soluzioni professionali deve rivolgersi a chi ne sa di più.

Perché non conviene usare un Mac

Come accennavo la volta scorsa, trovo poco sensato usare un Mac per ospitare un server web destinato a un sito basato su Jekyll (o, più in generale, per qualsiasi sito web, sia esso statico o dinamico).

La ragione è semplice: per gestire un sito con traffico moderato, un Mac è una soluzione eccessiva, un vero spreco di risorse (gli anglosassoni direbbero che è overkill, un termine che trovo particolarmente azzeccato).¹

Discorso diverso per la fase di sviluppo (io stesso ho usato un Mac per quella): avere a disposizione un sistema UNIX con una interfaccia grafica ben curata, degli editor potenti ma facili da usare, degli strumenti che semplificano la scrittura del codice e la ricerca degli errori sono vantaggi che non hanno prezzo.

E se ho un vecchio Mac che non uso più? Perché non destinarlo a gestire il mio sito?

Un vecchio Mac è ancora perfetto per scrivere, gestire la posta elettronica, navigare sul web, fare videoconferenze, comporre musica, imparare a programmare e molto altro. Ancora meglio se gli installiamo una versione recente di macOS con Open Core Legacy Patcher.

Ma usare un vecchio computer come server, da tenere acceso tutto il giorno, tutti i giorni? Non so, io non lo farei, non mi sembra una scelta affidabile. E comunque, anche volendo provarci, si ricadrebbe nel discorso più generale della prossima sezione.

Perché non conviene fare da sé

Al posto del Mac potremmo voler usare un PC, magari uno di quei gioiellini un po’ datati simili al Mac Mini che si trovano a poco più di 100 euro e che possono ancora dire la loro, come il Lenovo M95q o l’HP 800 G3. Oppure un Raspberry Pi 5 che, purtroppo, non è più conveniente come una volta, almeno se vogliamo usarlo come un semplice computer.

Come dicevo anni fa, una volta installatoci su Linux, questi minicomputer diventano perfetti “per imparare a gestire un server web e il sistema Linux associato oppure per fare delle prove con diversi CMS o generatori di siti statici prima di scegliere quello che vogliamo usare per il nostro sito”.

Non c’è nemmeno bisogno di collegarli ad una tastiera e ad un monitor, perché si può fare davvero tutto dal Terminale tramite collegamento ssh o, per chi preferisce la classica interfaccia grafica, accedendo al sistema con Chrome Remote Desktop o con uno dei tanti servizi di accesso remoto che ormai conosciamo tutti molto bene.

Ma possiamo usare questi minicomputer per gestire un sito “vero”, che deve essere attivo 24 ore su 24 e 7 giorni su 7?

Secondo me no.

Un sito web richiede la disponibilità di un indirizzo IP fisso pubblico e solo Fastweb lo offre gratuitamente, ma a certe condizioni. Gli altri provider non sanno nemmeno cosa sia, oppure bisogna sottoscrivere dei contratti specifici, che naturalmente sono più costosi dei normali contratti “home” e “business”.

Lo so, ci sono i servizi di DNS dinamico. Ma gli anni ‘90 sono passati da un pezzo, e oggi non affiderei mai i miei servizi web ad un servizio ballerino, con tempi imprevedibili di aggiornamento dell’IP. Tanto più che, se si vuole un minimo di affidabilità, si deve scucire qualcosa. E a quel punto, ne vale la pena?

Un altro problema sono le interruzioni improvvise di connessione a internet o di elettricità, magari a causa di lavori per strada, oppure perché il collega di studio o il partner ha deciso di accendere contemporaneamente tutti i condizionatori, o di usare lavatrice, forno e phon insieme.

Certo, esistono gli UPS, ma se siamo fuori ufficio o casa, dopo un po’ anche l’UPS si scarica e il nostro server si spegne.

E infine, non dimentichiamolo mai, c’è la questione della sicurezza, gli attacchi inevitabili e continui dei tanti sfaccendati che non hanno di meglio da fare nella vita. A meno di non essere già degli esperti in tema di sicurezza, siamo davvero disposti ad impelagarci in prima persona in cose che vanno ben al di là delle nostre competenze?

Cosa conviene fare da sé

Volendo fare da sé, l’opzione migliore è senza dubbio usare una macchina virtuale su uno degli innumerevoli servizi cloud, da UpCloud a Digital Ocean, oppure Heroku o Linode (ora Akamai Cloud), senza dimenticare naturalmente i grossi player come Amazon AWS e Google Cloud (ok, fra questi ci sarebbe anche Microsoft Azure). Se in questo momento non vi fidate a comprare americano, qui c’è una lista di provider cloud europei.

Una macchina virtuale sul cloud costa poco e non ha nessuno dei difetti elencati finora, a parte la questione della sicurezza, che però è gestita almeno in parte dallo stesso fornitore del servizio.

Ancora più sicuro, e pure a costo zero, è usare servizi come GitHub Pages che, ogni volta che si aggiorna un repository collegato basato su Jekyll, rigenera il sito e lo e pubblica automaticamente su github.io. La documentazione relativa è molto dettagliata, per cui è inutile che io aggiunga altro.

Cosa ho fatto io

Io sono un utente come tanti, e la soluzione che ho adottato può essere un buon esempio di come gestire in modo efficiente e relativamente economico (cosa che non guasta mai) l’hosting di un sito web, senza compromessi sulla qualità del servizio.

Questo sito è ospitato su Shock Hosting, un servizio di hosting che uso da anni e con un servizio di supporto eccezionale. In realtà in tanti anni ho avuto pochissimi problemi e sempre banali, ad esempio per una fattura pagata per sbaglio due volte, ma ogni volta la risposta del supporto non poteva essere più veloce.

Il piano base “Low Shock” da 2.99 dollari al mese offre spazio su disco e trasferimento di dati illimitati, e non impone limitazioni artificiose di velocità (tutte cosa che pochi concorrenti offrono). Questo piano è più che sufficiente per un sito statico, ma anche per un sito basato su Wordpress o altri CMS (o dico per esperienza diretta). I piani superiori sono identici a quello base, ma permettono di ospitare più domini, e passare da un piano all’altro richiede solo l’apertura di un ticket e una breve attesa.

Anche il nome del dominio è gestito da Shock Hosting e costa 12 dollari all’anno (un dollaro al mese), che è il costo normale di un dominio .com.

Naturalmente, Shock Hosting è solo uno degli infiniti servizi di hosting disponibili, anche se, per quanto riguarda il rapporto qualità/prezzo, mi sembra difficile trovare di meglio. In ogni caso, prima di scegliere vi consiglio di stare molto attenti alle condizioni di uso, perché la maggior parte dei provider pone dei limiti più o meno stringenti allo spazio su disco o alla quantità di dati trasferiti. Oppure alcuni offrono prezzi molto convenienti per il primo anno o i primi mesi, ma poi li aumentano in modo consistente. Se, prima di impegnarvi, riuscite anche a verificare come funziona il supporto è un bel vantaggio.

Altrimenti preferite un servizio che vi permette di pagare ogni mese o ogni trimestre, in modo da avere la possibilità di testare con calma il servizio e di verificare se risponde alle vostre esigenze. In seguito, potrete sempre decidere di pagare ad intervalli più lunghi.

Evitate invece come la peste i servizi che offrono sconti enormi se vi impegnate per due, tre o più anni, o per… l’eternità. Su internet non c’è niente di eterno, anzi sono proprio i servizi eterni quelli che muoiono più rapidamente. E se dovesse sucecdere avrete perso tutto quello che avete anticipato, altro che risparmio!

Il solo servizio di hosting non è sufficiente per melabit.com/posts/it, perché non permette di eseguire comma per gestire i commenti. La cosa più semplice da fare sarebbe stata passare ad usare un server virtuale, sempre su Shock Hosting, ma non mi piacciono le cose semplici. E poi il servizio di hosting offre dei vantaggi che non volevo perdere: si occupa della gestione del server web e della sicurezza del sito, esegue i backup, rinnova il certificato SSL, fornisce statistiche e molto altro. Tutte cose che valgono molto di più dei pochi euro al mese richiesti.

Proprio mentre pensavo a cosa fare, mi è capitato sotto gli occhi questo post, e ho deciso di assaggiare la cucina tedesca, acquistando un server virtuale da Hetzner. Per far girare comma è più che sufficiente l’offerta base CX22, che con meno di 5 euro al mese mi offre una macchina equivalente a quella base di Shock Hosting, che però costa il doppio. E la potenza della macchina virtuale è tale che posso tranquillamente generare il sito su questa macchina virtuale, trasferendo poi il risultato su Shock Hosting con rsync.

Quando ho scelto Hetzner, la guerra commerciale in atto fra USA ed Europa era solo nelle menti degli dei, ma con il senno di poi è stata una decisione azzeccata. Se un giorno perdessi l’accesso al mio servizio di hosting statunitense, oppure se il costo diventasse proibitivo per un europeo, ci metterei molto poco a trasferire tutto in lidi più sicuri. E ciao ciao USA.

Facciamo due conti

Ho scritto che secondo me non vale la pena fare da sé, usando un Mac o un PC per gestire il proprio sito. Ma dal punto di vista economico, potrebbe valerne la pena?

Cominciamo calcolando quanto spendo al mese per melabit.com/posts/it. Per l’hosting se ne vanno 3 euro, per il server virtuale 5 euro. Totale 8 euro al mese, che in un anno fanno 96 euro. A questo andrebbe aggiunto il costo del dominio, ma quello va pagato in ogni caso, quindi lo lascio fuori.

Mettiamo ora che io sia testardo e voglia usare a tutti i costi un mini PC o un Raspberry Pi per gestire il mio sito. Diciamo che per il computer nudo e crudo se ne vanno 100-120 euro, a cui va aggiunto un disco SSD decente e una quantità di RAM adeguata, che fanno almeno altri 60-100 euro (per il Raspberry Pi la RAM è quella è non può essere cambiata, ma al suo posto dobbiamo prevedere di acquistare case, alimentatore, dissipatore praticamente obbligatorio e scheda per disco SSD NVMe, che fanno almeno 100 euro in tutto).² Poi ci vuole un UPS, e sono altri 100 euro.

Il totale fa circa 300 euro (più o meno 30-40 euro), praticamente lo stesso di quello che spendo io in tre anni. Ma non è affatto detto che il mini PC o, peggio, il Raspberry Pi riesca a reggere tre anni di uso ininterrotto, per cui magari oggi si rompe la ventola, domani l’alimentatore, il disco comincia a fare le bizze, le batterie dell’UPS si esauriscono. Insomma, anche economicamente non è che convenga più di tanto.

Meglio, molto meglio il cloud.

In teoria, si potrebbe dedicare un intero Mac ad un sito che riceve un numero molto elevato di visite. Ma in questo caso servono soluzioni professionali, non è possibile fare da sé. ↩︎
Ma riuscire a rimanere vicino al limite inferiore di 160 euro mi pare davvero difficile. ↩︎

Da melabit a melabit: gestire i commenti con Jekyll

Wed, 05 Mar 2025 06:00:00 +0000

Come dicevo la volta scorsa, Jekyll non ha un sistema di commenti integrato, ma i suoi temi permettono spesso di gestire i commenti collegandosi a servizi di terze parti, come Disqus e simili.

Il problema di questi servizi è che possono smettere di funzionare da un giorno all’altro (vedi il caso di Muut, che non ha più nemmeno un sito web), oppure hanno regole opache di utilizzo e di raccolta dei dati dell’utente.

Un altro problema niente affatto trascurabile è che la maggior parte di questi servizi richiedono all’utente di registrarsi prima di commentare. La registrazione è utile per filtrare i commenti inopportuni o lo spam, ma è anche una barriera per il lettore casuale del post che voglia dire la sua.

C’è poi la questione del costo. Alcuni servizi di gestione di commenti sono a pagamento e non sono nemmeno economici, vedi il caso di Hyvor Talk che costa 12 euro al mese. Prezzo più che accettabile per un sito professionale o per una piccola azienda che voglia interagire con i suoi utenti – tanto più che spesso questi servizi gestiscono anche l’invio di newsletter e materiale pubblicitario vario – ma decisamente fuori scala per un blog fatto in casa come questo.

Alla ricerca del sistema ideale

Il mio interesse verso le questioni relative ai commenti è nato un anno fa quando, dopo la chiusura improvvisa di Muut, ho osservato l’enorme lavoro svolto dietro le quinte da Mimmo, MacMomo e Paoloo, per recuperare da Muut tutti i commenti di Quickloox – uno dei blog imprescindibili per chi si interessa di Apple, Mac e dintorni – per poi convertirli nel formato del nuovo motore dei commenti e reinserirli in bell’ordine nel blog.¹

Pochi mesi dopo ho messo in cantiere il passaggio da Wordpress Jekyll, e quello dei commenti era uno dei problemi principali da risolvere. Su Wordpress il problema non si pone, i commenti sono integrati e vengono salvati nel database del sito insieme al testo dei post. Ma quando si usa un sito statico, come quello generato da Jekyll, bisogna implementare qualche meccanismo per innestarvi sopra i commenti, che per la loro stessa natura sono degli oggetti dinamici.

Con il senno di poi, avrei potuto seguire i consigli di Mimmo e scegliere Comma fin dal primo momento. Ma arrivavo da Wordpress e l’idea di usare un database mi sembrava la più naturale.

E allora ho provato Cusdis, Commento, Commento++, Remark42, Zooment, tutti sistemi di commenti basati su un database.¹ Ho seguito passo passo le istruzioni, ho usato Docker, ho usato una macchina virtuale sul cloud con Linux, ho provato servizi che dovrebbero fare tutto da soli come Railway o Vercel. Niente da fare, ci fosse stato un sistema di commenti che funzionava come si deve!²

Esclusi a priori tutti i sistemi che si appoggiano a GitHub, come Giscus, Staticman o utterances, perfetti per gli sviluppatori che hanno già di sicuro un account, ma poco pratici per il lettore occasionale costretto a crearne un altro inutile, ne restava solo uno. Ovviamente Comma.

Al lavoro su Comma

E Comma è stato. Comma è scritto in Go e viene distribuito solo in formato sorgente. Per compilarlo serve quindi un compilatore per il linguaggio Go. Sul Mac il compilatore si installa scaricando il package preconfezionato e seguendo le istruzioni, oppure tramite il solito Homebrew,

$ brew install golang

Analogamente, su Linux Go si installa scaricando un file compresso ed estraendolo nella directory usr/local, oppure tramite i comandi del package manager della propria distribuzione,

$ sudo apt install golang
$ sudo dnf install golang
$ sudo pacman -S go

a seconda che usiamo Debian/Ubuntu, Fedora/CentOS, Arch, o uno degli infiniti derivati.

Una volta installato Go, compilare Comma è questione di un attimo,

$ git clone https://github.com/Dieterbe/comma.git
$ cd comma/src
$ go build

dove l’ultimo comando serve per controllare che il programma venga compilato correttamente. Se è tutto a posto, si può eseguire

$ go install .

che in un solo colpo compila il sorgente ed installa l’eseguibile comma in ~/go/bin/ (come al solito la ~ rappresenta la Home dell’account che stiamo usando).

Io prima di clonare il repository di Comma ho fatto un fork nel mio account personale, ma solo perché volevo cambiare qualcosetta nel codice.

La prima cosa che ho fatto è stata quella di cambiare l’estensione dei file dei commenti, da .cmt a .xml (linee 67 e 105 del mio file comment.go). I commenti sono infatti dei file XML, e non c’era ragione di usare una estensione non standard. In più, questa modifica permette di aprirli più facilmente con un editor di testo, che li formatta automaticamente in modo leggibile. Una piccola comodità, molto utile durante la fase di sviluppo. Sempre per aumentare la leggibilità, ho anche aggiunto 4 spazi prima di ogni tag XML (linea 71-73 di comment.go).

Infine, ho rimosso l’obbligo di inserire l’indirizzo email di chi scrive il commento (linee 94-96 di main.go). Volevo infatti un sito privo di qualunque forma di tracciamento degli utenti, evitando tanti grattacapi con la GPDR.³ In teoria, ciò può presentare qualche rischio a livello di sicurezza, ma davvero pensiamo che chi vuole fare dei danni inserisca la sua vera email?

Per quanto riguarda il frontend, cioè come l’utente vede il suo nuovo commento e la lista dei commenti precedenti, qui ho trasportato su Jekyll la gran parte del codice originale dell’autore di Comma, aggiungendo il supporto a Markdown e ripulendo il commento dal codice potenzialmente malevolo inserito nel testo. Per queste due ultime funzionalità ho tratto molta ispirazione dal codice scritto da Mimmo, MacMomo e Paoloo per Quickloox.

In quanto alle icone associate a ciascun commentatore, ho preferito farle generare da Jdenticon, forse perché le sue strutture geometriche simmetriche si adattano meglio alla mia personalità.

L’aspetto finale dei commenti mi pare piuttosto gradevole e ben integrato con il resto del sito, e anche la localizzazione funziona bene, anche in dettagli minimi come la riga sottile più in evidenza sotto “Aggiungi un commento”, che cambia a seconda che la scritta sia in italiano o in inglese.

Tutto il codice del frontend è in _includes/custom/comma-comments.html. Già che c’ero, ho aggiunto alla pagina dei post (_layouts/post.html), una piccola funzione in JavaScript che permette di tornare con un click in testa al post. A me serviva in fase di sviluppo, ma credo che possa essere utile anche a chi legge l’articolo, per cui l’ho lasciata nel codice finale.

Mettere tutto insieme

Una volta pronto sia il sistema di commenti che il codice per visualizzarli sul sito, bisogna far funzionare tutto assieme. Per prima cosa dobbiamo creare una cartella dove salvare tutti i commenti,

$ cd
$ mkdir ~/comments

poi attivare Comma a mano,

$ ~/go/bin/comma ~/comments localhost:5888

istruendolo a mettersi in attesa dei nuovi commenti sulla porta 5888 del computer locale localhost, salvandoli nella cartella ~/comments. Infine, dobbiamo aggiungere in _config.yml una riga che connetta Jekyll al server dei commenti,

#--- Comma comments ---
commentserver: http://localhost:5888

e tutto dovrebbe funzionare al primo colpo. Se invece di un computer fisico stiamo usando una macchina virtuale sul cloud, al posto di localhost dovremo usare il reverse DNS name della macchina (si veda l’articolo precedente), ma i dettagli di come si fa dipendono dal servizio usato, per cui non posso essere più preciso.

In un sito reale le cose diventano un po’ più complesse, ad esempio perché bisogna utilizzare il protocollo sicuro https: al posto del semplice http:, e questo richiede di configurare per bene il server web. Ma anche in questo caso i dettagli dipendono dal server web utilizzato, dalla configurazione dei servizi installati e così via, per cui è impossibile dire di più senza scrivere un intero manuale d’uso.

Quello che posso dire, invece, è che un sito vero richiede che Comma parta automaticamente, esattamente come succede al server web che gestisce il sito.

Assumendo che il sito giri su un server Linux (nel prossimo articolo spiegherò perché non ha molto senso usare un Mac come server web) e che Comma sia stato installato dall’utente webuser, per far partire Comma automaticamente ad ogni riavvio del sistema operativo (ma anche quando per qualche motivo il programma viene interrotto), dobbiamo eseguire

$ cd /etc/systemd/system
$ sudo touch comma.service

creando il file di configurazione comma.service vuoto, per poi inserire in questo file le righe seguenti,

[Unit]
Description=comma backend server
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/home/webuser/go/bin/comma /home/webuser/comments :5888
Restart=always
RestartSec=1
User=webuser
Group=webuser

[Install]
WantedBy=graphical.target

ricordandosi di sostituire a webuser il nome dell’utente che ha installato Comma. A questo punto,

$ sudo systemctl enable comma

attiva il meccanismo di avvio automatico che ci permetterà, da ora in poi, di dimenticarci (o quasi) dell’esistenza di Comma. Per interagire manualmente con il servizio si usano i comandi,

$ sudo systemctl status comma
$ sudo systemctl stop comma
$ sudo systemctl start comma

che servono rispettivamente ad interrogare lo stato del servizio, oppure a fermare e a riavviare a mano Comma. Sono comandi molto utili in fase di debugging, ma possono servire a volte anche in produzione, per cui è bene sapere che esistono.

Conclusioni

Avevo pensato di concludere qui questo viaggio nella descrizione tecnica del nuovo sito, ma mentre scrivevo questo articolo mi sono accorto che qualche parola sull’hosting potrebbe essere utile. E proprio questo sarà l’argomento della prossima puntata.

E nemmeno un database piccolo come SQLite! Tutti questi sistemi di commenti usano pesi massimi come MariaDB o PosgreSQL. ↩︎ ↩︎
Se fossi cattivo potrei pensare che le istruzioni fossero sbagliate apposta per spingermi ad usare le loro soluzioni cloud a pagamento. Ma io sono buono. ↩︎
Non ho niente contro la GPDR, anzi la trovo una normativa utilissima, almeno in teoria. Nella pratica, però, fa poco per tutelare davvero la privacy degli utenti, riducendosi nei fatti in un poco utile appesantimento burocratico. ↩︎

Da melabit a melabit: sviluppare un sito in Jekyll

Sat, 01 Mar 2025 06:00:00 +0000

Dopo la prima parte dedicata all’installazione e alla configurazione iniziale di Jekyll, con questa seconda parte di note commentate si entra nel vivo dello sviluppo di un sito in Jekyll a partire da un tema già pronto. Sviluppare da zero un tema per Jekyll, invece, va molto oltre le mie competenze, ma del resto chi è in grado di farlo non ha bisogno di leggere queste notarelle.

Cosa vogliamo?

Per prima cosa dobbiamo avere una idea chiara di come dovrebbe essere il sito dal punto di vista grafico e quali funzioni deve supportare. Vogliamo un blog personale con un semplice elenco di post? Vogliamo un sito più elaborato stile rivista? Vogliamo un sito vetrina per presentare la nostra attività o un progetto specifico? Vogliamo un sito fotografico o di documentazione?

Una volta chiarite le “specifiche” del sito, facciamo un giro su questo sito di temi per Jekyll, oppure su questo, o su questo, o infine su questo (non posso distinguerli per nome, perché si chiamano tutti Jekyll Themes). I più pazienti potranno scorrerli uno ad uno, gli altri preferiranno selezionate la tipologia di sito che gli interessa e guardare solo quei temi. In ogni caso, è bene prendere nota di quelli che ci piacciono di più e provate i siti demo, quando ci sono. È bene essere aperti, magari troviamo un tema interessante che esce fuori dalle specifiche, meglio segnarsi anche quello.¹

Come è fatto un tema

A questo punto non resta che provare. Per evitare di essere generico, descriverò l’installazione del tema Mundana che, guarda caso, è quello che ho usato per melabit.com/posts/it.

Ma, proprio come Mundana, la maggior parte dei temi non gem-based di Jekyll si installa clonando il suo repository su GitHub oppure scaricando un file compresso (nel qual caso, tutto la parte qui sotto relativa a git può essere saltata a piè pari). In entrambi i casi, ciò che installiamo è sia il tema che il sito vero e proprio, perché in Jekyll non c’è una separazione netta fra grafica e contenuti.

La prima cosa da fare è installare git sul computer. Su macOS è installato di default, ma è sempre una versione un po’ datata, e comunque come dicevo la volta scorsa, è sempre meglio separare i tool di sistema da quelli che usate per lo sviluppo. Del resto, con Homebrew ci vogliono pochi secondi, basta eseguire

$ brew install git

e avremo l’ultima (o quasi) versione di git installata sul Mac.

Con Linux non è molto diverso, ma questa volta dovremo usare l’installatore dei pacchetti per la distribuzione in uso, per cui eseguiamo uno dei comandi qui sotto

$ sudo apt install git
$ sudo dnf install git
$ sudo pacman -S git

a seconda che usiamo Debian/Ubuntu, Fedora/CentOS, Arch, o uno degli infiniti derivati.

Come dicevo, l’installazione di Mundana avviene clonando il suo repository,

$ git clone https://github.com/wowthemesnet/mundana-theme-jekyll.git
Cloning into 'mundana-theme-jekyll'...
remote: Enumerating objects: 324, done.
remote: Total 324 (delta 0), reused 0 (delta 0), pack-reused 324 (from 1)
Receiving objects: 100% (324/324), 4.12 MiB | 24.52 MiB/s, done.
Resolving deltas: 100% (116/116), done.

oppure scaricando ed espandendo il file zip del progetto.

Gli sviluppatori suggeriscono di fare il prima un fork sul nostro account GitHub e poi di clonare da lì. Secondo me ha senso se vogliamo contribuire al codice, altrimenti mi sembra un passaggio inutile. E comunque, chi sa cos’è un fork non ha bisogno di altre istruzioni.

Una volta finita l’installazione, possiamo spostarci nella directory di Mundana e curiosare un po’ in giro (per maggior chiarezza, tutti i nomi delle directory finiscono con uno /).

$ cd  mundana-theme-jekyll
% ls -nhp
total 72
-rw-r--r--   1 501  20   398B Feb 12T19:58:00 404.html
-rw-r--r--   1 501  20   510B Feb 12T19:58:00 Gemfile
-rw-r--r--   1 501  20   1.7K Feb 12T19:58:00 Gemfile.lock
-rw-r--r--   1 501  20   2.0K Feb 12T19:58:00 README.md
-rw-r--r--   1 501  20   1.7K Feb 12T19:58:00 _config.yml
drwxr-xr-x  11 501  20   352B Feb 12T19:58:00 _includes/
drwxr-xr-x   6 501  20   192B Feb 12T19:58:00 _layouts/
drwxr-xr-x  11 501  20   352B Feb 12T19:58:00 _pages/
drwxr-xr-x  20 501  20   640B Feb 12T19:58:00 _posts/
drwxr-xr-x   5 501  20   160B Feb 12T19:58:00 assets/
-rw-r--r--   1 501  20   149B Feb 12T19:58:00 docker-compose.yml
-rw-r--r--   1 501  20   9.2K Feb 12T19:58:00 index.html

La directory di Mundana contiene due file di servizio di RubyGems, Gemfile e Gemfile.lock, oltre al file docker-compose.yml che serve solo se usiamo Jekyll all’interno di un container Docker (cosa che qui non interessa). Tutto il resto fa capo a Jekyll.

Le pagine statiche del sito vanno messe nella cartella _pages, mentre tutti i contenuti dinamici, cioè quelli che vengono modificati di frequente come i post di un blog, vanno in _posts. Il contenuto delle pagine statiche e dei post può essere scritto indifferentemente sia in html che in Markdown.

La cartella _layouts contiene i file che generano le parti principali del sito, come le pagine statiche e quelle dei post o la barra laterale, mentre la cartella _includes contiene delle porzioni di codice che possono essere incluse nelle diverse pagine, più o meno come se fossero delle funzioni di libreria.

Queste quattro cartelle, che iniziano tutte con un underscore _, vengono elaborate dal motore di Jekyll, che le usa per costruire le pagine html vere e proprie del sito statico.

L’ultima cartella assets, invece, è dedicata ai contenuti del sito che non vengono elaborati dal motore di Jekyll, come i file css che specificano tutti i dettagli dell’aspetto grafico del sito, i file JavaScript necessari per svolgere certe funzioni che richiedono interattività,² e tutte le immagini del sito. Quando Jekyll genera un sito questa cartella viene copiata così com’è e il sistema crea automaticamente i link ai vari file.

Infine, il file _config.yml contiene tutti i parametri di configurazione del sito, fra cui il nome e la descrizione del sito, il link al logo o alla favicon, i plugin necessari per generare il sito, i parametri di paginazione, o l’elenco dei file e delle cartelle di servizio che non devono essere elaborati da Jekyll. Il file _config.yml può diventare piuttosto lungo e complesso, qui sotto per semplicità faccio vedere solo una piccola parte del file _config.yml di default di Mundana.

# Site
name: 'Mundana'
description: 'Mundana is a free Jekyll theme for awesome people like you, Medium like.'
logo: 'assets/images/logo.png'
favicon: 'assets/images/favicon.ico'
baseurl: '/mundana-theme-jekyll'

[...]

# Plugins
plugins: 
  - jekyll-feed
  - jekyll-sitemap
  - jekyll-paginate
  - jekyll-seo-tag
  
[...]

# Paginate
paginate: 10

# Exclude metadata and development time dependencies (like Grunt plugins)
exclude: [README.markdown, package.json, grunt.js, Gruntfile.js, Gruntfile.coffee, node_modules]

Già che ci siamo, semplifichiamoci il lavoro futuro con una piccola modifica al file _config.yml, sostituendo la riga baseurl: '/mundana-theme-jekyll' con baseurl: ''.

Dimenticavo, anche i plugin (e le relative dipendenze) sono anch’essi delle gemme di Ruby e non sono installati di default, per cui ci tocca farlo con

$ rm Gemfile.lock

che serve per evitare di avere conflitti quando Ruby ci propone di installare plugin più recenti di quelli riportati nel file Gemfile.lock. Subito dopo,

$ bundle install
[...]
Fetching gem metadata from https://rubygems.org/............
Resolving dependencies...
Fetching jekyll-paginate 1.1.0
Installing jekyll-paginate 1.1.0
Fetching jekyll-sitemap 1.4.0
Installing jekyll-sitemap 1.4.0
Bundle complete! 4 Gemfile dependencies, 39 gems now installed.
Bundled gems are installed into `[...]/.gems`

che installa i plugin veri e propri (e rigenera automaticamente il file Gemfile.lock con le versioni appena installate dei vari plugin).

Mettiamo di nuovo Jekyll alla prova

A questo punto non ci rimane che mettere di nuovo Jekyll alla prova, ma questa volta con il tema che abbiamo installato.

$ bundle exec jekyll serve --host=0.0.0.0

Il sito verrà rigenerato rapidamente e potrà essere visto all’URL http://localhost:4000 della nostra macchina reale, oppure all’URL della macchina virtuale o del server cloud che stiamo usando, sempre utilizzando la porta 4000 (per i server cloud l’URL ha una etichetta del tipo reverse DNS name o simili).

Rispetto ai semplici temi gem-based visti nell’articolo precedente Mundana è chiaramente un’altra cosa.

Qui la struttura del sito è molto più efficace: in cima vengono mostrati gli ultimi quattro post con le relative immagini, al centro spicca in grande evidenza un post con uno sfondo contrastante (ad esempio l’ultimo pubblicato) e, più in basso, tutti gli altri post sono disposti in ordine cronologico inverso. A fianco, una barra laterale ospita i post che desideriamo mettere in risalto.

Ora basterebbe sostituire i post preconfezionati di Mundana con i propri, aggiungere le immagini, fare due o tre modifiche al file _config.yml e in pochi minuti si avrebbe il sito pronto da mettere online, con tutti i post già organizzati in tante pagine belle ordinate (come si può vedere qui).

Il tema di default non basta

Un tema ben fatto è molto comodo e, come abbiamo appena visto, permette di andare online rapidamente e con pochissimo sforzo. Ma non è detto che così com’è riesca a soddisfare le esigenze di tutti.

Io ad esempio volevo realizzare un sito multilingua in italiano e in inglese, una funzionalità che Mundana non supporta di default.

Inoltre volevo che la Home del sito mostrasse un riassunto degli ultimi post con le miniature delle immagini di testa, ma senza che queste apparissero nelle pagine dei singoli post. Mundana gestisce correttamente la prima richiesta, ma non la seconda.

Un altro problema riguarda la paginazione: quella di default è bella, ma mostra un’unica striscia orizzontale di link a tutte le pagine generate. Quando queste sono troppe, la striscia si allarga a dismisura, finendo per sovrapporsi ad altri elementi grafici della pagina o per uscire dai margini del browser.

Infine, Mundana supporta di default il sistema di commenti Disqus, ma io preferivo una soluzione gestita in casa, evitando di appoggiarmi a servizi di terze parti che possono cambiare le regole di utilizzo o, peggio, cessare di esistere da un giorno all’altro.

Al lavoro!

Premetto che tutto il codice del tema modificato è disponibile su GitHub, all’URL https://github.com/sabinomaggi/mundana-theme-jekyll-multilang.

Paginazione

Cominciamo dalla paginazione. A partire dalla versione 3 di Jekyll (ora siamo alla 4.4.1), la paginazione è gestita dal plugin jekyll-paginate-v2. In Mundana, il codice di paginazione è integrato nel file index.html ed è molto semplice, tanto da dare problemi quando il numero di pagine del sito cresce.

Io ho spostato la paginazione in _includes/custom/paginator.html,³ facendo in modo che i link puntassero solo ad una parte delle pagine disponibili: quelle immediatamente intorno alla pagina corrente, la prima e l’ultima pagine e una pagina intermedia calcolata in base alla distanza della pagina corrente dalla prima (o dall’ultima). In questo modo la paginazione funziona correttamente anche in finestre molto strette o sui dispositivi mobili.

Sul codice c’è poco da dire: partendo dalla pagina corrente vengono determinati tutti gli altri elementi della paginazione, generando dinamicamente il codice HTML di ciascun link. Tutta la logica del codice è in Liquid, che è il linguaggio di templating usato da Jekyll. La sintassi di Liquid è un po’ astrusa e obbliga a fare qualche giochetto con le variabili, ma l’importante è che alla fine tutto funzioni.

Secondo me, la parte più interessante del codice è la prima riga, che serve per cambiare dinamicamente le stringhe di testo in base alla lingua in uso. Ma questo ci porta alla prossima sezione.

Supporto multilingue

Jekyll può gestire i siti multilingua tramite il plugin jekyll-polyglot, che però non comunica bene con il plugin di paginazione jekyll-paginate-v2,⁴ per cui mi serviva un’altra soluzione.

Polyglot è facilissimo da usare, basta aggiungere il plugin sotto la voce relativa nel file di configurazione _config.yml e definire due nuove variabili con tutte le lingue che ci interessano.

[...]

# Plugins
plugins: 
  [...]
  - jekyll-polyglot

[...]

# Polyglot
languages: [en, it, de, fr]
default_lang: en

A questo punto basta definire la lingua di ciascun post, aggiungendo nel suo front matter la variabile lang: (ad esempio, lang: en o lang: it) e il gioco è fatto.

Il front matter di Jekyll è un blocco di metadati in formato YAML inserito all'inizio di un file Markdown (.md) o HTML (.html).

Il front matter è racchiuso tra tre trattini (---) e serve a fornire informazioni su quella pagina o post, come il titolo, la lingua, il layout, e per personalizzare il comportamento delle pagine. Ad esempio:

---
title: "Benvenuto"
layout: default
permalink: /it/
lang: it
---

Quando Jekyll elabora il sito, utilizza il front matter per:

definire il template utilizzare per la visualizzazione del sito (layout: default).
personalizzare l’URL associato alla pagina (permalink: /it/).
impostare delle variabili specifiche per quel file, da usare nei layout e nei temi (lang: it). Se una data pagina o post contiene nel front matter la variabile lang:it, Polyglot potrà utilizzare questa variabile per applicare contenuti o stili specifici per la versione italiana del sito.

L’idea quindi era quella di emulare a mano il comportamento di polyglot. La prima cosa che ho fatto è stata definire nel file _config.yml due variabili analoghe a quelle usate da Polyglot,

#--- Custom localization variables ---
# Polyglot does not work well with Paginate-v2
# define these two variables instead
locales: [en, it]
default_locale: en

e aggiungere nel front matter di ciascuna pagina o post una variabile che in analogia con le variabili definite in _config.yml_ può essere locale: en oppure locale: it.

Per semplificare la gestione delle due lingue ho creato, all’interno della cartella principale _posts, due sottocartelle en e it dove inserire i post nelle rispettive lingue (in questo modo, aggiungere con sed la variabile locale giusta è una questione di pochi secondi).

Fatto questo, ho sfruttato una caratteristica specifica di Jekyll che, quando trova un file che nel nome contiene un indicatore di lingua, lo considera un’altra versione del file originale (senza indicatore), con sue variabili specifiche definite nel front matter.

In altri termini, se ho un file index.html che contiene tutto il codice necessario per costruire la pagina Home del sito e poi creo un secondo file index_it.html vuoto, ad eccezione del front matter in cui è definita la variabile locale: it, questo file index_it.html erediterà tutto il contenuto di index.html ma utilizzerà il valore della variabile locale per adattare la pagina alla lingua italiana. Questo meccanismo è spiegato molto bene in qualche pagina che ho consultato, ma purtroppo non trovo più i link relativi.

Ultimo mattoncino: quando si usa la paginazione, la variabile locale: it deve essere definita all’interno della variabile pagination: del front matter,

pagination:
    enabled: true
    locale: it

per cui tutto il codice usato per determinare in modo dinamico la lingua in cui è scritta una data pagina deve controllare sempre sia il contenuto della variabile page.locale che di page.pagination.locale,

Ovviamente bisogna adattare alla lingua anche tutte le stringhe di testo presenti nel sito. Per questo, c’è il file _data/translations.yml che contiene le traduzioni in inglese e in italiano di tutte le stringhe utilizzate.

Inutile dire che mettere a punto correttamente il meccanismo di localizzazione è stata la cosa che ha richiesto più tempo nel corso dello sviluppo di melabit.com/posts/it. Il modo in cui è stato fatto, però, consente di aggiungere una nuova lingua in pochi minuti: basta modificare la variabile locales in _config.yml, aggiungere un’altra cartella in _posts e un’altra bandierina in assets/images. Quasi quasi viene voglia di provare… 😂

Miniature e commenti

Superato lo scoglio della localizzazione, togliere la miniatura dell’immagine di testa dalla pagina dei post è stato uno scherzo. È bastato trovare le righe di codice coinvolte e commentarle e il gioco è fatto.

I commenti invece sono stati tutta un’altra storia, perfino più complicata di quella della localizzazione. E proprio ai commenti sarà destinato il prossimo articolo.

Ad esempio, proprio mentre scrivevo questo articolo, ho messo gli occhi su questo tema che non si adatta alla mia idea originale di sito, ma che forse avrebbe potuto fare lo stesso al caso mio (ma ormai non cambio). ↩︎
Jekyll è un generatore di siti statico, ma ormai anche un sito statico richiede un certo livello di dinamicità per gestire al meglio cose come le ricerche, come i commenti, e così via. ↩︎
Tutto il nuovo codice da includere l’ho messo nella cartella custom per distinguerlo, anche fisicamente, da quello originale del tema. ↩︎
Dato che diversi post di 4-5 anni fa riportano di aver usato senza problemi sia jekyll-polyglot che jekyll-paginate-v2, questo potrebbe essere un problema specifico di Mundana. Oppure è una incompatibilità venuta fuori nelle ultime versioni di Jekyll o dei due plugin. ↩︎

Da melabit a melabit: Jekyll, installazione e configurazione di base

Tue, 11 Feb 2025 06:00:00 +0000

Questo articolo non vuole essere una guida dettagliata alla installazione e configurazione di Jekyll; per quello ci sono le ottime guide riportate più sotto.¹

L’articolo è invece una raccolta commentata delle note che ho preso mentre sviluppavo melabit.com/posts/it, e sono il risultato di giorni e giorni di prove ed errori, di cambi di direzione, di letture alla ricerca del comando giusto. A me le note servivano per ricordare quello che avevo fatto e come avevo risolto i problemi che si presentavano di volta in volta. A voi potrebbero essere utili per fare tutto più in fretta e senza intoppi.

Installazione di Jekyll

Per fare delle prove con Jekyll non c’è niente di meglio che usare una macchina virtuale, magari con una versione server di Linux che carica poco il sistema principale. Una buona alternativa è un server cloud virtuale, anche economico, come UpCloud, Google Compute Engine, Amazon EC2 o similari. Per lavorare sul serio, invece, è molto più comodo e veloce usare una macchina reale, tanto più che seguendo queste istruzioni il rischio di fare danni è nullo o quasi. Io per fortuna avevo a disposizione un vecchio Mac, che mi ha permesso di provare e riprovare sapendo che, in caso di problemi, avrei potuto resettarlo facilmente.

La guida migliore per l’installazione di Jekyll è senza dubbio quella ufficiale, con istruzioni specifiche per i sistemi operativi più diffusi.

La guida per macOS è fatta bene, ma l’installazione richiede Homebrew e un buon numero di passaggi da eseguire con attenzione. Su Linux l’installazione è molto più facile, mentre su Windows la cosa migliora da fare è installare il Windows Subsystem for Linux (WSL) e poi lavorare di fatto in un ambiente Linux.²

Un dettaglio importante che manca nelle istruzioni per macOS – ma che invece è presente in quelle per Ubuntu, FreeBSD e gli altri Linux – è che, prima di eseguire il comando finale gem install jekyll (ma volendo anche prima di iniziare ad installare Jekyll), è bene aggiungere queste righe al file ~/.bashrc o ~/.zshrc (a seconda della shell usata),

#--- Install Ruby gems in the user account, e.g. in ~/.gems ---
export GEM_HOME="$HOME/.gems"
export PATH="$HOME/.gems/bin:$PATH"
#--- end ---

ed eseguire source ~/.bashrc o source ~/.zshrc per attivare le nuove variabili di ambiente (io sono rozzo e mi limito a chiudere il Terminale e a riaprirlo subito dopo).

A cosa servono quelle righe? Ad istruire il gestore dei pacchetti di Ruby, RubyGems, ad installare tutte le sue gemme,³ fra cui c’è anche Jekyll, nell’account dell’utente invece che a livello di sistema. Una cosa buona e giusta per separare l’installazione nativa di Ruby all’interno del sistema operativo da tutto ciò che installiamo noi, permettendoci di correggere gli (inevitabili) errori senza correre il rischio di intaccare le funzioni di base del sistema operativo.

A questo punto, è possibile eseguire l’installazione vera e propria di Jekyll,

$ gem install jekyll

seguita subito dopo da un’altra gemma molto utile, Bundler,

$ gem install bundler

che inspiegabilmente è stata completamente dimenticata nelle istruzioni per macOS .

Per istruire anche bundler ad installare tutto nell’account dell’utente, bisogna eseguire

$ bundle config set --local path $GEM_HOME

Infine, se stiamo usando una macchina virtuale o un server cloud e il nostro sistema operativo principale è macOS, possiamo installare anche questa gemma,

$ gem install rmate

che ci permetterà di usare TextMate, che secondo me è nel complesso il miglior editor per macOS che ci sia in circolazione, per editare i file su cui si deve mettere le mani, invece di dover usare nano, vim o emacs direttamente sulla macchina virtuale/cloud (che, avendo installata una versione server di Linux, non ha una interfaccia grafica).⁴

Il primo sito in Jekyll

Alla fine del processo di installazione di Jekyll, tutte le guide suggeriscono di creare un nuovo sito con

$ jekyll new my-new-blog
Running bundle install in [...]/my-new-blog... 
  Bundler: Resolving dependencies...
  Bundler: Bundle complete! 7 Gemfile dependencies, 30 gems now installed.
  Bundler: Use `bundle info [gemname]` to see where a bundled gem is installed.
New jekyll site installed in [...]/my-new-blog.

che crea una nuova cartella my-new-blog nella cartella corrente (i puntini fra parentesi quadre indicano la parte di percorso che dipende dal sistema operativo). Spostandosi nella nuova cartella e attivando il web server integrato in Jekyll,

$ cd  my-new-blog
$ bundle exec jekyll serve --host=0.0.0.0

potremo vedere il nostro nuovo sito all’URL http://localhost:4000 se stiamo usando una macchina reale. Se invece stiamo usando una macchina virtuale o un server cloud, dovremo puntare il browser all’URL pubblico fornitoci dalla macchina virtuale (o server cloud), utilizzando sempre la porta 4000.

Niente da dire, questa procedura è utile per verificare che tutto funzioni, e poi Minima, il tema di default, è davvero molto pulito ed elegante. Se Minima vi basta, potete chiuderla qui, sarà sufficiente dare un titolo al sito e aggiungere i contenuti e potrete partire immediatamente con il vostro nuovo blog in Jekyll.

Ma questa procedura ci dà anche una idea molto pallida di cosa si possa fare davvero con Jekyll. Perché, e questo è un limite non da poco, le funzioni di Jekyll sono strettamente integrate con i suoi temi grafici.

Jekyll e i temi grafici

Minima è un esempio di tema gem-based, installato al di fuori della cartella del sito e che, proprio per il fatto di separare nettamente i contenuti del sito dal suo aspetto grafico, può essere in teoria facilmente sostituito con un altro tema a gemma, come quello mostrato qui sotto.

Ma i temi di questo tipo sono pochi, in genere sono piuttosto minimali e, per la loro stessa natura, è più laborioso modificarli o aggiungere nuove funzioni. E quel che è peggio, spesso sono fatti per versioni ormai obsolete di Jekyll e non funzionano nelle ultime versioni.⁵

La stragrande maggioranza dei temi per Jekyll arriva invece in un formato che integra in un’unica cartella sia i contenuti che la grafica. Una cosa molto comoda quando si trova il tema giusto, ma che rende molto più complicato cambiare tema a posteriori.

Installare la maggioranza dei temi per Jekyll significa di fatto installare tutto il sito che lo contiene, dandosi poi da fare per sostituire i post e le immagini preconfezionate con i nostri post e con le nostre immagini. Di conseguenza, è preferibile prima scegliere un tema che ci piaccia e che supporti almeno una parte di quello che ci aspettiamo dal sito, e solo dopo iniziare ad estenderne le funzioni nel modo desiderato.

Ma questo sarà l’argomento della prossima puntata.

E se Jekyll non ci piace più?

Allora dobbiamo disinstallare tutto. Il modo moderno per farlo è usare questo comando,

$ gem uninstall --all --ignore-dependencies --executables --verbose

oppure, per chi ama la compattezza,

$ gem uninstall -aIxV

dove lo switch --all segnala di disinstallare tutte le gemme, mentre --ignore-dependencies permette di evitare di bloccare il processo di disinstallazione quando si disinstalla una gemma richiesta da un’altra gemma. Il terzo switch --executable serve per disinstallare gli eseguibili senza richiedere ogni volta una conferma. Infine --verbose è utile per farci spiegare per filo e per segno quello che sta succedendo.

Se avete seguito il consiglio iniziale di installare tutto nell’account utente non vi serviranno i privilegi di amministratore. Altrimenti avrete fatto male e per punizione dovrete anteporre sudo al comando di installazione.

Una volta disinstallate tutte le gemme, si potrebbe anche disinstallare ruby e i pacchetti accessori, usando Homebrew per macOS oppure il gestore dei specifico per la distribuzione Linux usata. Ma con i grandi dischi attuali, vale la pena darsi tanto da fare solo per risparmiare qualche decina di MB?

Alla prossima

L’articolo è già troppo lungo ed è meglio chiuderlo qui. Il prossimo articolo servirà per entrare nel vivo dello sviluppo di un sito con Jekyll. A presto!

A causa dell’abbondanza di documentazione, con Jekyll il vero problema è riuscire a distinguere le guide davvero utili da quelle che fanno solo perdere tempo. ↩︎
Da ora in poi non menzionerò più Windows, perché tutte le istruzioni necessarie a chi usa quel sistema operativo saranno identiche a quelle per Linux. ↩︎
Una gemma è un programma o una libreria scritta in Ruby che contiene al suo interno tutto ciò che serve per eseguirla, o per sviluppare nuovi programmi che ne sfruttano le funzioni. Le gemme vengono installate tramite il gestore dei pacchetti standard, RubyGems, il cui comando gem permette di eseguire tutti i processi di installazione, aggiornamento e disinstallazione delle varie gemme. ↩︎
Naturalmente il problema non si pone per chi è già un maestro di vim o emacs. ↩︎
E quando dico “spesso” non esagero. ↩︎

Da melabit a melabit: perché Jekyll?

Tue, 21 Jan 2025 18:00:00 +0000

– Fonte: Jametlene Reskp su Unsplash.

Come dicevo nell’ultimo post, lasciare la comfort zone di Wordpress non è stato per niente facile.

Fra doversi preoccupare solo di scrivere qualcosa di interessante, con tutto il resto gestito da una squadra di amministratori di sistema ed esperti di programmazione web, a dover fare tutto da solo c’è un abisso.

C’è voluto un bel po’ di tempo per configurare il nuovo sistema, aggiungere le funzionalità mancanti e risolvere i (tanti) problemi tecnici imprevisti. Tanto più che in parallelo continuavo a svolgere la mia normale attività lavorativa e, non dimentichiamo, dovevo pure scrivere un post ogni tanto.

Di conseguenza, la prima necessità era basare questo nuovo blog su una piattaforma stabile e affidabile, che non cambiasse pelle ogni settimana o, peggio, che scomparisse improvvisamente dalla circolazione perché lo sviluppatore si era stufato di giocare con il suo progetto.

Anche la disponibilità di una documentazione abbondante e ben fatta era fondamentale: avere guide chiare per configurare il sistema e trovare risposte rapide ai problemi (che sono inevitabili) è un aiuto enorme per non perdere giorni interi a impazzire dietro al codice.

Su queste basi la scelta era inevitabile, ed era identica a quella di tanti anni fa: Jekyll.

Perché Jekyll avrà pure tanti difetti, fra tutti la lentezza nella generazione del sito e la pesantezza del codice generato, ma esiste da ben 16 anni, viene ancora sviluppato con regolarità ma senza stravolgimenti (l’ultima release è di settembre 2024), e sul web si trovano guide su tutto ciò che può venire in mente quando si sviluppa un sito con questa piattaforma.

Del resto, non sarà certo un caso se GitHub ha scelto proprio Jekyll come piattaforma per generare un sito direttamente da un suo repository.

A suo tempo, Jekyll mi aveva tanto convinto da spingermi a scrivere tutti i 482 post del blog su wordpress.com in Markdown, con una intestazione in YAML come quella usata di Jekyll e con le immagini salvate in cartelle con lo stesso nome del post.

Su WordPress non serviva, perché tutto quello che dovevo (e potevo) fare era copiare il testo in un nuovo post, aggiungere le immagini e premere in bottone di pubblicazione (beh, in realtà è un po’ più complicato, ma ci siamo capiti).

Ma avere tutto bello e pronto nel formato giusto ha semplificato parecchio la transizione da WordPress a sito statico basato su Jekyll. Mi è bastato preparare la struttura di base, aggiungere i post e le immagini, e generare il sito per avere tutto bello e pronto (anche qui le cose sono leggermente più complicate, ma l’idea di base è quella).

Se non avessi conservato i testi originali, avrei potuto usare un plugin WordPress per esportare i post da WordPress in Jekyll (è proprio vero che esiste un plugin WordPress per qualunque cosa!). Ma il plugin non supporta i commenti, le immagini finiscono in una directory non standard e vanno spostate in quella corretta, bisogna correggere tutti i link… Alla fine, nel mio caso ci sarebbe voluto più tempo a sistemare tutto che a ripartire da zero.

Ora il lavoro di base è finito e tutte le funzioni principali del nuovo sito bene o male funzionano. A questo punto diventa più facile esplorare delle soluzioni alternative e, si spera, più performanti di Jekyll. In cima alla mia lista ci sono Bridgetown, che è un fork di Jekyll che vale la pena approfondire, e Middleman, che mi incuriosisce parecchio anche se non so bene il perché!

Ci sarà da divertirsi.

Da melabit a melabit: addio WordPress, ciao Jekyll

Thu, 02 Jan 2025 06:00:00 +0000

– Immagine generata dall’IA di Microsoft Designer.

Undici anni fa, quando ho iniziato a scrivere in questo spazio personale, non avrei mai pensato di rimanere per tutto questo tempo su WordPress.com, una piattaforma di blogging comoda ed affidabile, che però è sempre stata poco adatta al mio modo di lavorare. Con il tempo ho imparato a convivere con questi limiti, ma l’idea di cambiare non mi ha mai abbandonato.

Sin dall’inizio avevo ben chiaro quale piattaforma alternativa avrei voluto utilizzare. Qualche anno dopo ho riesaminato le alternative disponibili e i passi da fare in una lunga serie di articoli che alla fine si è conclusa con… un nulla di fatto, forse perché non ero convinto al 100% della decisione presa.

Del resto, non è facile abbandonare la comfort zone di una piattaforma con la quale hai avuto per tanti anni esattamente zero problemi, per imbarcarsi in una nuova avventura in cui bisogna gestire tutto in prima persona.

Qualche mese fa, però, è arrivata la decisione di Automattic, l’azienda che gestisce il software open source WordPress e tutti i prodotti derivati, di condividere di default tutti i contenuti presenti su WordPress.com con “terze parti”, cioè di fatto con i generatori di testi basati sull’Intelligenza Artificiale (ChatGPT e compagnia bella, per capirci), sempre affamati di nuovi testi con cui affinare il loro addestramento.¹ A quel punto non ci potevano più essere tentenamenti.

Come se non bastasse, poco dopo Matt Mullenweg, il fondatore di WordPress, ha dato di matto (nomen omen), evidenziando come, nonostante WordPress sia il il sistema di gestione dei contenuti (CMS) open-source più diffuso al mondo, il controllo esercitato in maniera centralizzata e sempre più dittatoriale rischia di mettere in dubbio il futuro aperto e trasparente della piattaforma.

E allora il dado è tratto! C’è voluto tanto tempo e anche tanto lavoro, ma da oggi questo piccolo blog ha una casa tutta sua, melabit.com/posts/it, dove poter sperimentare con una libertà molto maggiore di quella concessa finora. Vediamo come va.

Il nuovo sito è ancora un oggetto in divenire, la struttura di base è quella ma nei prossimi mesi ci saranno di sicuro modifiche e aggiustamenti. La prima cosa da fare è espandere la sezione in inglese, che al momento contiene solo una manciata di post, con link mancanti o ancora riferiti agli articoli originali in italiano. Vorrei anche aggiungere un sistema di notifica dei nuovi post.

Nel frattempo segnalatemi senza scrupoli nei commenti tutto ciò che non funziona o che funziona male.

Per i dettagli e gli aspetti tecnici della transizione vi rimando invece ai prossimi post.

Resta inteso che tutti i vecchi contenuti e i commenti rimarrano disponibili su melabit.wordpress.com. Almeno finché Mullenweg non mi caccia… 🤣🤣🤣🤣🤣

Perché è vero che è possibile rifiutare la condivisione dei propri contenuti, e l’ho fatto anch’io ma, è altrettanto vero che bisogna scegliere esplicitamente di non condividere i propri dati e non il contrario, come sarebbe più normale. E comunque non è affatto detto che questi contenuti non vengano razzolati lo stesso. ↩︎

Da melabit a melabit: conclusioni

Wed, 03 Jul 2019 06:00:00 +0000

“Dopo tutto questo parlare di hosting, domini, provider e cloud, si può sapere cosa hai deciso alla fine di fare per questo blog?”

Sono consapevole di contraddire quello che avevo scritto alcuni anni fa ma, dopo aver soppesato tutte le alternative, mi sono reso conto che la cosa migliore da fare in questo momento era cambiare il meno possibile, per cui ho deciso di continuare ad usare WordPress, ospitato questa volta su una piattaforma di hosting tradizionale.

Per ora niente generatori di siti statici come Jekyll (che nonostante tutto continua a piacermi tantissimo), Grav o Hugo, niente CMS alternativi, magari più veloci ed efficienti di WordPress. Passare dalla “gabbia” dorata di Wordpress.com – nella quale devo solo occuparmi di scrivere e a tutto il resto ci pensa Automattic – ad una piattaforma autogestita è già abbastanza complicato per volersi imbarcare in una transizione ancora più radicale. Qualche anno fa sarebbe stato più facile, ma in questo momento è un rischio che non voglio (e che non ho nemmeno il tempo di) correre.

– Fonte: Amador Loureiro su Unsplash.

Senza dimenticare che negli ultimi tre anni ho avuto modo di sperimentare a fondo la stabilità e l’affidabilità di WordPress gestendo un sito (semi)professionale con un carico di lavoro nettamente superiore a quello prodotto da questo blog e con editor multipli, interventi sul forum, un gran numero di utenti registrati, infinite richieste di supporto tecnico nonché (potevano mancare?) innumerevoli attacchi al sito. WordPress si è comportato benissimo, perché buttare via questa esperienza sul campo?

Non nascondo di essere stato attratto a lungo dall’ipotesi “WordPress + Raspberry Pi”, mi intrigava moltissimo l’idea di gestire tutto autonomamente, ma poi ho deciso che il gioco non valeva la candela e ho lasciato perdere.

Ormai è tutto pronto o quasi. Il nome c’è, l’hosting pure, ho anche scelto un tema nuovo e più adatto (spero!) a mostrare i contenuti disponibili, manca solo il tocco finale, la pressione del classico bottone di avvio. Se non ci sono imprevisti ~~luglio~~ settembre dovrebbe essere il momento buono.

Ma niente è per sempre e non è detto che, dopo aver completato questa prima transizione, non decida di farne un’altra più radicale adottando Jekyll, la piattaforma che considero ancora la più vicina al mio spirito di programmatore, seppur solo part-time.

Da melabit a melabit, la serie completa degli articoli

Da melabit a melabit: andare sul cloud

Mon, 24 Jun 2019 06:00:00 +0000

– Fonte: Daniel Falcão su Unsplash.

Il cloud computing è ovunque e ci sono decine di servizi diversi che ci permettono di usare un computer virtuale situato da qualche parte nel mondo come se fosse il computer fisico che abbiamo sulla scrivania. In questo campo i grossi calibri sono Amazon AWS, Google Cloud, Microsoft Azure, Red Hat OpenShift (in rigoroso ordine alfabetico), ma ci sono anche i servizi offerti da fornitori di servizi di hosting come SiteGround, DreamHost o Netsons oppure da provider più orientati al mondo degli sviluppatori come Digital Ocean, Codenvy, Heroku, UpCloud.

Descrivere tutto quello che fanno questi servizi è impossibile, le opzioni e le configurazioni sono tante e tanto diverse che cercare di orientarsi fra le varie possibilità fa letteralmente girare la testa (provate a districarvi nel sito di Amazon AWS e poi ditemi). Ma rimanendo a quello che ci interessa qui, tutti questi servizi mettono a disposizione un computer virtuale ospitato sull’onnipresente cloud dove possiamo installare un sistema operativo (generalmente Linux) e tutte le applicazioni necessarie per realizzare il nostro sito web.

Anche in questo caso valgono considerazioni analoghe a quelle fatte una settimana fa per il Raspberry Pi, con l’ovvia differenza che ora non dobbiamo preoccuparci degli aspetti legati all’hardware, visto che la macchina fisica e l’indirizzo IP sono forniti dal fornitore di servizi di cloud computing (in realtà la nostra macchina fisica non esiste nemmeno, il nostro computer virtuale sul cloud è solo un contenitore Docker ospitato insieme a mille altri su un server di un qualche datacenter).¹ A noi rimarranno comunque alcuni oneri importanti, come ad esempio quello di aggiornare e mantenere in sicurezza il sistema operativo e i pacchetti software che utilizziamo per realizzare il sito web.

Ma oltre a non doverci preoccupare di gestire l’hardware, il vero vantaggio di ospitare il sito su un servizio di cloud computing è quello di essere liberi di utilizzare per il sito il software che preferiamo, senza i vincoli stabiliti dai normali fornitori di servizio di hosting che normalmente danno la possibilità di scegliere solo fra un certo numero di applicazioni predefinite, selezionate fra quelle più popolari.

Se per il nostro sito vogliamo usare un CMS come Wordpress, Drupal, CMS Made Simple o Kirby non fa nessuna differenza, anzi un servizio di hosting tradizionale può essere preferibile perché ci permette di concentrarci sui contenuti, lasciando tutta la gestione del sito al fornitore del servizio di hosting. Ma se vogliamo utilizzare dei CMS meno diffusi come Ghost o Postleaf oppure dei generatori di siti statici come Jekyll, Hugo, Grav o Hexo,² la soluzione cloud ci offre una flessibilità impareggiabile, nettamente maggiore di quella offerta da un normale servizio di hosting.

Tutto questo però ha un prezzo da pagare. Un servizio di hosting decente può costare anche solo qualche decina di euro all’anno, per usufruire di un computer (anche se solo virtuale) nel cloud la cifra da sborsare è nettamente maggiore, dell’ordine di almeno 20-30 euro al mese (con variazioni enormi fra le offerte dei diversi provider).

Prima di scegliere fra hosting e cloud bisognerà quindi valutare realisticamente quello che vogliamo fare con il sito web (un blog personale è ben diverso da un sito di commercio elettronico), tenendo bene in conto dell’impegno richiesto per mantenerlo in forma e delle competenze tecniche necessarie per gestire un servizio mediamente complesso come questo. Trascurare quest’ultimo punto in particolare potrebbe significare dover spendere cifre nettamente maggiori per rimediare ai problemi di configurazione, o peggio di sicurezza, che potrebbero danneggiare gravemente non solo il sito ma anche la nostra immagine. In questo campo i costi non sono solo quelli che si vedono sul cartellino del prezzo.

Da melabit a melabit, la serie completa degli articoli

Il nostro unico problema sarà quello di associare l’indirizzo IP al nome di dominio (ma in genere lo stesso fornitore del nome di dominio ci mette a disposizione gli strumenti per farlo da soli). ↩︎
Dei primi tre ne ho scritto parecchio anche qui, chi vuole può leggere i vecchi articoli su Grav, Hugo e Jekyll. ↩︎

Script per tutti i giorni: semplici modifiche alle stringhe di testo

Fri, 23 Nov 2018 18:00:00 +0000

– Foto: telwink su Flickr.

Succede più spesso di quanto mi renda conto. Devo rinominare dei file, modificare un testo o fare altri pasticci con i miei documenti. Potrei usare una delle tante applicazioni ad hoc fatte per fare proprio quello. Ma perché perdere tempo ad installare ed imparare ad usare l’ennesima applicazione se con il Terminale posso fare prima (e meglio)?

Basta qualche comando ben piazzato nel Terminale, a volte qualche piccolo script in bash o in python, e si possono fare cose bellissime con poco sforzo.

E una volta fatte, perché tenerli per se e non condividerli, magari proprio qui? L’impulso iniziale me l’ha dato Federico “frix” Morchio durante una discussione sul canale Goedel di Slack gestito dal sempre ottimo Lucio Bragagnolo (aka… oops, noto anche come Lux, Loox e tanti altri alias).

Attenzione! Questo e i futuri post sull’argomento non saranno delle introduzioni a bash, a python, al Terminale di macOS (tendo sempre a dimenticare che non si chiama più OS X!), per quelle ci sono un sacco di ottime guide in rete. Chi vuole fare in fretta può iniziare leggendo la mia piccola guida a bash di qualche anno fa, Script di shell in OS X e magari anche Compleanno con permessi, la ripresa di un vecchio post sull’ormai defunto Ping che di fatto mi ha fatto iniziare l’esperienza di blogger.

Cominciamo con un antipasto veloce, una cosa apparentemente inutile (o quasi), ma che serve a dare una idea delle potenzialità di bash e di come, partendo da un’idea semplice, si possa trasformarla a poco a poco in qualcosa di più pratico e adatto ad un uso quotidiano.

Manipolare i nomi dei file

La prima cosa che faccio quando inizio a scrivere un nuovo post è creare un file Markdown con i metadati (titolo, data di pubblicazione, categoria e tag, chi usa Jekyll o Octopress sa di cosa parlo), a cui assegno un nome temporaneo. Una volta deciso il titolo definitivo, rinomino il file in un modo più razionale, in modo che possa ritrovarlo facilmente.

Per farlo seguo la convenzione sui nomi dei file di Jekyll,¹ secondo la quale il nome del file deve essere scritto come YYYY-MM-DD-titolo-del-post.md, dove YYYY indica l’anno, MM il mese e DD il giorno di pubblicazione (espressi rispettivamente con quattro e due cifre) e parole e numeri vanno separati con un trattino invece che con uno spazio. Sembra una cosa inutilmente complicata, ma permette di tenere ordinati i file in base alla data anche quando se ne modifica il contenuto in un secondo tempo. E comunque, evitare di utilizzare gli spazi nei nomi dei file è ancora oggi la cosa più razionale da fare nei sistemi basati su Unix come macOS.

Per la data non ci sono problemi, nei metadati è già scritta nel formato giusto, per cui è sufficiente copiarla ed incollarla direttamente nel nome del file tramite il Finder. Ma il titolo? Potrei usare il Finder anche per il titolo, inserendolo dopo la data nel nome del file e sostituendo a mano gli spazi con i trattini. Però è facile sbagliare, soprattutto quando il titolo è lungo. Ancora più facile è non essere consistenti, usando ogni volta una forma leggermente diversa e mandando a pallino i vantaggi dati dall’utilizzare nomi di file ben definiti.

E poi, vuoi mettere il divertimento di farlo fare a bash?

Un pezzo alla volta

Prendiamo come esempio il titolo di un post di qualche mese fa, “La privacy al tempo dell’Internet of Things: gran finale”. Per trasformare il titolo originale in una sequenza di parole separate da trattini è sufficiente lanciare il Terminale ed eseguire il comando

$ echo "La privacy al tempo dell'Internet of Things: gran finale" | sed "s/ /-/g"

dove echo scrive la stringa nel Terminale e la invia tramite il | (pipe) a sed, che si occupa di cercare tutti gli spazi e di sostituirli con un trattino, ottenendo

La-privacy-al-tempo-dell'Internet-of-Things:-gran-finale

Non male, ma ci sono due o tre cosette da sistemare.

Problema numero 1 (banale). Il formato di Jekyll prevede implicitamente che il nome del file sia scritto tutto in minuscolo. Personalmente trovo che questa forma sia più gradevole, ma è anche utile a semplificare e a rendere univoco l’ordinamento dei file (una fissazione, lo so, ma quando si maneggiano tantissimi file ogni giorno diventa una cosa fondamentale per lavorare meglio). Si può fare così

$ echo "La privacy al tempo dell'Internet of Things: gran finale" | tr "[:upper:]" "[:lower:]"

dove tr trasforma i caratteri maiuscoli ([:upper:]) in minuscoli ([:lower:]), ottenendo

la privacy al tempo dell'internet of things: gran finale

Domanda #1: cosa succede se nel comando precedente si usa tr "[:lower:]" "[:upper:]"?

Problema numero 2 (importante). Nei nomi dei file è preferibile usare solo lettere non accentate, numeri e alcuni caratteri di separazione: trattino, underscore e (se proprio dobbiamo) spazio. Se possibile è meglio evitare di usare il punto, che normalmente serve per separare il nome del file vero e proprio dall’estensione (caratteristica che è stata usata parecchio per distribuire file contenti virus ma che apparivano legittimi). Tutto gli altri caratteri devono essere rigorosamente evitati, perché spesso hanno significati speciali per il sistema operativo e creano solo guai.

Per togliere la punteggiatura possiamo usare la stessa tecnica di sopra,

$ echo "La privacy al tempo dell'Internet of Things: gran finale" | sed "s/[[:punct:]]//g"

dove in questo caso sed cerca tutti i caratteri di punteggiatura ([[:punct:]]) e li sostituisce con… niente (cioè li toglie), ottenendo in uscita

La privacy al tempo dellInternet of Things gran finale

Problema numero 3 (specifico). Il comando di prima rimuove anche gli apostrofi (che è sempre bene evitare di mettere nei nomi dei file, perché potrebbero dare problemi su sistemi operativi meno liberali di macOS).² Piuttosto che buttarli via, è preferibile però sostituirli con un trattino, usando ancora una volta sed

$ echo "La privacy al tempo dell'Internet of Things: gran finale" | sed "s/'/-/g"

che da in uscita

La privacy al tempo dell-Internet of Things: gran finale

Mettiamo tutto insieme

Usare bash (o qualunque altra shell di Unix) è un po’ come usare il Lego dove, mettendo insieme dei piccoli mattoncini di forme e colori diversi, si può costruire una portaerei (o quasi). Con bash si prendono dei semplici comandi come quelli visti prima, si mettono nell’ordine giusto, si collega l’output di un comando con l’input di quello successivo tramite il | (pipe), e alla fine si riescono a fare delle cose anche piuttosto sofisticate.

In questo caso, il comando

$ echo "La privacy al tempo dell'Internet of Things: gran finale" | tr "[:upper:]" "[:lower:]" | sed "s/'/ /g" | sed "s/[[:punct:]]//g" | sed "s/ /-/g"

genera la stringa

la-privacy-al-tempo-dell-internet-of-things-gran-finale

pronta per essere utilizzata come nome del file.

Domanda #2: Cosa succede se cambio l’ordine dei comandi? Perché questo è l’ordine migliore per convertire un titolo nel formato desiderato?

Domanda #3: Perché nel primo sed questa volta ho sostituito l’apostrofo ' con uno spazio (mentre nella descrizione del problema numero 3 avevo usato un trattino)?

Chi ha avuto la pazienza di leggere fin qui, si starà chiedendo che senso abbia complicarsi la vita con il Terminale e con bash, quando è molto più veloce modificare il titolo a mano nel Finder.

Tutto vero, ma è altrettanto vero che il post è stato più che altro una scusa per introdurre due comandi come sed e tr, molto utili ma anche molto poco conosciuti. E poi, partendo da questa base si possono costruire delle cose molto più utili, ma questo lo vedremo la prossima volta.

Revisioni

3-12-2018: Corretta una incongruenza nel testo originale, nel quale veniva usato una volta sed e un’altra tr per rimuovere i caratteri di punteggiatura.

Che poi è praticamente la stessa convenzione che usa Wordpress per generare i nomi dei post. ↩︎
La gestione generale dei caratteri accentati nei nomi dei file è un problema molto più complesso, che è meglio rimandare ad un post specifico sull’argomento, ammesso che ci sia interesse per l’argomento. ↩︎

Primo WordPress Meetup a Bari

Sat, 14 May 2016 06:00:00 +0000

Ieri ho partecipato al 1° WordPress Meetup, organizzato a Bari presso l’area di Ricerca del CNR. Il racconto dettagliato della manifestazione lo lascio agli organizzatori, Nicola ‘Koolinus’ Losito e Francesco Cozzi.

Da parte mia voglio solo dire di aver passato un pomeriggio molto piacevole, in una atmosfera amichevole e rilassata. Non mi sarei mai aspettato di trovare in una città come Bari così tanti sviluppatori professionisti, appassionati e competenti. Ho sentito parlare di strumenti, plugin ed applicazioni di cui non avevo la più pallida idea.

Intanto devo studiare, per essere più pronto la prossima volta, fra un mese, quando si entrerà nel vivo delle applicazioni per (e con) WordPress. Forse però è meglio che non mi faccia sfuggire che mi piace Jekyll, altrimenti non mi invitano più. :D

And the winner is...

Wed, 31 Dec 2014 06:00:00 +0000

Riassunto delle puntate precedenti. Wordpress.com è un’ottima piattaforma di blogging, ed ha il grosso vantaggio di liberare l’utente da tutte le preoccupazioni riguardanti la manutenzione del proprio blog. Non è però una piattaforma che si adatta bene al mio modo di lavorare, e ne ho già scritto diffusamente alcuni mesi fa. Però cosa scegliere fra le varie tipologie disponibili: wiki o CMS o piattaforme di blog, siti statici o siti dinamici? Per vari motivi mi sono orientato verso un generatore di siti statici, un programma che prende una serie di file di testo, di immagini e di documenti e li converte in un sito web completo secondo un tema grafico predefinito. In rete ci sono letteralmente decine e decine di generatori di siti statici ed il loro numero cresce molto rapidamente: erano 289 all’inizio di agosto, oggi sono ben 388! Come orientarsi in questo marasma? Basandomi su una lista di caratteristiche irrinunciabili (almeno per me), ne ho provati e scartati parecchi, buon ultimo Hugo, promettente ma rivelatosi alla fine piuttosto immaturo.

In realtà avevo deciso subito. Tutte le prove che ho fatto mi sono servite solo ad esplorare il più possibile il territorio, a provare le alternative e a verificarne i vantaggi e gli svantaggi.

La scelta più ragionevole, date le premesse, era solo una: Jekyll.

Per due ragioni fondamentali: prospettive di sviluppo del codice a medio-lungo termine e disponibilità di documentazione abbondante e di buona qualità. Senza queste due caratteristiche non si va avanti. Tutti gli altri generatori di siti web statici possono anche apparire interessanti, ma impallidiscono se li si confronta a Jekyll su questi due aspetti.

Tanto per fare un esempio: che senso avrebbe avuto scegliere uno dei tanti progetti giocattolo di un singolo programmatore? Può anche essere eccellente, ma quante sono le probabilità che continui ad essere sviluppato fra uno, due, tre anni? Magari fra sei mesi il programmatore si stanca e passa ad altro, non rispondendo più alle richieste di supporto o di correzione degli inevitabili errori. Che si fa, allora? Oppure: come si può cercare di configurare ed estendere il sistema prescelto se non esiste della buona documentazione, se magari l’unico modo per capire cosa fa il programma è analizzarne i sorgenti (auguri)?

Infatti fra i 388 generatori di siti statici elencati oggi da Static Site Generators, ben 171 non sono aggiornati da almeno un anno e 225 da sei mesi. E solo una settantina ha ricevuto un aggiornamento nell’ultimo mese. Insomma, ci sono circa 320 progetti censiti che in realtà sono morti, inutili, da scartare a priori.

I primi due generatori di siti web statici nella lista di StaticGen, Jekyll e il suo derivato Octopress, hanno ricevuto insieme su GitHub più di un terzo delle stelle – cioè delle manifestazioni esplicite di interesse nel progetto – guadagnate da tutti i 67 progetti elencati nel sito.¹ Non sarà che sono ritenuti così interessanti perché sono fatti bene e sono (relativamente) facili da usare e da metterci le mani?

Ora rimane solo da rimboccarsi le maniche, configurare Jekyll e trasportare il blog sulla nuova piattaforma.

Ma prima di allora, auguro a tutti coloro che pazientemente seguono questo blog un 2015 felice e, se possibile, migliore dell’anno che ci stiamo lasciando alle spalle!

Immagino che StaticGen censisca solo i progetti sviluppati attivamente. Probabilmente non è un caso che, se si considerano attivi solo i progetti aggiornati nell’ultimo mese, i numeri di Static Site Generators e di StaticGen concidano. Sarebbe interessante verificare se i progetti sono veramente gli stessi. ↩︎