Da grande voglio essere Bryan Cantrill: tre talk da vedere (più bonus track)

Da qualche mese ho preso l’abitudine di spendere un’oretta al giorno del mio tempo guardando dei talk, vista anche la carenza di conferenze dal vivo (tipologia di evento a cui ero molto affezionato) e non apprezzando tantissimo il formato delle conferenze online - banalmente perché tante volte avere la chattina al posto di una birra in un centro conferenze sminuisce un po’ l’intera esperienza.

Ma sto divagando. Qualche settimana fa Elastic si è esibita in un corposo relicensing di ElasticSearch, che io preferisco non commentare perché l’azione in sé si commenta abbastanza da sola. Quello che potete leggere in merito lo trovate sul blog di Drew DeVault, dove è linkato un talk molto affine alla questione presa in esame, ovvero un talk di Bryan Cantrill del 2011 su Solaris e IllumOS. È stato proprio in questa sede che ho (ri)scoperto la figura di Cantrill, un ingegnere controverso perseguitato per metà della sua vita da una risposta oggettivamente stupida su comp.sys.sun.hardware, dagli infiniti meriti tecnologici, e soprattutto un uomo che potrei stare ad ascoltare per ore semplicemente perché sì. Siccome sono andato in fissa, praticamente la mia ultima settimana è stata un continuo approfondimento delle opinioni, dello stile, dei meriti tecnici e del software stesso scritto da lui, accorgendomi che avevo letto di recente anche “Rust after the honeymoon”.

Questo dover ammettere che ogni volta che inciampo su un suo contenuto me lo spolpi voracemente mi ha fatto venire voglia di scrivere questo post in cui vi linko tre suoi talk che secondo me spiegano abbastanza bene come mai da grande io voglia essere Bryan Cantrill.

Fork Yeah! The Rise and Development of Illumos

Questo è il talk che citavo sopra: IllumOS era appena nato dalle ceneri di Solaris, e se c’è una cosa di cui quest’uomo è estremamente fiero è l’aver lavorato al fianco dei giganti prima dell’acquisizione di Sun, essendo poi diventato egli stesso un gigante scrivendo DTrace. A parte le cose divertenti come le prese in giro rispetto a Oracle e ai vari personaggi dell’epoca, una cosa che adoro di questo talk è il porre l’accento in maniera particolare sul principio fondante di Sun (che purtroppo è stato il suo canto del cigno):

Kicked ass, had fun, loved our customers, changed computing forever.

Il che per quanto mi riguarda è quello che cerco di fare ogni giorno.

Debugging Under Fire: Keep your Head when Systems have Lost their Mind

Il mio meccanismo di scoperta su YouTube è pressoché quello di tutti: vedo una cosa interessante nella sidebar dei video correlati, la clicko. È così che mi sono imbattuto in questo video, perché mi ha solleticato il fatto che mentre di solito tutti parliamo di best practice quando è tutto a posto e in ordine, veramente in pochi parlano di quello che dovresti fare quando c’è un incidente veramente grosso in produzione. La maggior parte dei talk con approccio SRE ti dicono cose come “vedi salire la metrica rossa sul grafichetto, fai squillare il PagerDuty di tutti, leggi l’handbook che hai preparato col tuo team”.

Questo è stato il primo e unico talk che io abbia mai visto che spiega cosa passa veramente per la testa di un software engineer durante un incidente in produzione nei primi due minuti: “Please don’t be me”.

Principles of Technology Leadership

Devo dire che questo talk mi ha incuriosito parecchio su quello che succede alla Monktoberfest, tanto che quando riprenderà in presenza vorrei andarci. Oltre l’apprezzamento per la conferenza dalle tematiche più umane che tecniche, comunque, questo talk mi ha fatto morire perché come dice uno dei commenti “voglio mettermi Always be hustlin’ pronunciato da Bryan Cantrill come suoneria del cellulare” ma soprattutto ho adorato, adorato, adorato la critica feroce agli Amazon’s technology leadership principles insieme a quelli di Uber.

Bonus track: The summer of Rust

Secondo voi è possibile che un coefficiente di stima già alto per una persona vada improvvisamente fuori scala con qualcosa che è una “bonus track” e non avevi nemmeno preventivato di metterlo in un post che ti eri appuntato da settimane? Con questo talk ho scoperto che almeno per me è possibile, non tanto per le affermazioni riguardo Rust, ma per quelle che precedono il racconto su Rust, che riguardano JavaScript, e con le quali da JavaScript software engineer ho empatizzato un sacco. Non avevo mai sentito qualcuno dire ad alta voce quello che già pensavo da me: “JavaScript is Lisp in C’s clothing” - ed è veramente strano, veramente strano che a dirlo sia una persona che si professa “not a programming language guy”, perché persone che invece si ammantano di un’oscura aura di mistero adorando discutere tutto il giorno di language design alla fine della fiera non sono mai arrivate a comprendere questa verità profonda.

E questo è un grosso indice di quanto l’ecosistema IT mondiale sia rotto in gran parte, dato che da una parte ci sono persone che dicono cose del genere e dall’altra ci sono persone convinte che un full-stack developer possa fare from zero to hero in sei mesi con un bootcamp che a questo punto non saprei come definire se non “miracoloso” dati i risultati che promette.

Alla luce di un’affermazione del genere, mi sento di scrivere anch’io qualcosa in merito: se veramente volete scoprire da dove viene JavaScript e comprenderne alcuni meccanismi che possono sembrare oscuri, studiate OCaml. Studiate il Lisp. Studiate il C. Fatelo bene, poi tornate a dirmi che non capite le scelte di design che stanno dietro al lexing o ad altre meccaniche.

Wrap-up

Di seguito una lista di commenti su YouTube a video di questo genere, che ho raccolto durante le mie visioni semplicemente scrollando un po’ con la rotella del mouse, coi quali concordo in maniera smodata:

• “I feel like I am watching a stand up comedian, but with topics I like to listen too.”
• “This guy has more stories to tell than all of my great grandfathers combined”
• “I am an hour in and this man has just now mentioned Rust for the first time… and can I just say, I completely forgot that this talk was about Rust and I do not care. I’m loving this”
• “when you let bryan cantrill have caffeine, a halo appears around his head”
• “This talk is more entertaining than a lot of Netflix comedy shows, thanks for it.”
• “His energetic speech style is truly one of a kind. Loves it.”

Devo dire che raramente mi è capitato di sentire talk che mi ispirassero così tanto in materia di system programming e in materia di software engineering più in generale. Che altro? Boh, vado a guardarmene un altro. Spero di essermi fatto capire. Sicuramenter Bryan Cantrill ci sarebbe riuscito meglio.

Mamma, ho costruito una libreria di actor modeling per NodeJS

Qualche tempo fa in un attimo di follia ho cominciato a farmi qualche schemino per portare alcune delle mie feature preferite di Elixir su NodeJS, per il semplice fatto che potevano essermi utili anche lì. Può sembrare che io stia cercando di avvitare un bullone con un cucchiaio, ma ci sono un paio di verità di cui preferisco fare un bel listato:

• Credo fermamente che l’actor model sia un paradigma vincente che consente di gestire la concorrenza in un modo in cui gli esseri umani, mentalmente, non vadano a pestarsi i piedi mentalmente con altre elucubrazioni passate o future. Nella mia testa quello che avviene quando programmo un GenServer in Erlang è molto, molto più fluido di quello che avviene quando scrivo un thread in C o una goroutine;
• NodeJS offre i Worker, un’entità software di cui è possibile fare spawn a cui fare offloading del lavoro del main thread. I worker process sono un’area all’interno della quale secondo me la ricerca non è ancora al suo picco.¹

Quindi date queste doverose premesse ho sentito di poter dare un microscopico contributo all’ecosistema JavaScript con una libreria che consente di fare spawn di un worker process con del codice arbitrario all’interno. Allo stesso tempo il processo che viene avviato avrà una primitiva receive a disposizione che gli consentirà di ricevere i messaggi che gli vengono inviati. A questo punto data l’infrastruttura di comunicazione sottostante sarà possibile dividere la nostra applicazione in più attori dalla logica separata.

Lo snippet che c’è nel README è abbastanza esplicativo, la libreria (che si chiama hoverlord) consente di fare una cosa del genere:

const http = require('http');
const { spawn, send } = require('hoverlord');

spawn(() => {
  const { receive } = require('hoverlord');
  receive((_state, { content }) => {
    console.log(`log: ${message}`);
  });
}, 'logger');

spawn(() => {
  const { receive, send } = require('hoverlord');
  return receive((state, message) => {
    switch (message.content) {
      case 'ping':
        const newState = state + 1;
        send('logger', newState);
        return newState;
      default:
        return state;
    }
  }, 0);
}, 'stateReducer');

http
  .createServer((req, res) => {
    send('stateReducer', 'ping');
    res.writeHead(200);
    res.end(`Current process\n ${process.pid}`);
  })
  .listen(4000);

In pratica cosa abbiamo qui? Abbiamo un processo principale che avvia il webserver per un’applicazione web (tramite l’HTTP server di Node, niente di esoterico), il quale risponde a ogni richiesta sulla rotta principale con il PID del processo facendo però aumentare un contatore mantenuto in un processo separato, e facendo loggare quello stesso stato a un altro processo ancora.

Ovviamente il lavoro non è terminato, ma per cose semplici hoverlord fa il suo lavoro in maniera veramente cristallina, tant’è che io stesso sono rimasto stupito provando a scrivere un po’ di test con Jest e cominciando a stressare un bel po’ il design. Finora è sempre andato tutto bene, quindi se provate a usarla e beccate qualche bel bug vi prego di aprire una issue.

Devo dirmi da solo che questo è il progetto più interessante a cui abbia lavorato ultimamente, e la cosa allucinante è che è tutto merito mio (dell’interessanza, intendo). Ho sempre desiderato scrivere una cosa del genere, ma non sapevo da dove partire. Finalmente dopo quasi un decennio di esperienza sul campo con JavaScript sono riuscito a farmi passare la sindrome dell’impostore, e sono troppo felice di aver trovato il tempo e l’area giusta su cui focalizzare i miei sforzi per un po’.

Direzione del progetto, evoluzioni future eccetera

Una volta dimostrato che è possibile avere delle primitive di spawn e receive simili negli intenti a quelle di Erlang, sia pure con le dovute differenze tecnologiche, la più grande criticità di hoverlord è quella di avere una funzione di require patchata in modo da usare come path primario quello del progetto JavaScript originale e non la /tmp dove viene memorizzato il chunk di codice JavaScript “spawnato”. Questa cosa in un progetto reale mostra delle crepe non banali, e devo studiare meglio come superarla perché allo stadio attuale fare require di alcune funzioni dentro gli attori di hoverlord è un problema.

Questa è anche una grossa chiamata alle armi: se qualcuno avesse lo stomaco per leggersi il codice di hoverlord (be warned) non credo di potercela fare da solo.

Ringraziamenti

• Emanuele De Cupis, per aver provato per primo la libreria e avermi dato alcuni utilissimi feedback - nonché per il suo stupendo tentativo di testare hoverlord in un setup end-to-end;
• Mattia Tommasone per aver scritto la prima PR “di terzi” rendendo il tutto uno sforzo corale e non più un progetto solista;
• Gianguido Sorà per avermi fatto da rubber duck durante le feste di Natale, specialmente riguardo il meccanismo di hashing degli attori.

Aspettando il 2021, e mettendo da parte il codice

Di solito mi approccio alla scrittura del post di fine anno un po’ prima, invece quest’anno, quest’anno che per molti è stato peraltro piuttosto problematico, non so quasi che scrivere. Ho la testa vuota, in bolla, caput, perché per me è stato un anno di grande scoperta in verità: stavo pensando di fare la lista delle cose che ho fatto e di quelle che vorrei fare nel prossimo “chunk” della mia vita, ma a trent’anni queste cose da diario preferisco lasciarle agli altri e concentrarmi invece su qualcosa che sia più - come dire - olistico.

Il 2020 per me è stato un anno di scoperta perché ho trovato finalmente il coraggio di guardarmi dentro e capire che percorso di vita intraprendere, quali sono le cose che voglio imparare a fare, i posti dove voglio andare. Ho imparato ad apprezzare i capisaldi che vorrei dare alla mia esistenza, ho imparato a fare fuori cose che credevo fossero importanti e invece non andavano più bene, ho imparato che alcune cose vanno bene così. Potrebbero andare meglio ma potrebbero anche andare peggio, e pensare con ansia a come potrei migliorarle non mi fa bene.

Per me quest’anno è stato, al netto delle disgrazie e delle gioie, un anno di grande consapevolezza. È stato complicato fare queste riflessioni in un appartamento di qualche decina di metri quadri, su una sedia che è la stessa sia quando ti svaghi che quando lavori, ma credo di aver fatto un buon lavoro introspettivo: ho trovato la forza, io che ho l’ansia che mi tiene sempre per mano, di dirmi “ok, ma adesso basta”.

Le mie più grosse soddisfazioni in questo 2020 vengono proprio da questo aspetto qui: rilassandomi, mi sono potuto dedicare a cose assolutamente prive di senso (forse) come esperimenti usa-e-getta in qualsiasi linguaggio di programmazione, a pensare a cosa vorrei fare l’anno prossimo non solo dal punto di vista professionale né solo da quello “nerdico”. A scegliere una nuova casa¹, a cosa metterci dentro.

Sapete cosa vi auguro? Il 2020 è stato un anno di merda per un sacco di gente, ma non per me. Vi auguro un 2021 come il mio 2020: un anno che vi faccia capire che l’importante non è stare sempre a tremila con tutto (passioni comprese²); bensì che siete nel posto giusto, al momento giusto, perché è il vostro posto e il vostro momento. Per 365 giorni, per 24 ore al giorno.

Auguri.

In foto³, più o meno, come è stato il nostro lockdown.

Controavvento 2020: basta con 'ste cose fighette, arriva il post-avvento punk

È stato un anno particolare: riflettevo con un amico carissimo su come abbia l’impressione che dal momento in cui eravamo a casa sua a cercare un po’ di refrigerio dal caldo estivo¹ a questo Natale siano passate tipo due sere. Il tempo passa inesorabilmente: è il suo bello e il suo brutto. E in un anno bislacco come questo, il tempo passa proprio in maniera altrettanto stramba, perché chiaramente siamo stati messi alla prova in diversi modi dei quali non mi va nemmeno di parlare per non cadere nella solita retorica di come una pandemia globale ha cambiato il nostro modo di vivere.

Anche perché a me col piffero. Nel senso: ero un orso, permango nel mio status di orso.

Fatto sta che sono successe due cose molto importanti: la prima è una certa qual proliferazione di contenuti atti a insegnarti financo come lavarti i denti, dall’altra una certa insofferenza crescente da parte del sottoscritto e di tutta una silente parte di pubblico rispetto a dati contenuti.

È così che Agnese, nel pieno del suo anno di “walkabout”, ha intrapreso un progetto che non solo risuonava con la sua indole e con l’indole di tutto il suo gruppo di lavoro²: un Calendario del ControAvvento, per ricordare a tutti che va bene scegliere di passare il tempo sul divano a guardare il muro, che non dobbiamo lasciare che la sindrome dell’impostore ci fagociti davanti a questi schermi e timeline piene di traguardi tagliati. Che forse ci sono persone come loro, che al posto dei cento metri piani preferiscono correre le maratone - e sono fatte per conseguire quel tipo di risultati. Che come disse una mia grande fonte di ispirazione³, quello che conta è la lunga percorrenza.

All’interno di questo contesto Agnese è arrivata a formulare attraverso il suo post una serie di conclusioni assolutamente giuste (dal mio modesto e parziale⁴ modo di vedere) sulla brand identity. Senza volervi raccontare anticipatamente altro, vi invito a leggere direttamente quello che ha scritto lei clickando qui.

Una cosa però la voglio ancora scrivere: questo progetto, che ho seguito da bordo campo come un allenatore troppo anziano anche per impartire consigli, è una cosa tutta loro di cui sono fierissimo perché ho visto che un gruppo di persone in autonomia è arrivato a contaminarsi smodatamente, e a capire che il mischione clamoroso di competenze e punti di vista molto spesso produce qualcosa che va ben oltre la somma delle parti.

E al di là di classi astratte e funzioni pure, è qualcosa di cui dovremmo tenere spesso conto anche noi sviluppatori.

Photo courtesy of Suzanne Jutzeler

Back to Linux

Atto di dolore: il mio computer fisso è stato un Hackintosh per una cospicua dose di anni. L’ho costruito in un momento in cui la supremazia di Intel nelle macchine di Apple sembrava essere una cosa indiscussa per gli anni a venire, e in un momento di straordinaria compatibilità con tutto l’hardware esistente. Non mi sento di aver buttato soldi e tempo, anzi: ho acquisito negli anni mettendo le mani in pasta con varie distribuzioni di macOS per dispositivi non-Apple una certa conoscenza di quello che c’è sotto il cofano, cosa che per un appassionato di sistemi operativi è sempre una grossa soddisfazione.

L’ultima build è stata particolarmente compatibile e divertente, sono stato aiutato da Gianguido e il setup ce lo siamo fatto insieme in videocall anni e anni fa. E non c’era nemmeno una pandemia globale in corso!¹

Insomma: di punto in bianco per colpa di Apple smettono di uscire i driver NVIDIA per MacOS, quindi non posso più aggiornare il mio sistema operativo. Di seguito una lista di ottimi motivi che mi hanno riportato sulla retta via:

• Niente più aggiornamenti del sistema operativo, quindi niente più nuove feature. Non sarebbe stato un problema, le nuove feature dei sistemi Apple sono veramente fegatelli. Se non che…
• Le applicazioni hanno smesso quest’anno di supportare High Sierra (che era la versione a cui ero fermo): Docker mi avvisava con un inquietante popup che avevo una versione non supportata, e di aggiornare il mio sistema operativo; il carico da novanta ce l’ha messo Homebrew qualche settimana fa mostrando un bel messaggio in console dicendo che da quel momento se avessi incontrato qualche problema di build era fortemente sconsigliato che aprissi una issue su GitHub. Lo stesso iTerm non gira più su High Sierra se non sbaglio.
• Ho aggiornato il laptop a Big Sur. Sul lato performance niente da dire, penso che sia stato fatto un ottimo lavoro. Sul lato UI viceversa ho pensato “chi ha trasformato il mio computer in un Kid Clementoni?”
• Last but not least, le mie cuffie bluetooth appena acquistate hanno qualche problemino con lo stack bluetooth/audio di macOS.

Insomma, nonostante io adori il fatto di avere un sistema operativo curato dal punto di vista della UX, la convivenza era diventata estremamente difficoltosa; quindi mi sono sentito in potere, una volta accumulato il coraggio di mandare a terra un setup vecchio di circa 3 anni e spicci, di sbattere macOS fuori di casa.

Hello Linux my old friend

Non voglio fare paragoni azzardati (e sarebbe un enorme atto di hybris) ma ogni volta che succede questa cosa mi sento come Daniel Robbins che torna a Linux dopo anni di BSD. Il primo pensiero che ho avuto, una volta avviata la mia Linux box reinstallata di fresco, è stata “flexibility at your fingertips”, ovvero qualsiasi personalizzazione finalmente a portata di dito. Con un briciolo di vergogna mi chiedo: perché ci ho messo tanto?

Ovviamente ho dovuto prendere qualche precauzione: negli anni ho accumulato un sacco di piccoli trucchetti e cavolate personali per aumentare il throughput della mia giornata lavorativa, e tutta questa suite di script, programmini e utility varie ha richiesto qualche piccolo adattamento. In un weekend lungo comunque (standoci dietro relativamente poco tempo se non la mattinata che mi ha richiesto l’installazione iniziale di Arch Linux²) ho sfangato tutto quanto, soprattutto per quanto riguarda il remap della mia tastiera, su cui avevo fatto un bel lavoretto di fino usando Karabiner. Ho riportato tutto su Linux usando xkeysnail, un software di cui probabilmente parlerò più in dettaglio a breve.

Dall’altra parte, una volta attraversata l’imperscrutabile barriera del “avrò una workstation funzionante prima di sera?”, mi sono potuto sedere un attimo a osservare il setup che avevo tirato su. Un setup per la precisione composto di:

• Arch Linux (kernel 5.9.14-arch1-1 al momento della scrittura di questo post);
• Systemd 247.2 e systemd-boot come bootloader, grazie a gsora e smlb per i consigli³;
• GNOME 3.38.2;
• Tema Arc Solid, una certezza;
• Un po’ di estensioni per GNOME Shell, giusto perché di serie viene fuori un po’ sguarnita⁴;
• Tilix come emulatore di terminale;
• Rofi come launcher di applicazioni;
• Firefox come web browser;
• Una sequela di altre applicazioni con le quali vi annoierei e basta.

Devo dire che sono rimasto piacevolmente colpito soprattutto dal fatto che GNOME Shell abbia risolto i suoi problemi di performance, dal fatto che Nautilus che già prima era un signor file manager adesso è veramente super maturo (con un bel po’ di feature e una bellissima interfaccia⁵), e dal fatto che lavorare con Linux è ormai un piacere raro.

Docker non è costretto a ricorrere a una ridicola macchina virtuale per poter funzionare, e l’hardware che hai sotto lo puoi sentire scalpitare. L’altro giorno ho scritto a un amico che stavo compilando una release di Erlang - tempo che lui mi rispondesse la macchina aveva già finito. Insomma: avete capito no?

Lavorare con GNOME oltre tutto è una sciccheria: devo dire che una volta risolti i problemi di performance dell’ambiente grafico macOS non mi manca per niente, specie dato il fatto che mentre GNOME è migliorato esponenzialmente anno dopo anno la UI del mio Macbook è diventata sempre peggiore. L’esperienza utente è ugualmente rifinita, e con dei piccoli ritocchi al tema di base (come ho già detto uso Arc nella variante solid, anche se Adwaita è migliorato un sacco nell’ultimo anno) si può veramente azzardare il paragone con altre esperienze desktop nella UX delle quali vengono spesi miliardi l’anno.

Insomma: è anche la prima volta che provo un setup full Linux col mio doppio monitor. E devo dire che mi trovo egregiamente. Spero che la soddisfazione cresca ancora :-) e soprattutto spero di scrivere presto qualche piccola guida “vecchio stile” riguardo delle cose che ho scoperto in queste settimane di rinnovata convivenza col pinguino.