31 Dec 2015

So long, and thanks for all the software

Ian,

Sei stato una tra le persone che più hanno contribuito a rendermi ciò che sono. Ora, presumo che dovremo cavarcela senza di te; sarà difficile.

30 Dec 2015

Jekyll e il flusso di pubblicazione

In un suo post, Nicola mi ha elogiato di aver mantenuto il ritmo di pubblicazione nonostante il passaggio a Jekyll. Per chi non lo conoscesse, Jekyll è il motore su cui si basa questo blog - o forse dovrei dire “non-motore” visto che di fatto è solo un generatore di siti statici. È vero, Jekyll da fuori sembra una figata assurda e quando poi ci sei dentro scopri che mentre tante cose sono facilissime rispetto a un CMS tradizionale, altre mancano di immediatezza, come la scrittura di un post. Visto che il buon kOoLiNuS si è dimostrato perplesso, vediamo di fare chiarezza su cosa influisca realmente in un flusso di pubblicazione basato su Jekyll, e anche su qualche aspetto collaterale.

Mentre lascio a te la lettura e la valutazione di questa mossa, volevo mettere in evidenza la frase finale. Jekyll sarà anche figo, ma è senz’altro geek e abbastanza tecnico… e quando nella vita si vuole stare comodi non sempre certe soluzioni sono tali da invogliarti ad approcciare alla scrittura.

Con l’eccezione di Dr.Blaster e Lucio, infatti, non conosco nessuno che una volta migrato su questa piattaforma abbia mantenuto il precedente ritmo di pubblicazione…

Pregi di Jekyll

Sicuramente una delle cose più rilevanti, è che hai tutto in locale. Nel caso in cui tu voglia scrivere, hai tutto a disposizione per farlo: basta aprire l’editor di testo, iniziare a buttare giù qualcosa, riguardarlo, dargli una forma (e una formattazione). Quando hai finito, chiudi l’editor di testo e via: salvi il file e ti basta fare un commit e un push su GitHub (oppure rigenerare il sito, nel caso in cui tu non stia usando un sistema di Continuous Integration o GitHub Pages come faccio io). Tutto arabo vero? Ecco appunto: a questo arriviamo dopo.

Un altro grandissimo pregio, è che praticamente non c’è bisogno di backup, dato che la larghissima maggioranza dei blog generati da Jekyll che conosco sono sotto un opportuno sistema di versioning. Jekyll, d’altronde, è pensato per fare proprio questo: mantenere il proprio blog tramite solo testo, un’alberatura di file grossomodo semplice e qualche comando da terminale. L’idea è geniale, anche perché espandendo il concetto espresso poco sopra, mantenendo tutto versionato e su un hosting Git/SVN, aggiungere contenuti non comporta praticamente sforzo, il backup si fa da sé, e così via.

Oltre questo, troviamo anche una personalizzabilità invidiabile: basta modificare i template dei formati dei propri post, tramite il Liquid Templating Markup, per aggiungere nuovi custom post type e tanto altro. Insomma, una cosa per veri smanettoni smaliziati, il che ci porta direttamente ai difetti. :-D

Difetti di Jekyll

Bello Jekyll, fico Jekyll, però è anche vero che per un blogger tutto questo significa alle volte una fatica bestiale. Nonostante l’infrastruttura perfetta infatti (dal punto di vista tecnico), il blogger è comunque una creatura che vive di impressione e ispirazione; la criticità quindi diventa proprio l’assenza di frontend, il fatto che senza strumenti che ti aiutino non riesci più a trovare quell’immediatezza, quel flusso di lavoro a cui ormai lungo i decenni il CMS ti ha abituato (nel mio caso, prima FlatNuke poi WordPress). A me Jekyll piace ancora, ma è anche vero che dopo più di un anno dalla migrazione, nell’intento di incrementare il ritmo di pubblicazione, ho cominciato a scrivere una gemma Ruby che dovrebbe contenere una serie di helper. L’ho messa su GitHub come quasi tutto il mio codice, e penso che presto ne farò il push anche su RubyGems.org :-)

Insomma, non è tutto oro quello che luccica, anzi: purtroppo nel caso di Jekyll è assolutamente reale che non c’è più quell’immediatezza che c’era con altri CMS; quello che è vero, tuttavia, è che lo strumento cambia il modo di scrivere, e sicuramente Jekyll ha fatto in modo che scrivessi cose leggermente più ponderate. Pian piano spero di arricchire Burst di funzionalità in modo da fornirmi tutto quello di cui ho bisogno.

È troppo vero: Jekyll ha reso di me un blogger peggiore (forse? Dato che comunque non scrivo più così spesso), ma penso che mi abbia reso più riflessivo e un programmatore migliore, indubbiamente. Il fatto che mi abbia dato nuove necessità da soddisfare, e nuovi problemi da risolvere, per me è un pregio ma per altri senza dubbio può essere un freno. E lo sarà: non è fatto per uscire dall’ambito geek, e quello che deve fare lo fa eccellentemente.

Difetti? Ne ha, però…

È vero che usare un martello di un tipo piuttosto che di un altro tipo non cambia che il chiodo venga piantato, ma uno dei siti più belli che io abbia visto nell’ultimo anno è basato su Jekyll e merita una menzione: parlo del sito di opensensorsdata, e di tutti i sottodomini, rigorosamente jekyllizzati. È un esempio ottimo, secondo me, di come Jekyll possa corrispondere in modo più che ottimo a determinate esigenze aziendali.

E ora scusate, devo andare a scrivere un software in Ruby per automatizzare la scrittura dei post per il mio blog basato sulla generazione di siti statici. A volte penso che, semplicemente, invece di automatizzare tutto solo per il gusto di farlo, dovrei semplicemente muovere il culo e scrivere di più :-)

Swift per Linux

So che è “roba di Apple”, ma il port su Linux di Swift mi intriga. Alla fine da quello che ho visto è un incrocio tra Python e Javascript (che sono due linguaggi che infatti adoro), con operatori interessanti e il supporto alla GlibC. Chissà, magari ci farò qualcosa di più uno di questi giorni :-)

Quello che è sicuro, è che per l’intanto il port su Linux è stato fatto. Sul sito ufficiale trovate i .deb disponibili per le ultime versioni di Ubuntu. Su Arch Linux, ovviamente, potete installarlo tramite il PKGBUILD che c’è su AUR.

PHP 7.0

Evidentemente i ragazzi di PHP amano il brivido del rischio e dei ripensamenti:

After doing the last evaluations in the RMs circle before going for 7.0.0 RTM preparations, we came to the conclusion that the current state does not look reasonable to be packaged as the final release.

Dopo lo stralcio di cui sopra di una mail al gruppo di lavoro, proprio due giorni fa è apparso il tag di PHP 7.0. Ovviamente, come tutte le creature appena nate, ne viene sconsigliato l’uso in produzione: handle with care :-)))

Atom è l'editor preferito di Jono Bacon, ma non il mio

Mi è capitato di inciampare nel post che linko sopra, di Jono Bacon, che dice che si è innamorato di Atom come editor di codice. A parte i lustrini sul “adesso lavoro a GitHub, suckers” (che effettivamente ha ogni titolo per piazzare :-D), ha condiviso una serie di impressioni, e il suo setup che - devo ammettere - ci tengo a copiare prima possibile. Purtroppo però con me Atom non sta avendo lo stesso viaggio rose e fiori:

Back in the day I used to use Eclipse with the PyDev plugin. I then moved on to use GEdit with a few extensions switched on. After that I moved to Geany. I have to admit, much to the shock of some of you, I never really stuck with Sublime, despite a few attempts.

Non capisco seriamente, dopo i primi venti minuti di utilizzo, come si faccia a non amare Sublime Text, e trovare allo stesso tempo Atom così affascinante - dato che Atom è una versione un po’ più “fighetta” del celebre editor che ormai è diventato un must-have per tutti gli sviluppatori. In questi giorni comunque ho avuto modo di provare Atom e qualche pregio ce l’ha:

• Supporto veramente buono a temi e coloscheme
• Eccellente autocompletamento della sintassi e buoni snippet
• È basato su Electron, che è la prossima tecnologia su cui voglio mettere le mani
• La personalizzabilità è all’ordine del giorno
• APM, ovvero il package manager di Atom che è banalmente un wrapper di NPM che installa temi e plugin da riga di comando

Nonostante questo però, ho trovato dei lati negativi che mi è stato impossibile sormontare, almeno per il lavoro quotidiani in ufficio:

• Atom è lento. Dico davvero: parlando di file molto grandi, è praticamente impossibile praticare uno scroll un po’ violento senza imbattersi nell’editor che arranca per starti dietro. Sublime mi ha abituato piuttosto male riguardo questo (non facendo veramente una piega anche su file da 40000 righe di codice) e mi aspetto sinceramente che un editor di testo che si pone come concorrente di Sublime Text. Colpa di Electron? Colpa di Javascript? Colpa di miocuggino? Che ne so.
• Nonostante ci siano molti plugin veramente fatti bene, il numero di estensioni disponibili non compete minimamente con quello di Sublime
• Il formato dei syntax highlighter è codificato in uno standard robusto che fa uso di JSON come notazione, tuttavia rompe la compatibilità con il formato supportato da Sublime Text, che era a sua volta retrocompatibile con quello di TextMate

Insomma, c’è materiale su cui riflettere; per quanto concerne le prestazioni, Atom è migliorato negli ultimi tempi ma senza lasciarmi a bocca aperta. Mi aspetto che migliori ancora per adottarlo su tutte le workstation, dato che mentre Sublime Text è fatto di codice proprietario, Atom è completamente open source.