Appena ho una mano libera

Questo periodo sto facendo un sacco, un sacco, un sacchissimo di cose.

Sto dando una mano con quelle poche conoscenze di Rust che ho a mantenere il mio feed reader per Linux preferito.

Sto lentamente riprendendo a contribuire a CouchDB.

Mi sto ammutinando, insieme a un gruppo di amici invasati, una volta a settimana, occupando in modo coatto il podcast di un caro amico.

Ma soprattutto, ho una casa nuova da sistemare e arredare insieme ad Agnese. Oggi ho finito di installare e attivare la connessione internet mentre arrivava un fracco di elettrodomestici nuovi.

Tutto questo per dire: avrei un sacco di cosette da scrivere, ma al momento mi trovo con troppa roba per le mani. A prestissimo!

Recensione: The Pragmatic Programmer, di Andrew Hunt e David Thomas

Prima di mettersi in bocca paroloni come “cloud native”, “microservizi” o cose simili, è necessario rafforzare i principi di base che muovono uno sviluppatore attraverso delle precise scelte di design. Come mai un determinato pezzo di software è scritto in un modo piuttosto che in un altro? C’è sempre una risposta a interrogativi di questo tipo, e The Pragmatic Programmer parla proprio di questo: delle persone che stanno dietro gli automatismi e il codice di cui tutti i giorni fruiamo e che chiunque faccia il nostro stesso mestiere ha davanti per almeno una decina di ore al giorno.

Al posto di abbandonarsi ai design pattern e ai tecnicismi (per quanto legittimi) questo libro è completamente composto di principi che rendono davvero uno sviluppatore forte di quello che conosce, piccole pillole come “cosa fare quando qualcuno ti chiede qualcosa”, “come comportarsi di fronte alle stime”, oppure il rubber-duck-debugging che oggi ormai è dato per assodato e le cui radici invece risalgono proprio a questo stupendo testo.

Testo che come avrete avuto modo di notare è vecchiotto; la prima edizione è del 1999, e per quanto nel tempo siano uscite varie riedizioni principalmente volte a svecchiare alcuni concetti e gli esempi ormai datati, il grosso dell’opera non è mai stato modificato e col tempo non solo tutto questo gli è valso il titolo di “uno tra i libri più influenti di sempre sulla programmazione”, ma per me è il libro più influente di sempre sullo sviluppo software. Personalmente - e lo dico complice il fatto che di libri tecnici ne ho letti, sia per l’università che nella banale sezione della manualistica - non sarei lo stesso sviluppatore, oggi, se non avessi letto The Pragmatic Programmer da cima a fondo, ahimé anche troppo tardi, l’anno scorso.

È stata una lettura che mi ha preso tempo ma alla fine è valsa la pena di ogni secondo speso sulle pagine, alcune veramente scorse a fatica perché è un testo denso.

I concetti che mi sono rimasti maggiormente come più cari da The Pragmatic Programmer? Eccoli qua:

• Il principio di ortogonalità dello sviluppo software: a volte è necessario che due entità all’interno di un sistema evolvano in parallelo in maniera disaccoppiata. Nel 2021 può sembrare un concetto naìf, ma provate a rileggere il vostro codice alla luce di questa affermazione;
• La teoria delle finestre rotte: più un progetto è marcio più è facile che marcisca. Quando vedete qualcosa che non va, aggiustatelo subito. Se avete un progetto pieno di cose che funzionano a singhiozzo, fate una lista delle cose da aggiustare e cominciate. Vi sorprenderete di quanto possono migliorarvi la vita anche piccoli gesti, se applicati con costanza;
• Il portfolio delle conoscenze: come state evolvendo il vostro skill set, soprattutto parlando di hard skill? Quanti linguaggi conoscete? Avete voglia di espandere la vostra toolbelt periodicamente?
• Power Editing: l’editor di testo per uno sviluppatore è come la coperta di Linus, o più semplicemente il mezzo attraverso cui quello che sappiamo si traduce prima in qualcosa di fruibile e in un secondo momento in denaro (momento venale, scusate). Conoscere il proprio editor di testo, facilitandosi il lavoro con tutto quello che il software che usiamo mette a disposizione, è essenziale per uno sviluppatore efficace;
• Tracer Bullets: saper tracciare un percorso lungo tutta la filiera (il data path, se vogliamo usare un tecnicismo) che i nostri dati percorrono, mettendo a punto una funzionalità in modo grezzo e successivamente rifattorizzarla e aggiungere le parti mancanti. Saper individuare con esattezza quali parti compongono lo scheletro della funzionalità che stiamo implementando e quali invece possono essere tralasciate per essere aggiunte senza sforzo in un secondo momento è un’abilità secondo me chiave per ogni ingegnere del software di successo.

Volete comprarlo? In ebook lo trovate in un sacco di posti, in hardcover è più difficile trovarlo. In ogni caso il libro ha a corredo un sito ufficiale su cui non solo viene venduto, ma su cui è presente la “Pragmatic Bookshelf”, ovvero altri libri di autori fidati su tematiche belle da spolpare. ;-)

Linux Foundation e OpenJS Foundation lanciano un corso gratuito di Node.js

Non sono tanto il tipo da certificazioni, ma una cosa è certa: alcune volte per scollinare un argomento particolarmente ostico serve avere un qualche tipo di aiuto da parte di qualcuno che ne sa di più. Node.Js per me non ha mai rappresentato un argomento ostico, così come JavaScript in generale, ma devo ammettere di aver avuto dei tutor e dei compagni di studi eccezionali.

Per chi non avesse lo stesso tipo di fortuna, sono molto felice di sapere che la Linux Foundation insieme alla OpenJS Foundation sta lanciando un corso gratuito di JavaScript e Node.Js. Siccome io adoro JavaScript, vi lascio il linketto qui così magari ve lo appuntate.

Sicuramente sarà fatto meglio di qualsiasi corbelleria che ti propinino i bootcamp che ti trasformano, a detta loro, in un full-stack developer in sei mesi.

Introduction to Node.js

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.