Microsoft Build, arrivo 😎

È già da un po’ di tempo che ho il piacere di stringere (metaforicamente dato che è elettronico) tra le mani il biglietto d’ingresso a Microsoft Build 2017, che si terrà a Seattle la settimana prossima. Lunedì ho il mio volo transoceanico e non potrei essere più eccitato così, soprattutto perché sono pieno di aspettative rispetto a quello che vedrò negli Stati Uniti.

Nello specifico, le cose su cui mi voglio concentrare saranno le sessioni di keynote in cui Microsoft condividerà la sua roadmap e le novità che ha in serbo, e ovviamente l’incontro con gli altri membri del programma Technical Advisory Group, di cui faccio parte.

Ovviamente, in particolare, sono interessato al lavoro che sta venendo fatto per portare l’ecosistema Linux su Windows tramite il progetto Windows Subsystem for Linux; già con il Creators Update è possibile fare tantissime cose in più con la Bash integrata dentro Windows, che sin’ora era stata relegata ad uno stadio di preview, quindi mi aspetto che questa settimana me ne facciano vedere delle belle.

Oltre la shell, però, sicuramente andrò a sniffare qualche cosa d’interessante su:

• Surface Laptop, che a me piace anche se sembra un divano;
• Azure Container Service, perché sono sempre il solito aficionado di Docker;
• Linux, perché chissà che Microsoft non abbia intenzione di portare altro software sul mio sistema operativo preferito.

Come compagni di viaggio d’eccezione, uno dal Technical Advisory Group e uno dal mondo del giornalismo, avrò Piergiorgio Lucidi, già mio collega in Sourcesense, grande esperto di information management e gran chitarrista, e Luca Annunziata, nerd come pochi, runner, e barba d’oro per l’estate 2017. 😎

Nel frattempo devo un grazie speciale a Paola Presutto, Andrea Benedetti (se sfonnamo! 😂) e Shelby Woods per aver reso tutto questo possibile. Kudos guys!

Come se tutto questo non dovesse bastare, qui potete trovare la fantastica introduzione in parte tecnica, in parte fatta di sentimenti e amarcord puro scritta da Andrea.

🍹

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.