13 Oct 2019
Gergely Orosz, qualche giorno fa (e se non seguite il suo blog ve lo consiglio caldamente):
[…] “bad code” is a lazy expression. It’s not specific and means different things to everyone.
Suggerisce quindi alcuni consigli quando si arriva a criticare del codice in maniera sana suggerendo un refactoring o direttamente in fase di scrittura. Come sempre l’interazione coi compagni di team risulta cruciale:
- Be specific
- Give a specific suggestion
- Talk about the future implications of the code you see, if not changed
- Ask the person writing the code, what they think about your comments
Sono tutti consigli giusti, e sono tutti principi che metto in pratica costantemente e che impattano sulla qualità finale del codice. Mi sento di aggiungerne uno mio in coda: se qualcosa ti sembra generalmente debole, i tuoi commenti non vengono apprezzati, o banalmente non c’è tempo e le cose stanno funzionando in questo stato di precarità, copri quella funzione infame con una suite di test. Questo permette di metricare “quanto” effettivamente un pezzo di codice è prono a rompersi, attraverso test stressanti (quindi copertura dell’happy path e due/tre altri casi più “tricky”) che rendano più sicura l’evoluzione della codebase tangente quella funzione, quel metodo, quell’oggetto che stiamo prendendo in esame.
A quel punto non c’è niente da fare: una test suite scritta bene parla per te, e funge da dimostrazione euristica che le tue preoccupazioni sono infondate, oppure che c’è qualcosa che va aggiustato immantinente.
A quel punto se il test infame continua a rompersi, beh: non è un problema tuo no? Anzi: in fase di riscrittura o in generale di miglioramento, avrai le spalle coperte dal te stesso del passato.
13 Oct 2019
Un post recente di ThoughtBot riguardo i messaggi privati nei tool di comunicazione aziendali e non:
Private messages silo information, which means either people have to repeat themselves or others miss out on the conversation. When you don’t allow others the chance to participate, everyone misses out on an opportunity to learn from each other.
Nell’eventualità in cui Bob e Alice vogliano scambiarsi un messaggio, a meno che non sia qualcosa di estremamente faceto come una lista della spesa, o un paio di raccomandazioni su qualche posto dove mangiare a New Orleans, la vedo dura che un messaggio mandato in un canale pubblico sia oggettivamente di poca utilità. La vedo altrettanto dura che incoraggiare l’atteggiamento opposto, ovvero discutere di tutto in privato, sia produttivo sia per il team che per l’azienda.
Di solito quello che viene a crearsi è un sapere frammentato in insiemi delle parti.
Di seguito quindi le mie raccomandazioni riguardo la comunicazione asincrona per i lavoratori del digitale e non, remoti o on-site che siano:
- Manager/Leader: questo tipo di figure si dovrebbero assumere il compito di facilitare la comunicazione attraverso atteggiamenti concilianti e la diffusione di blameless culture. Allo stesso modo non dovrebbe far sentire gli altri costantemente osservati dall’occhio di falco del capo.
- Worker: chi mira a lavorare in un ambiente di questo tipo non dovrebbe avere paura di sentirsi osservato, perché sarebbe estremamente scorretto da parte di chi sta più in alto nell’organizzazione strumentalizzare i messaggi per usarli in altri tempi e altre sedi.
Team che affrontano i problemi di comunicazione usando l’approccio opposto devono prepararsi ad affrontare una serie di effetti collaterali dovuti ai silo che si creano per via di questo tipo di attività.
Il 99% dei team che ho preso in esame nella mia vita lavorativa, alla fine dei giochi, non erano pronti ad affrontare questo tipo di side-effect.
Lascio a voi l’esercizio di immaginare le conseguenze.
01 Sep 2019
Ho iniziato a leggere un thread affascinante su LWN, in ripresa di un post piuttosto lungo sul blog di Packt:
Systems programming often involves low-level manipulations and requires low-level details of the processors such as privileged instructions. For this, Rust supports using inline Assembly via the ‘asm!’ macro. However, it is only present in the nightly compiler and not yet stabilized. Triplett in a collaboration with other Rust developers is writing a proposal to introduce more robust syntax for inline Assembly.
Non penso che il punto sia rendere obsoleto C quanto ormai è obsoleto Assembly. Casomai, penso che il punto sia ridare dignità a ognuno di questi strumenti nel modo migliore. Rust è un ottimo rimpiazzo di C per quanto riguarda la programmazione di sistema, soprattutto quando vengono meno determinati bisogni (ovvero restrizioni dovute alla memoria che puoi avere su determinati chippetti). Assembly, viceversa, è un tool che a meno di assurde invenzioni non è possibile sostituire.
Rust indirizza tutti questi bisogni in una maniera estremamente elegante, unendo una sintassi estremamente efficace, tooling ottimo, soprattutto moderno, e alcune finezze funzionali che lo rendono il mio primo candidato quando si tratta di piccoli programmi.
Il thread su LWN è veramente ricco di spunti, ve lo raccomando. Per esempio dal commento di Archimedes:
cargo as build system is “nice and simple” and can handle a lot but falls short if complex builds are needed which can be done in C using the automake/autoconf, cmake, … hell …
Questo evidenzia una giovinezza in alcuni aspetti del tooling legato a Rust, e anche degli aspetti in cui la catena di montaggio attuale si può migliorare a tal punto da servire come punto d’appoggio per una brand awareness fortissima da parte di aziende che decidono di scrivere larga parte del loro software in Rust, e sentono questo tipo di necessità.
Poi non venite a dire che non ve l’ho detto. ;-)
31 Aug 2019
Ne hanno già parlato ampiamente tanti blogger, su tutti voglio citare Aldo:
Questa mattina ho ricevuto un invito tramite Google Calendar a partecipare a un “evento” in cui avrei vinto un iPhone. L’invito era ripetuto per 5 giorni, dal 23 al 27 agosto. Ovviamente l’invito conteneva un link.
A quanto pare, l’orbe terracqueo ha scoperto che se invii una email con un invito a un evento su Google Calendar, quell’evento viene subito aggiunto al calendario con tanto di notifiche ricorrenti su partecipazioni, accettazioni e quant’altro. E gli spammer hanno capito che era terreno fertile.
Ne sono molto infastidito: è una feature che usavo da anni, e pare che l’unico modo per scongiurare l’eventualità che questo tipo di evento ricapiti sia disabilitare la possibilità che GMail faccia questa cosa. Sempre dal post di Aldo:
È possibile evitare del tutto questa truffa, cambiando due impostazioni generali di Google Calendar, che sono attive di default. Basta disattivare in “Impostazioni generali” > “Impostazioni evento” > “Aggiungi automaticamente gli inviti”, mettendolo su “No, mostra solo gli inviti a cui ho risposto”, mentre, poco più sotto, in “Opzioni di visualizzazione” disattivare “Mostra eventi rifiutati”.
Io però sono estremamente contrariato: semplicemente vorrei che Google disabilitasse questo tipo di comportamento per le email marcate come spam. Altrimenti si viene condannati a smettere di usare qualcosa di comodo, semplicemente per via di uno scriteriato abuso da parte di qualcun altro.
15 Aug 2019
In questo periodo di totale nullafacenza che sono le ferie mie e di Agnese ho preso la palla al balzo per dare un’aggiornata globale a un progetto che ha preso un numero imbarazzante di star su GitHub, che aveva bisogno di tantissimo amore (non ci mettevo mano letteralmente da anni), e che aveva anche un discreto numero di notifiche di sicurezza dovute a librerie non aggiornate.
Sto parlando di Stocazzo As A Service, un esperimento divertente che mi ha permesso illo tempore di sperimentare un po’ con Hapi, un framework per lo sviluppo di applicazioni web, e che ha persino ricevuto qualche pull request interessante.
Ci ho messo abbastanza poco a capire che non sarebbe bastato aggiornare le dipendenze, e che in realtà la codebase aveva bisogno di una riscrittura totale in barba a tutte le raccomandazioni del tipo “non andare a rompere quello che funziona” che ogni guru del software vi darebbe. Non essendo un pazzo suicida però ho deciso di lavorare iterativamente, seguendo la regola del boy scout, un sacco di cautela e la suite di test che avevo già scritto in precedenza.
Siccome vengo da anni di JavaScript ma soprattutto anche da (meno) anni di Elixir nel tempo libero, ho sentito subito la mancanza di alcune cosette:
- Un formatter come
mix format;
- Un tool di analisi statica come Credo;
- Pipe operator e immutabilità.
Siccome per quanto riguarda la terza non potevo farci niente (almeno non sul momento), ho deciso di concentrarmi sul rendere la mia toolchain un po’ più confortevole, quindi ho aggiunto Prettier e ho configurato npm per formattare tutto tipo mix format; successivamente, ho dato un bel giro di vite alla codebase esistente aggiungendo ESLint al progetto con una configurazione abbastanza generica.
A quel punto ho aggiornato le librerie di testing (Code per expectation e Lab per la test instrumentation) e ho cominciato a vedere cosa si rompeva. L’interfaccia col webserver in realtà non era cambiata molto: il brutto del guardare indietro al codice che hai scritto tanto tempo fa è più che altro lo sguardo lanciato nel baratro degli errori di gioventù che hai commesso. Tipo un modulo utils e una serie di funzioni dentro che fanno “cose” fantasiose coi parametri che gli passi. Ho stracoperto quella parte di test, perché era la parte più debole, poi ho portato tutto alla nuova versione di Hapi, che è leggermente diversa nel funzionamento dato che si basa molto su async e await. Contestualmente ho aggiornato la test suite, in modo da usare nuove funzioni.
L’ultimo passo è stato cominciare a riscrivere la libreria di “utils” che avevo partorito all’epoca. Ormai forte di una test suite a prova di bomba, non potevo rompere niente e sono stato guidato dai test rotti alla ricerca di eventuali problemi.
Ci ho messo un paio d’ore a fare tutto, forse tre. Non era una codebase particolarmente larga, quindi mi sono potuto permettere il lusso di farle un lifting completo.
“Che c’è di nuovo?” Direte voi, miei lettori. “È una storia di un refactoring come tanti altri”. Ed è vero. Quello che ho notato però è come la mia esperienza con un altro linguaggio e un’altra piattaforma mi abbia condotto alla ricerca del miglior tooling per fare quello di cui avevo bisogno, e come io abbia messo in pratica best practice totalmente trasversali.
In parole povere, sono convinto che nel momento in cui impariamo un nuovo linguaggio, o un nuovo tool, impariamo un nuovo modo di lavorare oppure perfezioniamo il metodo che abbiamo già. E questo, almeno per me, è incredibilmente incoraggiante, perché con questa esperienza ho avuto modo di toccare con mano quanto il tempo che ho speso su Elixir abbia cambiato in meglio le mie abitudini in maniera estremamente profonda.
Photo courtesy of Safar Safarov
