Grav on Melabit

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. ↩︎

Grav, bello ma impossibile

Thu, 28 May 2015 06:00:00 +0000

KOoLiNuS, uno dei più attenti lettori di questo blog, mi ha suggerito di dare una occhiata a Grav, un moderno generatore di siti web statici,

follemente veloce, ridicolmente facile e favolosamente potente

L’ho provato per qualche giorno, con la prospettiva di verificare se potesse essere una alternativa a Jekyll, il generatore di siti web statici che ho deciso da tempo di usare per questo blog al posto di Wordpress (non chiedetemi però quando avverrà).

Gli sviluppatori non esagerano, Grav è veramente bello e facile da usare.

Mi piace in particolare la possibilità di scaricare dei siti preconfezionati, contenenti il sistema base, il tema grafico e alcuni plugin già configurati, che implementano i tipi più comuni di sito web, dal blog al sito di fotografie, dal sito di presentazione di un prodotto a quello di e-commerce.

Installazione e uso di Grav

Premessa: tutti gli esempi seguenti verranno eseguiti nella directory Sites, contenuta nella Home dell’utente. Una volta creata questa directory dal Finder o dal Terminale, si noterà che l’icona della cartella ha impresso il simbolo di Safari. Per parecchie versioni di OS X infatti (fino a Lion se ricordo bene), Sites è stata una delle directory predefinite presenti nella Home degli utenti di OS X. Nonostante Apple abbia rimossa da tempo questa directory, io continuo a trovarla molto comoda per gestire dei siti web di prova.

Grav può essere installato sia dalla linea di comando che scaricando un file zip contenente un sito già pronto e perfettamente funzionante.

Nel primo caso, basta lanciare il Terminale, spostarsi nella directory Sites ed eseguire in sequenza i comandi

	$ cd ~/Sites
	$ git clone https://github.com/getgrav/grav.git
	$ cd grav/
	$ bin/grav install

con i quali (1) si seleziona la directory di lavoro, (2) si scarica il codice di Grav dal sito del progetto, (3) ci si sposta nella directory grav/ del sito e (4) si installano il tema grafico e i plugin predefiniti.

Completata l’installazione, si può provare rapidamente che tutto funzioni eseguendo, sempre dalla directory grav/ il comando

$ php -S localhost:8000

e puntando il proprio browser all’indirizzo web

http://localhost:8000

per visualizzare in tutta la sua magnificenza grafica il sito web di default generato da Grav.

Sinoti che il comando php -S localhost:8000 esegue un server web basilare integrato in PHP, uno degli strumenti fondamentali per sviluppare applicazioni web, presente di default in OS X. Ovviamente nulla impedisce di usare al suo posto apache, il principe dei server web, presente anch’esso di default in OS X. Purtroppo è diventato difficile convincere apache ad usare la directory ~/Sites in aggiunta a quella predefinita, /Library/WebServer/Documents/.

Fra tutte le directory contenute in Grav, la più importante è la directory user/, che contiene le pagine del sito e i relativi plugin, temi e file di supporto.

Le pagine del sito sono contenute in user/pages/ e sono scritte in Markdown, uno degli strumenti più interessanti per scrivere testi per il web, che utilizza una sintassi molto più semplice e leggibile del classico codice HTML.

Il modo più semplice per aggiungere una nuova pagina al sito è spostarsi nella directory user/pages/

cd user/pages/

copiare la directory 01.home in, diciamo, 02.nuova_pagina

cp -p -r 01.home 02.nuova_pagina

e modificare opportunamente il contenuto del file default.md presente all’interno della directory 02.nuova_pagina.

Il titolo della pagina, definito nella intestazione del file default.md verrà usato per aggiungere automaticamente una nuova voce al menu del sito web. Il prefisso numerico associato al nome di ciascuna directory stabiliscono l’ordine con cui compaiono le pagine nel menu del sito.

Se si vuole installare uno dei siti preconfezionati, bisogna invece scaricare il file zip relativo in ~/Sites/. Come già detto, contiene oltre al sistema base i plugin necessari ad implementare le funzionalità desiderate e il tema grafico previsto dagli sviluppatori per quel particolare tipo di sito web.

Una volta scompattato il file zip e rinominata la directory generata con un nome più conveniente (in questi casi non c’è bisogno di essere troppo creativi, grav va benissimo), basta spostarsi all’interno della directory del sito e lanciare il server web PHP

$ cd ~/Sites/grav
$ php -S localhost:8000

per attivare il nuovo sito web, visibile come già visto prima all’indirizzo

http://localhost:8000

Aggiornamento e installazione di plugin e temi

Il comando di Terminale gpm (grav package manager) permette di aggiornare il sistema e di installare i plugin e i temi di Grav. Il comando gpm deve essere eseguito posizionandosi nella directory grav/ del sitoe specificando la directory bin che contiene l’eseguibile.

I principali comandi implementati in gpm sono molto semplici:

$ bin/gpm index

che mostra la lista completa dei plugin e dei temi disponibili,

$ bin/gpm info nome_plugin
$ bin/gpm install nome_plugin
$ bin/gpm uninstall nome_plugin

che permettono rispettivamente di ottenere informazioni, installare o disinstallare un particolare plugin o un tema di Grav.

Inoltre il comando

$ bin/gpm self-upgrade

aggiorna Grav all’ultima versione disponibile, mentre

$ bin/gpm update

aggiorna i plugin o i temi già installati. Quest’ultimo può essere anche seguito dal nome del plugin (o del tema) da aggiornare.

Documentazione

La documentazione di Grav è fatta molto bene, anche se è piuttosto succinta e un po’ carente nei dettagli.

Purtroppo, data la relativa giovinezza del progetto, mancano ancora i tutorial online creati dagli utenti, che molte volte sono più utili della documentazione “ufficiale” per imparare ad usare un software come questo.

Molte volte, infatti, i programmatori non riescono a spiegare al meglio il funzionamento dei software che sviluppano, si perdono in dettagli inutili e tralasciano gli aspetti fondamentali. Gli utenti finali sono spesso più bravi e, avendo imparato ad usare il software da zero, si rendono conto meglio delle difficoltà che si incontrano nell’uso quotidiano del programma.

Bello ma impossibile

Tutto bene, allora? L’ho già detto, Grav è veramente bello e interessante, una opzione allettante se si vuole mettere su un nuovo sito web. Ammetto che se partissi da zero potrei perfino considerare di usarlo al posto di Jekyll.

Ma non lo farò.

Innanzi tutto perché sono ormai andato troppo avanti con Jekyll, ho letto decine di articoli e di tutorial, ho una idea piuttosto chiara di quello che voglio fare e non mi va di buttare a mare il lavoro fatto finora.

Inoltre Grav va benissimo finché si sta dentro i recinti stabiliti dagli sviluppatori. Ma comincia a mostrare di essere ancora piuttosto immaturo se si prova ad uscire, anche di poco, da questi recinti.

La struttura delle directory e dei file che costituiscono un sito è troppo rigida. Voglio creare una nuova pagina di un sito web statico? Devo andare in user/pages/ e aggiungere una directory con un nome qualunque, che deve però iniziare con un numero. In questa directory devo creare un file default.md che contiene il testo della pagina e il cui titolo definisce la voce di menu del sito web associata alla pagina.

Posso usare un’altro nome per il file al posto di default.md? Assolutamente no. Come faccio se ho già una serie di file contenenti il testo delle pagine? Devo rinominarli uno ad uno e distribuirli in ciascuna delle directory numerate. E se le pagine contengono già dei link che le collegano le une alle altre, non sarò mica obbligato a cambiare i link uno a uno? Probabilmente si.

E se voglio aggiungere delle pagine statiche ad un blog già pronto, ad esempio il bellissimo Notepad? Le pagine statiche devono andare in user/pages/, quelle del blog in user/blog/. Se provo ad aggiungere in user/ la directory pages/ contenente una o più pagine statiche, non c’è verso, continuerò comunque a vedere solo i post del blog.

Perfino i plugin e i temi installati da Terminale nel 50% dei casi non funzionano, senza che Grav dia delle indicazioni utili per capire il perché.

Sono sicuro che c’è un modo per superare questi problemi, ma io non ci sono riuscito e la documentazione non aiuta. Meglio aspettare che Grav maturi un po'.