Thor - ovvero scriviamoci il nostro task runner per Ruby

Stasera tornando a casa ho avuto la “brillante idea” di mettermi a trafficare con il Rakefile che uso per manutenere questo blog e automatizzare ad esempio la creazione dei file markdown o per eseguire una build locale. Mi è capitato di notare una cosa più del solito: il metodo che usa Rake per passare i parametri ai task fa schifo.

Per passare un parametro a un task bisogna scrivere una cosa tipo rake foo[bar], che per quanto possa essere rapido da scrivere non è nemmeno compatibile con ZSH, che si lamenta. L’equivalente che ho usato sempre sino ad oggi è rake "new[post-slug]", che mette a tacere ZSH ma fa ancora più schifo esteticamente. Viceversa guardandomi intorno per un modo più furbo di passare i parametri a Rake, ho scoperto Thor.

Thor è una figata di software che si compone di due pezzi: una libreria per creare delle utility CLI, piccoli programmini a riga di comando che sbrighino dei task arbitrari. L’esempio di base è questo, preso dal sito ufficiale:

require "thor"

class MyCLI < Thor
  # contents of the Thor class
end

MyCLI.start(ARGV)

In realtà sfruttando qualche gabola interna documentata in maniera un po’ allegra (ossia: io non ho trovato documentazione su questo, ma ho rubato in giro) possiamo sfruttare Thor come Rake, per scriverci la nostra classe Ruby che faccia da task runner. Per fare un esperimento ho preso il mio Rakefile:

require 'date'

task default: %w[build]

task :run do
	sh "jekyll serve"
end

task 'build' do
	sh "jekyll build"
end

task :new, [:title] do |t, args|
	fn = "_posts/#{Date.today().to_s()}-#{args.title || "slug"}.md"
	File.new(fn, "w")
	puts("Successfully create file: #{fn}")
end

E l’ho riscritto usando Thor. Ho creato un Thorfile scritto così:

require 'date'

class Default < Thor
  
  desc 'up', 'Serves the blog locally through Jekyll\'s embedded server'
  def up
    exec("jekyll serve")
  end

  desc 'build', 'Builds the static site'
  def build
    exec("jekyll build")
  end

  desc 'new SLUG', 'Creates a new post with the provided slug'
  def new(slug)
    filename = "_posts/#{Date.today().to_s()}-#{slug}.md"
    File.new(filename, "w")
    puts("Created file: #{filename}")
  end

end

Ci sono due trick che usiamo, e che sono leggermente sottintesi nella documentazione: un Thorfile viene sempre cercato come predefinito insieme a qualsiasi file .thor, quindi possiamo chiamare il file in questo modo ed evitare di passare un filename a Thor stesso; l’altro trucchetto è che una classe Default non ha bisogno di prefissi per i nomi dei task. In questo modo leviamo di mezzo un bel po’ di complessità rispetto all’uso classico di Thor, che è ben più potente, definendo i task in maniera molto simile a un Rakefile.

Tutto questo con un plus però: ovvero il fatto che possiamo finalmente passare degli argomenti in una maniera normale e umana ai nostri task, e il check automatico degli argomenti da parte di Thor stesso fa sì che non sbagliamo a passare più o meno parametri di quelli necessari, pena degli alert super sexy.

L’effetto è questo:

$ thor new thor-task-runner
Created file: _posts/2017-05-03-thor-task-runner.md

$ thor new 
ERROR: "thor new" was called with no arguments
Usage: "thor :new SLUG"

$ thor new top kek
ERROR: "thor new" was called with arguments ["top", "kek"]
Usage: "thor :new SLUG"

Io per stasera ho trovato il giocattolo nuovo, e sono proprio soddisfatto. Come sempre, è bandita la domanda sulla vita sociale, dato che la risposta è come al solito un no secco. Adoro il mio divano. E adoro anche Thor.

Vim setup per Markdown

Di recente ho iniziato ad essere insoddisfatto degli editor Markdown che uso - o meglio, loro il loro lavoro lo fanno benissimo, sono io che avendo un flusso di lavoro orientato alla riga di comando non riesco a integrarli perfettamente. Ho provato a scrivere qualche plugin di ZSH per dover passare sempre meno dal cursore del mouse e rendere tutto “streamlined”, ma proprio non ci riesco.

Viceversa la cosa che adoro è usare Vim, e stamattina avendo un po’ di tempo a disposizione ho spulciato un po’ l’Internet; greppa che ti rigreppa è uscito questo meraviglioso post che illustra come creare un setup completo per editing di file Markdown con Vim senza troppi sforzi.

I’ve been struggling with the Vim setup I use to write for a while now. For a geek, I have a pretty standard work flow. iTerm is my terminal emulator. Inside that I run tmux. Inside that I run vim. I write my text in Markdown and commit my work to a Git repository. For ages I’ve been using my regular coding setup with a few hacks to the ftplugin for Markdown. It worked but it didn’t work well. I’ve since decided that it’s time to set about fixing it.

E con questo, diciamo addio a Byword e Typora, dato che almeno per il momento posso definirmi soddisfatto.

GNOME Shell con GPU Intel, configurazione (circa) finale

E insomma, dopo tanto smanettare forse credo di aver trovato una quadra su quella che dovrebbe essere la mia configurazione ottimale per quanto concerne GNOME Shell e la poverissima GPU Intel a cui mi diverto a dare il tormento tenendo spenta la scheda grafica discreta (che non mi serve praticamente a niente su Linux, se non a trasformare questa macchina in una fornace da calcolo).

In poche parole, modificando /etc/environment lo facciamo diventare come segue:

#
# This file is parsed by pam_env module
#
# Syntax: simple "KEY=VAL" pairs on separate lines
#

CLUTTER_VBLANK=True

Dopodiché configuriamo il driver video in questo modo, modificando il file /etc/X11/xorg.conf.d/20-intel.conf:

Section "Device"
	Identifier  "Intel Graphics"
	Driver      "intel"
	Option      "TearFree"    "true"
	Option      "SwapbuffersWait" "true"
	Option      "AccelMethod" "sna"
EndSection

In parte questo mistero l’avevamo già eviscerato in passato, riuscendo a migliorare la situazione ma non a debellare la problematica. Quello che questa configurazione fa è forzare uno specifico metodo di accelerazione grafica (che è quello di default, e dovrebbe essere quello di ultima generazione - sia mai che non andasse da solo), impostando poi sia TearFree che SwapbuffersWait.

Insieme a questo anche uno specifico tweak di Clutter fa sì che le performance siano migliori nel complesso, a costo di usare qualche ciclo di calcolo in più. Mi pare che questa configurazione performi molto meglio sulla mia macchina, ne sono veramente soddisfatto.

Questa configurazione va molto, molto bene anche con Wayland.

Forse c’è ancora qualcosa che si può fare. I’ll keep you posted.

Trappole più comuni in Elixir

Recentemente mi sono appassionato molto ad Elixir, linguaggio funzionale che fa uso della Erlang VM per definire una piattaforma veramente versatile orientata ai processi isolati comunicanti via messaggi.

In particolare questo post che ho letto di recente su Blackode mette in luce alcuni aspetti particolari del linguaggio con i quali chi non ha confidenza rischia di fare assunzioni un po’ troppo coraggiose.

Un ottimo esempio:

We think that the result of list ++ value would be [1,2,3,4,5,99] but in general it will be [1,2,3,4,5|99]. This is a improper list. You cannot use length function over. In proper list, when you iterate over the list, the tail would be [] empty list. This is different with the improper list.

Ubuntu, il ritorno a GNOME, e al diavolo la convergenza

Ti gratti la testa pensando che magari non hai letto bene i titoli dei feed una settimana fa, poi sgrani gli occhi, capisci che diamine accade, ti fai una risata, fai sedimentare, decidi di scrivere, ti interrompono, cancelli tutto, il lavoro entra a gamba tesa minando definitivamente la tua produttività di infimo scrittore.

È così che dopo una settimana sei ancora lì a cercare le parole per commentare un evento del genere: Ubuntu abbandona Unity, e passa a GNOME. Dopo anni di scatole rotte con la convergenza, con questo e con quest’altro, e dopo aver creato un brand niente male con la propria fichissima (secondo alcuni) interfaccia grafica, tutto alle ortiche perché giustamente chi se ne frega della convergenza ora che l’ultima moda è l’IoT che appizza le informazioni nel cloud, il quale sicuramente è un business che per Linux funziona meglio.

We will shift our default Ubuntu desktop back to GNOME for Ubuntu 18.04 LTS.

Ma è davvero così?

Incertezze

Non si è capito poi molto di che cosa abbia intenzione di fare Canonical per Ubuntu 18.04 LTS, se non (per il momento) degli straordinari proclami su Unity e GNOME: quello che viene detto, è che in realtà “continueremo a sviluppare il miglior desktop di sempre”, ma non si capisce se questo sia riferibile a Unity 7 o all’esperienza desktop globale, integrando GNOME alla perfezione e applicando delle patch qua e là per far sentire gli utenti meno spaesati.

We will continue to produce the most usable open source desktop in the world, to maintain the existing LTS releases, to work with our commercial partners to distribute that desktop, to support our corporate customers who rely on it, and to delight the millions of IoT and cloud developers who innovate on top of it.

Più di tutte le frasi sul futuro, questa ha attirato la mia attenzione in modo abbastanza coatto, lasciandomi incerto: è così vero che vengono abbandonati tutti i progetti relativi a Unity? L’alternativa è che Unity rimanga solamente come shell grafica, delegando tutto il comportamento sottostante a GNOME, che verrà reintegrato nel sistema operativo in maniera più pesante rispetto a come è già stato fatto sinora.

In ancora un altro scenario, è possibile che Canonical lasci perdere Unity 8, e si concentri su Unity come shell grafica puramente detta, cotninuando quel filone di sviluppo, integrando gli stessi pezzi di GNOME che integra adesso; in questo contesto avrebbe comunque senso “we will shift our default Ubuntu desktop”, dato che significherebbe solo “signori, abbiamo cambiato idea per la prossima release, e grazie per tutto il pesce”.

Oppure ancora, come molti hanno già scritto, ed è importante notare che non sono stati smentiti da nessuno (anzi, Mark Shuttleworth stesso domenica ha avallato questa ipotesi), Ubuntu passerà veramente a GNOME. Questo mi farebbe veramente molto piacere, perché la distribuzione Linux di Shuttleworth rientrerebbe nel “mainstream” delle distribuzioni Linux normali – per così dire – abbandonando lo sviluppo di un fattore realmente distintivo, concentrandosi sulle cose che non funzionano e migliorandole. Non solo per Ubuntu, ma per Linux in sé, marchio dal quale Ubuntu (al contrario di Android, possiamo dirlo) non è mai stata capace di affrancarsi del tutto. Ed è meglio così.

Coopetition

In quest’ottica forse si potrà ricominciare a vedere Ubuntu come un contributor attivo della comunità e dell’upstream Linux principale. Questo upstream ad ora comprende un numero indefinito di “cose” tra cui le principali, Linux/Xorg/Wayland/KDE/GNOME – e basta. Mir, ad esempio, non ha mai visto vera luce e non ha mai cercato di ritagliarsi uno spazio in questo ecosistema, preferendo stare al margine. Data anche l’ingerenza di Red Hat, sicuramente queste sono scelte che non pagano, mentre è molto più virtuoso cercare di contribuire all’ecosistema Wayland con il proprio compositor, con i propri bugfix, in definitiva con il proprio codice.

Per gli anni a venire, mi auguro di rivedere Ubuntu in prima fila per Linux su desktop, esattamente come gli anni passati, ma senza schierarsi a parte con un brand diverso dicendo “noi siamo più fighi”, perché tanto Linux non credo che abbia bisogno di questo. Non ne ha bisogno e non ne avrà mai bisogno perché non è così che l’ecosistema è stato generato, e non è decisamente così che il segmento microscopico mondiale di utenza Linux vede ciò che è necessario.

Piuttosto, a me non fanno impazzire le performance delle animazioni di Mutter, il window manager di GNOME Shell. Magari Canonical potrebbe contribuire con delle patch.

P.S.: Marco Usai mi ha mandato uno splendido audio col suo virilissimo accento sardo per spingermi a pubblicare questo post. Purtroppo nella prima stesura ho dimenticato di menzionarlo.

Pics courtesy of OMG! Ubuntu and Arc Theme’s GitHub