Wordpress on Melabit

Da melabit a melabit: perché Jekyll?

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

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

Swift contro Python, ovvero mele contro pere

Mon, 03 Oct 2022 06:00:00 +0000

– Fonte: Martina Leuderalbert su Unsplash.

Alle elementari la maestra mi aveva insegnato a non sommare le mele con le pere, cioè a non mettere insieme (o paragonare) cose e fatti molto diversi fra loro. Non ha quindi senso sommare 3 litri di acqua con 5 chilogrammi di farina o chiedersi se 40 metri sono più o meglio di 20 secondi.

Quello che diceva la mia maestra lo dicono, sono sicuro, le maestre di tutto il mondo, ma c’è sempre qualcuno assente a queste lezioni.

Il Golia della programmazione moderna

Uno di questi è stato di sicuro Ari Joury che, nonostante il suo dottorato in fisica delle particelle, non si è fatto scrupoli a pubblicare su Medium questo Swift was poised to replace Python. Then it tanked.

Cosa dice l’articolo? Che nel mondo del machine learning i linguaggi di programmazione più usati sono Matlab, R, Julia e soprattutto Python. Quest’ultimo, nato originariamente per sviluppare dei piccoli script senza troppe pretese, è diventato oggi un vero “Golia della programmazione moderna”, tanto da essere usato estensivamente da aziende come Dropbox, Instagram e Pinterest per i loro servizi online.

Grazie alla disponibilità di librerie come TensorFlow o PyTorch (nonché, aggiungo io, di librerie di base come Pandas o NumPy), Python è diventato anche il linguaggio di elezione di chi si occupa di machine learning e di analisi dei dati.

La crescita di Python sembra bloccata da un paio di anni, ma la sua enorme diffusione lo farà rimanere comunque un attore centrale anche nel prossimo futuro.

Entra in scena Swift

Fin qui tutto vero e condivisibile. Magari si potrebbe eccepire qualcosina sull’importanza di R nell’ambito dell’analisi dei dati, ma non voglio essere puntiglioso.

Il guaio è che se uno si limita a scrivere queste cose non se lo fila nessuno, chi vorrà mai leggere l’ennesimo articolo generico sulle virtù di Python per il machine learning (e non) o su quale linguaggio è destinato a soppiantarlo?¹ Ci vuole un colpo d’ala.

Per fortuna c’è sempre Apple che, come il nero, va bene su tutto e, soprattutto, garantisce sempre un bel po’ di click. E allora perché non mettere in mezzo Swift?

Swift è un linguaggio di programmazione sviluppato da Apple con l’obiettivo specifico di sostituire Objective-C come linguaggio di elezione per lo sviluppo delle applicazioni per iOS e per macOS. Swift è facile da imparare e la sua sintassi leggibile ricalca quella di Python, è vero, così come quella di Julia e di tanti altri linguaggi di programmazione moderni.²

Swift però non ha mai preteso di essere, come sostiene il nostro Ari, il nuovo “Re della Programmazione”. Ad Apple non interessa posizionare Swift come uno strumento di programmazione general purpose, le interessa solo che venga usato per programmare le applicazioni per i suoi sistemi operativi. Del resto, il fatto che manchi di una versione per Windows taglia fuori una fetta così importante di potenziali utenti da rendere impossibile a priori una pretesa tanto assurda.

A maggior ragione Swift non ha mai preteso di essere il nuovo strumento principe per il machine learning, come il buon Ari sotto sotto ci vuole far intendere. È vero che Google ha provato a supportare Swift all’interno di TensorFlow (di cui Google è il principale sviluppatore), ma questo esperimento, come succede con tanti altri prodotti dell’azienda di Mountain View, è stato interrotto nel 2021. È ragionevole pensare, infatti, che chi sviluppa in Swift preferisce usare gli strumenti per il machine learning integrati in macOS/iOS piuttosto che prodotti di terze parti.

Io sono più popolare di te

Ma la cosa più sconcertante è pretendere di confrontare la popolarità (o meno) dei linguaggi di programmazione utilizzando una metrica fasulla come la percentuale di domande poste ogni mese su StackOverflow relativamente ad uno o ad un altro linguaggio. In base a questa percentuale, la popolarità di Python è cresciuta costantemente fino alla fine del 2020, per poi stabilizzarsi al 16% del totale delle domande su StackOverflow, mentre quella di Swift dopo aver raggiunto un massimo del 3% è in declino e ora si aggira nei dintorni dell'1.5%.

Perché è una metrica fasulla? Perché finché siamo sui grandi numeri e confrontiamo la popolarità di Python con quella di JavaScript può anche avere senso basarsi sul numero di domande poste su StackOverflow per valutarne la diffusione.

Ma se buttiamo nel calderone anche la terna HTML, CSS e PHP, che sono ancora oggi tre strumenti fondamentali per chi fa sviluppo web, troviamo che questi ultimi sono in costante declino, senza però che la decadenza (su StackOverflow) di PHP venga compensata da un incremento corrispondente nell’interesse verso JavaScript.

Anche Wordpress, che piaccia o non piaccia sta dietro il 40% dei siti web, secondo la metrica di StackOverflow sarebbe in calo. Idem per MySQL.

E allora la spiegazione può essere un’altra: più che la diffusione, le domande su StackOverflow ci fanno vedere la complessità del linguaggio e la qualità della sua documentazione: HTML, CSS e PHP (o Wordpress e MySQL) sono prodotti ben assestati, per loro esistono ottime guide sul web che ne spiegano diffusamente i segreti. Di conseguenza non è necessario cercare risposte più o meno occasionali su StackOverflow, e comunque quelle che ci sono già bastano ed avanzano.

Python e JavaScript, al contrario, hanno una sintassi di base piuttosto semplice ma per essere usati al meglio hanno bisogno di un gran numero di librerie aggiuntive, che sono spesso più complesse del linguaggio base e che vengono aggiornate ed espanse di continuo. La documentazione relativa non tiene sempre il passo dello sviluppo, per cui il modo migliore per imparare ad usare al meglio le centinaia e centinaia di API disponibili è quello di rivolgersi a qualche esperto su StackOverflow, spingendo così in alto la popolarità dei due linguaggi.³

Secondo la logica basata sul numero di domande su StackOverflow anche C e C++, i linguaggi usati per la programmazione di sistema (e non) su Linux e Windows, sarebbero in declino, e lo stesso succede a concetti di base come algoritmo, architettura, classe o database. Ma sono in declino perché c’è davvero poco interesse o solo perché anche per loro c’è abbondanza di documentazione di ottimo livello, senza doversi ridurre a porre sempre delle nuove domande su StackOverflow?

Nel mio piccolo lo faccio anch'io: quando programmo in R uso pochissimo StackOverflow, perché posso usare l'ottimo help in linea di RStudio e perché la documentazione che accompagna le librerie aggiuntive di R è centralizzata sul [CRAN](https://cran.r-project.org/) (_The Comprehensive R Archive Network_) ed è di altissima qualità. E quando tutto questo non basta, posso trovare decine di siti e di blog che spiegano benissimo gli aspetti più ostici del linguaggio. Quando passo a Python (un linguaggio che, sia chiaro, mi piace parecchio), StackOverflow diventa quasi una necessità, perché la frammentazione e la mancanza di sistema di gestione centralizzata delle librerie di Python rendono molto più complicato trovare documentazione aggiornata di qualità.

Decaduto o semplice?

Swift è un linguaggio semplice con una ottima documentazione ufficiale, un eccellente strumento di apprendimento del linguaggio (e non solo) come Swift Playgrounds e un numero relativemente ridotto di librerie aggiuntive, c’è davvero bisogno di passare un sacco di tempo su StackOverflow per usarlo al meglio?

Guardando il grafico relativo al numero di domande relative a Swift ci si accorge che i picchi di interesse corrispondono alle date di presentazione della versione 1.0 (giugno 2014) e al rilascio delle versioni 2.0 (settembre 2015), 3.0 (settembre 2016) e 5.0 (marzo 2019) e, come è naturale, dopo ogni presentazione l’interesse tende a decadere, proprio perché per usare il linguaggio c’è davvero poco da chiedere su StackOverflow.

A supporto di questa tesi c’è il risultato di questa semplice query SQL, con la quale ho provato a calcolare il numero di domande poste su StackOverflow ogni anno. Di SQL ne so pochissimo per cui dovete prendere i risultati con le pinze, ma sembra che il numero di domande su StackOverflow sia in progressiva diminuzione, da un massimo di 2.2 milioni di domande nel 2016 a 1.6 milioni nel 2021.

Una volta raggiunta una base di conoscenza sufficientemente ampia non ha molto senso porre sempre delle nuove domande (che su StackOverflow sono fortemente scoraggiate) ma ci si può limitare ad utilizzare il materiale già esistente. Questo almeno per le tecnologie più stabili, come possono essere HTML, CCS, PHP, Wordpress, MySQL… oppure Swift. Quando invece abbiamo a che fare con strumenti in rapidissima evoluzione, come Python o JavaScript, StackOverflow diventa davvero il modo migliore per imparare.

Conclusioni

C’è bisogno di dilungarsi ancora? Non credo, dico solo che basarsi su ipotesi fantasiose o metriche poco affidabili per ipotizzare scenari catastrofici per Swift (o, al contrario, scenari entusiasmanti per Julia⁴) mi pare francamente insensato.

– Fonte: Dilbert di Scott Adams.

Capo: Non si possono confrontare mele e arance.

Dilbert: È chiaramente sbagliato, perché li hai appena confrontati e dichiarati diversi.

Wally: Mele e arance sono entrambi alimenti che crescono sugli alberi. Sarebbe assolutamente valido confrontarli dal punto di vista nutrizionale.

Dilbert: Ho notato che molte delle cose che escono dalla tua bocca non hanno senso.

Capo: Parli come mia moglie.

Wally: Non puoi paragonare tua moglie al tuo subordinato. Sono mele e arance.

Capo: Cosa sta succedendo qui?

Wally: Non lo so, ma non lo paragonerei a lavoro.

Ari sembra avere le idee un po’ confuse sul futuro di Python, dato che su Medium ha anche pubblicato Why Python is not the programming language of the future, oppure Bye-bye Python. Hello Julia! e perfino Why TensorFlow for Python is dying a slow death. ↩︎
E non è un caso, perché alla base di tutti questi linguaggi c’è sempre il buon vecchio BASIC, il primo linguaggio di programmazione davvero per tutti, che è stato il linguaggio di base dei computer personali degli anni ‘80 su cui si sono fatti le ossa tutti i grandi nomi dell’informatica di quegli anni. ↩︎
Le sole domande sulla libreria pandas di Python (una libreria fondamentale per chi usa Python per l’analisi dei dati) assommano al 3% del totale, le principali librerie per il machine learning (TensorFlow, Keras, PyTorch, scikit-learn, OpenCV, NLTK) fanno un altro 2%, mentre quelle su Django e Flask (le principali librerie Python per lo sviluppo di applicazioni per il web) sono quasi al 2.5% del totale generale. Chiaramente queste domande vengono anche conteggiate come domande relative a Python. ↩︎
Perché sì, l’interesse per Julia sembra essere in aumento su StackOverflow, ma parliamo di non più dello 0.16% (1/10 dei valori di Swift) e anche in questo caso i picchi corrispondono al rilascio delle varie versioni del linguaggio. ↩︎

Cronaca di un disastro: come sopravvivere alla pagina bianca di WordPress

Wed, 22 Jan 2020 06:00:00 +0000

Questo non è un post adatto per chi si spaventa facilmente. Se siete ansiosi o deboli di cuore fatevi un favore e non continuate a leggere.

Premessa

Quando si verifica un disastro in ambito informatico (e non solo) la cosa più importante è non perdere mai la calma. E poi non bisogna avere fretta di rimettere le cose a posto, meglio riflettere prima di agire. Naturalmente avere un backup aggiornato a disposizione aiuta sempre moltissimo.

Tutte le volte che ho dovuto affrontare un disastro di tipo informatico – e fra casi personali, amici e conoscenti succede relativamente spesso – queste linee guida sono sempre state utilissime per risolvere il problema. L’ultima volta, però, una installazione di WordPress andata completamente in tilt ha messo a durissima prova la mia pazienza, oltre che le mie conoscenze tecniche. Ecco il racconto di quello che è successo.

Una giornata particolare

Oltre a questo blog, amministro da anni Il nostro CNR, un sito finalizzato alla discussione di tematiche relative al mondo del CNR e della ricerca in generale. Come melabit, anche Il nostro CNR è basato su WordPress. Il sito è piuttosto popolare, ha un discreto numero di visualizzazioni giornaliere, purtroppo sono sempre troppo pochi quelli che hanno la voglia e la pazienza di intervenire sul forum. Ma questo è un male tipico degli italiani, bravissimi a discutere animatamente al bar (verba volant…), ma molto meno propensi a mettere per iscritto quello che pensano, magari per paura di ritorsioni (…scripta manent ).

Poco prima di Natale Corrado Zunino, un giornalista di Repubblica sempre molto attento ai problemi della ricerca, pubblica un articolo in cui rivela che la procedura di elezione del rappresentante del personale nel CdA del CNR, conclusa un mese prima, potrebbe essere stata viziata da brogli. Il rappresentante eletto alla tornata precedente era stato una vera e propria spina nel fianco per la dirigenza del CNR e, non pago di quattro anni di fatiche e sacrifici anche personali, aveva deciso di ripresentarsi per un secondo mandato, con ottime possibilità di successo. Toglierlo di mezzo e sostituirlo con qualcuno meno rigido e competente era quasi una necessità.

Subito dopo aver letto l’articolo su Repubblica decido di diffonderlo tramite Il nostro CNR. Del resto, dopo la trasmissione di Report del marzo 2017 che ha rivelato la lunga serie di ruberie avvenute in un istituto del CNR (di certo non l’unico) e ancora di più dopo l’arresto dell’ex-direttore del CNR e dei suoi sodali, nel nostro ente l’interesse per queste vicende ripugnanti è altissimo.

– Fonte: Il Mattino, 20 novembre 2019.

Aggiornamenti inattesi

Entro quindi in quello che è un po’ il retrobottega del sito, la cosiddetta dashboard, l’interfaccia di gestione dei contenuti e delle funzionalità di WordPress, per scrivere un post sulla notizia di Repubblica e come al solito trovo alcuni plugin da aggiornare (i plugin sono dei pezzetti di codice che estendono le funzioni del sito). Succede praticamente ogni volta che accedo alla dashboard, e senza pensarci più di tanto clicco sul pulsante di aggiornamento. È una procedura assolutamente sicura e comunque, anche se uno dei plugin non dovesse più funzionare bloccando il resto del sistema, mi basterebbe modificare i nomi di qualche file per disattivarlo e recuperare la piena operatività del sito.

Questa volta invece, per qualche motivo incomprensibile, insieme all’aggiornamento dei plugin parte anche l’aggiornamento dell’intero codice di WordPress dalla versione 4.x all’ultima versione disponibile, la 5.qualcosa. Aggiornamento che per tanti motivi non volevo ancora fare, e soprattutto che non avrei mai fatto senza prima eseguire un backup affidabile di tutto il sito.

Non riesco ancora a capacitarmi di cosa possa essere successo, ma sono sicuro al 100% di non averlo fatto io stesso per errore. I pulsanti per aggiornare i plugin o il codice di WordPress sono ben distinti e non possono essere premuti contemporaneamente (lo vedete qui sotto), e poi ricordo benissimo di aver letto i messaggi che elencavano i plugin in corso di aggiornamento. Ma, quando alla fine del processo ho cliccato per tornare alla pagina principale, ho visto partire anche l’aggiornamento del codice di WordPress, e a quel punto non potevo più far niente per interromperlo.

È possibile che l’aggiornamento del codice sia partito da solo per qualche baco di Wordpress o di un plugin, del resto i bachi del software sono inevitabili. Una cosa seccante, ma ancora niente di preoccupante.

Un backup è per sempre?

Una volta concluso l’aggiornamento non voluto di WordPress, apro una nuova scheda del browser per controllare cos’è successo al sito. Compare solo una pagina completamente bianca. Il sito in effetti funziona ancora, ma non carica correttamente le pagine, e anche la dashboard appare completamente vuota. Per fortuna i file che costituiscono il sito ci sono ancora tutti, e anche il database usato da WordPress per memorizzare i dati variabili del sito è ancora al suo posto.

Un sito web dinamico come WordPress è costituito in genere da due componenti ben distinte: la prima comprende tutti file che costituiscono il sito web vero e proprio e che vengono modificati di rado, in particolare il codice WordPress e le personalizzazioni dell'utente, i plugin, i temi grafici, le immagini e tutti i documenti collegati alle pagine del sito (questa componente sarà denominata da ora in poi "file del sito" o semplicemente "sito"). La seconda componente è costituita da un database nel quale vengono memorizzati i dati variabili del sito, fra cui i testi degli articoli e degli interventi sul forum, le informazioni relative agli utenti registrati, i dati di accesso e moltissimo altro.

Quando succedono queste cose nel 99% dei casi la colpa è di qualche plugin che funziona male o non funziona affatto. Non c’era del resto da stupirsi, uno dei motivi per decidere di non aggiornare alla versione più recente di WordPress era legato proprio al fatto che almeno due plugin piuttosto importanti non erano ancora stati aggiornati per funzionare con le nuove versioni di WordPress e di PHP, il linguaggio di programmazione per il web con il quale è sviluppato WordPress.

Per correggere il problema della pagina bianca ci sono sostanzialmente due metodi: il primo richiede di disattivare i plugin uno ad uno, fino a scoprire quello che non funziona. Richiede ore ed ore di lavoro certosino e non avrebbe comunque risolto il problema dell’aggiornamento indesiderato del sito. Nonostante tutto, ho provato a disattivare i due, tre plugin più critici ma non cambiava niente.

Il secondo metodo prevede di ripristinare il sito da un backup recente e, in questo caso specifico, ha l’enorme vantaggio di poter tornare alla versione precedente di WordPress. E dato che il provider scelto per ospitare il sito fa un backup ogni ora, mi sembrava più che naturale scegliere la seconda soluzione.

Ed è qui che sono cominciati i guai.

Apro un ticket, cioè una richiesta di supporto tecnico, presso il provider e chiedo come ripristinare il sito da un backup eseguito intorno alle 9 del mattino, ora alla quale ero sicuro di non aver fatto ancora niente. Purtroppo non posso fare da solo, l’assistenza tecnica mi avvisa che la procedura di ripristino del database di WordPress deve essere effettuata dal provider, altrimenti dà errore.

Ovviamente li lascio fare, indicando il backup da ripristinare, il #687 eseguito alle 8:53, e ribadendo che volevo un ripristino totale, pulito, sia del sito che del database su cui si appoggia (la conversazione qui sotto, così come tutte le conversazioni successive, vanno lette dal basso verso l’alto).

Non funziona, anzi è peggio, i file del sito sembrano a posto, ma il database viene ripristinato solo in parte e quindi in pratica non serve a niente.

Intanto mi sono fatto dare l’intero backup del sito e del database delle ore 8:53 in formato standard e in questo backup il database sembra completo. Però ogni volta che l’assistenza tecnica prova a ripristinarlo la procedura fallisce. Secondo loro perché il database è corrotto, secondo me perché la loro procedura di ripristino non funziona bene.

Provo allora a chiedere il ripristino da un backup di un paio di giorni prima, ma non cambia niente. È già passato un giorno, il sito è ancora giù e io faccio una pessima figura con i colleghi che lo frequentano.

Andare sul cloud

A questo punto decido di lasciar perdere l’assistenza tecnica e di fare da solo, usando il backup del sito e del database che mi sono fatto dare per ricostruire il sito da zero. Potrei usare come al solito una macchina virtuale, dove installare una versione server di Linux con tutto quello che serve per far funzionare WordPress, ma questa volta preferisco di andare sul cloud in modo da poter lavorare, se serve (e servirà molto spesso!), anche da casa.

Scelgo AWS Cloud9 di Amazon, funziona bene, costa poco e mi sembra più affidabile di altri servizi che ho usato in passato, come Codeanywhere, Koding o Pilvia, che cambiano continuamente modello di business. Accedo al mio account e creo una nuova istanza di AWS Cloud9, dove installo la versione 18.04/Bionic LTS di Ubuntu Linux.¹

Potrei scegliere anche Amazon Linux, una versione di Linux specifica per Amazon AWS e basata su RedHat e CentOS, ma preferisco andare sul sicuro, in fondo Ubuntu deriva sempre da Debian, e nel mondo Linux non c’è niente di meglio di Debian.

Tralascio i dettagli dell’installazione di tutto quanto serve per far funzionare WordPress su Linux (ma se richiesto potrebbe essere argomento di un prossimo articolo). Il server web Apache, il linguaggio di programmazione PHP e il sistema di database relazionale MariaDB,² sono già installati di default in Ubuntu LTS, si tratta solo di configurare opportunamente tutto per girare su AWS Cloud9 e di creare il database per WordPress. Già che ci sono, installo anche phpMyAdmin, un programma comodissimo che permette di gestire un database MySQL (e quindi anche MariaDB) tramite una interfaccia web.

A questo punto basta scaricare il codice di WordPress ed effettuare la famosa installazione in 5 minuti per essere a posto.

Beh, magari fosse così semplice! Tutto quello che ho in questo momento è un sito funzionante ma vuoto, invece a me serve ripristinare tutto il contenuto de Il nostro CNR.

Per farlo, sostituisco i file del sito e il database di WordPress con quelli contenuti nel backup fornito dal provider. Sembra difficile, ma avendo pieno accesso al terminale di Linux ed essendo l’amministratore onnipotente del sistema su cui gira WordPress diventa un gioco da ragazzi. Riavvio MariaDB ed Apache per fargli rileggere i nuovi dati su cui operare, ma non funziona.

Naturale, il database contiene l’indirizzo web (URL) del sito originale, https://ilnostrcnr.it, ma ora sono su Amazon AWS e l’URL del sito che ho creato è completamente diverso, è qualcosa tipo https://b0ef0914612e145f8fad9237c0dabd8a.vfs.cloud9.us-east-2.amazonaws.com. Non ho intenzione di combattere con i DNS o il file hosts, per cui entro nel database con phpMyAdmin, seleziono la tabella wp_options e sostituisco l’URL originale contenuto nei record siteurl e home con quelli forniti da Amazon AWS.

Riavvio di nuovo MariaDB ed Apache e finalmente il sito torna a vivere. Con phpMyAdmin controllo se il database ha degli errori, e in effetti ci sono, ma niente di così grave che possa impedirne il ripristino (e del resto a me funziona tutto perfettamente).

A questo punto è quasi routine, ed è anche l’occasione per dare una bella rinfrescata alle funzionalità del sito. Entro nella dashboard e rimuovo il plugin All-in-One WP Migration, che usavo per fare i backup personali del sito ma che che non è compatibile con le ultime versioni di PHP 7.x, e cancello dal terminale la directory relativa. Rimuovo anche il plugin Count per Day, ottimo per analizzare le statistiche di accesso al sito ma che non è aggiornato da un anno e non è stato testato con le versioni più recenti di WordPress. E dato che ha violato le linee guida di WordPress è stato pure rimosso dall’archivio (repository) ufficiale dei plugin di WordPress.

Controllo di nuovo il database usando sia una funzione seminascosta di WordPress³ che il solito phpMyAdmin ed ora è tutto a posto, dopo la rimozione dei due plugin problematici anche gli errori del database sono scomparsi.

Ritorno al provider

A questo punto mi rimane solo da fare un backup del sito e del database, che il provider potrà usare (o meglio “dovrà usare”, visto che finora non ha fatto niente di significativo) per ripristinare il sito originale.

Ma la cosa si rivela più difficile del previsto e l’interazione fra il supporto tecnico e me sembra un dialogo fra sordi,

che sfocia rapidamente nella incomunicabilità totale. Il sito è giù da ben 11 giorni ma al servizio tecnico importa pochissimo. Inutile provare ancora a ricevere un supporto degno di questo nome.

Prima di tagliare i ponti con il servizio tecnico ho preparato un Piano B. Ore di ricerche sul web mi hanno fatto trovare Duplicator, un plugin che sembra perfetto per le mie esigenze. In apparenza è uno dei soliti plugin di backup/ripristino di una installazione di WordPress, che alla fine richiedono sempre l’acquisto della versione Pro per essere davvero utili. Duplicator invece è diverso, la versione Pro aggiunge delle funzioni molto interessanti per chi gestisce dei siti web per professione, ma la versione base gratuita fa tutto quello che mi serve, è solo leggermente più complicata da utilizzare.

In previsione del piano B ho già provato a fondo Duplicator, usandolo per fare un backup completo del sito e per ripristinarlo in una nuova istanza di AWS Cloud9, e funziona in modo spettacolare. Mi piace soprattutto il fatto che lavori a bassissimo livello, sembra quasi di usare il terminale, che è poi quello che farei io stesso se il provider mi concedesse un accesso pieno e senza limitazioni via ssh al mio sito e soprattutto al database associato.

Entro quindi nel pannello di controllo del mio sito web e di tutti i tool collegati, il notissimo cPanel, cancello tutti i file del sito e anche il database che ha creato tanti problemi, e già che ci sono aggiorno PHP alla versione 7.2, la stessa versione disponibile in AWS Cloud9. Mi tremano un po’ i polsi, da ora in poi se sbaglio non posso più tornare indietro, ma ho delle alternative migliori?

A differenza degli altri plugin di backup/ripristino che conosco, Duplicator non ha bisogno di una installazione preesistente di WordPress per funzionare, ma insieme al backup del sito genera un programma in PHP che effettua da solo il processo di ripristino del sito e del database associato. Anche l’URL che ho modificato a mano diretatmente nel database vengono aggiornati correttamente. Bastano pochi minuti e il sito torna a vivere.

È il 2 gennaio, sono passati ben 14 giorni dal disastro.

Conclusioni

Quando dicevo all’inizio che la lettura di questo articolo non è adatta a chi si spaventa facilmente o è ansioso, stavo scherzando, ma non troppo. Questa esperienza ha davvero messo a dura prova le mie capacità tecniche, nonché la mia pazienza nell’interagire con chi dovrebbe fornire un supporto tecnico decente.

Ma dopo un paio di giorni era diventata una sfida personale, una specie di esame fuori tempo massimo, sei capace di risolvere questo problema difficile? E poi, naturalmente, c’era la necessità di non fare brutta figura con tanti colleghi…

Ovvio che alla scadenza del contratto bisognerà cambiare provider, tutto sommato questo finora non è stato male, ma finché va tutto bene sono buoni tutti, le differenze si vedono solo quando il gioco si fa duro. Avevo già pensato di farlo per altri motivi, ma il dover traslocare il sito su un’altro spazio web mi preoccupava un po’. Ora, con l’esperienza che mi sono fatta, sarà uno scherzetto.

A differenza delle versioni normali di Ubuntu Linux, che vengono rilasciate ogni sei mesi, le versioni LTS, Long Term Support, vengono rilasciate solo nella primavera degli anni pari e sono particolarmente indicate per un sistema server. ↩︎
MariaDB è un derivato (fork) del notissimo database MySQL, prodotto dagli sviluppatori originali di MySQL e compatibile praticamente al 100% con la versione corrispondente di MySQL. L’origine del fork sta nell’introduzione da parte di Oracle, che nel 2010 ha acquisito la ormai decaduta Sun Microsystems con tutto il suo parco software fra cui Java e proprio MySQL, di estensioni proprietarie disponibili solo per la versione a pagamento di MySQL. ↩︎
Bisogna aggiungere nel file wp-config.php la riga define('WP_ALLOW_REPAIR', true);, andare all’URL di amministrazione YOURSITE.com/wp-admin/maint/repair.php (dove YOURSITE.com deve essere sostituito con l’indirizzo web del sito) e seguire le istruzioni. ↩︎

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

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

Da melabit a melabit: la scelta del dominio

Tue, 05 Jun 2018 06:00:00 +0000

Se la scelta del servizio di hosting più adatto alle nostre esigenze è difficile, ancora più complicata è la scelta del nome di dominio (o solo dominio), cioè del nome univoco assegnato ad un sito web, che lo caratterizza e lo rende facile da ricordare, come ad esempio www.google.com, www.debian.org oppure www.nomesito.it.

Breve lezioncina preliminare (sono noioso, ma bisogna pure capirsi). Un dominio è composto da tre parti separate da punti: la prima parte è il noto acronimo www (cioè world wide web), una specie di marchio di riconoscimento del web (come la @ per la posta elettronica) che ormai viene usato sempre più di rado.¹

La parte finale è detta dominio di primo livello (o TLD, Top Level Domain) e serve ad identificare la tipologia del sito web (.com per i siti commerciali, .org per quelli senza scopo di lucro) oppure la nazione dove opera il sito (.it). Però, dopo la liberalizzazione dei TLD, queste definizioni sono diventate sempre meno significative.

Infine la parte di mezzo è il nome dell’host (google, debian oppure nomesito negli esempi di sopra), la parte del nome di dominio che caratterizza veramente il sito.

Aggiungendo il metodo di accesso, http:// o ormai quasi sempre la versione sicura https://, si ottiene l’URL, cioè la stringa univoca https://www.nomesito.it, che permette al browser di accedere al sito web desiderato.

Finita la lezione, veniamo alla parte più significativa dell’articolo: come si fa a scegliere il nome di dominio più adatto per il nostro sito? Le regole di base sono già tutte in questo articolo, inutile ripeterle un’altra volta.

Per una volta voglio usare un approccio più pratico e raccontare come e perché ho scelto proprio melabit come nome di dominio per questo sito, applicando senza nemmeno saperlo alcune delle regole contenute nell’articolo appena citato. Tre regole in particolare: volevo un nome di dominio che fosse breve e facile da scrivere, e che una volta letto non sembrasse qualcosa di diverso e imprevisto. Perché la ragione conta, ma il caso ha sempre il suo bel daffare a metterci i bastoni fra le ruote.

La primissima idea di tenere un blog personale non è mia, ma dell’amico Lucio Bragagnolo, che molto gentilmente mi aveva invitato ad aprirne uno su Macworld Italia. Si doveva chiamare “iLife of Brian”, un bel gioco di parole con il nickname che uso più o meno sempre su internet (con qualche variazione).² Ho ancora il testo del post di presentazione, che non ho mai pubblicato perché intanto Macworld ha chiuso su due piedi.

Ci ho pensato e ripensato e alla fine ho deciso di fare da solo. Ma senza più l’ombrello protettivo di Macworld ho escluso immediatamente di chiamarlo “iLife of Brian”, i motori di ricerca non l’avrebbero mai trovato. Provate a cercare “iLife of Brian” su Google (ma anche su Bing, su DuckDuckGo, su quello che vi pare), vi verrà fuori solo e sempre qualcosa dei monumentali Monty Python. Il confronto era improponibile.

Allora ho preso il fidato nvALT, che uso molto più di Notes per buttare giù degli appunti veloci, e ho cominciato a buttare giù una serie di nomi per il blog. Poi li ho messi in ordine (si può fare a mano, ma sapere usare un po’ il Terminale può essere utile anche per queste cose) e mi sono messo a cercare su internet se erano disponibili o no.

C’è voluto un po’ di tempo e di pazienza, e alla fine è venuta fuori questa lista. Nella colonna di sinistra sono finiti tutti quelli già utilizzati, un vero peccato perché alcuni erano veramente carini. Rimanevano quelli della colonna di destra.

A questo punto ho cominciato a tagliare. Alcuni nomi erano troppo lunghi e complicati (mactechbit, openappletech), spesso troppo anglosassoni per un blog destinato volutamente ad un pubblico italiano (openmactools, toolsformac). Poi c’erano i nomi troppo caratterizzati verso aspetti molto particolari del mondo Mac (melaprog, scientificmac) mentre io volevo mantenere la possibilità di di scrivere di tutto quello che mi piaceva (e mi interessava). Tagliati anche loro senza pietà.

Alla fine mi ero deciso per melaperta. Poi quasi per caso, mentre lo ripetevo mentalmente, mi sono accorto che poteva essere scambiato per un sito per adulti (provate anche voi e ditemi). Avrebbe fatto molto bene alle statistiche di accesso, lo so, ma ho tagliato anche melaperta senza pietà.

Il nome immediatamente successivo era l’unico che non aveva controindicazioni, ed è così che è nato melabit.

Per approfondire

Host-academy, Cos’è un dominio?, 2018.
Nicola Losito, 22 consigli per la scelta del tuo prossimo nome a dominio, 2017.
ReteLab, Come scegliere un nome di dominio, 2016.
Andrea Di Rocco, Come scegliere un dominio per il tuo nuovo sito web, 2016.

Da melabit a melabit, la serie completa degli articoli

Dato che ormai il web è diventato onnipresente, l’acronimo www non è più indispensabile per riferirsi ad un sito, e quindi si può usare solo google.com (detto dominio nudo o naked) al posto di www.google.com. ↩︎
Nickname che deriva sia dal film più famoso dei grandi Monty Python, sia dal nome di uno dei fisici con cui più ho avuto a che fare, Brian Josephson, uno capace di vincere un premio Nobel pubblicando un solo articolo significativo. Tanto che subito dopo si è praticamente rimbambito. ↩︎

Da melabit a melabit: la scelta dell'hosting

Mon, 21 May 2018 06:00:00 +0000

Dopo l’introduzione generale di un mese fa (è già passato un mese!), eccoci subito a quello che forse è il passo più difficile della transizione, la scelta del servizio di hosting. Nella maggior parte dei casi, per avere una presenza su internet dobbiamo appoggiarci ad una azienda (provider) che ci mette a disposizione il server che ospita il sito (il servizio di hosting propriamente detto) e tutta l’infrastruttura hardware e software che rende il sito raggiungibile attraverso internet.

Ho letto da qualche parte che scegliere un servizio di hosting è come sposarsi: bisogna scegliere il partner, stabilire una relazione e sperare che duri nel tempo. E come nel matrimonio, separarsi non è mai facile né privo di conseguenze negative. Non so quanto sia vera la parte riguardante la separazione (dal provider), ma posso testimoniare che la semplice scelta del servizio-partner si è dimostrata molto più complicata di quanto potessi immaginare. Ho pensato quindi di elencare le linee guida che ho seguito per la scelta, sperando che possano essere utili anche a qualcun’altro.

Prima di iniziare un piccolo disclaimer: questi consigli sono adatti a chi voglia mettere su un blog o un sito web per un professionista o una piccola azienda, magari anche un piccolo sito di commercio elettronico. Chi ha bisogno di gestire un sito web di livello superiore farà meglio a rivolgersi altrove, i principi di base sono più o meno sempre gli stessi ma cambia parecchio il peso che si da ai vari fattori. E poi, è più che probabile che in questi casi non vi basti più un normale servizio di hosting condiviso (shared hosting) ma che abbiate bisogno di un server virtuale privato (VPS) o perfino di un server “fisico” vero e proprio (dedicated hosting).

Su internet le guide alla scelta dell’hosting non mancano, purtroppo per la maggior parte non sono altro che degli spot pubblicitari per questo o quel provider. Fra tutte quelle a cui ho dato una occhiata, l’unica che mi sento di consigliare è questa guida di SitePoint: c’è anche qui un po’ di pubblicità, ma almeno quelli di SitePoint lo ammettono onestamente.

Avere pazienza. Non sto scherzando, è una cosa fondamentale. I provider che forniscono servizio di hosting sono centinaia, se non migliaia (nel mondo). Ognuno di loro a parole fornisce un servizio esemplare, una assistenza immediata, un prezzo stracciato. Nella maggior parte dei casi sono delle balle o perlomeno delle affermazioni, diciamo così, piuttosto esagerate. Di conseguenza dovete rassegnarvi a navigare a lungo in rete, per cercare di capire cosa offrono (e soprattutto cosa non offrono) i vari provider e se quello che vi danno serve veramente.

Niente è per sempre. Niente è per sempre, soprattutto su internet. Un certo numero di aziende nascono, crescono e prosperano. Ma tante di più chiudono malamente dopo pochi anni. Come potete fidarvi di provider semisconosciuti che offrono servizi di hosting a vita, da pagare ovviamente sempre in anticipo, magari allettandovi con lo zuccherino di uno sconto mai visto?

Provare il servizio. Sono invece molto interessanti i provider che offrono pagamenti su base mensile o bimestrale. Si spende di più, è vero, ma si può provare direttamente la qualità del servizio offerto. E dopo un mese o due di prova sul campo, potrete decidere a ragion veduta se rimanere con quel provider passando ad una tariffazione annuale o se cambiare aria in cerca di qualcosa di meglio. E poi, se un provider decide di copiare Netflix e di farsi pagare ogni mese, secondo me sa il fatto suo ed è sicuro che il servizio che offre non fa fuggire i clienti dopo i primi trenta giorni. Proprio come Netflix.

Tenere i piedi per terra. Forse è una banalità, ma prima di scegliere questo o quel contratto bisogna fare due conti e valutare quanto spazio occuperà il vostro sito (oggi e nei prossimi anni). Con “spazio” intendo proprio lo spazio occupato sul disco rigido del server dai testi, dalle immagini e magari dai documenti allegati nonché, se usiamo un CMS dinamico come Wordpress, Drupal o, Dio ce ne scampi!, Joomla, dal database associato. Altrettanto importante è valutare il numero di utenti che visiteranno il sito. Inutile acquistare un servizio di hosting con spazio su disco “infinito” e banda di traferimento dati altrettanto “infinita” se poi non vi serve. A parte che l’infinito qui non esiste, a che vi serve tutto questo spazio se oggi avete solo dieci pagine e cento visitatori al giorno? Meglio iniziare con un contratto base, assicurandosi di poterlo aggiornare prontamente quando ce ne sarà bisogno. Anche perché i servizi di hosting forniti dai vari provider cambiano molto velocemente seguendo l’evoluzione tecnologica, per cui è probabile che, quando avrete veramente bisogno di più spazio e di più banda, riuscirete a spuntare prezzi e condizioni decisamente più convenienti di quelli odierni.

Ciò che è veramente importante. Tre parole: HTTP2, SSL, backup. Se il provider non vi garantisce queste cose fondamentali, andate da un’altra parte. E se ve le fa pagare a parte, valutate bene se vi conviene o se non è meglio rivolgersi altrove. In tutti i casi, su questo non ci piove, dovete averle tutte e tre. Per il backup in particolare, non fidatevi del provider e fate voi stessi un backup periodico del sito in aggiunta a quello automatico, che in ogni caso deve essere almeno giornaliero (penso comunque che nessun provider oggi possa pensare di stare sul mercato con qualcosa di meno). Perché? Perché non potete mai essere sicuri che il backup del provider funzioni finché non succede il fattaccio e in quel malaugurato caso è meglio avere una seconda alternativa. Ma anche perché potete essere ancora meno sicuri che un bel(?) giorno il provider non chiuda tutto all’improvviso, lasciandovi senza servizio e pure senza backup.

Ciò che è abbastanza importante. Server che usano dischi SSD al posto di quelli meccanici. Ho qualche dubbio che facciano veramente la differenza, vista la scarsa qualità delle linee dati del nostro Paese (che me ne faccio di un server che legge velocissimamente i file dal disco se poi ci vuole un sacco di tempo per trasmetterli a destinazione?), però i dischi SSD sono più affidabili di quelli meccanici, quindi: perché no?

Ciò che è piuttosto importante. Se il provider vi offre una CDN o dispone di più server sparsi per l’Europa (come è sufficiente per un sito italiano) o per il mondo, fateci un serio pensierino sopra, soprattutto se il prezzo è onesto. La velocità su internet è tutto, se il sito ci mette più del dovuto a caricare i testi e le immagini, i visitatori si scocciano e scappano via. Non ci vuole molto, basta un ritardo di due o tre secondi. Le nostre linee dati si danno già parecchio da fare per rallentare la velocità di accesso ai siti (l’avete già letto prima), per cui è consigliabile stare sul sicuro e ridurre per quanto è possibile gli altri colli di bottiglia. Non è male poter avere un accesso al server anche tramite SSH, ma solo se sapete già usare il Terminale, del Mac o di Linux, perfino quello di Windows (finalmente dalle parti di Microsoft si sono decisi a metterne uno decente).

Ciò che è incontrollabile. Tante guide che ho letto prestano molta attenzione (troppa attenzione, secondo me) ad aspetti come l’affidabilità del servizio di hosting, la velocità nel rispondere alle richieste di aiuto, la qualità del supporto tecnico, la reputazione dell’azienda. Purtroppo sono tutti fattori sui quali non potete avere il minimo controllo, almeno finché non provate il servizio per qualche mese (anche per questo è utile poter iniziare con dei pagamenti mensili). In teoria la reputazione aziendale può essere valutata leggendo qualche recensione sul web o dando una occhiata a quello che dicono i social. In teoria. Nella pratica le recensioni sono inutili, nel 99.99% dei casi sembrano, e sono, solo pubblicità. Sull’affidabilità di quello che compare sui social è inutile sprecare tempo e parole.

Sicurezza. Dovrei consigliarvi di scegliere un provider che curi particolarmente bene la sicurezza dei server e della infrastruttura di rete. Che disponga degli strumenti software adatti a respingere le principali tipologie di attacchi e che soprattutto sappia usarli. Che aggiorni rapidamente i software che girano sui server e magari anche quelli utilizzati dai siti web dei clienti, in modo da riparare velocemente alle vulnerabilità, agli errori di programmazione, che vengono scoperti ogni giorno e che possono essere sfruttati dai tanti malintenzionati che girano per il web. Purtroppo tutto ciò è forse ancora meno controllabile a priori della qualità del servizio offerto dal provider, e in questo caso anche i mesi di prova iniziale non bastano a darvi informazioni utili su questo aspetto (fondamentale!) del servizio. In questo caso particolare, una azienda nota e attiva da parecchi anni è potenzialmente preferibile ad una startup appena nata, ma non è neanche detto a priori, magari i gestori della startup sono particolarmente esperti in questo campo e possono agire con una rapidità ed una efficienza impossibili per una azienda di grosse dimensioni. Insomma, la questione sicurezza è veramente spinosa, l’unica cosa che mi sento di consigliare è quella di provare a verificare se il provider che avete scelto è stato soggetto ad attacchi nel passato e come ha reagito. È un consiglio molto debole, lo so, spero che qualcuno abbia delle idee migliori.

Prezzo chiaro. Questa cosa la metto alla fine, in modo che sia più evidente. Non so a voi, a me danno profondamente fastidio quei provider (e sono tanti, anche fra i più quotati, come Bluehost, SiteGround o per stare in Italia, Aruba o 1&1) che propongono un prezzo molto basso per il primo anno, che poi si duplica (o si triplica) negli anni successivi. Un sito web non è un affare di un solo anno, e anche il servizio di hosting dovrebbe essere una relazione a lunga scadenza. Un provider lo sa benissimo e, se fa così, mi da l’impressione di essere un furbetto che applica la stessa politica di marketing di un supermercato. Con la differenza che ci vuol poco a cambiare supermercato, mentre trasferire il sito da un provider all’altro è una faccenda molto più complicata.

Trasferimento. Se avete già un sito web e volete cambiare provider, siate consapevoli che trasferire il sito, fra DNS, dominio, email, database, CMS (e di tante altre cose che ora non mi vengono in mente), non è facilissimo. Se avete conoscenze tecniche sufficienti e tempo a disposizione fatelo pure da voi, in tutti gli altri casi vale decisamente la pena affidarsi al provider che avete scelto. Costa un po’ ma dubito che ve ne pentirete.

Da melabit a melabit, la serie completa degli articoli

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.

Perché open source

Thu, 02 Feb 2017 06:00:00 +0000

Free e open source

Sono da sempre un estimatore della distribuzione del software secondo il modello free o open source e se posso preferisco usare programmi di questo tipo. Anche il mio software pubblico è distribuito secondo licenze di questo tipo (ad esempio questo, appena pubblicato).

Ma perché usare il software free (ad accesso libero) o open source (a sorgente aperto)?¹

Le questioni filosofiche le lascio a personaggi del calibro di Richard Stallman, massimo esponente del movimento del free sofware e fondatore del progetto GNU, e di Eric Raymond, avvocato di un modello aperto ma più vicino agli interessi dele aziende, che hanno descritto in modo egregio i fondamenti di questi modelli di distribuzione del software in due saggi imperdibili, Free Software, Free Society e The Cathedral and the Bazaar (la bibliografia finale rimanda alle versioni italiane di questi volumi).

Leggere il codice

A me interessa affrontare qui una questione molto più spicciola e mostrare come l’accesso al codice permetta di migliorare la qualità del software e di correggerne rapidamente i bachi.

Il concetto di accesso al codice può sembrare campato in aria, riservato solo ad una piccola elite di programmatori esperti. In effetti mettere le mani nel codice è spesso molto più semplice di quanto si pensi e si può fare senza nemmeno essere programmatori esperti o particolarmente dotati.

Ecco una piccola storia pratica e personale. Non è la prima di questo genere che mi succede, ma è quella più recente.

Buttato fuori

Negli ultimi tempi mi sono occupato di sviluppare un sito web quasi istituzionale in Wordpress. La genesi è stata fin troppo lunga – ci sono sempre mille cose da fare ogni giorno – ma alla fine il sito è stato presentato ufficialmente la settimana scorsa.

Per vari motivi non ho sviluppato il sito sul mio Mac, dove avrei potuto usare un sistema di revisione e tenere traccia diretta di tutti i cambiamenti, ma direttamente sul server che ospita il sito. Anzi, per stare sicuro, per lo sviluppo vero e proprio ho usato una copia del sito, sul quale provavo le novità prima di trasferirle al sito principale.

Come è ovvio, gli ultimi giorni prima della presentazione sono stati frenetici, con un sacco di aggiunte e di modifiche dell’ultimo minuto. In questi casi la disciplina va a farsi benedire: non c’era semplicemente tempo di provare ogni cosa sulla copia prima di trasferirla al sito vero e proprio. Ed è chiaro che in questi casi, con una scadenza in vista, c’è un rischio altissimo che succeda qualche guaio all’ultimo minuto.²

Infatti.

All’improvviso, dopo chissà che operazione, sono stato buttato fuori senza complimenti dal mio account di amministratore. Il sito era lì vivo e vegeto, ma di fatto non potevo fare più niente.

Per fortuna potevo almeno accedere all’interfaccia di gestione del server. Da qui la cosa più semplice da fare sarebbe stata quella di ripristinare il sito e il database dall’ultimo backup – fatto ore prima! – cercando poi di ricordare tutto quello che avevo cambiato dopo il backup. Una cosa praticamente impossibile.

Ma per fortuna ci sono i file di log di Wordpress e lì l’errore era stampato chiarissimo, con il nome del file e la riga esatta dove si era verificato il problema. Il colpevole era un plugin di Wordpress che avevo aggiornato poco prima senza patemi. Sembrava inoffensivo: non faceva niente di fondamentale, serviva solo a configurare lo stile grafico del forum del sito.

Worpress è open source e anche i plugin lo sono, quindi il codice è disponibile e si può leggere e modificare a piacere.

Perfino uno come me, con una conoscenza solo basilare di PHP e JavaScript con cui è scritto Wordpress, con un’occhiata veloce poteva capire il motivo dell’errore, una (molto) banale svista del programmatore. Errore che però aveva conseguenze così gravi da impedirmi di lavorare al sito.

Rapida correzione, salvataggio, tutto a posto e in mezz’ora potevo di nuovo entrare nel mio account e tornare lavorare come prima.

Naturalmente sono andato nell’area di supporto del plugin e ho descritto quello che era successo e come avevo risolto il problema. In fondo, se qualcuno ti da un software gratis, è il minimo che si possa fare per sdebitarsi.

Dopo poche ore era uscita la versione aggiornata e corretta del plugin.

Provate ad avere un problema serio con un prodotto commerciale, magari pagato a caro prezzo, e poi ditemi come e in quanto tempo viene risolto. Non ci sarebbe storia.

Bibliografia

Per una volta i volumi citati sopra sono disponibili in italiano. Ho aggiunto anche un bellissimo libro di Sam Williams che tratta della vita e delle ragioni di Richard Stallman nel contesto della cultura hacker degli anni ‘80.

Eric Raymond, La cattedrale e il bazaar, 1998, Apogeo. Disponibile in italiano in una prima versione ridotta rispetto al testo originale aggiornato.
Richard_Stallman, Software libero pensiero libero - Volume primo, Stampa Alternativa, 2003. Disponibile online in formato pdf.
Richard_Stallman, Software libero pensiero libero - Volume secondo, Stampa Alternativa, 2004. Disponibile online in formato pdf.
Sam Williams, Codice Libero (Free as in Freedom, Apogeo, 2010. Disponibile online in formato ePub/Kindle e per iBooks.

Post scriptum

Oltre al senso di libertà, ciò che ho appena descritto è una delle cose più interessanti dell’open source: ci sono così tanti occhi e tanti cervelli con competenze diverse che è normalmente molto facile risolvere i problemi, molto più facile che con un team fisso di sviluppatori, con competenze per forza di cose più statiche.

E poi dai, contribuire a qualcosa senza nemmeno conoscersi, senza avere un interesse economico diretto, fa bene allo spirito e forse anche alla società. Fa meno bene al portafoglio, ma non si può avere sempre tutto.

Le differenze fra il software free e quello open source sono spiegate piuttosto bene in questo breve articolo e, in modo più approfondito, in queste pagine di Wikipedia e WikiWikiWeb. Imprescindibile anche il punto di vista del progetto GNU. ↩︎
Persino il backup a volte non basta: se si fanno modifiche continue, anche perdere un paio di ore di lavoro ripristinando da Time Machine può essere un danno gravissimo. ↩︎

Duecento

Tue, 05 Jul 2016 06:00:00 +0000

Con il post di sabato scorso siamo arrivati a 200. Due anni e mezzo di melabit e duecento post, in media uno ogni quattro giorni e mezzo. Non male, se si considerano i tanti impegni di ogni giorno, che mi impediscono di dare una periodicità più serrata al blog.

Poiché questo in fondo è un blog dedicato alla programmazione e ai sistemi operativi (anche se me ne dimentico spesso), invece di celebrare l’evento preferisco prendere la palla al balzo e descrivere alcuni semplici comandi di Terminale, che userò per fare una piccola analisi dei post scritti finora.

Lancio il Terminale (chi segue con continuità il blog dovrebbe sapere come fare, per gli altri il Terminale si trova in Applicazioni > Utility) e mi sposto nella cartella (directory) che contiene tutti i miei post,

$ cd ~/cartella/del/blog/

Per prima cosa voglio controllare di aver scritto veramente 200 post.

Sin dall’inizio ho deciso di usare per i nomi dei file sorgenti dei post il formato anno-mese-giorno-titolo-separato-da-trattini.md, dove anno-mese-giorno indica la data di pubblicazione, ad esempio 2016-07-05 per questo post, e .md è l’estensione standard dei documenti scritti in Markdown, il linguaggio di formattazione per il web che uso per scrivere questi post. La cartella contiene altri file e cartelle, ma solo i post completi hanno il nome in questo formato. Per contare i post contenuti nella cartella mi basta quindi eseguire il comando,

$ ls 20*.md | wc

che con ls (list) elenca tutti i file il cui nome inizia con il secolo corrente e termina con il suffisso .md. L’output di ls viene inviato tramite il simbolo | (pipe) ad un ulteriore comando del Terminale (in realtà della shell bash, ma oggi non voglio essere troppo pignolo), wc (word count), che conta il numero di linee, parole e caratteri (e volendo anche di byte) di un file o, come in questo caso, dell’output del comando precedente.

La risposta del Terminale è

201     202    8704

dove il primo numero rappresenta il numero di linee dell’output di ls, cioè il numero dei file elencati da ls che rispettano le specifiche stabilite dal comando (e di conseguenza il numero dei post).

Il Terminale quindi mi dice che finora ho scritto 201 post. 201? Certo, i post sono 201 perché nella lista c’è anche questo post (potrei fare in modo da non considerarlo, ma renderebbe tutto inutilmente più complicato).

C’è però un dettaglio che non torna. Il secondo numero, 202, indica il numero di parole dell’output di ls. Poichè, come già notato, il nome dei file è nel formato anno-mese-giorno-titolo-separato-da-trattini.md, che per wc equivale ad una parola singola, i primi due numeri restituiti da wc dovrebbero essere identici. Se il Terminale indica che c’è una parola in più, significa che uno dei file contiene nel nome (per sbaglio) uno spazio al posto del trattino.

Per cercare il file in questione, eseguo questa volta

$ ls 20*.md | grep " "

inviando l’output di ls a grep, uno dei tool più importanti del Terminale, che serve per cercare una o più stringhe di testo in un file. Normalmente la ricerca viene effettuata usando una espressione regolare, ma in questo caso è più che sufficiente limitarsi a cercare la presenza di un semplice spazio nell’output di ls. La risposta è,

$ 2015-12-23-first-draft-la prova.md

dove manca effettivamente il trattino fra “la” e “prova”. Correggo subito, eseguo di nuovo

$ ls 20*.md | wc
     201     201    8704

e questa volta ottengo il risultato che mi aspetto.

Ora che ci siamo scaldati, proviamo qualcosa di più divertente. Voglio sapere quante parole in tutto ho scritto finora in questi famosi 200 post. Facile, basta sostituire ad ls il comando cat (concatenate), che stampa sul Terminale il contenuto dei file indicati dopo il comando. Eseguendo

$ cat 20*.md

non faccio altro che stampare sullo schermo uno dietro l’altro il contenuto di tutti i file dei post. La stampa dei file è velocissima, ma scrollando all’indietro nel Terminale si può verificare che ci sono veramente tutti. Se volessi potrei usare less,

$ cat 20*.md | less

per stampare i file riempiendo una pagina alla volta del Terminale (e potendo anche tornare indietro). Ma non mi interessa, preferisco inviare l’output di cat a wc,

$ cat 20*.md | wc
   10639  113141  836099

da cui risulta che i 200 (anzi 201) post scritti finora sono composti in tutto da 10639 linee (che equivalgono in pratica ai paragrafi, separati fra loro da un a capo) e da ben 113141 parole.¹

Ogni post è quindi composto in media da

$ echo "113183 / 200" | bc
565

ben 565 parole.² Per calcolare la media ho usato bc, la calcolatrice integrata nel Terminale, un oggetto poco conosciuto ma a volte molto comodo. Anche in questo caso ho utilizzato il pipe (|) per inviare alla calcolatrice l’outupt di echo, il comando che stampa su schermo la stringa (o le stringhe) che lo segue. Volendo avrei anche potuto usare bc in modo interattivo,

$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
...
113183 / 200
565
quit

Il risultato non è precisissimo, ogni file dei post ha anche una intestazione che non compare su Wordpress e che contiene titolo, data, categoria e tag, e così via. E poi non bisogna dimenticare che c’è di mezzo anche questo 201-esimo post, che è già ben più lungo di 565 parole. Ma insomma, ad occhio dovremmo essere più o meno sulle 520-530 parole effettive per post.

Ma c’è modo di vedere quante parole ci sono in ciascuno dei post? Certo, basta racchiudere i comandi precedenti in un ciclo for,

$ for i in `ls 20*.md`; do echo $i; cat $i | wc -w; done

dove i è l’indice del ciclo for, a cui viene associato di volta in volta uno dei nomi di file stampati da ls. Nel corpo del ciclo do... done, per ogni valore di $i (in bash, ogni volta che si usa una variabile, le si antepone il $), si stampa con echo $i prima il valore della variabile (cioè il nome del file), poi si usa cat $i | wc -w per stampare il contenuto del file e inviarlo al contatore wc. L’opzione -w (word) di wc serve per contare solo le parole. Eseguendo il ciclo ottengo

$ for i in `ls 20*.md`; do echo $i; cat $i | wc -w; done
2013-12-18-il-migliore-spot.md
     238
2013-12-18-melabit-il-blog.md
     497
2013-12-19-una-pinta-di-tablet.md
     346
2013-12-20-la-dogana.md
     165
2013-12-21-rinominare-i-file-con-il-terminale.md
     669
...
2016-05-24-rapidweaver-7-in-anteprima.md
     729
2016-05-27-cartellino-rosso-su-facebook.md
    1385
2016-05-28-la-matematica-di-facebook.md
     356
2016-06-05-playlist-per-bora-bora-brian-boru.md
     278
2016-07-02-da-latex-a-word-e-ritorno.md
    2278
2016-07-05-duecento.md
     987

Per analizzare i dati è più comodo salvare la lista su un file, facendo in modo che il titolo del post e il conteggio delle parole stiano sulla stessa linea.

Facile, per salvare l’output di un comando di Terminale su un file si usa il simbolo > seguito dal nome del file (ricapitolando, il simbolo | invia l’output di un comando ad un altro comando, mentre il simbolo > lo invia ad un file). Per stampare titolo e conteggio sulla stessa linea, è sufficiente aggiungere al comando echo l’opzione -n (no newline).

Eseguendo il comando così modificato,

$ for i in `ls 20*.md`; do echo -n $i; cat $i | wc -w; done &#62; ~/Desktop/words.dat

compare sul Desktop il file words.dat, le cui prime 5 righe sono,

$ head -5 ~/Desktop/words.dat
2013-12-18-il-migliore-spot.md     238
2013-12-18-melabit-il-blog.md     497
2013-12-19-una-pinta-di-tablet.md     346
2013-12-20-la-dogana.md     165
2013-12-21-rinominare-i-file-con-il-terminale.md     669

esattamente come richiesto. Partendo da questi dati, è facile calcolare la distribuzione del numero di post in funzione del numero di parole,

da cui è evidente che quasi la metà dei post contiene non più di 300 parole.

Più specificatamente, si trova che la mediana è uguale a 346, che significa che metà dei post contiene meno di 346 parole e l’altra metà ne contiene di più. Forse non sono poi così prolisso come ho sempre pensato.

Domanda (facoltativa): Perché c’è questa grossa differenza fra la media e la mediana del numero di parole che compongono i miei post?

Si noti che se l’output di un comando che stampa qualcosa sul Terminale viene inviato ad un altro comando per un’ulteriore elaborazione, l’output stesso viene risucchiato dal secondo comando e non compare più sullo schermo. ↩︎
Forse sono troppo prolisso, 565 equivalgono a più di una pagina (densa) di un libro di formato medio-grande. ↩︎

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

Imparare ad usare Wordpress

Wed, 13 Apr 2016 10:00:00 +0000

È parecchio tempo che non consiglio qualcuno dei volumi offerti giornalmente da Packt. Ma oggi si può scaricare liberamente WordPress 3 Complete, e non posso evitare di segnalarlo, perché WordPress è il sistema di gestione dei contenuti (CMS) più diffuso e popolare, che chiunque sia interessato al web non può esimersi dal conoscere.

La fama non è immeritata, perché WordPress coniuga al meglio potenza e facilità d’uso, e le sue pecche sono di sicuro inferiori ai suoi meriti. Non è un caso che anche questo piccolo blog giri (ancora) sotto Wordpress.

Buona lettura!

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

Un dominio personale

Thu, 06 Mar 2014 06:00:00 +0000

Dopo solo due mesi dalla nascita di questo blog i limiti di Wordpress.com sono diventati evidenti, tanto da spingermi ad acquistare (tecnicamente affittare) il dominio melabit.com/posts/it in modo da poter effettuare una transizione su una piattaforma più flessibile.

Devo ammettere che nel complesso Wordpress.com non è affatto male. L’interfaccia di gestione del blog è un po’ pesante, è vero, ma comunque è molto migliorata negli ultimi anni. Anche la configurazione del blog è sufficientemente flessibile, soprattutto se teniamo conto che le funzionalità principali della piattaforma sono totalmente gratuite.

Mi è anche piaciuta la possibilità di poter provare i temi grafici sul sito live, che è l’unico modo per testare in modo approfondito l’effetto reale del tema grafico scelto. Io ho dovuto scartare moltissimi temi che mi piacevano solo perché non mostravano in modo accettabile i (pochi finora) frammenti di codice che ho inserito nel testo dei post. Probabilmente su un semplice sito di prova non sarei riuscito ad accorgermi di questi dettagli, o me ne sarei accorto troppo tardi.

Al confronto, Blogger è tremendo. L’ho provato a lungo prima di decidere e mi è sembrato decisamente meno pratico da usare di Wordpress.com. Una delle cose più sgradevoli era il fatto che ogni cambiamento del tema scombinasse completamente l’impostazione del sito: per correggere gli errori dovevo resettare tutto alle impostazioni di default o, a volte, perfino correggere a mano il codice di impostazione dei widget! Per uno strumento rivolto agli utenti comuni e prodotto da un gigante come Google non è certo un buon biglietto da visita.

Però anche Wordpress ha gravi limiti. I due più seri e legati fra loro sono l’impossibilità di effettuare il backup del sito e la cattiva implementazione del codice di markdown, utilizzabile per scrivere i post al posto dell’html. All’inizio è successo parecchie volte che il sorgente in markdown venisse convertito in html, senza alcuna possibilità di recuperarlo da un backup.

Per non perdere il sorgente degli articoli sono quindi stato costretto a scrivere il testo degli articoli sul Mac con un editor specifico per markdown (io preferisco MultiMarkdown Composer e Markdown Pro, ma ne riparleremo in dettaglio prima o poi) per poi copiarlo a mano nell’editor online di Wordpress.

Decisamente poco pratico, anche perché poi ogni ulteriore correzione prima della pubblicazione del post deve essere sincronizzata con il sorgente sul Mac. E da (anche) sviluppatore, trovo assurdo il dover tenere lo stesso codice in posti diversi, una pratica che induce troppo facilmente all’errore.

Un’altro limite, meno serio, è legato alle immagini. L’upload dei file grafici è molto lento e bisogna necessariamente usare l’html per inserire le immagini nel testo dell’articolo, o almeno io non sono riuscito a farlo in markdown.

Insomma, è arrivata rapidamente l’ora di cambiare. Il nome di dominio personale è il presupposto. Ma per la transizione vera e propria ci vorrà ancora tempo.