Octopress on Melabit

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

Automatizzare il Mac dal Terminale - Sua maestà cron

Sat, 22 Nov 2014 06:00:00 +0000

Nella prima parte di questa serie abbiamo visto come usare il comando at per automatizzare determinate attività sul Mac dal Terminale.

At è utile ogni volta che si vuole eseguire un comando automaticamente una sola volta e in un momento ben definito

Ma at ha anche parecchi limiti e non è adatto a svolgere una attività periodica in modo trasparente, come richiesto da Lucio Bragagnolo nel post da cui ha preso spunto questa serie.

Un demone chiamato cron

Lo strumento più adatto a questo scopo è cron, il cui nome deriva dal greco chronos (tempo). Cron permette di eseguire comandi singoli o interi script, in modo automatico ad una data e ora stabilita, con una precisione che arriva fino al minuto.

Cron è nel gergo di Unix un demone, un comando eseguito automaticamente all’avvio di OS X (o di Linux) che rimane sempre attivo in sottofondo e agisce senza necessità di alcun intervento da parte dell’utente. Cron si attiva ogni minuto ed esegue (quando serve) i comandi contenuti nel file crontab di configurazione.

Ogni utente del Mac ha a disposizione un proprio file crontab, ma esiste anche un file crontab di sistema gestito dall’amministratore, normalmente il primo utente creato al momento della installazione di OS X. I file crontab degli utenti sono contenuti nella directory /usr/lib/cron/tabs/ e si chiamano con il nome account (o nome breve) dell’utente, quello di sistema è /etc/crontab.

Non c’è bisogno di precipitarsi a controllare, nelle nuove versioni di OS X il file /etc/crontab non esiste più, come vedremo la prossima volta.

Dal Terminale, si può visualizzare il contenuto del proprio file crontab con il comando

$ crontab -l

mentre per modificarlo bisogna necessariamente usare

$ crontab -e

e mai un editor di testo (cosa fra l’altro impossibile senza essere amministratore del Mac).

Infine il comando per cancellare il proprio file crontab è

$ crontab -r

Com’è fatto crontab

Ma come è fatto un file crontab? È piuttosto semplice: un file crontab è composto da una o più righe contenenti ciascuna sei campi (colonne) separati da spazi

*	*	*	*	*	comando

Nei primi cinque campi si inseriscono le indicazioni di data ed ora, sostituendole agli asterischi, nell’ultimo campo il comando o il nome dello script da eseguire. Ad esempio,

05	*	*	*	*	echo "Tanti saluti da cron!"

stamperà sul Terminale al quinto minuto di ogni ora la stringa “Tanti saluti da cron!”

In realtà sul Terminale non viene mai stampato nulla. Infatti, analogamente ad at, ogni volta che cron esegue un comando definito nel file crontab di un utente, provvede ad inviargli una email con l’output completo generato dal comando stesso, email che può essere letta dal Terminale con (chi ci avrebbe mai pensato!) mail. La ragione è semplice: cron potrebbe agire dietro le quinte per mesi od anni, effettuando azioni periodiche come il backup in rete di determinate directory o la pulizia del sistema da certi file inutili. È più razionale inviare all’utente interessato una email che gli permetta di controllare, quando ne ha tempo e voglia, che tutto vada bene, invece di disturbarlo periodicamente mentre sta usando il Terminale con l’output delle azioni eseguite da cron.

Per disabilitare l’invio della email mandando l’output del comando eseguito da cron sul file output.txt sul Desktop, si può utilizzare la tecnica standard di Unix di redirezione dell’output

05	*	*	*	*	echo “Tanti saluti da cron!” » ~/Desktop/output.txt

dove il simbolo » aggiunge l’output del comando eseguito da cron alla fine del file output.txt (usando un solo > si sovrascrive ogni volta il contenuto precedente del file).

Data e ora in cron

Rimane da definire come sono codificate le indicazioni della data e dell’ora a cui eseguire cron. Non è molto difficile, almeno se ci si limita ai casi più comuni. La figura seguente mostra il significato dei campi del file crontab.

[caption id=“attachment_1418” align=“aligncenter” width=“500”] Significato dei campi di una riga del file crontab.[/caption]

Quindi per eseguire un comando al quindicesimo minuto di ogni ora bisogna inserire la riga

15	*	*	*	*	comando

mentre per farlo alle 2:00 di ogni lunedì

00	02	*	*	1	comando

Alcuni simboli permettono di specificare dei valori multipli in un campo. Il trattino “-” indica un intervallo, per cui la riga

30 07	*	*	1-5	comando

esegue il comando alle 7:30 dal lunedì al venerdì.

La virgola “,” indica una lista di valori. Quindi

00	08	1,15,30		*	*	comando

esegue il comando specificato il giorno 1, 15 e 30 di ogni mese.

L’asterisco equivale a selezionare tutti i valori consentiti per il campo a cui si riferisce. Una riga come questa

*	*	*	*	*	echo "Tanti saluti da cron!"

istruisce cron ad eseguire il comando echo "Tanti saluti da cron!" una volta al minuto e per sempre!

Infine la barra “/” indica l’incremento del campo numerico, per cui

*	*/3	*	*	*	echo "Tanti saluti da cron!"

equivale a far eseguire il comando ogni 3 ore.

Tutto qui. Ci sono delle finezze ulteriori, ma chi fosse interessato può leggere qualche articolo specifico su cron, come questa pagina su Wikipedia¹, o questo tutorial molto dettagliato.

Cron online

Per i più pigri esiste un servizio online che genera automaticamente la riga del file crontab corrispondente alle date e ore specificate tramite l’interfaccia web. Ma si fa prima ad imparare la sintassi di cron che ad orientarsi nella miriade di opzioni del servizio.

Molto più utile mi sembra il Cron Sandbox, un altro servizio online che consente di verificare che la lista di date e ore generate da una particolare riga del file crontab corrisponda a quanto ci si attende.

Al lavoro

Se vogliamo usare il comando cron per eseguire lo script ~/bin/makeblog e rigenerare automaticamente il blog “Pazzi per la mela” alle 2:00 di ogni notte, dobbiamo inserire nel file crontab la riga

00	02	*	*	*	~/bin/makeblog

e dimenticarci subito dopo della sua stessa esistenza. Cron lavorerà per noi ogni notte, preciso ed instancabile senza infastidirci, a meno che non decidiamo di andare a controllare quello che sta combinando.

E Lux?

Non mi sono dimenticato di Lux. Come già ricordato la volta scorsa, Lux vorrebbe poter scrivere i post del suo blog lasciando al sistema il compito di aggiornare i file html e di trasferirli sul server per la pubblicazione online. E vuole farlo indifferentemente dal Mac o dall’iPad (e perché no, anche dall’iPhone).

Con cron è semplice. Basterà mettere la directory contenente i vari pezzi del blog Octopress dentro la cartella di Dropbox del Mac ² e creare lo script makeblog, configurando cron in modo da eseguirlo automaticamente all’ora desiderata.

Se Lux volesse poter aggiornare il blog quattro volte al giorno (esagerato!) alle ore 0, 6, 12 e 18, dovrebbe inserire in crontab la riga

00	*/6	*	*	*	~/bin/makeblog

oppure qualcosa di più specifico come

30	1,5,12,19	*	*	*	~/bin/makeblog

adattando così gli orari di aggiornamento ai propri ritmi di lavoro.

Ogni volta che Lux scrive un nuovo post con il Mac non dovrà fare altro che salvarlo nella directory giusta della sua installazione di Octopress, né più né meno di come fa già ora. Se invece usa l’iPad o l’iPhone, deve solo ricordarsi di inviare il post a Dropbox, scegliendo la stessa directory che usa sul Mac. Appena l’iPad si troverà connesso ad una rete, invierà il nuovo file a Dropbox, che lo spedirà a sua volta al Mac.

Tutto automatico, senza Apple Script, Azioni Cartelle, e mal di testa.

Conclusioni

Con cron the sky is the limit, o quasi. Io per anni ho fatto fare a cron il backup completo del contenuto di un sito web professionale, contenente centinaia di documenti e di programmi da distribuire agli utenti registrati, e del relativo database MySQL. Una volta scritto lo script che eseguiva il backup vero e proprio (questa è stata la cosa veramente complicata, visto che volevo mantenere backup multipli orari, giornalieri e mensili), ho lasciato fare a cron e… me ne sono letteralmente dimenticato.

Ma non finisce qui. La prossima volta mi toccherà parlare di launchd. Come potrei evitarlo, visto che questo blog è focalizzato (più o meno) sul Mac?

Poteva mai mancare un riferimento ad una pagina di Wikipedia? MA non è certo colpa mia se Wikipedia è una delle cose migliori del web e che tante pagine sono fatte veramente bene. ↩︎
Si potrebbe anche usare un collegamento simbolico o un altro servizio di condivisione dei file, ma non generalizziamo troppo. ↩︎

Automatizzare il Mac dal Terminale - Il comando at

Thu, 06 Nov 2014 06:05:00 +0000

Qualche giorno fa Lucio “Lux” Bragagnolo ha pubblicato sul suo interessantissimo blog (da seguire assolutamente ogni giorno!), un post in cui poneva una domanda molto stimolante. Lascio a lui la parola per descrivere il problema:

Octopress – il motore di questo blog – si basa su una cartella che risiede nel Mac. La cartella contiene sottocartelle varie che ospitano i pezzi del blog. Pubblicare questo articolo significa creare un file e metterlo nella giusta cartella, per poi dare un comando di Terminale che genera una edizione aggiornata del blog e un altro comando di Terminale che deposita una copia dell’edizione dentro il server di pubblicazione.
Spesso mi trovo a scrivere pezzi per il blog su iPad, lontano da Mac. Facciamo finta che il Mac rimanga irraggiungibile fisicamente per tutta la giornata. Qual è la strategia che richiede meno lavoro in assoluto per pubblicare il pezzo?

Detto in modo più generale, la domanda di Lux è:

quali strumenti possono essere usati sul Mac per automatizzare determinate attività nel modo più semplice e veloce possibile?

Nella discussione che è seguita sul blog il mio incontrollabile alter ego virtuale ha proposto velocemente due o tre possibili soluzioni, promettendo anche di approfondirle appena possibile.

Credo che questo sia lo spazio migliore per farlo, tornando finalmente a discutere di argomenti connessi alla programmazione e alla amministrazione del Mac, dopo parecchio (troppo!) tempo dedicato a divagazioni più o meno lontane dal target principale del blog.

Introduzione

Sul Mac sono disponibili diversi strumenti che permettono di automatizzare le operazioni effettuate sul sistema. Mi concentrerò qui sui comandi di derivazione Unix presenti di default in OS X, perché sono strumenti ben testati ed affidabili e sono utilizzabili anche su piattaforme diverse dal Mac.

Avrei voluto concentrare la discussione in un unico post, ma mi sono accorto che raggiunto una lunghezza eccessiva e difficile da digerire in una sola volta.

Ho deciso quindi di dividere la trattazione in più parti distinte. In questa prima parte mostrerò l’uso di at, il comando più semplice disponibile su OS X per questo scopo.

Nei prossimi post mostrerò l’utilizzo di strumenti più avanzati come cron e launchd. Cercherò poi di descrivere ulteriori prodotti di terze parti ed eventualmente anche una soluzione basata su Automator (ammesso che questa sia in grado di fare al meglio quanto richiesto, cosa di cui non sono troppo sicuro in questo momento).

Per evitare di essere troppo vago cercherò di circoscrivere il problema, basandomi strettamente su quanto richiesto da Lux, ma provando anche a rendere facile l’estensione di quanto descritto a casi più generali.

Pazzi per la mela

Supponiamo di voler automatizzare la pubblicazioni dei nuovi post sul blog “Pazzi per la mela”, raggiungibile all’indirizzo IP http://pazziperlamela.it (inutile cliccare sul link, il blog non esiste).

Pazzi per la mela utilizza Octopress per convertire i file di testo che costituiscono ciascun post in pagine html statiche, che devono essere poi copiate sul server remoto che gestisce il sito web del blog.

Sul Mac, tutti i testi dei post e i file di configurazione del blog si trovano nella cartella ~/Documenti/pazziperlamela/, dove ~ indica per convenzione la cartella Inizio (o home) dell’utente del Mac, identificata nel Finder dall’icona di una casetta.

Ogni volta che si aggiungono nuovi post o si modificano quelli già esistenti, bisogna rigenerare le pagine html, eseguendo dal Terminale i comandi

$ cd Documenti/pazziperlamela/

per posizionarsi all’interno della cartella del blog, e poi

$ rake generate

per ricreare sul Mac le pagine html che costituiscono il sito web del blog. Un ulteriore comando

$ rake deploy

sincronizza le pagine html modificate con il server remoto tramite rsync, probabilmente il migliore strumento di sincronizzazione bidirezionale fra un server remoto e il sistema locale.

Mettiamo insieme questi comandi creando un semplice script di shell,

	#!/bin/bash
	cd ~/Documenti/pazziperlamela/
	rake generate
	rake deploy

salviamolo in ~/bin con il nome makeblog e rendiamolo eseguibile (le istruzioni dettagliate si trovano in Script di shell in OS X).

E arriviamo finalmente alla parte centrale del post.

Supponiamo di voler rigenerare automaticamente il blog “Pazzi per la mela” una volta al giorno, magari alle 2:00 di notte per evitare che troppi lettori siano collegati nel momento in cui vengono modificate le pagine del blog.

Vediamo come farlo, usando il comando più semplice presente sul Mac

Un comando semplice semplice

Lo strumento più semplice che possiamo usare sul Mac per automatizzare determinate operazioni è at, che esegue uno o più comandi alla data e ora specificata. La sintassi di at adatta a questo scopo è

$ at -f script -m ora data

dove script è il nome dello script di shell contenente i comandi da eseguire, mentre ora e data possono essere specificate sia in modo assoluto, ad esempio “02:00” oppure “02:00 Nov 06” (senza virgolette), che in modo relativo, “now + 1 minute”, “tomorrow”.

In alternativa si può specificare la data e l’ora in formato POSIX,

$ at -f comando -m -t YYYYMMDDhhmm

cioè scrivendola al contrario di come siamo abituati, iniziando dall’anno e finendo con i minuti. Qui YYYY indica l’anno, MM il numero del mese, DD il giorno, infine hh e mm l’ora e i minuti. Tutti gli elementi della data vanno inseriti usando due (o quattro) cifre e facendoli precedere eventualmente da uno zero. In questo formato, il 6 Novembre alle ore 2:00 diventa “201411060200”

Per motivi che mi sfuggono, il comando at è disabilitato di default in OS X. Per attivarlo bisogna eseguire da Terminale

$ sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.atrun.plist

dopo di che il comando at rimarrà disponibile anche riavviando il Mac.

Si può ora utilizzare at per eseguire automaticamente lo script di shell makeblog all’ora desiderata, scrivendo nel Terminale

$ at -f ~/bin/makeblog -m 02:00 tomorrow

Il Terminale (o meglio bash) ci risponderà con l’indicazione della data e dell’ora completa alla quale verrà eseguito lo script. Dopo averlo completato, inoltre, bash sarà tanto gentile da inviarci una email con l’output completo prodotto dallo script.

A meno di non configurare opportunamente il servizio di posta elettronica interno di OS X (una cosa che va ben oltre gli scopi di questo post), questa email però non riuscirà a raggiungere la nostra abituale casella di posta elettronica. Potrà però essere letta dal Terminale con il comando (poteva essere diversamente?) mail.

Troppo semplice per essere utile?

Purtroppo il comando at non è adatto a soddisfare quanto richiesto da Lux.

Infatti, dopo aver finito di scrivere un nuovo post, Lux dovrebbe comunque lanciare il Terminale e configurare at in modo da fargli eseguire lo script makeblog alle due della notte successiva. Se invece sta usando l’iPad, dovrebbe collegarsi tramite ssh al Mac e fare la stessa cosa da remoto.

Ma, avendo accesso al Terminale, e indipendentemente dal fatto che avvenga in locale o in remoto, è molto più semplice eseguire direttamente lo script makeblog, senza complicarsi ulteriormente la vita.

Quindi at non serve a niente?

Certo che at serve (altrimenti che senso avrebbe avuto scrivere questo post?). Ma serve nei casi in cui si vuole eseguire una determinata attività sul Mac automaticamente e una volta sola, mantenendo il pieno controllo del momento esatto in cui viene fatta partire.

Se invece vogliamo eseguire un’attività periodicamente e quasi dimenticandocene, at non serve e bisogna usare per forza di cose degli strumenti più avanzati.

Il mio incontro con at

Sono sicuro di non aver mai usato finora at su OS X, ma questo comando mi è stato utilissimo diversi anni fa, quando ho avuto accesso a delle favolose workstation Sun.

All’epoca dovevo eseguire delle simulazioni che duravano parecchie ore. Un semplice PC era improponibile: non solo perché era troppo lento, ma anche perché c’era sempre qualcuno che, zelante, lo spegneva la sera passandoci davanti (nonostante tutti i cartelli di avviso che potevo mettere davanti al monitor).

Un amico grande esperto di Unix (ho imparato i fondamenti da lui!) mi permise allora di usare le workstation Sun del laboratorio di elaborazione video che gestiva.

Per ottimizzare l’uso delle macchine e non dare fastidio agli altri utenti, dovevo però lanciare le simulazioni di notte, quando i sistemi erano quasi inattivi. Passavo poi gran parte della giornata successiva a controllare e ad elaborare i dati prodotti durante la notte e a preparare i file di configurazione per le successive elaborazioni notturne.

Questo ciclo, preparazione-calcolo-elaborazione, mi impediva di usare cron (un comando che vedremo la prossima volta), che avrebbe eseguito ciecamente le simulazioni ogni notte al momento stabilito, anche nei week-end o nei giorni in cui per qualche motivo non ero riuscito ad elaborare i dati.

Invece at era perfetto per questo scopo. Una volta completata la scrittura dei nuovi file di configurazione, li trasferivo tramite rete locale sulle Sun e configuravo at in modo da eseguire un nuovo ciclo di simulazioni la notte successiva. Semplice e veloce.

Accessori ma sempre utili

Fra i comandi di supporto di at, sono particolarmente utili atq, che permette di elencare i comandi at in attesa di essere eseguiti, e atrm seguito da un numero intero, che cancella il comando at in coda identificato dal numero intero associato. Ad esempio

$ atq
35	Thu Nov  6 02:00:00 2014
36	Thu Nov  6 06:00:00 2014
37	Sat Nov 15T12:15:00:00 2014

$ atrm 36
$ atq
35	Thu Nov  6 02:00:00 2014
37	Sat Nov 15T12:15:00:00 2014

Se si vuole disabilitare di nuovo at, bisogna eseguire da Terminale

$ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.atrun.plist

Conclusioni

In questo lungo post abbiamo visto il più semplice comando che può essere utilizzato per automatizzare determinate attività sul Mac. Nel prossimo post affronteremo cron, il re indiscusso degli strumenti adatti a questo scopo.