Qualche giorno fa Brent Simmonsha dato l’annuncio del lieto evento: uno dei progetti open source migliori di cui io abbia mai seguito gli sviluppi ha annunciato la versione 6.0, e quel software è proprio NetNewsWire.
Ma cominciamo dall’inizio: cos’è NetNewsWire? NetNewsWire è un lettore di feed RSS che sincronizza anche con Feedly, Feedbin, e un’altra buona caterva di servizi online per leggere i feed. Quest’ultima versione sincronizza anche i feed letti, nel caso in cui non usassimo nessuno di questi servizi, direttamente via iCloud; personalmente io sono un grosso fan dei feed RSS per praticamente qualsiasi cosa, e uso NetNewsWire principalmente come “interfaccia” per quanto riguarda il mio account Feedly.
Ho un’applicazione di questo tipo per ogni dispositivo che uso, il mio Macbook non fa eccezione, e devo dire di non essere mai stato così soddisfatto di un feed reader, anche perché di NetNewsWire posso vedere tutto il codice su Github, che è una cosa molto particolare se consideriamo che stiamo parlando di un’applicazione per Mac.
Brent Simmons ne parla parecchio, e si concentra spesso sullo stimolare questo tipo di sforzo per quanto riguarda l’ecosistema Apple, persino nella guida ai contributi per il suo lettore di feed:
First thing: don’t send money. This app is written for love, not money. :)
NetNewsWire is all about three things:
The open web
High-quality open source Mac and iOS apps
The community that loves both of the above
Supporting all these things takes work.
In poche parole: NetNewsWire è il mio lettore di feed preferito per Mac. Questa nuova versione introduce un bel po’ di novità. È open source. Spero di avervi fatto venire voglia di usarlo.
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!
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 è illibro 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. ;-)
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.
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.
