Web on Melabit

RIP Linux Journal

Fri, 15 Dec 2017 18:00:00 +0000

La notizia è di pochi giorni fa, non ci sono più soldi e Linux Journal ha dovuto cessare le pubblicazioni. L’ennesima rivista che muore perché non riesce più a reggere la concorrenza del web. Ha resistito più di BYTE e di Dr. Dobb’s, sarà solo una piccola soddisfazione ma è sempre meglio di niente.

Linux Journal è stata per tanti anni la migliore rivista dedicata a Linux e al mondo del free software, nessuna rivista concorrente è mai riuscita ad ergersi al suo livello.¹

Purtroppo anche per Linux Journal a un certo punto è arrivata la crisi: la pervasività di internet, la disponibilità pressoché immediata sul web di notizie e di informazioni tecniche, spesso anche di livello eccellente, ha reso sempre più irrilevanti le riviste tradizionali. Che senso aveva comprare Linux Journal per (ri)leggere cose che avevi già visto due mesi prima sul web?

Nemmeno l’abolizione della versione cartacea della rivista ed il passaggio ad una diffusione solo elettronica sono riuscite a invertire la parabola discendente, anzi forse l’hanno persino accentuata. Parecchi lettori insoddisfatti sono scappati via, la diminuzione degli introiti ha avuto conseguenze negative sulla qualità dei contenuti allontanando ancora di più i lettori affezionati, che conservavano religiosamente le copie di carta dei tempi belli (anche io sono stato a lungo fra questi).

Ma i ricordi e la storia sono importanti e, nonostante la disaffezione, ho voluto subito comprare l’archivio completo della rivista (in html), con gli articoli pubblicati dal primo numero del 1994 all’ultimo di novembre di quest’anno. Un paio di anni fa infatti, a causa di una perdita d’acqua, ho perso tutti i vecchi numeri tenuti incautamente in uno scatolone in cantina, e anche se non sono esattamente un appassionato della lettura su congegni elettronici, la versione elettronica della rivista è sempre meglio che niente. Del resto costa meno di 11 euro, un vero affare, anzi praticamente un furto.

Riuscire ad acquistare l’archivio di Linux Journal però non è facile, ad ulteriore dimostrazione del decadimento degli ultimi tempi. Sulla home page non si trova nessun link, con Google sono arrivato a questa pagina, dalla quale però non si riesce ad inserire l’ordine nel carrello. Invece questo link funziona perfettamente, ma ci ho messo dei giorni per accorgermene.

Se è difficile comprare regolarmente ciò che resta di Linux Journal, è facilissimo invece arrivare ad una pagina non protetta del sito della rivista che contiene tutti i numeri disponibili in formato elettronico (che in teoria sono ancora in vendita), prima solo in pdf e poi anche in epub e mobi. Ho comprato regolarmente l’archivio ufficiale e quindi non mi sento in colpa a scaricarli (ma penso che l’amministratore del sito farebbe meglio a cambiare mestiere).

Per chi ha più scrupoli di me, segnalo che tutti i numeri usciti in pdf di Linux Journal (cioè quelli pubblicati a partire da aprile 2005) sono già stati archiviati anche su Archive.org, dove chiunque può leggerli o scaricarli in modo del tutto legale.

Il contenuto della rivista in formato html è accessibile anche dal sito di Linux Journal, ma come al solito non c’è nessun link che permetta di arrivarci dalla pagina principale (e probabilmente nemmeno dalle altre). Lo storico primo numero si trova a questo link, https://www.linuxjournal.com/issue/1, per accedere agli altri basta cambiare opportunamente il numero alla fine dell’URL (l’ultimo numero disponibile è il 206 di giugno 2011). In questo caso l’amministratore del sito non ha colpe, era normale per Linux Journal rendere liberamente accessibili i numeri della rivista dopo alcuni mesi dalla pubblicazione. Probabilmente hanno smesso di farlo quando hanno lanciato l’edizione digitale migliorata della rivista. Provatela ed avrete una sorpresa.

R.I.P., Linux Journal, che gli elettroni ti siano lievi.

A parte Linux Gazette, che però più che una rivista era una fanzine per il web pubblicata da volontari appassionati di Linux (l’archivio funzionante di tutti i numeri di LG si trova qui). ↩︎

Viaggetto

Sat, 07 Oct 2017 06:00:00 +0000

Per fortuna internet non è solo sciocchezze o vere e proprie truffe, ogni tanto si possono trovare vere e proprie oasi di bellezza e di maestria tecnica.

Se avete qualche minuto libero godetevi questo viaggetto in treno, sono sicuro che non ve ne pentirete. Funziona su tutti i browser che supportano WebGL, anche quelli per tablet e smartphone.

RapidWeaver 7 in anteprima

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

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

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

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

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

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

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

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

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

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

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

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

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

Dieci anni perduti

Mon, 16 Mar 2015 20:00:00 +0000

Notiziona oggi sul sito di Repubblica,

[caption id=“attachment_1758” align=“aligncenter” width=“605”] Symbolics.com, il primo dominio “web” secondo Repubblica [/caption]

La preistoria del web: 30 anni di dominio .com

e ancora,

Il 15 marzo 1985 dalla Symbolics (nella foto), azienda statunitense che si occupava di informatica, la prima registrazione del dominio .com. […] Ma tra i dinosauri del web c’erano anche tante realtà minori, che operavano prima ancora che l’IT crescesse con la bolla della New Economy e che i social network segnassero la svolta."

Strano, ero sicuro che il web fosse stato concepito solo nel 1989 da Tim Berners-Lee al CERN e che fosse stato descritto sul newsgroup alt.hypertext solo nel 1991.

Ricordavo anche che Mosaic, il primo (o quasi) browser grafico per il web, era stato rilasciato nel 1993.

Accidenti, ricordavo male, il web invece esisteva già da 10 anni.¹

Peccato averli persi. ;)

È vero che il primo dominio .com è stato registrato il 15 marzo del 1985 da Symbolics, symbolics.com. Ma un dominio internet non implica necessariamente il web, in origine serviva solo a dare un nome facile da memorizzare ad un insieme di computer presenti in rete. Ma sarà mica necessario documentarsi prima di scrivere, no? ↩︎

And the winner is...

Wed, 31 Dec 2014 06:00:00 +0000

Riassunto delle puntate precedenti. Wordpress.com è un’ottima piattaforma di blogging, ed ha il grosso vantaggio di liberare l’utente da tutte le preoccupazioni riguardanti la manutenzione del proprio blog. Non è però una piattaforma che si adatta bene al mio modo di lavorare, e ne ho già scritto diffusamente alcuni mesi fa. Però cosa scegliere fra le varie tipologie disponibili: wiki o CMS o piattaforme di blog, siti statici o siti dinamici? Per vari motivi mi sono orientato verso un generatore di siti statici, un programma che prende una serie di file di testo, di immagini e di documenti e li converte in un sito web completo secondo un tema grafico predefinito. In rete ci sono letteralmente decine e decine di generatori di siti statici ed il loro numero cresce molto rapidamente: erano 289 all’inizio di agosto, oggi sono ben 388! Come orientarsi in questo marasma? Basandomi su una lista di caratteristiche irrinunciabili (almeno per me), ne ho provati e scartati parecchi, buon ultimo Hugo, promettente ma rivelatosi alla fine piuttosto immaturo.

In realtà avevo deciso subito. Tutte le prove che ho fatto mi sono servite solo ad esplorare il più possibile il territorio, a provare le alternative e a verificarne i vantaggi e gli svantaggi.

La scelta più ragionevole, date le premesse, era solo una: Jekyll.

Per due ragioni fondamentali: prospettive di sviluppo del codice a medio-lungo termine e disponibilità di documentazione abbondante e di buona qualità. Senza queste due caratteristiche non si va avanti. Tutti gli altri generatori di siti web statici possono anche apparire interessanti, ma impallidiscono se li si confronta a Jekyll su questi due aspetti.

Tanto per fare un esempio: che senso avrebbe avuto scegliere uno dei tanti progetti giocattolo di un singolo programmatore? Può anche essere eccellente, ma quante sono le probabilità che continui ad essere sviluppato fra uno, due, tre anni? Magari fra sei mesi il programmatore si stanca e passa ad altro, non rispondendo più alle richieste di supporto o di correzione degli inevitabili errori. Che si fa, allora? Oppure: come si può cercare di configurare ed estendere il sistema prescelto se non esiste della buona documentazione, se magari l’unico modo per capire cosa fa il programma è analizzarne i sorgenti (auguri)?

Infatti fra i 388 generatori di siti statici elencati oggi da Static Site Generators, ben 171 non sono aggiornati da almeno un anno e 225 da sei mesi. E solo una settantina ha ricevuto un aggiornamento nell’ultimo mese. Insomma, ci sono circa 320 progetti censiti che in realtà sono morti, inutili, da scartare a priori.

I primi due generatori di siti web statici nella lista di StaticGen, Jekyll e il suo derivato Octopress, hanno ricevuto insieme su GitHub più di un terzo delle stelle – cioè delle manifestazioni esplicite di interesse nel progetto – guadagnate da tutti i 67 progetti elencati nel sito.¹ Non sarà che sono ritenuti così interessanti perché sono fatti bene e sono (relativamente) facili da usare e da metterci le mani?

Ora rimane solo da rimboccarsi le maniche, configurare Jekyll e trasportare il blog sulla nuova piattaforma.

Ma prima di allora, auguro a tutti coloro che pazientemente seguono questo blog un 2015 felice e, se possibile, migliore dell’anno che ci stiamo lasciando alle spalle!

Immagino che StaticGen censisca solo i progetti sviluppati attivamente. Probabilmente non è un caso che, se si considerano attivi solo i progetti aggiornati nell’ultimo mese, i numeri di Static Site Generators e di StaticGen concidano. Sarebbe interessante verificare se i progetti sono veramente gli stessi. ↩︎

Hugo, la prova

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

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

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

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

Installazione

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

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

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

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

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

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

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

$ brew install hugo

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

Un sito di prova

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

$ cd Documenti
$ hugo new site testhugo

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

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

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

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

  $ cd Documenti/testhugo
  $ hugo [opzioni]

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

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

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

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

4 directories, 2 files

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

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

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

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

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

### Chi sono

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

Io sono. Io chi sono?

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

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

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

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

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

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

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

5 directories, 3 files

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

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

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

$ hugo server --buildDrafts

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

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

Un po’ di stile

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

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

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

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

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

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

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

$ hugo server --theme=hyde --buildDrafts

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

Tutto bene?

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

Nemmeno per sogno.

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

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

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

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

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

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

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

Conclusioni

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Catastrofismo targato Apple

Sun, 10 Aug 2014 06:00:00 +0000

“Un futuro oscuro per Apple.”
“Dopo Steve Jobs Apple sta perdendo colpi?”
“Perché Apple fallirà nei prossimi 2 anni nonostante abbia riserve per 159 miliardi di dollari.”
“L’iWatch sarà un totale fallimento se Apple non esce a presentarlo entro i prossimi 15 giorni.”
“Steve Jobs aveva programmato l’uscita dei nuovi prodotti per due anni. Cosa succederà ora?”

Vuoi aumentare la popolarità del tuo sito web? Vuoi creare con poco sforzo pagine web cliccatissime? Vuoi aumentare gli introiti del tuo sito web?

Per farlo non c’è niente di meglio che inventare notizie sulla Apple. Vere, false, verosimili, non importa, quello che è veramente importante è parlare di Apple, meglio se in termini apocalittici.

Ma perfino scrivere notizie false costa tempo e fatica.

Da oggi tutti i tuoi problemi sono risolti, hanno pensato a te con l’Apple Clickbait Generator, il generatore di notizie casuali sulla Apple. Ad ogni click, un nuovo articolo catastrofico sulla Apple.

Che importa che sia totalmente inventato, a te interessano solo i click.

Peccato solo che devi tradurre almeno le parti più significative in italiano. Ci vorrebbe un bel traduttore automatico…

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

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

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

Come orientarsi in questa moltitudine?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cosa voglio allora?

Voglio un sito web statico ma allo stesso tempo moderno.

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

Insomma, voglio un generatore di siti web statici.

Il sistema prescelto deve:

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

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

I limiti di Wordpress.com

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

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

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

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

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

Però è ormai diventata troppo stretta per me.

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

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

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

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

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

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

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

La musica è finita

Fri, 25 Jul 2014 06:00:00 +0000

Jaron Lanier, uno dei pionieri del web, in una recente intervista a Riccardo Staglianò su il Venerdì di Repubblica sostiene che “il web sta uccidendo la classe media”, distruggendo industrie che fino a pochi anni fa fatturavano miliardi di dollari – l’industria musicale, quella della fotografia, le agenzie di viaggio, le librerie, i giornali – sostituendole con nuovi servizi che “impiegano un millesimo dei dipendenti della old economy”.

Non ho le competenze per discutere l’affermazione generale. Ma credo anche che le cause della crisi dell’industria musicale siano siano piuttosto diverse.

È ormai un luogo comune: l’industria musicale è stata messa in crisi negli ultimi 15 anni da Napster prima, da iTunes dopo e dall’online oggi. Sempre secondo i dati dell’intervista, oggi l’industria musicale “Vale un quarto di quanto valeva solo pochi anni fa. Presto varrà un decimo”.

Ma siamo sicuri che queste siano veramente le cause del declino dell’industria musicale? O che il declino non sia dovuto invece soprattutto alla scarsa qualità della musica prodotta e venduta oggi?

Ascolto moltissima musica e la maggior parte è costituita da dischi prodotti negli anni ‘60 e ‘70, dischi intramontabili, capolavori del rock e del jazz, con parecchie incursioni nella musica cosiddetta “classica”.

Dischi da ascoltare dall’inizio alla fine, costituiti spesso da brani legati fra loro da un filo logico, quasi fossero una sinfonia ottocentesca.

Oggi invece l’industria musicale sforna quasi esclusivamente hit da consumare velocemente, uno o due brani accattivanti cuciti insieme a robaccia senza pretese, per produrre un disco che poi nessuno vuole. Ovvio che poi chi li ascolta preferisca scaricare (legalmente o illegalmente, non importa in questo momento) solo l’hit del momento, lasciando il resto all’oblio che merita.

E anche al di fuori della musica più commerciale, non è che le cose vadano meglio. Il jazz riproduce se stesso, ripetendo all’infinito temi e idee del passato. Un po’ di fusione con altri generi musicali, e poi?

La classica è cristallizzata all’ottocento, sempre e solo gli stessi dieci autori e le solite composizioni. L’ultima idea un po’ originale è stata quella di recuperare gli strumenti originali e il modo di suonarli, diventata presto una filologia rigida e decisamente stucchevole.

Ci sono poi questioni ulteriori che non fanno altro che peggiorare la situazione.

I CD costano e tanto, i prezzi sono rimasti praticamente stabili nel corso degli anni nonostante che i costi di produzione e di realizzazione siano ormai bassissimi. Negli anni ‘80, all’inizio dell’era del CD, l’alto costo del CD veniva imputato alla necessità di ammortizzare il costo degli impianti. Dopo più di trent’anni gli impianti saranno stati ammortizzati più volte, ma il prezzo è rimasto lo stesso.

Anche la politica (poteva mancare?) ha dato un bel contributo ad alzare i prezzi, con balzelli medievali e assurdi e un livello di IVA altissimo rispetto a quello praticato per i libri. Senza rendersi conto, come per la benzina, che esiste un livello oltre il quale il prezzo diventa talmente alto da ridurre i consumi fino al punto di diminuire anche gli introiti delle tasse.

Come se non bastasse la qualità audio dei CD è pure scarsissima. Il suono viene pompato a livelli sempre più alti rendendolo un impasto totalmente privo di sfumature. E per ascoltare una tale robaccia anche un mp3 compresso va benissimo, a cosa potrebbe mai servire un impianto audio di qualità? Ma questo argomento merita un post tutto suo.

Non dimentichiamo infine l’aspetto estetico. Il CD è un oggetto anonimo, un guscio di plastica con una copertina microscopica e, quando c’è, un libriccino inguardabile e praticamente illeggibile. Nulla al confronto della potenza artistica delle copertine degli LP. Cosa c’è da perdere a barattarlo con un file da inserire nel lettore mp3 o nel computer? O a duplicarlo in un altro CD, magari con una scritta traballante a penna?

Ho copiato anch’io tanti LP a suo tempo, avevo decine di cassettine sparse per la casa e la macchina, ma l’ascolto delle cassette era un forte impulso a possedere poi l’originale. Non solo per la qualità audio ma anche per il valore intrinseco, la bellezza dell’LP. Il CD non ce l’ha, ovvio poi che il duplicato abbia esattamente lo stesso valore dell’originale. Non è solo un fatto di tecnologia ma anche di estetica.

Non si vendono dischi? Forse perché non ci sono dischi che valga veramente la pena comprare.

L’industria musicale si sta suicidando e la popolarità degli mp3 è solo il riflesso della sua poca lungimiranza.

Per un click in più

Sat, 14 Jun 2014 06:00:00 +0000

Oops! Tim Cook tweets photo of Mac production line running Windows – PCWorld

Accidenti! Tim Cook twitta una foto della linea di produzione del Mac [Pro] su cui gira Windows – PCWorld

Grande scandalo, a leggere l’articolo. Come è possibile che il Mac (Pro) sia prodotto usando Windows?

Peccato che chi lo ha scritto non abbia nessuna nozione del fatto che (purtroppo) la maggior parte delle macchine industriali siano controllate da programmi software molto specifici (e costosi!) i quali, proprio per la loro specificità, sono scritti solo per un ben determinato sistema operativo. In questo settore il concetto di multipiattaforma non esiste. Si compra la macchina con il software associato e stop. Avviene lo stesso per sistemi diversissimi dai bancomat alle macchine automatiche per il caffé.

Qui Windows fa la parte del leone. La sua ampissima diffusione, con la conseguenza che la maggior parte dei programmatori lo sa usare, insieme al basso costo dei PC da usare per lo sviluppo e poi in produzione lo rendono una scelta quasi inevitabile. Del resto in questi casi quello che importa non è il sistema operativo ma l’applicativo che ci si fa girare sopra (spesso l’unica applicazione installata).

E nonostante ciò, anche in questi casi Windows fa ogni tanto le bizze e va in crash, esattamente come nel PC di casa. Come si potrebbe vendere un bel contratto di assistenza, altrimenti?

Insomma, l’articolo dice solo ovvietà. Ma fra le righe parla male di Apple.

Tanti, tanti bei click assicurati.

Chissà...

Thu, 12 Jun 2014 06:00:00 +0000

Negli ultimi sette giorni si è piazzata al secondo posto nel numero di accessi a questo sito, scavalcando USA e Turchia, la… Citta del Vaticano!

Sarei veramente curioso di sapere chi… ;)

Sono passati 25 anni: le origini del web

Thu, 15 May 2014 06:00:00 +0000

[caption width=“1120” align=“aligncenter”]WorldWideWeb, il primo browser web per il Next Cube (1990).[/caption]

Quest’anno si celebrano i 25 anni del World Wide Web, la tecnologia che ha permesso la diffusione di massa di Internet.

Il web nasce nel 1989 con la proposta del fisico Tim-Berners Lee all’amministrazione del CERN di creare un sistema distribuito costituito da documenti legati gli uni agli altri da opportune parole chiave - i cosiddetti ipertesti – che rendesse più semplice lo scambio e la diffusione delle informazioni fra i ricercatori del CERN, impegnati in progetti che coinvolgevano migliaia di persone sparse in ogni angolo della Terra.

La presentazione ufficiale del Web avvenne nel corso della First International Conference on the World-Wide Web del maggio del 1994, esattamente 20 anni fa.

La proposta originale è stata scritta con un Mac e non a caso: uno dei primi programmi per gestire gli ipertesti prima dell’avvento del World Wide Web è stato HyperCard di Bill Atkinson, forse il programma più famoso sviluppato per Mac OS.

Il mondo del Mac ha messo lo zampino anche nel primo browser (con editor HTML integrato), il WorldWideWeb – rinominato poco dopo Nexus per evitare confusioni con il Web vero e proprio – sviluppato nel 1990 da Tim Berners-Lee su (e per) computer NeXT Cube.

Il primo sito web è ancora online ed è attualmente in fase di restauro per riportarlo per quanto è possibile allo stato originario dell’inizio degli anni ‘90. Può essere navigato sia usando un browser moderno che tramite uno splendido simulatore del line-mode browser (browser a modalità di linea), il browser multipiattaforma sviluppato presso il CERN allo scopo di consentire a chiunque l’accesso al web, anche tramite i terminali seriali a caratteri dell’epoca.

Particolarmente curiosa è la pagina relativa all’elenco dei server web esistenti nel 1992: una trentina!

Il World Wide Web è un bellissimo esempio di come la ricerca fondamentale – il CERN si occupa di fisica delle particelle, i mattoni fondamentali dell’universo, un settore della scienza apparentemente molto lontano dalla vita di tutti i giorni – possa avere ricadute assolutamente imprendibili e molto più fruttuose dei soldi spesi per finanziare la ricerca stessa. Come nel caso della corsa allo spazio degli anni ‘60, che ha dato fra l’altro origine allo sviluppo travolgente dei circuiti integrati e più in generale della tecnologia microelettronica, senza la quale non esisterebbe il mondo come lo conosciamo oggi.

Una cosa che tanti – soprattutto la nostra classe politica – dimentica troppo spesso.

Ci tenevo a parlarne qui.

Impressioni su Koding: addendum

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

Ieri, scrivendo delle mie prime impressioni su Koding, ho dimenticato un dettaglio fondamentale: le macchine virtuali create su quella piattaforma non possono (almeno per ora) fornire un servizio di hosting, utile per ospitare un sito web personale.

Per ragioni di sicurezza e di efficienza nell’uso dei server, infatti, la macchina virtuale viene disattivata un’ora dopo il logout dall’account associato.

Non ho avuto modo di provare, ma immagino anche che il sistema effettui automaticamente il logout dell’utente dopo un certo tempo di inattività (altrimenti basterebbe effettuare il login nel proprio account senza più uscire per tenere sempre attiva la propria macchina virtuale). Un futuro servizio a pagamento fornirà una macchina virtuale attiva in permanenza.

Per maggiori dettagli, si possono consultare le FAQ e la documentazione generale della piattaforma, raggiungibile effettuando il login nel proprio account e cliccando sull’icona con il punto interrogativo sulla barra del menu o andando direttamente al sito della Koding University.

Impressioni su Koding

Wed, 12 Mar 2014 06:00:00 +0000

Qualche giorno fa ho segnalato su questo blog che Koding stava offrendo una macchina virtuale gratis con 3 GB di spazio su disco.

Lo spazio disponibile poteva essere ampliato mediante il meccanismo del win-win referral (non mi viene una traduzione migliore di “invito vinci-vinci”): invitando amici e conoscenti a registrarsi, entrambi ricevono in premio 1 GB di spazio in più, fino ad un massimo di 20 GB.

Lo stesso meccanismo viene usato dai servizi di storage online come Dropbox, Copy e simili per ampliare la base dei propri utilizzatori.

Il sito di Koding è stato preso d’assalto e finora, dei 250 TB disponibili, ne sono stati assegnati la metà. In effetti mi aspettavo che esaurissero tutto più in fretta: forse queste sono opportunità troppo di nicchia per allettare il pubbico generalista che passa il suo tempo online su Facebook. O forse la causa sta nel fatto che i server sono andati in sovraccarico, rendendo tutte le operazioni – persino la banale spedizione dell’email di conferma dell’iscrizione – estremamente lente. O forse 250 TB sono così tanti che è veramente difficile esaurirli, perfino con una offerta generosa come questa.

In ogni caso, la lentezza dei server ha reso finora molto difficile usare veramente la propria macchina virtuale, e quindi una prova dettagliata deve essere rimandata a tempi più tranquilli.

La macchina virtuale è comunque basata sulla penultima versione 13.04 (Raring Ringtail) di Ubuntu Linux, uscita ad aprile dell’anno scorso. L’installazione dei pacchetti disponibili (dovrebbero essere gli stessi presenti nella versione desktop) è semplicissima, come su tutti i sistemi basati su Debian GNU/Linux. Io ho provato ad installarne alcuni senza problemi, anzi l’installazione è velocissima perché usa un archivio locale (mirror).

Il sistema nasce per essere usato tramite il Terminale disponibile nell’interfaccia web (non male, ha anche le schede) o tramite collegamento ssh remoto, per eseguire applicazioni a linea di comando o che girano in un browser. Ma dovrebbe essere possibile utilizzare anche applicazioni con interfaccia grafica, configurando il sistema a finestre X11.

Purtroppo non è stato possibile provare ad usare X11 (il tempo disponibile è finito), che potrebbe aprire lo spazio ad applicazioni molto più interessanti di un semplice servizo di emulazione via web.

Comunque, una una macchina virtuale basata su Linux ed accessibile tramite interfaccia web è interessante in sé, indipendentemente dalle applicazioni pratiche. Le possibilità didattiche sono infinite, con il vantaggio di non dover installare o configurare nulla, e di poter usare la macchina virtuale anche tramite iPad (magari con una tastiera esterna). Ma anche i tablet basati su Android e persino(!) i tablet D.O.A. con Windows RT andrebbero benissimo: magari finalmente potranno servire a qualcosa!

Aggiornamento. Siamo a giovedì 13 marzo e l’offerta continua. Credo proprio che andranno avanti ad oltranza, fino ad esaurire lo spazio disponibile. Chi è interessato farebbe bene ad affrettarsi…

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.