Cms on Melabit

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: fare da sé?

Tue, 18 Jun 2019 06:00:00 +0000

– Fonte: Glen Carrie su Unsplash.

Non avrei mai immaginato che sarebbe passato un anno intero prima di riuscire a scrivere ancora di trasferimento del blog, hosting e così via. Nel mezzo c’è stata una transizione lavorativa improvvisa e quasi inaspettata oltre che vari impegni familiari improrogabili e non sono riuscito a fare di più. Ma abbiamo già perso troppo tempo, quindi meglio venire subito al dunque.

Fare da soli

Abbiamo già visto come scegliere il servizio di hosting, cioè l’azienda (o provider) che gestisce l’infrastruttura hardware e software su cui si basa il nostro sito web e che lo rende raggiungibile attraverso la rete. Un provider ha un certo costo, che per un blog personale o un sito web di un professionista o di una piccola azienda può andare da un minimo di 20-30 euro a qualche centinaia di euro all’anno, a seconda del provider, dei servizi scelti e del livello di supporto desiderato. A fronte di questa spesa assolutamente ragionevole, utilizzare un provider permette di delegare la gestione di tutta l’infrastruttura hardware, l’aggiornamento del sistema operativo e del software su cui si basa il sito, la sicurezza, il backup e così via, a degli esperti professionisti (si spera!), lasciando a noi solo il compito di gestire i contenuti veri e propri del sito.

Ma… e se volessimo lo stesso fare da soli? Magari perché vogliamo imparare a gestire un server. Oppure perché vogliamo provare diverse soluzioni prima di decidere come realizzare definitivamente il nostro sito. Perché siamo restii a far gestire il nostro sito da un provider che domani potrebbe scomparire. Per semplice curiosità o perfino perché vogliamo riutilizzare come server web un vecchio computer lasciato a marcire in cantina.

Cominciamo dalla fine. Se sperate di poter fare quello che era così comune agli albori del web, prendere un computer ormai vecchio e poco performante e fargli gestire il vostro piccolo sito web, mi dispiace ma dovete ricredervi. Il web di oggi è molto diverso da quello di 15-20 anni fa, è infarcito di JavaScript, di contenuti dinamici, di CSS, di decine di altre tecnologie completamente sconosciute anche solo cinque o sei anni fa. Un computer vecchio, con un processore obsoleto, poca RAM, con un hard-disk lento come una lumaca, non ce la fa più a gestire in modo efficiente il web odierno, a meno di non ostinarsi a realizzare un sito vecchio (anzi, vecchissimo) stile, con le pagine scritte in HTML puro e collegate manualmente l’una all’altra. Un sito come quelli di GeoCities o giù di lì.

Raspberry Pi

Per fortuna per un sito web non serve nemmeno una workstation superpotente con processore Xeon e decine di gigabyte di RAM, è sufficiente un computer moderno anche se a basso costo.

E fra i computer a basso (o meglio, bassissimo) costo disponibili sul mercato, il più interessante è senza alcun dubbio il Raspberry Pi, il microcomputer grande poco più di un pacchetto di sigarette (si può dire ancora?) che ha prodotto una vera e propria rivoluzione fra i cosiddetti maker, che lo usano per i progetti più svariati e a volte incredibili, dai semplici sistemi domestici di videosorveglianza o intrattenimento a progetti avanzati di monitoraggio ambientale, robotica o intelligenza artificiale.

Se il Raspberry Pi va bene per queste applicazioni, a maggior ragione può essere usato per implementare un NAS, un servizio cloud personale o un server web casalingo (dove con questo termine intendo indicare in generale un blog personale o un sito di un professionista o di una piccola azienda).

Io ho provato a trasferire questo blog sul mio Raspberry Pi 3 B e ha funzionano tutto perfettamente, molto meglio di quanto mi sarei potuto aspettare. Per farlo, ho installato Raspbian (la versione di Debian GNU/Linux specifica per il Raspberry Pi) scegliendo la versione Lite senza interfaccia grafica,¹ ho installato e configurato Wordpress seguendo queste istruzioni stringate ma molto chiare e infine ho trasferito tutto il contenuto del blog usando il plugin di esportazione installato di default in Wordpress. Più o meno due ore di lavoro, andando piano e controllando bene quello che stavo facendo.

I risultati sono andati oltre le più rosee aspettative: la velocità di accesso al blog era indistinguibile da quella garantita dall’hosting attuale su Wordpress.com e anche l’utilizzo del backend, cioè del sistema di gestione di Wordpress (articoli, file allegati, plugin, utenti e così via), non faceva assolutamente rimpiangere quello a cui sono abituato ormai da tanti anni.

A chi volesse provarci a sua volta e non ha già un Raspberry Pi a disposizione, consiglio di acquistare il modello più recente, il Raspberry Pi 3 B+ (costa 32 euro su Amazon, qualcosa di più su PiHut), e una scheda micro SD veloce da almeno 16-32 GB, tenendo conto che la velocità della scheda è molto più importante della capienza.

Pro e contro

Il Raspberry Pi è perfetto 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.

Il Raspberry Pi non ha nemmeno bisogno di essere collegato ad un monitor e ad una tastiera e mouse, ma può essere gestito senza problemi da remoto tramite l’interfaccia ssh (naturalmente bisogna avere dei rudimenti di conoscenza del Terminale, cosa comunque necessaria per chiunque voglia imparare a gestire Linux e un sistema server). In più è molto piccolo, messo in un case come questo o questo fa la sua figura e può essere tenuto tranquillamente in bella vista sulla scrivania o accanto al router.

Ma anche se, come io stesso ho potuto verificare, funziona molto bene con Wordpress e probabilmente anche con qualunque altro CMS o sistema statico che ci possa venire in mente di installare, usare un Raspberry Pi come sistema definitivo sul quale ospitare un server web (ma anche un NAS o un cloud casalingo) richiede di curare attentamente una serie di dettagli niente affatto trascurabili. È importante tenere presente che, anche se l’articolo è focalizzato sull’uso del Raspberry Pi, le considerazioni che seguono valgono in parte per qualunque computer che possiamo voler usare come server web.

Il processore del Raspberry Pi genera poco calore e non ha bisogno di un dissipatore o di una ventola. Ma il microcomputer è progettato per essere usato per qualche ora e poi spento, cosa succede se lo teniamo acceso 24 ore su 24? Ci sarà bisogno di montare un dissipatore metallico o una ventola, oppure di usare un case metallico adatto a dissipare il calore prodotto dal processore (io ho fatto così).

Le schede SD utilizzate dal Raspberry Pi come memoria di massa sono notoriamente fragili e poco adatte ad un uso prolungato. Ci sono soluzioni che permettono di utilizzare un disco esterno meccanico o SSD (o anche due) al posto della scheda SD, sono molto interessanti ma richiedono un minimo di manualità e di esperienza per installare e configurare il tutto.
Alimentare un server con un alimentatore da parete e il suo fragile connettorino microUSB ha un livello di affidabilità decisamente scarso. Se poi aggiungiamo un disco esterno, è facile che la potenza fornita dall’alimentatore USB diventi insufficiente. Molto meglio usare un alimentatore ad hoc, magari insieme ad un case adatto ad ospitare tutti i componenti come questo (si veda anche la figura qui sotto). Purtroppo, mettere insieme una cosa del genere richiede un livello di manualità e di esperienza ancora più elevato.

– Fonte: The Stuff We Build, Raspberry Pi Web Server.

Sempre in tema di alimentazione elettrica, per usare il Raspberry Pi come server è indispensabile aggiungere una batteria tampone, adatta a tenere il Raspberry Pi alimentato anche in assenza di corrente elettrica, meglio se associata ad un piccolo UPS per il router (se va via la corrente di casa e il router si spegne, tenere alimentato il Raspberry Pi non serve comunque). Il solo UPS può anche andare bene per alimentare i due dispositivi, bisogna solo controllare che abbia una potenza sufficiente ad alimentare il router ed il Raspberry Pi per diverse ore.
Un server web ha bisogno di un nome di dominio e di un indirizzo IP associato. Per il nome di dominio c’è poco da fare, va richiesto necessariamente ad una azienda intermediaria (registrar) come Register.it, GoDaddy, Cloudflare, Google Domains e costa circa 10-15 euro all’anno (spesso molto meno il primo anno). Al nome di dominio bisogna associare l’indirizzo IP del nostro sito, che in genere è gestito direttamente dal provider del servizio di hosting. Se vogliamo fare da soli dobbiamo riuscire ad ottenere in qualche modo un indirizzo IP personale. Purtroppo i normali provider telefonici che usiamo per accedere ad internet da casa o dall’ufficio, Wind/Infostrada, Vodafone o simili, ci assegnano degli IP dinamici, che possono cambiare nel tempo, mentre a noi serve un IP statico, da associare una volta per tutte al nome di dominio. Scordatevi i servizi di DNS dinamico come DynDNS, OpenDNS o NoIP e simili, questi possono andar bene per accedere di tanto in tanto alla videosorveglianza o ai dispositivi IoT di casa, non certo per un server web. L’unico provider che conosca che fornisce facilmente un IP statico ai clienti è Fastweb, basta chiederlo ed è anche gratuito.
Da non dimenticare la questione dell’aggiornamento e della messa in sicurezza del sistema operativo e dei pacchetti software che utilizziamo per realizzare il sito web. Linux è intrinsecamente un sistema operativo sicuro, ma ciò non toglie che bisogna preoccuparsi di aggiornarlo frequentemente, nonché di aggiornare tutti i pacchetti software di contorno, in particolare quelli utilizzati per il sito web, in modo da evitare non solo che il sito finisca sotto il controllo di qualche script kiddie che non ha di meglio da fare, ma soprattutto che il nostro microcomputer diventi una base di partenza per i malintenzionati della rete per effettuare attacchi mirati a più vasta scala.

Conclusioni

Come è facile notare le mie perplessità sull’uso del Raspberry Pi come server web casalingo (così come di qualunque altro computer usato per questo scopo) sono soprattutto di natura hardware, e in fondo riflettono il fatto che questo microcomputer nasce come sistema sperimentale o di sviluppo, non come sistema affidabile da tenere in funzione 24 ore su 24.

Anche dal punto di vista puramente economico non mi sembra una grande idea: fra Raspberry Pi, UPS, case e accessori vari si rischia di superare facilmente il costo di un servizio di hosting pluriennale, con in più i tanti grattacapi descritti.

Il Raspberry Pi invece è imbattibile come sistema didattico ed è di sicuro uno dei migliori acquisti che si possano fare in questo momento, una specie di ritorno ai tempi eroici degli anni ‘80 quando chi comprava un computer come il Commodore 64, lo Spectrum o, per i più fortunati, l’Apple II doveva rimboccarsi le maniche e imparare i rudimenti della programmazione e magari anche dell’elettronica per usarlo al meglio. È una vera fortuna che quei tempi siano tornati, oggi.

Da melabit a melabit, la serie completa degli articoli

La versione ideale per un server web al quale, dopo la configurazione iniziale, si accede quasi esclusivamente tramite l’interfaccia web. ↩︎

È proprio una sporca faccenda, WordPress.com!

Mon, 23 Apr 2018 18:00:00 +0000

È successo anche a me, e proprio come l’avevano descritto Roberto e katsiematsi.

Giorni fa mi è arrivata una email che segnalava la pubblicazione di un nuovo post su Socket 3, uno dei blog che seguo di più in questo momento, che come Melabit si appoggia al servizio gratuito di WordPress.com.

In genere leggo i post sul Mac, ma questa volta il titolo mi aveva incuriosito e ho toccato il link per leggerlo subito sul telefono. Poi per qualche motivo mi sono distratto, forse per una telefonata, forse per una email arrivata sull’account “istituzionale”. E quando ho guardato di nuovo lo schermo del telefono ho trovato questo,

insieme all’inevitabile SMS che mi informava che, fortunello!, ero stato iscritto al servizio Every Play, 5 euro alla settimana per ricevere qualche giochino idiota.

Iscritto senza volerlo, è chiaro, e senza aver accettato nulla. Non è la prima volta che succede a me o ai miei familiari, ma in genere succede con degli SMS fasulli, mentre questa volta la colpa sta di certo nell’aver visualizzato il post su WordPress.com.

Di questo sono sicuro al 100%: ho toccato il link, si è aperto il browser alla pagina del post, che a sua volta ha caricato la pagina di Every Play, come si vede chiaramente nella prima immagine, dove il numero 2 in alto a destra è il numero di pagine aperte nel browser.

Poiché mi sono distratto, non sono sicuro se è comparso sul telefono qualche avviso a tempo che mi ha iscritto dopo tot secondi di inattività. Ma se anche fosse andata così (improbabile), sta di fatto che mi sono ritrovato iscritto ad un servizio a pagamento, inutile e costoso, senza aver mai accettato esplicitamente nulla!

È chiaro che ho annullato immediatamente l’iscrizione, cosa confermata dal secondo SMS mostrato qui sotto.

Ora, a parte la seccatura e i 5 euro rubati, quello che è successo è stata una vera fortuna,¹ perché dimostra oltre ogni dubbio che c’è davvero qualcosa che non va nel modo in cui WordPress.com gestisce la pubblicità inserita nei blog, almeno quando si usa lo smartphone. Ho provato in tutti i modi, senza riuscirci, di far comparire pubblicità “cattiva” su Melabit usando i browser che ho sul Mac e sull’iPad, mentre la pistola fumante si trovava sul telefono.

A ben pensarci è naturale, mettendo annunci truffaldini sul telefono si possono sottrarre immediatamente soldi dal credito della SIM mentre con le altre piattaforme bisogna usare metodi più visibili, con i quali è più difficile portare a termine la truffa.

Quello che è meno naturale è che WordPress.com non riesca a prevenire fattacci come questo che, sono sicuro, saranno stati segnalati da tantissimi utenti di tutto il mondo.

Ed è stata una vera fortuna anche avere la presenza di spirito di fare gli screenshot proprio mentre le cose stavano succedendo. ↩︎

Da melabit a melabit: introduzione

Mon, 16 Apr 2018 06:00:00 +0000

Come promesso, con questo post inizia la descrizione quasi in tempo reale del passaggio del blog da WordPress.com ad un servizio di hosting più flessibile.¹

Come ho già scritto tempo fa, WordPress.com offre un servizio impeccabile, comodissimo per chi vuole iniziare ad avere una presenza sul web. Il servizio è affidabile e ragionevolmente veloce, gli aggiornamenti sono automatici, praticamente non bisogna occuparsi di nulla tranne che di scrivere. È veramente difficile chiedere di più ad un servizio gratuito come questo.

Il vero limite di WordPress.com, che tutto sommato è anche la sua forza, è la mancanza di flessibilità. Con l’account gratuito non si possono installare altri plugin oltre a quelli previsti da Automattic, l’azienda che gestisce lo sviluppo e la commercializzazione della piattaforma di blogging (open source) più diffusa al mondo.

Una cosa comprensibile per motivi di sicurezza e affidabilità, ma che naturalmente dopo un po’ risulta troppo limitante, perché impedisce di estendere le funzioni del blog oltre i confini ristretti stabiliti da Automattic.

Idem per i temi. WordPress.com ne offre parecchi, sia gratuiti che a pagamento e ad un prezzo più che onesto, ma oltre quelli non si può andare, prendere o lasciare.

Infine c’è la questione della pubblicità, di cui ho scritto di recente, con annessi servizi di profilazione di ciò che i frequentatori del blog fanno online. Forse quello che è successo ad alcuni lettori può essere considerato un evento eccezionale o particolarmente sfortunato. Ciò non toglie che la presenza di annunci pubblicitari alla fine degli articoli, pur se giustificabile,² falsa un po’ troppo l’immagine del blog, e lo mette quasi sullo stesso piano di quelle decine e centinaia di siti che ospitano contenuti raffazzonati alla bell’e meglio con il solo scopo di guadagnare dagli annunci che ne infarciscono le pagine.

Per tutte queste ragioni è arrivata l’ora di cambiare, passando ad un servizio di hosting che consenta di gestire in proprio la piattaforma e di utilizzare finalmente il nome di dominio personale, melabit.com/posts/it, lasciato in sospeso per troppi anni.

In linea di principio, la cosa più semplice sarebbe quella di utilizzare uno dei piani a pagamento offerti da WordPress.com. Purtroppo dei tre piani disponibili i primi due, Personale e Premium, offrono (molto) poco di più rispetto al piano gratuito e praticamente servono solo per rimuovere la pubblicità e per usufruire di un dominio personalizzato e dei temi premium. Mentre il piano Business, l’unico che consente di installare tutti i plugin e i temi che si desidera, a 25 euro al mese è decisamente troppo caro per un piccolo blog come questo, costruito nei ritagli di tempo e con il solo scopo di mettere a disposizione qualche contenuto di buona (si spera!) qualità.

L’unica opzione ragionevole è quindi di cercare un servizio di hosting con un buon rapporto qualità/prezzo e una affidabilità provata, e che naturalmente permetta di far girare la piattaforma software scelta per il blog.

Ma questa è una storia che riguarda la prossima puntata.

P.S. Questo post l’ho scritto a mano in macchina, mentre aspettavo mia figlia. Una esperienza molto vecchio stile ma anche molto efficiente, ci ho messo meno di mezz’ora a buttarlo giù. Perché a mano posso scrivere malissimo (io stesso a volte riesco a capire a fatica quello che ho scritto) ma molto più velocemente che con la tastiera. Perché tanto so di dover copiare il testo sul computer e quindi non mi preoccupo troppo degli errori. Perché tutte le correzioni e gli spostamenti del testo di vedono chiaramente, e si continua a vedere anche il testo originale non corretto (una specie di controllo di versione rudimentale). Una esperienza da ripetere (e di cui riparlare, più avanti).

Da melabit a melabit, la serie completa degli articoli

Ma anche più complesso da gestire. ↩︎
Automattic dovrà pur cercare di recuperare, almeno in parte, i costi del servizio gratuito. ↩︎

È una sporca faccenda, WordPress.com: profilazione

Sat, 07 Apr 2018 06:00:00 +0000

Mentre cercavo di far comparire le inserzioni pubblicitarie alla fine dei miei post, mi sono reso conto di quanti servizi di profilazione (tracker) esterni a WordPress.com mettano il naso nelle pagine del blog.

Ci sono naturalmente gli onnipresenti social, collegati tramite i pulsanti di condivisione, e c’è Google Analytics, che lo stesso WordPress.com utilizza per misurare i parametri di accesso al sito.

Ma poi ci sono una serie di servizi dai nomi più oscuri ma significativi – DoubleClick di Google, Adapt.tv e Advertising.com, entrambe costole di AOL e quindi di Verizon, AppNexus, che applica tecniche di machine learning per rendere “la pubblicità digitale più predittiva ed intelligente”, Criteo, che “aiuta a costruire esperienze personalizzate per gli acquirenti”, SkimLinks, ovvero “fai soldi con i tuoi contenuti”, BidSwitch e Demandbase di cui vi risparmio la filosofia di marketing – che analizzano tutto quello che facciamo con il browser, le ricerche effettuate, i link seguiti, le pagine che leggiamo, per costruire una immagine sempre più precisa di noi, delle nostre abitudini e di quello che ci piace, con un solo e unico obiettivo: sapere tutto di noi per presentarci degli annunci pubblicitari mirati e quindi sempre più efficaci.

Tenendo conto di tutto, l’home page di Melabit viene tracciata da ben 16-17 servizi di profilazione diversi, con un forte impatto negativo nella velocità di accesso al sito, come ci si accorge facilmente se si prova ad usare uno dei tanti strumenti di analisi delle prestazioni disponibili in rete, come WebPagetest.org, GTmetrix o Pingdom.

Tanto per fare un confronto, ecco quello che compare guardando l’home page di un sito semi-istituzionale, sempre in WordPress ma ospitato su un servizio di hosting a pagamento, che ho messo su da un anno con alcuni colleghi. Niente servizi di profilazione opachi e indesiderati, solo Google Analytics, che sarà pure invasivo, ma che almeno è stato attivato appositamente per contare gli accessi al sito.

Forse possiamo ancora a difenderci.

È una sporca faccenda, WordPress.com

Tue, 03 Apr 2018 18:00:00 +0000

Mentre leggevano uno degli ultimi articoli pubblicati, Roberto e katsiematsi (😃) si sono ritrovati abbonati senza volerlo ad uno di quegli stramaledetti servizi a pagamento di loghi, suonerie o giochini insulsi, veri e propri furti consentiti da una legislazione perlomeno distratta.

Con l’iPhone è un attimo, arrivati in fondo all’articolo basta toccare senza volere l’annuncio cattivo per ritrovarsi alleggeriti di parecchi euro (e con il fastidio di doversi anche dare da fare per annullare l’abbonamento).

Non avevo idea che WordPress.com, la piattaforma gratuita che ospita il blog, consentisse inserzioni di questo tipo. L’interfaccia di amministrazione del sito mi avvisa che ci potrebbero essere degli annunci pubblicitari alla fine dei post, ma non dice nulla sul tipo di annunci mostrati, né tantomeno mi consente di sceglierli o di vietarli, a meno di non passare ad uno dei piani a pagamento (tante grazie, preferisco fare da me).

Ma anche senza essere amministratore, Firefox (il browser che uso normalmente) non mi fa vedere gli annunci pubblicitari, che vengono bloccati a priori dall’ottimo uBlock Origin, una delle estensioni indispensabili per qualunque browser.

Solo se disattivo esplicitamente l’estensione vedo finalmente gli annunci alla fine degli articoli, in questo caso assolutamente benigni.

Nonostante usi la modalità di navigazione anonima, ho la netta impressione che WordPress sappia lo stesso chi sono, sarà un caso ma gli annunci che mi fa vedere sembrano dedicati proprio a me. Le cose non cambiano se uso Safari o Chrome sul Mac o iOS. Con Android invece la pubblicità è più generica, forse perché lo uso poco e il sistema ha meno informazioni sulle mie abitudini di navigazione.

Sia quel che sia, è arrivata l’ora di abbandonare WordPress.com. Un po’ di pubblicità mi sta bene, è ragionevole che WordPress.com voglia guadagnare qualcosa in cambio del servizio di hosting gratuito che mette a disposizione, ma un conto è vedere un annuncio con Cannavacciuolo, un altro è farsi incastrare senza volere da qualche servizio a pagamento ai limiti della legalità.

Ci pensavo da tempo, anzi da troppo tempo, l’ho anche scritto più volte, ma alla fine ha sempre prevalso la pigrizia. Anche perché il piano gratuito di WordPress.com sarà anche limitato (e credetemi, lo è!) ma evita di dover affrontare un sacco di fastidi collegati alla gestione del sito, dagli aggiornamenti allo spam agli inevitabili problemi di sicurezza.

Ma come dicevo prima, il dado è tratto, fra poco sarà attivo melabit.com/posts/it, un dominio che ho acquistato da anni ma che ho lasciato dormire per tanto, troppo tempo. Sarà anche una buona occasione per raccontare quasi in diretta i dettagli della transizione che, come ho già verificato, non sarà facilissima e nemmeno indolore.

Come sempre, stay tuned.

RapidWeaver 7 in anteprima

Tue, 24 May 2016 11:15:00 +0000

Oggi, anzi contemporaneamente alla pubblicazione di questo post, esce la nuova versione di RapidWeaver, la versione 7, che secondo il comunicato stampa di Realmac Software, è il maggiore aggiornamento mai rilasciato del programma.

Qualche giorno fa ho ricevuto in anteprima una copia per la stampa (la stampa? :o ) di RapidWeaver 7 (da ora in poi RW7) con relativo numero di licenza, e quindi mi sono sentito moralmente obbligato a giocherellare un po’ con il programma.

Dico subito che RW7 mi piace. Non userei mai RW7 per questo blog e nemmeno per un sito che viene aggiornato frequentemente. Per questo tipo di siti sono molto più adatti i generatori automatici di contenuti, statici o dinamici a seconda dei gusti.

Ma per un sito vetrina di una piccola attività professionale o per presentare un software, un ebook, un video autoprodotto, ammetto che dopo aver provato RW7 ci penserei due volte prima di non usarlo.

Perché per una volta è vero quello che dice la pubblicità, con RW7 è possibile – e perfino divertente – creare un sito web da zero senza conoscere l’html e le tecnologie web. Alcuni temi predefiniti di buona qualità e con un numero notevole di opzioni di configurazione permettono di dare al sito un look originale e allo stesso tempo vicino ai canoni stilistici del momento.

Quando si crea il primo progetto in RW7 compare una pagina vuota che suggerisce di guardare il video Getting Started per imparare ad usare il programma. Sono stato tentato di farlo, ma poi ho deciso di verificare se fosse possibile usare RW7 senza saperne niente. Ed in effetti è possibile: in una mezz’ora di lavoro ho creato senza troppi intoppi un semplice sito di prova con alcune pagine contenenti testo e immagini, una galleria di fotografie e perfino una mappa del sito.

Ho usato troppo poco RW7 per riuscire a fare una recensione completa del programma o una guida introduttiva all’uso di RW7. Voglio però menzionare alcune cose che non mi piacciono o che sembrano dei veri e propri bachi, sperando che vengano corrette nelle prossime release del programma.

Manca un modo visuale per creare dei link fra le diverse pagine del sito, ad esempio trascinando l’icona di pagina di destinazione dalla finestra laterale sinistra direttamente nell’editor. Può darsi che leggendo la documentazione o guardando i tutorial si riesca a farlo, ma di sicuro la cosa non è possibile con il semplice drag-and-drop, sia usando l’editor markdown che quello visuale.
Considerazioni analoghe valgono per l’inserimento delle immagini nelle pagine del sito.
La versione attuale integra ben 56 temi diversi. La maggior parte però ha un look piuttosto datato e non è nemmeno adattabile ai dispositivi mobili. Dubito che qualcuno possa voler creare oggi un sito con i temi Aqualicious, Birthday o School. Meglio allora includere pochi temi ben fatti, configurabili e responsivi, adatti ad essere visualizzati sia su un computer che su tablet e smartphone.
A questo proposito, alcuni i temi responsivi che ho provato hanno un bug fastidioso: passando alla visualizzazione per iPhone o iPad, il banner in cima alla pagina si restringe correttamente in orizzontale ma non in verticale, finendo per risultare troppo alto (e fastidioso) per lo schermo relativamente piccolo dell’iPhone o dell’iPad in modalità landscape.

Tirando le somme, sono convinto che RapidWeaver 7 sia un buon acquisto. Costa una cifra decente, 90 euro (o 40 euro per l’aggiornamento), può essere installato su due Mac e si ha una garanzia soddisfatti o rimborsati di ben 30 giorni. Non mi sembra nemmeno che ci siano limitazioni sul numero di siti gestibili con una singola licenza.

Per il professionista o il piccolo imprenditore che voglia sviluppare in casa un sito di presentazione della propria attività, RW7 costa di sicuro molto meno di uno sviluppatore professionista, che non farebbe molto meglio di quanto fatto automaticamente dal programma.

Per un sito più sofisticato, ad esempio un sito di commercio elettronico, comincio ad avere qualche dubbio: bisogna acquistare un certo numero di plugin, metterli insieme e far funzionare il tutto, un’operazione che può costare più del programma stesso e che probabilmente non è alla portata dell’utente medio, per di più con poco tempo a disposizione.

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

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'.

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

Hugo, la prova

Sun, 28 Dec 2014 06:00:00 +0000

Massimiliano vene scostumato. Cioè… niente, lo so… È proprio il nome che è scostumato. Perché Massimiliano… Per esempio, questo ragazzo sta vicino alla mamma… questo ragazzo si muove per andare a qualche parte? La mamma prima di chiamare Mas-si-mi-lia-no, il ragazzo già chissà dove è andato, chissà cosa sta facendo! Non ubbidisce, perche è troppo lungo! Invece Ugo, quello come sta vicino alla mamma e sta per muoversi: Ugo! Il ragazzo non ha nemmeno il tempo di fare un passo. Ugo!, e deve tornare per forza, perche lo sente, il nome. – Massimo Troisi, Ricomincio da tre (1981)

Sono passati diversi mesi dalla mia (quasi) promessa di provare approfonditamente Hugo, uno dei generatori di siti web statici più promettenti. Finalmente sono riuscito ad avere un po’ di tempo libero da lavoro e famiglia per installare e provare Hugo, ed ecco qui le mie impressioni.

Lo dico subito: Hugo non mi è piaciuto. Il primo impatto è buono, non lo nego, ma appena ho cominciato ad usarlo con un sito di test mi sono accorto che presenta delle notevoli debolezze, almeno rispetto alle mie idee circa la futura implementazione di questo blog.

Installazione

Hugo è facilissimo da installare. La pagina Hugo Releases contiene il codice di Hugo compilato per le diverse piattaforme. L’ultima versione di Hugo per i Mac recenti è hugo_0.12_darwin_amd64.zip (i Mac hanno sempre usato processori Intel, chissà perché la versione a 64 bit per OS X è etichettata con il suffisso amd64), ma va comunque benissimo anche la versione a 32 bit, hugo_0.12_darwin_386.zip, compatibile anche con i Mac Intel più vecchi.

Una volta scaricato il file .zip, bisogna scompattarlo e copiare l’eseguibile hugo_0.12_darwin_amd64 in /usr/local/bin o preferibilmente in ~/bin. Per evitare di dover scrivere ogni volta un comando così lungo, consiglio di rinominare l’eseguibile in hugo o, meglio, di creare un soft-link al file originale.

Da Terminale e supponendo di aver già scaricato il file .zip nella cartella Downloads

$ cd Downloads
$ unzip hugo_0.12_darwin_amd64.zip
$ cd /usr/local/bin
$ sudo cp -p ~/Downloads/hugo_0.12_darwin_amd64/hugo_0.12_darwin_amd64 .
$ ln -s hugo_0.12_darwin_amd64 hugo

Se si vuole invece installare Hugo in ~/bin non serve usare il comando sudo

$ cd Downloads
$ unzip hugo_0.12_darwin_amd64.zip
$ cd ~/bin
$ cp -p ~/Downloads/hugo_0.12_darwin_amd64/hugo_0.12_darwin_amd64 .
$ ln -s hugo_0.12_darwin_amd64 hugo

Per chi usa Homebrew, l’installazione è ancora più semplice. È sufficiente eseguire da Terminale

$ brew install hugo

che, oltre ad Hugo, installerà automaticamente il compilatore Go e i sistemi di controllo di revisione Bazaar e Mercurial.

Un sito di prova

Hugo permette di creare automaticamente la struttura di default di un sito, da cui partire per ulteriori personalizzazioni ed aggiunte. Spostiamoci in una directory del nostro account, ad esempio Documenti, e creiamo il sito testhugo con il comando

$ cd Documenti
$ hugo new site testhugo

La struttura del sito di default è molto semplice [1^],

$ tree testhugo
testhugo/
├── archetypes
├── config.toml
├── content
├── layouts
└── static
4 directories, 1 file

contiene solo il file di configurazione config.toml e le quattro directory standard del sistema. Fra queste, la più importante è content, che contiene i file originali delle pagine e dei post del sito in formato markdown ovvero, prendendo a prestito un termine tipico della programmazione, i sorgenti del sito.

Tutte le operazioni successive vanno eseguite da Terminale tramite il comando hugo seguito dalle relative opzioni. Il comando deve essere eseguito necessariamente dall’interno della directory del sito

  $ cd Documenti/testhugo
  $ hugo [opzioni]

Un sito web non serve a niente se non ci sono dei contenuti. Hugo ha un comando per creare una nuova pagina del sito. Eseguendo

 $ hugo new chi-sono.md
 /Users/.../Documenti/testhugo/content/chi-sono.md created

Hugo crea il file chi-sono.md nella directory content,

$ tree testhugo/
testhugo/
├── archetypes
├── config.toml
├── content
│   └── chi-sono.md
├── layouts
└── static

4 directories, 2 files

e aggiunge automaticamente stato, titolo e data di creazione (in formato ISO8601/Zulu) nel frontespizio (front matter) del file.

+++
draft = true
title = "chi-sono"
date = 2014-12-27T21:19:56Z
+++

Il frontespizio di default è in formato TOML (identificabile dal fatto che le variabili sono racchiuse fra una coppia di linee contenenti la sequenza +++), ma in alternativa possono anche essere usati i formati YAML e JSON più diffusi.

Ovviamente il contenuto vero e proprio della pagina deve essere inserito a mano, con un editor di testo.¹ Editiamo il file chi-sono.md, aggiungendo le righe seguenti

+++
draft = true
title = "about"
date = 2014-05-20T10:04:31Z
+++

### Chi sono

Io sono. Io chi sono? Il cielo è primordialmente puro ed immutabile mentre le nubi sono temporanee. Le comuni apparenze scompaiono con l'esaurirsi di tutti i fenomeni. Tutto è illusorio privo di sostanza, tutto è vacuità.

Io sono. Io chi sono?

Per creare una pagina in una directory contenuta all’interno della directory principale content, dobbiamo scrivere il percorso completo al file markdown della pagina, relativamente alla directory content. Quindi

$ hugo new cartella/annidata/nuova-pagina.md

crea il file nuova-pagina.md, contenuto nella directory content/cartella/annidata/.

Un esempio particolare di questo meccanismo è costituito dai post di un blog, che vanno obbligatoriamente inseriti nella directory content/post/. Il comando

$ hugo new post/un-post.md
/Users/.../Documenti/testhugo/content/post/un-post.md created

crea il nuovo post un-post.md, inserendolo nella directory content/post/. Di conseguenza, la struttura del sito diventa

$ tree testhugo/
testhugo/
├── archetypes
├── config.toml
├── content
│   ├── chi-sono.md
│   └── post
│       └── un-post.md
├── layouts
└── static

5 directories, 3 files

Anche in questo caso valgono le considerazioni fatte prima: Hugo crea automaticamente il frontespizio del post, a cui naturalmente va poi aggiunto il contenuto vero e proprio.

Hugo integra anche un semplice server web. Non è quindi necessario installare o configurare un server web completo, come apache o nginx, per visualizzare le pagine web create dal sistema.

Una volta definiti i contenuti del sito, basta eseguire il comando

$ hugo server --buildDrafts

per convertire i sorgenti in markdown nelle pagine html del sito, che saranno visibili puntando il browser all’indirizzo http://localhost:1313. L’opzione --buildDrafts istruisce Hugo a convertire in html anche le pagine ancora in formato draft (o bozza), cioè quelle che contengono nel preambolo la riga draft = true. Questa opzione è utilissima quando si effettuano delle prove, ma non dovrebbe mai essere usata per un sito vero.

Il processo di conversione dei sorgenti in pagine html è velocissimo: con il mio sito di test contenente tutti i sorgenti di questo blog la conversione è praticamente immediata. Anzi, una delle caratteristiche principali di Hugo e una delle ragioni per cui è stato sviluppato in origine è proprio la sua grande efficienza nel convertire i sorgenti in markdown in file html, anche nel caso di siti contenenti migliaia di documenti.

Un po’ di stile

Se proviamo ad eseguire il comando hugo server --buildDrafts otterremo un sito funzionale ma assolutamente povero dal punto di vista grafico.

Per fortuna Hugo permette di installare facilmente un gran numero di temi predefiniti, con cui si può cambiare facilmente l’aspetto grafico del sito. Per farlo basta eseguire una volta per tutte

$ cd Documenti/testhugo		# per spostarsi all'interno della directory del sito
$ git clone --recursive https://github.com/spf13/hugoThemes themes
Cloning into 'themes'...
remote: Counting objects: 83, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 83 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (83/83), done.
...

che installa nella directory del sito tutti i temi disponibili alla pagina hugoThemes. Dopo l’installazione la struttura del sito diventa

$ tree testhugo/
testhugo/
├── archetypes
├── config.toml
├── content
│   ├── chi-sono.md
│   └── post
│       └── un-post.md
├── layouts
└── static
└── themes
    ├── LICENSE
    ├── README.md
    ├── herring-cove
    │   ├── ...
	├── html5
    │   ├── ...
	...
	└── tinyce
        ├── ...
		└── theme.toml
	
183 directories, 625 files

In alternativa, si può scaricare il file zip presente nella pagina web hugoThemes, scompattarlo e copiare tramite il Finder o il Terminale la directory themes in Documenti/testhugo/.

A questo punto possiamo provare a ricreare il sito web di prova usando uno dei temi appena installati

$ hugo server --theme=hyde --buildDrafts

e caricando di nuovo la pagina http://localhost:1313 nel browser. Ora il sito appare decisamente meglio.

Tutto bene?

In sintesi: Hugo è facile da installare, ha una struttura piuttosto semplice, dispone di parecchi temi preconfezionati, crea automaticamente le nuove pagine e i nuovi post. Tutto bene, allora?

Nemmeno per sogno.

La maggior parte dei temi non funzionano – o funzionano soltanto dopo una serie di modifiche ad-hoc più o meno complicate – nonostante siano distribuiti come i temi più o meno ufficiali di Hugo. È vero che il progetto è giovane e in rapida evoluzione, ma credo che sarebbe stato decisamente meglio distribuire ufficialmente solo i temi già pronti per essere usati out-of-the-box, cioè quelli che non hanno bisogno di configurazioni o modifiche particolari.

Disporre di un comando specifico per creare nuove pagine o nuovi post è utile solo fino ad un certo punto. Innanzi tutto perché non può essere utilizzato da chi usa spesso l’iPad per preparare i propri post (non guardate me, io per ora l’ho fatto solo in estate). E poi, qual’è il vero vantaggio – in termini di tempo o di facilità d’uso – di creare automaticamente un nuovo file in markdown con qualche riga di frontespizio preconfezionata, quando poi la parte inevitabilmente più lunga e complicata del lavoro è quella di scrivere il contenuto della pagina (o del post)?

Per il frontespizio si possono usare ben tre formati diversi, TOML, YAML e JSON. Già così la cosa è abbastanza confusionaria, ma questo è il meno. Quello che è veramente grave è che nella documentazione di Hugo, a parte questa brevissima pagina, non si trova nessun dettaglio sui tre formati del frontespizio, sulle variabili predefinite, su come crearne di nuove o su come passare da un formato all’altro. Può anche darsi che le informazioni ci siano ma che io non sia riuscito a trovarle, ma allora perché tenerle così ben nascoste nei meandri del sito del progetto?

E qui arriviamo al punto dolente più importante: la documentazione. La documentazione su Hugo è veramente scarsa, tutto si risolve più o meno nelle poche pagine che costituiscono il sito del progetto.

In rete non si trova praticamente nessun tutorial indipendente, nessuna pagina di trucchi o di consigli, nessun informazione del tipo io ho fatto così. Tutto quello che c’è è più o meno un copia e incolla dal sito ufficiale di Hugo, come questo post o quest’altro. Questa pagina sembra ben fatta, ma in fondo è solo una sintesi in un documento singolo di quello che si trova disperso sul sito ufficiale. La cosa migliore che ho trovato finora su Hugo è questa serie di post: non male, ma troppo poco approfondita.

Di conseguenza è quasi impossibile mettere le mani in Hugo e imparare ad estenderne le funzionalità oltre a quelle predefinite. A parte studiare i sorgenti, ovviamente.

Anche in questo caso potrei sbagliarmi o essere stato troppo superficiale nel leggere la documentazione disponibile. Ma se nel corso delle mie prove con Hugo non sono riuscito a fare una cosa banale come visualizzare le categorie e i tag dei post del mio sito di test, non riesco nemmeno ad immaginare quanto potrebbe essere ostico cercare di aggiungere qualche funzione leggermente più complessa: un breadcrumb, un box di ricerca, l’elenco dei tag più usati, o magari un servizio di commenti alternativo a Disqus.

Conclusioni

Come ho già detto il primo impatto con Hugo è positivo, ma appena si cerca di usarlo in pratica ci si scontra con i suoi limiti attuali, la scarsità di documentazione su tutti.

Sarà anche facile da installare, sarà perfino relativamente semplice da usare così com’è, ma per ora, mi dispiace, Hugo non fa per me.

Consiglio come al solito TextMate 2, TextWrangler, Atom, Brackets, più o meno in ordine di (personale) preferenza. Altri editor veri, da BBEdit o Sublime Text (che prima o poi mi deciderò a provare a fondo) agli editor storici emacs o vi, presenti di default in OS X, vanno naturalmente altrettanto bene. ↩︎

I limiti di Wordpress.com: cosa ho scartato e perché

Tue, 12 Aug 2014 06:00:00 +0000

Come orientarsi fra le decine e decine di generatori di siti web statici esistenti? Quali scartare a priori e quali considerare per una prova più approfondita? In base a quali criteri selezionare i sistemi promettenti nel mare di quelli non adatti allo scopo o perfino del tutto inutili?

Aiuta parecchio elencare le caratteristiche irrinunciabili, come aiuta leggere le impressioni degli altri utilizzatori. Ma alla fin fine bisogna arrotolarsi le maniche, provare di persona i sistemi ritenuti più promettenti ed affidarsi anche al proprio intuito.

In questi mesi, nei ritagli di tempo, ho provato più generatori di siti web di quello che avrei voluto, quasi tutti quelli elencati nel post precedente. Ma sono stati pochi quelli che mi hanno colpito, nel bene o nel male.

Hyde al primo impatto mi è piaciuto molto per lo stile anni ‘70 del sito. Però dietro lo stile non c’è niente, né introduzione, né documentazione, nulla. Anche il sito corrispondente su GitHub Pages è decisamente povero e di alcune pagine ci sono solo i titoli. Meglio lasciar perdere.

DropPages e Calepin sono accomunati dal fatto di usare Dropbox per gestire il sito web. Non c’è nulla da installare, basta creare una cartella, all’interno di quella standard di Dropbox, che contenga i sorgenti in Markdown del sito. Una opportuna applicazione web accede a questa cartella, converte i documenti e le relative immagini in file html e li sincronizza con il sito vero e proprio, mantenuto sui server di ciascuna delle due applicazioni. Facilissimo, e con il beneficio di avere un backup continuo e automatico di tutto sul cloud. Ma perché dovrei consentire ad una applicazione web di accedere ai miei dati su Dropbox, e con quali garanzie per la sicurezza dei miei file? Lasciamo perdere anche qui.

Pico. Interessante, peccato che non sia mai riuscito a farlo funzionare in locale. Del resto la documentazione si riduce ad una sola paginetta html.

Anchor CMS. Un vero peccato, sembra veramente bello. Ma è stato un errore, in realtà non è altro che un CMS come tanti, con il suo bel database MySQL, proprio quello che volevo evitare.

Octopress, l’ho già scritto, è basato su Jekyll ma cerca di rimuoverne le parti più ostiche, più da programmatore. Ma lo sviluppo di Octopress è fermo da anni, e poi a me questa idea della semplificazione a tutti i costi non piace tanto. Però Octopress merita comunque una menzione d’onore.

Infine arriviamo a Ruhoh. Ruhoh è stato in cima alla lista dei preferiti per parecchio tempo. L’ho installato e provato senza problemi. La documentazione è dettagliata ed estesa, tranne (opinione personale) per quello che riguarda i temi grafici. Però, per creare la struttura del sito e le pagine che lo compongono, bisogna usare dei comandi specifici, ed anche un po’ confusi. Assolutamente no, voglio la libertà, voglio poter creare i documenti che compongono il sito tramite il Terminale, il Finder o anche in remoto, voglio poterli mettere dove preferisco all’interno della struttura del sito, riordinandoli finché non sono soddisfatto e lasciando al generatore il solo compito di convertirli in file html. Anche Ruhoh, purtroppo, non va bene per me. Attenzione che senza un gestore delle “gemme” di Ruby, Ruhoh è pure complicato da rimuovere.

I limiti di Wordpress.com: generatori di siti web statici

Sat, 09 Aug 2014 06:00:00 +0000

Come ho già scritto qualche giorno fa, ci sono letteralmente decine di generatori di siti web statici, quasi quante sono le distribuzioni di Linux. Io nei miei bookmark ne ho una trentina.

Come orientarsi in questa moltitudine?

Per le distribuzioni di Linux esiste Distrowatch, un sito popolarissimo che cerca di classificarle tutte. Analogamente, esistono almeno due siti che cercano di elencare tutti i generatori di siti web statici: StaticGen e Static Site Generators. L’approccio dei due è totalmente diverso anche se le informazioni riportate sono praticamente le stesse.

Il primo ordina di default i generatori di siti statici in base alla popolarità, ma si possono applicare vari filtri basati sul linguaggio di programmazione, la valutazione degli utenti e persino gli issue, i problemi riscontrati dagli utenti.

L’altro è apparentemente una tabella ordinata alfabeticamente (in questo momento elenca ben 289 sistemi diversi!), ma cliccando sulle intestazioni si può ordinarla in base al linguaggio di programmazione, alla valutazione degli utenti o alla data in cui il sistema è stato aggiornato per l’ultima volta. Quest’ultima è una informazione utilissima, se un sistema non è aggiornato da anni non vale la pena perderci tempo.

Provando ad applicare un po’ di filtri si copre che esiste perfino un generatore, StatiKiss Framework, basato su Bash, ma il sito web ufficiale contenente la documentazione non risponde. In realtà esisteva un’altro sistema interessante basato su Bash, NanoBlogger, il cui sviluppo è stato però sospeso all’inizio del 2013. Evidentemente Bash non va bene per sviluppare siti web.

Si può trovare anche Zodiac, un generatore di siti statici scritto in AWK, un linguaggio perfetto per la manipolazione di file di testo, sviluppato fra gli altri da Brian Kernighan, uno dei padri di Unix e del linguaggio C. A leggere il README Zodiac sembra semplice da usare, supporta markdown e la struttura delle directory in cui sono organizzati i documenti utilizzati per generare il sito è ragionevole. Ma purtroppo la popolarità di Zodiac è scarsa, scarsissima. Si potrebbe di certo usare per un progetto personale e soprattutto per imparare, ma è impensabile volere sostituire Wordpress con qualcosa come Zodiac. A chi rivolgersi, dove cercare aiuto e documentazione se si volesse fare qualcosa di non previsto dal programmatore, ad esempio gestire un sistema di commenti?

Fra i generatori di siti web statici ci sono persino due sistemi scritti in .NET. Ma vogliamo farci veramente del male?

Ma lasciamo perdere le curiosità. Quali sono invece i top player? Quali sono i sistemi più popolari, più diffusi e, si spera, più affidabili? Facile, il primo in assoluto è Jekyll, un generatore sviluppato in Ruby, un linguaggio di programmazione che è più o meno la risposta giapponese a Python, molto diffuso per sviluppare applicazioni web. Seguono Octopress (un derivato semplificato di Jekyll, il cui sviluppo però è fermo dal 2011), Pelican in Python, Middleman ancora in Ruby e Hexo in JavaScript.

Ci sono comunque altri generatori interessanti, alcuni con nomi veramente curiosi, Ruhoh, Hugo, Pico, Calepin, DropPages, Pancake, Anchor CMS, Hyde, Sculpin, HTMLy,Dropplets, Chronicle. Esiste persino il venerabile (ha quasi 10 anni!) Dir2web, l’unico prodotto italiano che conosca.

Non mancato anche i prodotti a pagamento come Kirby e Statamic. O come Cactus, che è pure specifico per il solo Mac.

Per questi ultimi no grazie, il web nasce e deve rimanere multipiattaforma, sistemi sviluppati per uno specifico sistema operativo non mi vanno bene a priori. E trovo pure irragionevole cercare di vendere questi prodotti: se devo pagare per Statamic, quanto dovrei dare agli sviluppatori di Apache? Sei uno sviluppatore e vuoi guadagnarci? Distribuisci gratis il prodotto, dimostra nei fatti che è buono, fai in modo che diventi il più popolare possibile e poi vendi il supporto. Cercare di vendere software come questi, che subiscono la concorrenza di sistemi equivalenti, gratuiti e di qualità analoga se non migliore, è veramente sciocco.

I limiti di Wordpress.com: una nuova piattaforma per il blog

Wed, 06 Aug 2014 06:00:00 +0000

Assodato che, nonostante i suoi tanti pregi, Wordpress.com non va più bene per me, si tratta ora di scegliere una nuova piattaforma per questo blog.

Fosse facile. Ci sono centinaia di alternative fra cui scegliere, wiki, CMS o piattaforme di blog, siti statici, siti dinamici. Classico esempio di information overload. Troppe informazioni, troppe alternative rendono difficile prendere una decisione efficace.

Cerchiamo quindi di semplificare un po’ le cose. Iniziamo da cosa non voglio.

Non voglio innanzitutto usare una piattaforma wiki, che va benissimo per un sistema in cui i contenuti siano scritti e modificati da più utenti in parallelo, ma non ha senso per un banale blog come questo. E poi, detto fra noi, i Wiki non mi sono mai piaciuti, troppo difficili da navigare, troppo difficile trovare le informazioni. A parte Wikipedia naturalmente, la cui natura di enciclopedia si sposa bene con la struttura non-lineare del wiki.

Non voglio nemmeno usare un sistema di gestione dei contenuti (CMS) o una piattaforma di blog (i confini sono confusi), che sia un peso massimo come Drupal o Plone, un sistema più agile come CMS Made Simple o MODX oppure, come è stato suggerito nei commenti al post precedente, il promettente Ghost. Un CMS non cambierebbe nulla rispetto a quello che succede oggi con Wordpress.

Anzi, sarebbe persino peggio, sarei costretto ad installare il CMS prescelto in locale per lo sviluppo e la configurazione, a portarlo poi sulla piattaforma di hosting prescelta, a mantenere la sincronizzazione fra le modifiche locali e quelle sul sistema visibile in rete, a gestire gli aggiornamenti ed il backup. L’ho fatto in passato, so bene come si fa, ma so altrettanto bene che fa perdere una montagna di tempo. Per un sito professionale ne vale la pena, per un hobby come è questo blog, no.

Non voglio nemmeno dover avere a che fare (se possibile) con un sito dinamico e con i suoi file sepolti in un database. Un sito dinamico ha senso se si deve presentare un gran numero di informazioni che variano costantemente nel tempo (si pensi ad un sito di commercio elettronico o a quello di un quotidiano), ma per un blog con aggiunta qualche pagina che raccolga i testi in modo più sistematico? Inoltre, un database rende molto più complicato il controllo di versione dei documenti o il passaggio ad un altro sistema di gestione dei contenuti, nel caso si cambi idea o vengano fuori strumenti più avanzati.

Cosa voglio allora?

Voglio un sito web statico ma allo stesso tempo moderno.

Non voglio un sito costituito da una serie di pagine web collegate fra loro a mano (non siamo più, e da tanto, negli anni ‘90!), voglio un sistema che prenda una serie di file di testo, di immagini e di documenti, creando automaticamente il sito web ed aggiornandolo ad ogni mia modifica dei contenuti.

Insomma, voglio un generatore di siti web statici.

Il sistema prescelto deve:

essere facile da installare e da configurare;
poter gestire contemporaneamente un blog e delle pagine fisse;
facilitare l’inserimento dei nuovi contenuti, consentendo ad esempio di scrivere i testi con un linguaggio di markup semplificato come markdown o simili e non solo in html puro o (peggio!) tramite le orride interfacce grafiche simil-Word;
permettere il controllo di versione dei testi e del sito web nel suo complesso;
essere popolare (non una delle decine di progetti di nicchia che muoiono dopo pochi mesi), con una base di utenti tale da permettere di reperire con facilità informazioni e supporto;
supportare qualunque tipo di hosting;
avere di un aspetto grafico gradevole, con temi grafici vari e facilmente adattabili.

Di generatori di siti web statici ce ne sono a decine. Decisamente troppi. Ma solo uno esce decisamente dalla mischia e sembra una scelta quasi obbligata.

I limiti di Wordpress.com

Fri, 01 Aug 2014 06:00:00 +0000

Il titolo di questo post è fuorviante. Non voglio parlare qui in generale dei limiti di Wordpress, ma piuttosto della mia esperienza d’uso con questa piattaforma e dei suoi limiti rispetto al mio modo di usarla.

Wordpress.com è una piattaforma di blogging, basata sul noto CMS open source Wordpress, che offre la possibilità di aprire un blog in modo del tutto gratuito ma con alcune restrizioni poco significative, tra cui l’impossibilità di installare plugin di terze parti e di utilizzare temi grafici differenti da quelli offerti dalla piattaforma.

Dopo più di sette mesi di gestione di questo blog devo ammettere che, nonostante una certa prevenzione iniziale, il servizio offerto da Wordpress.com è decisamente eccellente.

La piattaforma è veloce (a differenza di quanto avveniva alcuni anni fa) e permette di gestire e configurare in modo molto comodo il proprio blog. I temi grafici sono ben fatti e si può modificare l’aspetto del sito anche quando questo è già attivo, senza correre il rischio di distruggere tutto (hai sentito Blogger?)

Però è ormai diventata troppo stretta per me.

Innanzi tutto per come gestisce i testi in Markdown. Tutti i miei post sono scritti in Markdown e poi inseriti nel blog tramite l’interfaccia web di Wordpress.com. Il guaio è che, se nell’editor dei post si passa per sbaglio dalla modalità solo testo (in cui si può inserire un post in Markdown) a quella visuale (simile ad un wordprocessor ), si perde tutto il codice Markdown originale, che viene sostituito dal codice HTML corrispondente.

Ormai mi sono abituato ma all’inizio bastava un click sul link sbagliato per perdere tutto il testo originale. Ovviamente il contenuto del post non andava perduto (almeno quello!) ma era comunque seccante dover reinserire a mano tutti i comandi Markdown al posto di quelli HTML.

Questo errore mi ha costretto a conservare una copia dei post originali e a mantenerli sincronizzati con le modifiche effettuate direttamente nell’editor online prima della pubblicazione definitiva. Sembra una sciocchezza ma alla lunga è seccante. Fra l’altro, mentre scrivo mi sono accorto che l’errore è stato finalmente corretto ed ora è possibile passare da una modalità all’altra senza perdere nulla…

Ancora più scomodo è il modo in cui vengono gestite le immagini. Innanzi tutto bisogna copiare le immagini nella libreria dei Media. Purtroppo, anche se si può usare il drag and drop per farlo, non è poi possibile organizzare le immagini in cartelle – una vera necessità quando iniziano a moltiplicarsi – e perfino modificare il nome dei file delle immagini.

Anzi, se si volesse in seguito sostituire una immagine già copiata con un’altra con lo stesso nome, quest’ultimo viene cambiato aggiungendovi un numero progressivo e rendendo necessario modificare i link all’immagine sostituita.

Non basta. Non si può nemmeno usare il codice Markdown per inserire le immagini della libreria nel testo, ma solo il solito HTML, o almeno io non ci sono mai riuscito.

Credo che questi esempi bastino. Di conseguenza sto ormai cercando di passare ad una piattaforma di blogging più controllabile e soprattutto che sia più vicina alla mia mentalità e al mio modo di lavorare. Stay tuned.