webdesign jekyll cms blog

Benvenuto Jekyll!

Esattamente un anno fa avevo iniziato a imbastire una specie di blog, basato sul noto CMS Drupal. Amo quel sistema, per svariati motivi, e l'ho usato per molti progetti, sia per lavoro che per hobby. Un progetto no-profit di cui sono orgoglioso è http://360kayak.org. Ma non sto qui a discutere sulle qualità indiscusse di Drupal.

Ma allora perché il sito che vedete non è fatto in Drupal? Anzi, sembrerebbe fatto in html grezzo, come i siti degli anni ottanta, quando gif animate di colori discutibili facevano da padrone. Cos'è successo?

Prima di tutto, ho deciso di cambiare, il che fa sempre bene. Il sospetto che un CMS basato su php e una cascata di hooks e callbacks non facesse proprio al mio caso l'ho avuto testandolo nel mio piccolo server domestico (un vecchio Asus eeebox con l'hard disk leeeeentissimo). Caricare una pagina necessitava di qualche secondo, non tanto per la dimensione dei file (html5 striminzito e pochissime immagini) ma per il tempo dovuto al processamento del contenuto, dei template, dei moduli, dei blocchi e chi più ne ha più ne metta.

Poi una malsana idea stava facendo capolino: mettere il sito in un sistema embedded, magari un Arduino o un Raspberry. Farci girare il php non è impossibile, ma oltre a essere limitato, esula dal compito che dovrebbe avere un microprocessore di quelle dimensioni. Comunque il discorso è finito li (per il momento) ma mi ha spinto a sperimentare in una direzione diversa dal solito.

Il mio grande amore dell'anno scorso è stato GIT, che per qualche oscuro motivo guardavo con sospetto, sicuro del fatto che Subversion lo sapevo usare e ormai avevo tutti i progetti controllati con SVN da molti anni. Vabbé, anch'io alla fine sono caduto nella trappola (per fortuna!) e ho portato tutti i vecchi progetti (personali e aziendali) nel nuovo sistema GIT.

Ma cosa c'entra un sistema di controllo versione con un CMS?

Mi son promesso di non usare un database di tipo SQL, né un linguaggio server-side tipo php (per i motivi di prima). La soluzione? Alla vecchia maniera: file html statici. Mi permette di usare un sistema di controllo versione che gestisca l'intero sito, senza dover attuare strani trucchi per controllare anche il contenuto del database (per non parlare dei file cache di Drupal, nascosti in posti improbabili).

Wow! Finalmente un controllo versione sul sito! Mi sembra di aver scoperto l'acqua calda :(

Comincio a interrogarmi su quali svantaggi potrebbe portarmi questo sistema... Ahimè, son parecchi:

  • devo tornare a scrivere i post in html (con Drupal usavo Markdown)
  • se aggiungo una voce al menu devo modificare tutti i file o trovare almeno uno script che lo faccia al posto mio (con php sarebbe bastato un include)
  • devo aggiungere a mano i link in ogni dove quando posto un nuovo articolo

Senza parlare dell'ideazione grafica e la creazione di css, layout etc... ma quello è un problema che c'è anche con in soliti CMS, se si aborrono i temi predefiniti.

Non ce la farò mai!

Poi mi chiedo "Vorrai mica che sono l'unico ad aver bisogno di una cosa del genere? Provo a creare una serie di script che mi aiutano a gestire la cosa, poi serviranno anche a qualcun altro!". Cerca un attimo come fare e tlac! Decine di sistemi che lo fanno! Scopro addirittura che GitHub ha un servizio chiamato GitHub Pages che funziona proprio così. E usa Jekyll.

L'ho trovato!

Jekyll Logo

Eh sì, questo programmino, anzi "Ruby Gem" fa proprio tutto quello che volevo, addirittura supporta il mio tanto amato Markdown e sembra fatto apposta per essere usato con Git. Incredibile! Mi è bastato imbastire il sito con il mitico initializr, ritoccare due file e portare i (pochi) vecchi post da database a file. Fatto!

Poi ho scritto questo articolo, mo lo pubblico, ché son le due di notte ed è ora di dormire! Appena ho due minuti nei prossimi giorni, scrivo bene bene come ho fatto.

Ti è piaciuto l'articolo? Condividilo! Commentalo!

comments powered by Disqus