un tossisco sullo schermo.

Vado a riempire la bollaccia ma voi partirete, ci sono.

Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.

Sono le 9.46 e stiamo registrando sempre sempre più tardi, ma comunque Gitbar resiste e ogni settimana arriva nei vostri lettori di podcast.

Mi raccomando newpodcastapps.com per trovare un lettore di podcast indipendente oltre al classico Spotify.

Ecco, forse è anche il caso di utilizzare un podcast reader che supporti bene tutte le feature e che in qualche modo non ci intrapoli nel contesto di Spotify.

Benvenuti su Gitbar, il podcast dedicato al mondo dei fullstack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.

È arrivato il momento di presentare i due ospiti di oggi.

Uno è una conoscenza ormai sedimentata di Gitbar, nonché un mio caro amico, e un altro è una conoscenza abbastanza nuova di Gitbar, è la prima volta che lo sentite qua, ma anche lui è una persona che stimo tantissimo.

Abbiamo con noi Paolo Insonia e Marco Ippolito.

Ciao ragazzi! Buonasera! Piccola introduzione giusto per capire chi siete.

Allora, Paolo è uno staff engineer a NearForm, ormai stasera Gitbar è un po' casa NearForm, siamo tre NearFormer che registriamo e non è sponsorizzato questo episodio, lo dico subito, quindi possiamo dire tutto il contrario.

Paolo è staff engineer a NearForm, è anche una delle peste di diamante del DevRel Team.

Marco invece è un software engineer a NearForm e anche lui è uno dei membri del DevRel Team di NearForm, dico giusto? Sì, dici bene, dal primo aprile sarò ufficialmente nel team di Developer Experience di NearForm.

Ok, Marco ha subito sottolineato una mia incorrettezza, io ho detto DevRel Team perché questo periodo ce l'ho in testa, ma in realtà si tratta di un team di Developer Experience.

Ve ne ho parlato più di una volta di questo team qui ai microfoni di Gitbar, ma oggi li ho invitati per raccontarci una storia.

Voi lo sapete, a Gitbar non raccontiamo spesso storie, esperienze e percorsi di carriera, però dicevo, ho voluto apportare questa esperienza personale, questo percorso personale, perché ho osservato un momento particolare di questo percorso che in qualche modo era la partenza, no? E poi con assoluto piacere ho visto come si è evoluto, però io sono una vecchia, avete presente le vecchie che stanno alla finestra e che devono sapere tutto di tutti? Mi mancano i passi intermedi, no? Per cui sono qua a chiederveli.

Iniziamo la storia.

Molti di voi hanno sentito di Alicante, perché nella puntata con Michele ne abbiamo parlato, praticamente abbiamo fatto un'ora e mezza dove parlavamo della nostra esperienza ad Alicante.

E proprio ad Alicante, durante un giro in bicicletta, io ricordo chiaramente una frase di Marco che diceva, oh raga, io sono, ho voglia di fare qualcosa di figo, tiratemi fuori qualcosa di figo.

E poi vedi Paolo che disse, tranquillo, prepara il culo sulla sedia perché ci penso io, ti devasto.

Da quel punto, in nulla fino a raggiungimento, cioè in nulla, io non ho più visto niente, fino a raggiungimento però di un traguardo che dal mio punto di vista da osservatore esterno è un traguardo importante per il quale io faccio i complimenti a Marco e per il quale poi ne parleremo.

Però voglio che in qualche modo mi raccontiate cos'è successo dopo quel preparati perché ti devasto.

Vai Marco, lasciatela parlare.

Come un po' tutte le grandi storie si inizia da uno scherzo, così da una battuta.

Io ero sempre, mi ricordo sempre interessato al nodo, al soccorso, ai funzionamenti, però vedevo questo progetto enorme, molto complesso, a cui non avrei saputo come approcciarmi in nessun modo.

Allora, così, scherzando, visto che Paolo è uno dei contributori che abbiamo in NearForm, ho detto dai, ci vorrei provare anch'io, cioè vorrei fare anch'io qualcosa di figo, allora glielo ho lanciato, gli ho detto così dai fammi partecipare anche a me e mai avrei sospettato che poi sarebbe andata a finire così.

All'inizio è stato uno scherzo, poi effettivamente mi sono messo lì sulla prima issue e ci ho messo una settimana per scrivere tre righe di codice e poi piano piano, grazie a Paolo, grazie a tutte le issue che lui mi consigliava e al lavoro, insomma, ho acquisito familiarità con il progetto e sono stato impegnato, quindi è stato un percorso abbastanza lungo, comunque ci sono voluti circa sette mesi, sei, sette mesi, è stato anche un percorso duro, cioè, di contribuzioni costanti fino a sera tardi, sabato e domenica, però mi sono divertito, è stato divertente.

Giusto per fare chiarezza, ormai l'hai spoilerato, quindi possiamo dirlo, il ruolo che poi alla fine di questo percorso di sette mesi che hai fatto è stato quello di core collaborator su Node.js, correggetemi se sbaglio potrei fare strafalcioni.

Da quel momento, dal momento in cui Paolo ha sentito la tua disponibilità, tu Paolo come ti sei mosso? Perché trasformare un'offerta da una parte, una disponibilità che è da una parte un'offerta, io ci sono, ma dall'altra anche una grossa richiesta d'aiuto, guidami per favore, a livello pratico come si pone un mentor all'inizio di questo percorso? Il punto è, partendo dall'inizio, dal primissimo momento, voi mi conoscete, giornalmente sono un burlone, ti ho fatto uno scherzone per la cronaca, non ho voluto perché mi sono dimenticato per davvero di chiedertelo, e quindi ho detto proviamo.

Io sono un burlone, l'avete visto spesso e volentieri, anche in ambiti assurdi, però Marco mi si è avvicinato e ha detto, ma perché voglio fare qualcosa di bello, e ho pensato, fa sul serio, non fa sul serio, la butta lì tanto per, però poi non è sul serio, però a un certo punto mi sono reso conto che sì, scherzava, ma non completamente, quindi era davvero interessato.

E allora il punto è, questo magari ne possiamo parlare in seguito, ma parte dell'attività di X-Team o DevRel, come lo vuoi chiamare tu, perché poi manco noi sappiamo come ci chiamiamo di preciso, siamo di solito DevDX, ma facciamo DevRel per tutto il resto del pianeta, quindi passiamoci il nome.

Il punto è stato, come Dx noi, come Nier Form, il team di Nier Form non è solo pensato per l'esterno, diciamo, noi facciamo Dx verso l'esterno, il team è pensato anche per fare mentoring, appunto, e attività di coaching interne.

Quindi se viene una persona da me e dice, voglio iniziare a fare su Node, io ti piglio, o a un certo punto ti prendo sul serio.

A quel punto ho applicato l'unico metodo che conoscevo, e anche un metodo per cui ho letteralmente mandato a quel paese in maniera buonaria il mio mentor su Node, durante un collab summit, perché vi racconto questo aneddoto.

Durante il collab summit che ha proceduto nel NodeConf, quindi vi parlo di ottobre, noi con il laboratorio discutevamo su come si porta nuova gente su Node, come si fa, come possiamo fare in modo che la gente venga su Node, inizi a contribuire e vada avanti, e il mio mentor, che è il buon Matteo Collina, che tutti ben conoscete, se n'è uscito con, beh, li sommergiamo di issue e vediamo se si riemergono, letteralmente, questo è letteralmente ciò che ha detto, davanti a tutti quanti, al che io devo dire che ho risoluto di fronte a lui, ho fatto Matteo, mi ha fatto morire per me, si va a cagare, buonariamente proprio, però quando poi mi è troccato a me, mi sono reso conto che effettivamente l'unico metodo è quello, ovvero, è chiaro che non ti lascio in una issue senza guida, però te ne do tante, con difficoltà spero crescenti, sottolineo spero perché a volte quella che sembra il fix di una riga si richiede un incubo di due mesi e viceversa, quindi uno ci prova da quello che la issue descrive, dice guarda questa mi pare facile, poi magari un assurdo incubo, però ci proviamo, quindi a difficoltà crescenti, seguendo in questo caso Marco mano a mano, diciamo guidandolo nel prendere familiarità con una porzione del codice di Nod, fino a che poi non diventi autonomo e poi inizi a farlo da solo, purtroppo non c'è altro da fare, sembra crudele, sembra il classico paragone degli spartani che buttavano la gente dalla rupe o i leoni dalla rupe, robe del genere, ma in questo caso purtroppo non ho trovato un metodo migliore, però a quanto pare ha funzionato, quindi o mi è andata di fortuna o ci ho colto una delle due, non lo so.

Quindi non esiste un learning path per l'esplorazione di una codebase vasta e complicata come può essere quella di Nod? Secondo me il problema non è la vastità ma è l'età, perché è quello il problema, la codebase vasta puoi provare pure a esplorarla, ma se noi pensiamo che Nod, la prima release uscita alla bellezza di, stiamo nel 23, di 14 anni fa, quando si scriveva un javascript diverso, con dei pattern diversi e robe varie, e ci sono pezzi stratificati di quella codebase, perché magari ci sono dei moduli in recenti, quindi il codice abbastanza recente, la butto lì l'ultimo inserito il test runner, è codice recente, più o meno ci si riesce a mettere in mano, ma nel mio caso specifico ho scelto all'epoca di occuparmi dello stack HTTP di Nod, quindi HTTP client, HTTP server, che esistono dalla versione 0 di Nod, quindi lì c'è stratificato 14 anni di bug, feature, refactoring, refactoring soprattutto parziali sfortunatamente, che poi si vanno magari a combinare con, simultaneamente, la stessa situazione nel modulo stream e la stessa situazione nel modulo net, perché poi si basano su quelli, e quindi il problema non è capire come è fatto il codice, bene o male lo riesci a seguire, a volte è capire perché fa così, è una cosa antilogica, ma poi capisci che aveva senso quando venne scritto, ma adesso è stato tolto, ma non è stato aggiornato tutto, perché ovviamente è enorme, Marco potrà confermare, ci sono delle cose da comprendere, che ci vuole un giorno solo a capire cosa fa una riga di codice, certe volte, e non è quante righe sono, è quali righe sono, sfortunatamente.

Voglio passare a Marco, c'era una volta Marco, che fa il pull della codebase di Nod e inizia a metterci mano, sinceramente, dal momento in cui tu hai aperto il primo file, qual è stata la tua paura se ne hai avuto una? Il primo impatto con Nod è spaventoso, perché anche solo per buildare il progetto e per lanciare i test bisogna seguire una guida piuttosto dettagliata, quindi scaricare Xcode, fare il setup di Ccache, Ninja, ci sono tutta una parte di tooling che va fatto il setup, e poi la prima build impiegò qualcosa come 20 minuti, quindi ho detto, ma cosa sto facendo JavaScript? Infatti poi, diciamo, lavorare sul codice è stato come imparare un linguaggio nuovo, perché il JavaScript con cui è scritto Nod è un po' particolare, sono dei pattern di gruppo nero familiari, dei pezzi di codice un po' arcani, che non avevo mai visto nella mia esperienza, quindi mi sono ritrovato come da zero, come una persona che deve imparare tutto e su quella codebase ero un po' spesato, però grazie alla prima issue, che era un'issue banale, però da lì, grazie all'aiuto di Paolo, guardando, spiegandomi cosa faceva questo pezzo di codice, cercare di capire cosa stesse succedendo, da lì piano piano ho iniziato a prendere familiarità con il codice attorno a quello che poi su cui dovevo lavorare per risolvere la issue, quindi prima capire cosa faceva quella funzione, capire cosa poteva fare, e anche adesso dopo un bel po' di contribuzioni, penso di aver visto forse il 5% della codebase, ci sono tantissime parti di cui non conosco nulla e non ho mai visto ancora per quanto è vasto e complesso il progetto, quindi la mia paura è stata di non essere in grado, di non essere capace poi di metterci le mani, perché una volta scaricato si magari compila pure, poi il problema è farla, è risolverla la issue, non è stato facilissimo.

Vedo ancora la fatica e il dolore nei tuoi occhi mentre lo racconti e Paolo fa sì con la testa.

Un po' sai mi hai ricordato, non tanto tempo fa, qualche settimana fa, quando mi sono compilato Node Core, che era il primo, scusami, mi sono compilato Bitcoin Core, anche quello una codebase dove c'è c++, è una compilazione che dura più di un'oretta, per lo meno la mia macchina ci ha messo più di un'ora nel portatile, e là si attiva una cosa, si attiva la, solitamente, faccio, apro una parentesi, solitamente quando approcciamo una codebase, in un modo o nell'altro, in prima, seconda issue, riusciamo a conoscere, a conoscere una buona parte del progetto, 60-70%, prima, seconda, terza issue, e quindi siamo confident.

Nel momento in cui si approccia a queste enormi codebase, si deve superare il limite psicologico del non posso sapere tutto, quindi in qualche modo devo fare i conti con quello che non posso sapere, che mi circonda e che magari in parte devo intuire, e questa cosa spaventa, e questa cosa spesso triggere, io porto anche un po' della mia esperienza personale, spesso triggera il far capo, il contattare il mentore.

Adesso, con quanto, ogni quanto lasso di tempo a contattare il mentore, quello varia dalla paura che si genera, quindi dal loop di paura, di tensione interna che si genera, e dalla disponibilità del mentore.

C'è da dire che si rischia di finire in situazioni dove si pinga il mentore ogni quarto d'ora.

E qua voglio passare dal mentore invece, come si fa a Paolo quindi, come si fa a controllare il pushback da parte del mentino, il fatto di, pa' non ci ho capito un cazzo, aiutami, pa' che cos'è questa cosa, e come fa il mentore a dire no, spendici un'altra ora, qual è la linea guida per dire no, ci devo investire ancora più effort tu, prima di venirti a guidare.

Allora, faccio una digressione giusto su quello che hai detto prima, per fare un plauso a chi ha organizzato Node, perché è una cosa che tu parlavi sul discorso del 60-70% della codebase, eccetera.

Quando io ti ho detto che mi occupavo dello stack HTTP di Node, non era un'informazione completamente casuale, nel senso, quando tu inizi a contribuire su Node, scegli un ambito di cui occuparti.

Nessuno si aspetta che tu conosca tutti i moduli, io conosco solo HTTP, NAT e STREAM, non ho idea di come sia fatto per esempio CRYPTO o ZILIB o roba del genere.

Quindi questo ti aiuta, perché tu sai che arrivano liscio su ZILIB, a parte che GitHub nemmeno ti notifica, perché sono fatti in un modo particolare la notifica.

Se la ish non ha a che fare con lo stack di cui ti occupi, te ne puoi dimenticare.

E ti aiuta perché ti aiuta l'ansia di dire non devo imparare tutto Node, imparo la parte di cui mi occupo.

Poi se voglio aggiungere un altro pezzo, scelta mia, posso iscrivermi a un nuovo team interno e andiamo avanti.

Quindi questo aiuta la gestione del nuovo ignoto, praticamente, da un lato.

Per tornare alla tua domanda comunque, ti posso dire che, precisando che Marco è stato il mio primo mentee, quindi l'ho usato un po' come cavia, in realtà ho usato un approccio molto casuale e molto involontario.

Nel senso, Marco mi scriveva sempre, magari su Slack, dicendo guarda Pa, sto bloccato su sta issue.

Dico, va bene Marco, non ci stanno problemi.

Fammi finiti e fa sta cosa, che sto freddo perché io odio, diciamo, interrompere il task.

Fammi finiti e fa sta cosa, ci sentiamo tra una mezz'oretta, che poi diventano sempre due ore, purtroppo, confermarlo perché la mia stima dei tempi fa decisamente cagare, ma lasciamo perdere.

Però il punto è, ci vediamo tra un'ora che diventano due, tu nel frattempo continua a darci un'occhiata, vedici cavia un ragno dal buco e a volte, effettuando un quarto d'ora dopo, ok, va fatto.

Completamente a caso, non era mia intenzione fare il pushback che dici tu.

Però, se qualche momento ora l'ascolto, sto trucchetto può funzionare, perché non fai percepire magari al menti che stai facendo il pushback per dire, mettici un po' più il culo sulla sedia, per mettere, diciamo, per citare magari i nostri genitori ai tempi dello studio, da un lato.

Però, dall'altro, questa tecnica io la userai anche continuamente per verificare e assaggiare la grinta della persona, perché poi anche quello.

Cioè, tu puoi avere la volontà di lavorare su un node, perfetto.

La buona fede nessuno la discute, però se a un certo punto non riesci a dimostrare grinta nel dire, ok, se tu non mi puoi rispondere subito, ci continui a sbattere la testa, magari non arrivo a niente, però tra due ore ti potrò sicuramente dare qualche informazione in più e dimostrare che almeno ci hai messo la grinta, o per dirla la napoletana, la cazzimma, sopra per portarti avanti la issue.

È un buon modo per valutare anche l'aspetto psicologico piuttosto che quello tecnico del mentino.

Questa è una cosa interessante, perché in realtà dimostra quanto skin in the game c'è da parte del mentino.

E adesso faccio una domanda che però presuppone una risposta sincerissima da parte di Marco.

Nel momento in cui si riceve un pushback e tu ti trovi nella merda fino al naso, perché non ci stai capendo una cippa di quello che ti circonda.

A me capita costantemente, capita a tutti, anche ai senior, agli staff, anche ai ninja.

In quel momento è noto che comunque si attiva un carico psicologico nel dire non ce la faccio, vaffanculo, lascio tutto, non sono all'altezza, quindi si triggera la sindrome dell'impostore.

Come hai gestito queste paure, anche la sindrome dell'impostore poi alla fine? Certo, ma io in questa situazione che hai descritto mi sono ritrovato molte volte, soprattutto ai primi task, ma tuttora ci sono delle volte che non ho idea di questa cosa, come risolverla.

Diciamo lavorare su Nord mi ha insegnato molto da questo punto di vista, perché ho capito che le risposte non arrivano subito, bisogna dargli del tempo.

Per esempio, guardando quelle che sono le issues o GitHub, nessuno si aspetta che tu risolvi una issue in un giorno o due giorni, non c'è nessuno lì che ti dice, ehi, dai, risolvila.

C'è bisogno del suo tempo, della sua ricerca e comunque anche della crescita che c'è dietro la risoluzione di una issue, di cercare di capire il contesto.

Per esempio ci sono volte in cui ho staccato e ho fatto altro, altre volte in cui sono andato su GitHub e ho iniziato a vedere, magari nelle pull request passate su quel pezzo di codice, quali fossero stati i commenti a riguardo, del background che c'era dietro una issue, di chi ci aveva lavorato, di quanto tempo fa, o magari chiedevo ad altre persone che avevano lavorato più contesto riguardo quel pezzo di codice.

Quindi, diciamo che la cosa più importante secondo me è non andare nel panico, perché alla fine nell'open source su queste cose non ti corre dietro nessuno.

Bisogna essere pazienti, soprattutto con se stessi, secondo me, non agitarsi troppo, e poi, mentre aspettavo che Paolo si liberasse, devo dire che io non mi ho mai messo pressione, non mi sono mai sentito sotto pressione, anzi per me, dirmi guarda ci sentiamo tra un po' perché sono impegnato, oppure ci sentiamo domani mattina, io l'ho vista come una cosa totalmente naturale, perché ognuno lavora su progetti diversi e ci sta che la comunicazione sia asincrona.

Quindi mi ha aiutato molto e per me è stata naturale poi la progressione verso l'essere un po' più indipendente.

Anche io ho iniziato sulla parte HTTP, in modo che comunque potevamo essere allineati io e Paolo, conoscendo lo stesso modulo, e poi pian piano mi sono spostato anche su altre parti, quella degli stream, adesso sto lavorando sulla parte di un po' di tooling, sulla parte di sicurezza, quindi poi credo che vada un po' a gusto personale la parte del progetto su cui ci piace lavorare, però come ha detto Paolo bisogna iniziare da una cosa, che poi diventa troppo dispersiva.

Hai detto una cosa guarassanta, ti offrirei un pasticcino per quello che hai detto, perché credimi, quello di prendersi il proprio tempo.

Io questa cosa l'ho imparata in Irthon, l'azienda dove lavoro, e mi è costato parecchio sforzo all'inizio, nel senso che ero abituato a gestire Codebase che ho fatto sempre partire da zero io.

E là il margine di tempo che si ha dal verificarsi un problema all'immaginare la soluzione è molto limitato, perché conosci ogni angolo della Codebase che hai fatto.

Quando approcci su progetti a più mani, di complessità più grande, devi in qualche modo, lo devi a te stesso, devi darti tempo.

E quando tu leggi un issue e non hai idea di come risolverla dopo i primi 5 minuti, è normale che le prime volte ti sale l'incazzo, ti viene nervoso, perché dici no, no, ma sono veramente tonto.

Non funziona così, perché tu devi creare la struttura di contesto, che è quello che diceva Marco poco fa, ti devi creare il contesto, la base, e ti devi lasciare il tempo di raggiungere la soluzione, perché c'è un viaggio, e durante questo viaggio, che passa dal capisco il problema, perché anche il comprendere il problema ha bisogno di tempo, a ho idea di come posso risolverlo, lungo questo viaggio, quello che succede è che tu scopri la Codebase, ne scopri una parte ancora più grande, e soprattutto tu diventi confident anche coi tuoi tempi.

Tempi che vuoi anche per il mondo che viviamo, per i social che ci hanno abituato a una comunicazione bom bom bom bom bom bom bom, o alle informazioni a spizzichi e bottoni, bocconi non ci diamo più, dobbiamo rimpossessarci del nostro tempo anche quando lavoriamo.

Vi dico un'altra cosa, io avevo l'idea di chiudere sempre l'issue in massimo una giornata lavorativa.

La prima volta che ho trovato un issue su autocannon, mi sa che me l'avevi fatto tu la review Paolo, o tu o Matteo, e ci sono rimasti tre giorni.

E vabbè che sono tre giorni, ma ora quando mi ricordo hanno un issue che lo sanno.

Sul Node il tempo medio delle mie issue sta un mese, scusa delle PR, non delle issue delle PR, un mese ci metto io a mergiarla.

Raffaella anche sette mesi, c'è stata la version model.

La version model è di sette mesi, ma è follia.

Tra le cose si considera che sulle issue di Node il carico cognitivo è doppio, perché tu non vuoi guardare solo la Codebase di Node, guardi anche la Codebase di chi ti ha riportato il bug.

Marco sa benissimo perché abbiamo lavorato su due issue simili, ma diverse.

Ha già capito, si è messo le mani in faccia.

Non voglio dare la colpa perché ci sono capitati loro, però può essere chiunque.

L'SDK di AWS, ci hanno riportato due issue diverse, una faceva crashare le assertions delle HTTP server, e l'altra faceva uscire Node senza errori, perché svuotava l'event loop.

Quindi tu hai dovuto capire prima cosa facesse Node e poi cosa facesse l'SDK di AWS, che tu non vedi mai e ti dimenticherai due minuti dopo.

Quanto ci abbiamo messo a fare la diagnosi prima della soluzione? Sì, quella diagnosi è stata terribile.

Una delle issue, che poi il problema non era nemmeno che c'era un bug, ma è dimostrare che non fosse un bug di Node, perché il processo usciva in maniera pulita.

Quindi il problema era che usciva questo processo e non si capiva il perché.

Grazie a questa issue ho imparato molto bene a andare a debuggare Node, ho dovuto ripercorrere tutto quello che è lo stack della richiesta e anche però ho dovuto conoscere la codebase della SDK di AWS, che neanche quella non è una codebase facile.

E poi ho scoperto che alla fine non era un bug di Node, quindi tutto quello sforzo per poi non c'è niente da fissare, è solo lato AWS.

Tanto lavoro per poi...

Due mesi della nostra ed ha buttati proprio.

Perché l'ha buttati? Gli utenti adesso lo sanno, la issue su AWS è ancora aperta, non l'hanno fissata.

Ho anche aperto una pull request che è stata ignorata.

Se lavorate per AWS andate a vedere la pull request.

C'è qualcuno che ci sente che lavora per AWS.

La guardo perché i processi che terminano in Xtenticode 0 non è una bella cosa.

Non ho mai visto svuotare l'event loop di Node, non mi mancava questa cosa in tanti anni.

All'inizio era come te Mauro, dice cavolo ci sto a mettere un sacco di tempo, poi vado a vedere, Raffael ci ha messo sette mesi.

Per farti un altro esempio, James Nell che ha inventato il protocollo QUIC per Node, quindi QUIC la base di HTTP3 eccetera, ha aperto la pull request tre anni fa, è ancora aperta, l'ha riaperta la seconda volta perché era troppo grande e gli hanno visto dispezzare e l'ha riaperta una terza volta e ancora non è emergiata.

Perché nessuno riesce a fare la review di quella, il pull request perché è enorme.

Anche quella è una cosa interessante, ci arriviamo dopo però sul processo di review e sulla comunicazione che sta nel processo di review.

Nel momento in cui il tempo per portare a compimento una pull request è così lungo, e questo lo chiedo a Paolo ancora prima di Marco, perché comunque c'è una risposta da mentor e una risposta più personale.

Quando il tempo è così lungo, i sette mesi di Raffael per fare il sistema di diritti come si chiamano le autorizzazioni? Permission model.

Permission model di Node, come fai ad avere una motivazione tale per cui riesci a passarli questi sette mesi senza dire oh vaffanculo io la PR la chiudo, la PR la chiudo, ciccia.

Credo che la risposta sia personale, non c'è una risposta univoca.

Per esempio per me apro la PR, a un certo punto vedo che ancora non viene emergiata e mi girano profondamente.

Quel senso di incompiuto mi turba.

Mia moglie mi prende in giro che ho disturbi ossessivo-compulsivi, che sono ingegnere, che ho i paraocchi, quel che ti pare.

Probabilmente è così, la mia personalità è stata rovinata dai miei studi, sicuramente.

Però io ogni tanto vado su GitHub e pulo il request e vedo una PR aperta da un mesi e dico cavolo, cavolo, cavolo, sta PR sta chiude.

Non riesco a guardarla lì in completa.

Potrei anche dire come dici tu, mi sono stufato, me la auto-chiudo, che ho ragazzi, amici come prima, fa niente.

Però poi là subito il fatto è, se la chiudo comunque è incompleta.

Allora lì mi triggera il rage mode praticamente.

Però la risposta che suppongo sia personale, perché ognuno la vede a modo proprio.

Raffaele alla fine ci ha messo sette mesi, perché comunque l'ha dovuto rivedere più volte.

Per dirti, non è inusuale che tu una PR la possa riscrivere diverse volte all'interno della stessa PR.

Fai force push perché la tua prima soluzione o era non proprio incorretta, ma non proprio corretta totalmente, oppure aveva degli obbrobriosi effetti collaterali, che non potevi manche farlo.

Per dirti l'ultima, io ho solo una PR pendente al momento, che non riesco a chiudere perché in locale e sul mio server Linux in remoto passano i test.

Vado sulla sede, uno dei test non passa, non ho modo di riprodurre il problema, non riesco a riprodurlo.

Ma non posso chiudere quella PR, la PR è completamente fatta, testata in locale, che non crasha mai, crasha in remoto.

E quella rimane lì.

La classica spina nel fianco che ti dice, ma non c'è niente, da pace.

Poi per esempio, nel mio caso specifico, questa PR è una SemVer Major e Raffael mi ha detto, guarda pa', io devo chiudere la codebase di Node20 la devo chiudere il 1° aprile, quindi ho 4 giorni per farla passare, se no se ne parla l'anno prossimo per essere inclusi in una linea stabile.

E questo Raffael non l'ha detto con cattiva intenzione, me l'ha semplicemente comunicato, cioè guarda, cerca di farlo entro il 1° aprile e lo chiudiamo in 20.

Pensa quando sto rilassato verso sta PR.

A livello psicologico però, il problema è chiaro, a livello psicologico come lo gestisci o non lo gestisci? All'inizio mi dà la motivazione, poi se non riesco a te, a volte magari l'ho fatta, l'ho lasciata lì un po' pendente, anche se poi avevo altre cose da fare, perché sia per me che per Marco fare il Node Contributor non è nella parte hobby del tempo, ma è nella parte lavorativa.

Quindi è chiaro che se io magari una volta posso prendermi il tempo sul Node, poi devo andare in conferenza per dirne una.

Allora, la devo lasciar perdere, poi a un certo punto dico, mi ricordo, guarda c'è sta PR che la dobbiamo mergeare, il fatto che magari sto stretto di tempi mi dà la motivazione per approcciarle, mi dà la green tagonistica, se mi passate il termine, che se poi non riesco a risolvere, diventa frustrazione agonistica e mi allontano altre tre settimane da sta PR per il nervoso e passo ad altro.

Quindi è un rinforzo positivo e negativo continuo che boh, è un senso di frustrazione assoluto, onestamente.

Poi a volte lo prendo in maniera positiva, a volte in maniera negativa, ma la lunga è quello.

Poi ci sono anche sistemi impliciti di Node che ti fanno morire, tipo la tua PR funziona, è tutta a posto, ma hai dimenticato di fare il linting su una riga di codice, la CI non passa, fai un altro push e devi aspettare un altro approval e altre due giorni per poterla mergeare perché c'è il wait time dopo l'ultimo approval.

E a quel punto vuoi buttare all'aria tutti i computer che c'hai a tiro.

True story, Marco Arnuito, è successo anche alle più volte e la vuoi uccidere qualcuno, non ci stanno santi.

Quindi ci sono vari problemi.

Problemi non in Node, attenzione, in feedback psicologici.

Marco, invece tu come hai gestito questa cosa della motivazione quando poi i tempi si dilattano? Dunque, io non ho avuto PR con tempi lunghissimi, diciamo che tutte le PR che ho aperto sono state mergeate nel giro di massimo un mesetto.

Qualcuno potrebbe dire che sono tempi abbastanza lunghi, però per un progetto come Node in cui c'è bisogno che diverse persone facciano una review, quindi come ha detto Paolo ti ritrovi più volte a dover descrivere tutto, anche perché è importante dire che su Node ci sono delle persone che conoscono molto bene degli ambiti e hanno il contesto necessario per capire quello che sta succedendo nella tua pull request.

Quindi se effetti un cambiamento che ritieni sciocco, magari quella linea di codice è stata messa lì quattro anni fa per un motivo che non conoscerai mai e quindi durante la fase di review ti viene detto no, la tua pull request non va bene, la scrivi dal capo, quella riga di codice non la puoi toccare.

E da lì riparte tutto il processo, a me è capitato qualcosa del genere che magari fai il tuo fix, funziona perfettamente, apri la pull request e nella fase di review ti dicono riscrivi tutto, non va bene.

E' anche questo un po' il bello di Node, secondo me ci vuole tanta umiltà e poi anche capire che si è lì anche per imparare, perché alla fine si impara sempre di più, si scoprono cose nuove.

Io non l'ho mai vissuta male, non l'ho mai vissuta come una critica personale, l'ho sempre trovato molto, molto costruttivo e questo credo che mi abbia permesso anche di trovare la motivazione per andare avanti, perché sono l'ultimo arrivato sul progetto e ho tutto da imparare.

Aggiungo alcuna cosa a quello che ha detto Marco, il processo di pull request review su cui torneremo dopo, come hai chiesto tu Mauro.

Quando Marco parla del fatto che ti fanno la review e dicono guarda sta riga non la devi toccare o questo non va bene, roba del genere, capita a me spesso quando tocco il codice C++, se non ho almeno una review da Anna Enigsen che conosce bene il layer C++, non mi sento a mio agio ammiragiarla, perché so che se lo guarda lei vado tranquillo.

Il punto è, è sempre fatto però col massimo rispetto e mai con la cattiveria o la spocchia che uno potrebbe immaginare.

Ti arriva uno come Matteo, come Anna, come James, con la tranquillità più assoluta, dicono guarda, no, guarda no, in maniera molto brutale, però pulita, onesta, massimo rispetto, perché l'unico scopo è uno la qualità del progetto e due la costruttività di coperta e la sostenibilità come terza cosa sia assolutamente.

Perché se Marco va via, Polo va via, Node crolla sotto il suo peso, James va via.

Abbiamo un problema nei core team che non avete idea.

Avete parlato di righe che non vanno toccate e in tante codebase questa cosa è presente, spesso sono dei pezzi di codice che io amo chiamare, che nascondono una tribal knowledge, quindi un qualcosa rilasciato di padre in figlio, da cold maintainer a young contributor, no, tipo le leggende sulla casa degli spiriti, qualcosa del genere.

Quando però ci si approccia una codebase, cavolo, la tribal knowledge è obscurity, è qualcosa che non si conosce, che difficilmente, secondo io in un talk la chiamai gli unknown, ciò che non sai di non sapere.

Ed è difficilissimo da spottare questa cosa.

Dal vostro punto di vista esiste un modo per sistematizzare questa conoscenza? Per fare in modo che una volta che è passato Marco che quell'informazione è passata, sia in qualche modo lasciata ai posteri, in qualche modo? Per me la risposta è dipende.

A parte che tu hai curiosamente citato il fatto di tramandare la conoscenza di padre in figlio, faccio presente che su Node Core, adesso non è ancora un collaboratore ma prima o poi ci arriverà, James Nell collabora col figlio che adesso fa esistere nei suoi bug.

Siamo arrivati al punto che ci sono padre e figlio letteralmente sul progetto, che sembra una battuta ma è successo, ho conosciuto il figlio ragazzo fantastico a Kilkenny al NodeConf lo scorso ottobre.

Ma comunque, Mauro il problema è che dipende, perché quella che tu chiami tribal knowledge ci possono essere due possibilità, è stata generata volutamente o è stata generata per caso? Ora se qualcuno tre anni fa ha scritto una riga oscura, un B2I superheader per dirti una cosa più assurda che mi viene in mente e non ci ha scritto un commento sopra, merita di essere che qualcuno gli vada a bussare alla casa e gli tiri un bel cazzotto in faccia, perché giustamente è cattiveria quella.

Ci sono ovviamente case del genere e questi sono i casi in cui si dovrebbe evitare di dire sì ma in fase di pull request, hai scritto sta riga che non vuol dire niente, mettici un commento, cosa che spesso succede, qualche volta ci chiedono il codice, ragazzi due commenti nel codice perché sennò tra due anni voi stessi non vi ricordate perché l'avete messo e succede spesso.

Questa è una.

L'altra purtroppo, nella mia esperienza è quello che mi sono trovato a vedere su Node, è l'oscurity involontaria.

C'è una riga di codice che potrebbe essere l'ultima superstite di dieci precedenti righe di codice, che una volta messe tutte insieme avevano senso, c'è rimasta solo lei per qualche motivo e quella è rimasta.

Di nuovo si troverebbe che in fase di pull request quando tu inizi a eliminare quelle righe di codice, ma quando ne eliminate una, metteteci un commento, che ne so, questa operazione non è più necessaria, questa sotto sì, per cose del genere, no? Si può intervenire solo in fase di pull request, perché l'unico controllo è la, scusa, intendo fase di pull request review ovviamente, perché se nessuno controlla il codice che scrivi, tu non ci metti niente.

Ti faccio un esempio, io ho citato che sono nello stack Http di Node, una cosa che ho tuttora omesso di dire è che sono anche uno dei principali, se non il principale attualmente, maintainer di LLHttp, che è il parser Http di Node, che è una libreria che, ascoltatori, mo vi sgancio una bomba, è un codice che transpila da TypeScript a C, senza passare per JavaScript e roba di mezzo.

Da TypeScript viene generata una libreria C statica.

Eh, ragazzi, per il vostro contesto Mauro sta facendo faccia che non avete idea, che dice che è sta roba.

Io infatti quando l'ho vista ho detto, ma come è possibile? Perché LLHttp si basa su un parser chiamato LLParse, che fa questa cosa qui, che può scrivere qualunque tipo di parsing di linguaggi LL praticamente.

Ora, il problema è, questo software è stato scritto da Fedor Indutni, quasi in totale isolamento, ci ha fatto anche un talk sopra che spiegava un po' come era fatto, più o meno.

Non c'è uno straccio di documentazione, una, che sia una.

Io che ci ho dovuto mettere mano a LLHttp, mi pare che Marco non sia detto che tu ci hai messo mai mano a una misa di Node tra se scampata? No.

Fulbacchione.

Tutt'attento, tutt'aggiusto io, mo appena mi ricapita.

No, scherzi a parte, però, chi mi fa le review, per esempio, chi mi fa le review su LLHttp, mi fa le review e dico, sì, ma io ipotizzo che quello che tu hai fatto è corretto, perché io non so cosa ho fatto.

Chi mi fa la review non ha idea di che cavolo io abbia fatto e perché l'abbia fatto.

Ah, i test sono scritti in Markdown traspilato in C, per intenderci, quindi è una cosa un po' assurda.

Non avete idea.

Ma il discorso è, quello è un intero pezzo di software che è oscurità pura.

Non c'è uno straccio di documentazione da nessuna parte.

Non c'era neanche la procedura di release, in realtà l'ho dovuto creare io da zero, la procedura di release per fare il cutout di una nuova patch version o quello che è.

Quella è oscurità voluta, che però all'epoca, il punto qual era? Era involontaria, perché Fedor era presente nel team, quindi dici, guarda Fedor, ho questo problema con LLHttp.

Va beh, ci penso io.

Quindi il classico single point of failure.

Nel tempo lui è sparito, perché io non lo vedo online da diverso tempo, diciamo come attività pubblica.

Ci avrà i suoi problemi, ci avrà il suo lavoro, nessuno gli può dire nulla per carità.

Quel software che era conosciuto è di punto in bianco diventato un buco nero, su cui si può mettere mano in maniera molto limitata.

E non c'è niente che si possa fare, e non era una situazione prevedibile, perché io non prevedo di sparire da la mattina alla sera da domani, no? Quindi che puoi fare? Essere più proattivo e dire se mi succede qualcosa, se ho un buon tesoro su di me, e dici a fare corna da tutte le parti mentre scrivi la documentazione, allora come fai? È un po' complessa come situazione.

Questo lo capisco.

Nel contempo però posso dire che qua tocchiamo un punto borderline, perché io ho sempre detto, no? Il codice è uno strumento di comunicazione tra umani e non tra uomo e macchina.

Perché se io voglio comunicare con la macchina io scrivo in assembly.

Ma se sto scrivendo un codice, in qualche modo devo comunicare con gli esseri umani.

Se utilizzo un linguaggio ignoto, se scrivi in aramaico, non posso pretendere che gli umani moderni spreddano il mio verbo, no? In modo semplice, o comunque si prendano in carico le mie parole.

E questa cosa funziona nei software a un certo livello.

Quando più scendi sotto, più ho notato che trattare il codice come mezzo di comunicazione si perde.

Vuoi perché devi privilegiare le performance, vuoi perché talvolta devi fare una patch a qualcosa di particolare, non lo so.

Però una cosa che noto è che veramente quel senso di strumento di comunicazione un po' si perde.

E a quel punto, secondo me, è anche una questione di responsabilità.

C'è da dire che magari chi ha scritto quel pezzo di codice l'ha fatto per farlo nel minor tempo possibile, con degli strumenti che gli permettevano di farlo nel minor tempo possibile, però là c'è sempre il trade-off, no? Quindi tu fai qualcosa velocemente e però poi rimane là.

E mancano le risorse per portare avanti poi quel pezzo di codice.

Il problema è quello, la cosa che ho comesso di dire è che storicamente, sono entrato nel team di Node un anno e mezzo fa, e l'HTTP è stato creato tre anni fa, se non ricordo male.

Perché è stato creato? Perché il vecchio parser di Node, chiamato con molta fantasia HTTP, HTTP underscore parser, era lento, era mostruosamente lento.

Allora si sono posti il problema, ragazzi dobbiamo creare un parser che sia veloce.

Quello che ho detto TypeScript AC, alla fine ad alto livello, cos'è? Un gigantesco switch statement, immaginate uno switch gigantesco con qualcosa come centinaia di migliaia di case, così funziona.

Che è il modo più veloce, mi è stato detto, anche in altri ambiti, utilizzato lo stesso trucchetto, per fare del software iper-ottimizzato per queste prestazioni.

La sensibilità va a donnine però.

E il punto, tu hai ragione nel dire sì, ma dovremmo comunicare, è vero.

Però dovremmo anche essere performanti, dovremmo anche essere sicuri, dovremmo anche essere, passandomi il termine, sexy per gli utenti.

Quante cose dobbiamo vedere simultaneamente? Purtroppo la documentazione, come la testabilità spesso, sono quelle che prima se ne vanno all'aria.

Quando devi, diciamo, la famosa cosa del triangolo, hai tre cose, scegli ne due, sicuro la documentazione è quella che se ne viene ignorata, abbiatamente, e di cui ti penti due anni dopo, però, ovviamente.

Però ti ha fatto sopravvivere nel breve termine.

Voglio ritornare a Marco.

Hai parlato di codice arcano, no? Un po' fuori dai canoni del JavaScript che avevi usato fino ad allora.

Cosa intendi per codice arcano? Quali erano i costrutti? Siccome tra gli ascoltatori ce ne sono un gozziliardo che, secondo me, su 1500-1600 ascoltatori, 1200 lavorano in JavaScript.

E quindi ti chiedo, cosa è che hai trovato così strano, così arcano, così neolitico? Allora, in particolare, non è che c'è un operatore in particolare, però si può vedere, un po' come un geologo che guarda un sedimento, si vede proprio la stratificazione del codice negli anni.

Cioè, vedi dei pezzi di codice, quelli più antichi, vedi come si usava a fare una volta in JavaScript, lavorare con i prototype degli oggetti, non c'era il chaining condizionale, quindi c'erano questi if, and, and, and, and, and, lunghissimi.

Vedi diverse cose che magari non ti aspetti, perché c'è una riga che è molto moderna e quella successiva magari risulta strana.

È un po' un mix, un mix di persone, un mix di tempi diversi in cui anche si usavano tecnologie diverse, c'erano stili differenti, quindi questo aumenta un po' la complessità.

Come suggerisce Paolo, i primordials, che prima di Node non avevamo mai visto, prima di lavorare su Node non avevamo mai visto, e su Node si usa.

Che roba è? Io non l'ho mai vista, dico la verità.

Non lo vuoi sapere.

Vai Marco, provaci tu, non so neanche come spiegarlo di preciso.

Allora, sono delle...per esempio io ho messo le mani per divertimento su un array join, che la funzione join di un array in Node è un primordial, ma potrebbe essere una funzione che corrisponde alla sua implementazione in JavaScript pura, cioè quella che viene eseguita poi da V8.

Paolo, magari correggimi perché è un po' un concetto un po' latano come concetto.

Sì, diciamo per mantenersi sull'esempio di array.join praticamente, allora se tu avessi un array di string in JavaScript avresti array, quindi parentesi quadra, 1,2,3, punto join, qualunque carattere in mezzo, no? Questa sarebbe la chiamata tipica in JavaScript.

Ora il punto è, in Node a un certo punto si sono posti il problema di dire se noi...all'interno di Node fare una cosa del genere è pericoloso, perché se qualcuno modifica la firma di join, come puoi fare in JavaScript, il monkey patching classico, modifichi il metodo join, Dio solo sa quello che possono fare.

Perché noi quando andiamo a eseguirla all'interno di Node core, utilizzeremo quella funzione e vai a vedere che succede, quindi è un problema di sicurezza gigantesco.

Si chiama prototype pollution, che JavaScript te lo permette.

Allora, qual è la soluzione che hanno trovato? Che funziona perfettamente, è un palo nel sedere quando scrivi l'APR, perché è un incubo.

Se te lo dimentichi ti rompe le scatole l'Inter e tutto il discorso della CI, oppure ti devi ricordare di metterli in ordine, insomma è un po' contorta la cosa, però in pratica il punto qual è? Che io invece di fare array.join, faccio const array join, che è una funzione senza il punto, array join, mancava il case, require da primordials, e poi faccio array join.

Il primo argomento è l'array e il secondo è il separatore.

Non so se ho reso l'idea.

Sì, sì.

È come se facessi in pratica la call, come quando facciamo la call, fai function.call, il target del messaggio e gli argomenti, e lo fai per ogni singola funzione, array join, array push, che ne so, mat.random, tutte, tutte sono utilizzate così.

Immagina quanto è bello usarle.

Guarda, tranquillo, non è l'ultimo progetto, ma qualche progetto fa, io ho visto una roba del genere, con lo dash, quindi non dai primordial, ma dai lo dash, e la situazione era praticamente la stessa.

Performante come un appepiaggio del 74.

Ma va bene.

Però quello, capisci che quando inizi a vedere quello, non è il JavaScript che tu scriverai mai, a meno che non finisci in progetti brutti, ma in generale è il JavaScript che non scriveresti mai.

È un JavaScript anti-pattern, che scrivono le più grosse persone talentose in JavaScript del pianeta.

C'è il motivo, come ti dicevo, è perfettamente sensata la soluzione, molto intelligente, è un po' anti-pattern.

Ma queste cose fondamentalmente sono documentate? Non credo.

Sì, ma le leggerai dopo che le trovate? Cioè la documentazione la troverai molto dopo che avrai cercato di lavorarci, perché comunque c'è tantissima documentazione, ci sono tantissime strade anche di documentazione.

Quindi anche il primo impatto con premodals? No.

Ma perché? Però anche questi sono gentili su Node.

Cioè su Node siamo gentili perché, per esempio, se io dimentico di usare un premodals, non mi sbattono un RTFM a caso, Read Fucking Manual a caso, ma dicono, guarda dove è che ho usato.

Usare i premodals, poi magari dico, scusa ma fa capire perché? E allora a quel punto mi sbattono il link alla guida, guarda c'è scritto, e Giuseppe mi dice, Marco ma tu lo sai sempre dopo aver fatto la cavolata, non ci stanno santi, non c'è modo, ci sono talmente tante cose da ricordare che non ce la fai semplicemente.

Sapete che a proposito di questo vi dico questa idea, ditemi se è completamente pazza.

Paolo ha sentito il mio talk sull'esplorazione della codebase, no? Alla fine di quel talk, dopo che l'ho fatto risedimentare per qualche mese, mi è venuta in mente un'idea.

Una cosa che ho trovato, visto che stiamo parlando di documentazione, è che spesso la documentazione è sconnessa col codice.

Tolte quelle righe di commento che tu puoi lasciare, ma che si basano sull'effetto serendipiti, no? Ci piondi davanti e ti appaiono le righe di commento che in qualche modo ti spiegano il perché quel pezzo di codice sta là.

Ma tolte quelle righe per le quali non esiste un metodo sistematico per raggiungerle, quello che manca alla documentazione, che di per sé dovrebbe essere un metodo sistematico per raggiungere l'ignoto, è il collegamento con la codebase.

Vi faccio un esempio.

Da una parte c'è il manuale, o il manuale, la documentazione, con la roba che ti spiega il motivo per cui esistono i primordials, e subito sotto hai un modo per jumpare ai primordials nella codebase.

È da un po' che sto pensando a una documentazione così, no? Che ti permetta di saltare all'interno del codice partendo dal concetto spiegato.

Mi sembra poi così assurdo.

No, non è assurdo.

Questo viene fatto soprattutto per quando magari risolvi un bug o fai una feature relativa a un RFC, per esempio, che sarebbe molto difficile da spiegare senza avere un contesto il perché hai creato una feature particolare.

Quindi attraversando il codice su node trovi spesso link a delle issue, link a delle pull request, link a delle RFC che ti vanno a spiegare effettivamente perché quel pezzo di codice è stato aggiunto, perché altrimenti sarebbe davvero impossibile.

Ma semplicemente perché su una funzione semplice magari ci sono 10.000 casi particolari che richiedono di conoscere un contesto.

Quindi è molto gradito avere un link su cui tu puoi riuscire a capire quello che sta succedendo.

Se ho capito bene, Mauro, tu parlavi anche del link inverso, quindi della documentazione back nel codice.

Questo è un po' più complicato secondo me, perché è facile perdere l'integrità referenziale, se mi passi il termine.

Quindi io piuttosto che quello...

Aspetta, cerco di spiegarmi meglio.

L'idea è ottima, il problema è realizzarla che è complicato.

A quel punto quello che di solito io faccio, quando scrivo documentazione e voglio che ci sia un link inverso al codice, non faccio il link al codice, metto direttamente uno snippet di codice nella documentazione, magari anche piuttosto grosso, che quello sicuro non si muove dalla documentazione e si deve sperare che sia comunque un minimo di sync con il codice vero e proprio.

E quello è il problema.

Allora, il punto sai qual è? È facile che una funzione cambi nome, forse è un po' più difficile in una codbase però saccomenuto con una funzione sparisca del tutto.

Quindi dici, guarda, la funzione si chiamava Pippo, non si chiama più Pippo, si chiama Pluto, però la riesco a ritrovare nel codice, dico, vabbè, la stessa, quindi la documentazione è più o meno quella.

L'idea...

però l'idea è qua.

Siccome ci stavo pensando, stavo pensando di fare un POC, quindi la mia idea era...

l'idea qual era in realtà? L'idea era di puntare al pezzo di codice un commit preciso, ok, e poi volendo, con uno slider, esplorare la storia da quel punto fino al momento attuale di quel pezzo.

Così diventa una figata.

È molto figo.

Fare il link al commit su GitHub praticamente, col Lash proprio.

Esatto, da Lash, Lash fa il Riga, quindi punta un oggetto di Git specifico.

Ah, e fa l'embedding, ok.

Fa l'embedding e con lo slider tu hai la possibilità di spostarti nella storia di Git.

Io Git te l'ho raccontato, no, gli studi che ho fatto su Git.

È figo come cosa, è molto figo.

E a quel punto tu riesci a fare il link e il link inverso e diventa una figata quando devi fare endoff, anche per i progetti facili al di là di Node.

È da esplorare, ti dico, ti deve esplorare.

È una bella idea, proseguila.

Farevi un'altra domanda, che anche qua è uno dei momenti dove il carico psicologico è molto alto.

In un progetto come Node.js, dove il code reviewer è decisamente più alto del collega della media, a livello proprio di...

non voglio dire capacità professionale, però parliamo di seniority molto più alta del collega medio.

Come funziona il processo di review? Beh, come funziona? Tendenzialmente il processo di review a grandi linee è lo stesso di quello che avviene in qualunque altra azienda.

La differenza è che le persone che fanno code review magari conoscono molto molto bene il codice perché lavorano sul progetto da tanto tempo e quindi conoscono anche le implicazioni di quello che il codice che sta scrivendo ha.

Cioè, in Node.js ci sono degli esperti di alcune parti di codici.

Cioè, per esempio, se c'è una pull request sulla parte HTTP, ci sarà sicuramente qualcuno che tagga Paolo, tagga Matteo, oppure sugli stream ci c'è Ronag.

Ogni modulo ha degli esperti che vengono chiamati, che vengono taggati e poi il processo di code review alla fine è lo stesso.

Cioè, ti viene suggerito di aggiungere documentazione, ti viene suggerito di aggiungere un commento, ti viene richiesto di fare il refactor di una parte, oppure ti viene detto, no, no, guarda, quello che hai scritto non va bene, devi riniziare da capo.

Oppure dicono, no, questa cosa non si può fissare e quindi ti chiudono la pull request.

Cioè, è vario.

La differenza è anche che la qualità del codice tendenzialmente è molto alta.

Cioè, il processo di code review è molto stringente.

Magari ci sono delle issue che sono di poco conto e quindi ci sono soltanto due reviewer o uno delle volte e quindi per roba di poco conto.

Però c'è un cambiamento importante, una fissura importante, ci sono anche 30 code reviewer.

Cioè, per esempio, la parte di Raffael sul Permission Model ha subito un processo di code review lunghissimo, ma soprattutto da tantissime persone.

Quindi immagina il parere di 20-30 persone diverse sulla stessa parte del codice.

Magari ognuna con un focus differente, quando tocchi una parte larga della code base vai a toccare moduli differenti.

Quindi tante opinioni, a volte alcune contrastanti.

Quindi non sai nemmeno a chi dare retta.

È vero, è vero.

È vero perché poi non dobbiamo dimenticare che le persone che lavorano su Core sono sia hobbysti, ma sia, come nel caso mio e di Marco, dipendenti.

Cioè, ciamo, agiscono per conto dell'azienda.

Quindi è chiaro che parte di quello che ti dicono è la loro esperienza personale, le loro intenzioni personali, e parte è anche quello che magari serve alla loro azienda, che ne so.

Non mi tocca starì perché se no il nostro prodotto non funziona più, per dire un'assurdità, no? Ora non mi è mai capitato, ma so che è una cosa assolutamente possibile.

Il punto è che nelle pull request review c'è una quantità di informazioni che arriva elevata.

E so che ti sta a cuore l'argomento, infatti te l'ha già tolto il gancione.

Per esempio, Marco ha detto che la PR di Raphael ha preso sette mesi di review, da 30-40 persone diverse, ma ha dimenticato di dire la quantità di commenti che ha preso, perché dire 30 persone può essere una persona che commenta una volta Amen, no? Qua parliamo di centinaia di commenti.

È una cosa enorme.

È capitato anche a me, in una PR che avevo scritto prima in C++ addirittura, e poi a un certo punto ho detto, ah, guarda, non serve manco toccare il C++, bastava questa cosa in JavaScript.

Quindi l'ho scritta due volte in modo completamente diverso.

I commenti della vecchia versione rimangono, anche se purtroppo sparisce il codice, quindi è un po' difficile navigarlo, però più o meno delle cose rimangono.

Io nel frattempo ho imparato tante cose sul C++, sull'area C++ e sul layer JavaScript di Node.

A me personalmente a volte triggera la sindrome dell'impostore, perché arriva gente che, appunto, sa a meradito sul tuo codice e ti devasta.

Bonariamente, perché loro non hanno intenzioni cattive.

A volte ti arriva che, che cazzo ci faccio io in mezzo a questi, per dirlo proprio, diciamo, a basso livello proprio.

Però ci sta, ci sta.

Credo che il processo inizi e questo tipo di progetti riescono a evidenziare proprio questo concetto di comunicazione, lato code review, a partire dalla creazione della pull request, dal testo a commento della pull request.

Io ho delle descrizioni di pull request, tra l'altro piccolo spoiler, ci sarà presto una puntata barra talk su questo, le descrizioni delle pull request, precisi, approfonditi, che spiegano i dettagli come nei grandi progetti open source raramente li ho trovati altrove.

E credo che tutto parta proprio da quella descrizione, che talvolta è un elenco puntato di feature, altre volte è più concentrato sull'impatto che la pull request dà all'interno della code base, ma che ha comunque un livello di dettaglio molto alto.

E quello secondo me è il punto di partenza.

Vero? Io sono il peggiore in questo.

Te posso garantire.

Io sono la persona che tipo scrivere 400 righe di codice in JavaScript senza battere ciglio, se devo scriverne 5 per descrivere la pull request come Dio comanda, sembra che mi stia portando al patibolo.

Non ho la ragione, però sono una persona brutta in questo, perdonatemi.

Io devo ringraziare invece il nostro amico e collega Paolo Chiodi, che ringrazio a braccio, perché grazie a una sua performance review le mie descrizioni delle pull request sono passate da caratteri a caso battuti sulla tastiera a elenchi abbastanza dettagliati nella descrizione dell'impatto.

Quindi grazie Paolo della tua cazziata sulla performance review.

Altra cosa a margine qua, però non è il topic di oggi.

Questo è uno dei motivi per cui io adoro le performance review, specie quando ci sono dei lati negativi che vengono evidenziati.

Deve essere così.

Io lo subito da Matteo sulle soft skill per esempio.

Ho lo stesso paragone.

Tu immagini, io faccio DX, per i primi due anni Matteo mi faceva le performance review, mi diceva tecnicamente stai a posto, fai cacare nella comunicazione.

C'ho lavorato, c'ho lavorato, c'ho lavorato, adesso faccio DX che è solo comunicazione, vedi un po' tu per assurdo dove puoi arrivare.

Sono assolutamente d'accordo con te su questo in pieno.

E subito dopo in realtà avviene la discussione nel thread della pull request.

E quello che voglio farvi due domande.

Uno, quando la discussione diventa veramente lunga su una feature che hai scritto, per le quali hai anche un'affezione, una qualche affezione, che si cerca di minimizzare, come si fa a evitare il sentirsi giudicato? Pur, faccio una nota a margine, pur stando magari in una situazione dove i reviewer fanno tutto tranne che giudicarci, e lo fanno nel migliore dei modi, nel modo più soft, però comunque la sensazione dell'essere giudicato c'è sempre durante una pull request.

Una codrip.

Sì, è vero, cioè le prime volte magari quando subivo una review con magari cinque commenti, cambia questo, cambia questo, cambia questo, poi neat, fai questa piccola modifica, errore di spelling, comunque, cioè, dici cavolo, praticamente non ci ho capito niente io della pull request, però alla fine sul nod ci fai un po' il callo, perché secondo me è la normalità.

Quando lavori su roba complessa, delle volte fa anche sentire al sicuro il fatto che qualcuno ti dica come fare, come migliorare un pezzo di codice, è anche rassicurante questa cosa, perché sai che c'è qualcuno che magari, in caso non sai fare un qualcosa, ti aiuta.

A me mi spaventano di più quelle pull requests dove nessuno ti fa la review, dove rimangono senza review, appese per tanto tempo.

Lgtm, punto esclamativo, quelle sono ancora le più spaventose, Luca.

Andiamo con le Matteo, se mi stai ascoltando, e spendici le due righe però.

Matteo risponde sempre con le gtm e tu dici ma l'ha letto veramente o c'è il risponditore automatico? Cioè a volte ti viene il dubbio, ma leggi le QR e se glielo chiedo, se non le ho letto tutte, e vabbè, figurati.

Guarda, adesso faccio ridere Marco, tu sai che quando fai una QR arriverà sempre Antoine a un certo punto, giusto? Cioè sempre.

Sì, sì, meno male.

Cioè, buona neve, Antoine, adesso ho pronunciato male, tu sei francese, dovresti pronunciarlo meglio di noi.

Cioè in ogni PR, e se ci stai ascoltando e parli italiano, sappi che ti adoro, non lo dico negativamente, lo dico positivamente, io so sempre che qualunque PR faccio, arriverà lui che troverà sempre una cavolo di virgola fuori posto nella documentazione, intendo letteralmente una virgola, c'è sempre una virgola fuori posto.

Però io sto tranquillo che non posso scrivere puttana te in descrizione, nella documentazione, perché non ne fa passare una.

Forse è anche la più noioso, guarda, manca un punto alla fine di sta frase nel commento del codice, quindi potrebbe essere assolutamente inutile, non te lo fa passare.

E tu però stai tranquillo, ci va, pure se sei un po' distratto qualcuno controlla.

Ha ragione Marco, quando nessuno si guarda una PR, la rischi di fare danni.

Che poi, sul no delle un'APR, può fare danni anche devastanti, per dire.

Per gestire, poi, per rispondere anche alla tua domanda, a me per esempio nella terz'ultima PR commerciato si era creato un problema leggermente diverso, nel senso che tutti questi due tipi di problemi erano stati risolti.

E si era arrivato ad un certo punto in cui c'era solo da decidere, ma sto fix lo vogliamo mettere o no? Perché era un fix di un utilizzo improprio di Express, tu immagini, anzi scusami, di una dipendenza di Express, e il mio fix andava a risolvere questo problema di Express, ma nascondeva l'utilizzo improprio da parte della dipendenza, e quindi indirettamente dell'utente.

Al che, uno dei contributori mi ha detto, si ma tu risolvi il problema, ma legittimiamo l'utente a fare sta cavolata.

Non mi sembra il caso.

Dovrebbe essere piuttosto Express a sistemare sto problema.

Tranne che Express, e apre più che do parentesi, faccio il buon Matteo della situazione, ascoltatori non usate Express vi prego.

Ce l'ha detto due settimane fa, Matteo, qua su Gitbar.

Appunto, ecco, e ancora non lo sento l'ora dell'episodio, stavo recuperando un po' gli episodi, e il punto è, cavolo quella cavolo di dipendenza, che Express tuttora usa, l'ultima release è stata otto anni fa.

Non c'è nessuna speranza che quel pacchetto venga mai fixato.

Quindi tu che fai? Fixi Nod, cioè fixi Nod, ti assicuri che Nod protegga da sta cavolata e poi però l'utente può farlo in altri ambiti, o lasci gli utenti morire nel loro brodo perché Express non sistema una libreria? A quel punto qual è la soluzione? Io personalmente circolo a Diplomazia e dico, vabbè, io Paolo ho quest'opinione, tu altro contributo, c'hai quest'altra opinione, non resta altro che fare, sentiamo un terzo parere che disambigua la parità, e si fa come dice lui.

Non c'è altro modo, perché fai? Nonostante nei Nod ci siano, per esempio un'altra cosa da godere, nonostante su Nod ci siano i membri del TSE, come potrebbero essere Matteo, Raffael, James e così via, e poi ci siamo noi semplici i contributor, se mi passate il termine, non fanno mai per pesare il loro ruolo.

Cioè loro discutono della gestione tech, diciamo governance di Nod, però quando si è in pull request, review, si è tutti uguali.

Il mio parere vale come il tuo.

Quindi allora che un giorno arriva il collaboratore e gli dice, senti io so TSE, devi fare come dico io.

Non è mai successo.

Allora il punto è, io mi sento libero di dire, chiamo una terza persona che mi dà il parere e me lo disambigua.

Cioè dico ragazzi, qualche altro collaboratore, dia il proprio input così vediamo in che direzione andare.

Alla fine la piara è stata mergiata, perché poi abbiamo trovato anche una soluzione io e l'altro collaboratore confrontandoci.

Però c'è stato un...

Il punto è, se la collaborazione è produttiva, tu vai avanti.

La butto lì, mi raccontava il nostro buon amico Michele Riva, di altre comunità, dico non faccio il nome per privacy, tra virgolette, di comunità di altri linguaggi di programmazione, che invece hanno quelle comunità tossiche che ti devastavano.

E sappiamo tutti che...

Chissà perché so già il linguaggio di cui stai parlando.

Io non lo dico, però ci siamo capiti.

Allora, là tu non ci metti mano.

Ti scoraggiano se ne hanno un certo tipo di personalità.

Non ci metti mano.

E non collabori.

E poi il linguaggio rimane magari di nicchia, visto che sappiamo di che stiamo parlando.

Quello è il problema.

No, per me i Node dal primissimo giorno, anche quando ero un signor nessuno, ero nemmeno un collaborator, quindi comunque potevo fare PR, ma non potevo per esempio mergearmele, non mi hanno mai fatto pensare il fatto che io fossi un signor nessuno uscito dal buco del morrise in cui vivo.

Tutto qua.

Su questo sono anche io che voglio agire le tue parole.

Devo dire che la comunità che c'è dietro Node è fantastica.

Cioè, le persone che lavorano su Node sono davvero persone che non...

Anche le cavolate che ho scritto nelle pull requests non mi hanno mai fatto pensare.

Mi hanno sempre supportato, aiutato, sempre col rispetto.

Quindi non me l'aspettavo, però alla fine se ci pensi, persone che di un certo tipo, comunque di un certo livello, poi si dimostrano anche umanamente molto alla mano.

Comunque, io nel passato non avrei mai detto di riuscire a collaborare su un progetto come Node.

Adesso che ci sono e vedo anche gli altri, dico che non c'è nessun problema, tutti potrebbero provarci, tutti potrebbero farlo, anche perché è la comunità stessa che ti spinge.

Cioè, la comunità che ti dice si, apri una pull request, se non ce la fai, ti aiuto io, ti do un suggerimento.

Quindi è questa anche, questa positività che c'è, che fa tanto, rispetto, come ha detto Paolo, ad altre comunità in cui appena scrivi una sciocchezza, subito ti attaccano.

Su Node non mi sono mai sentito attaccato personalmente.

Credo che sia a livello strategico la scelta migliore da fare, nel senso che bisogna in qualche modo tutelare la tecnologia.

Per tutelare la tecnologia bisogna limitare il single bus factor, o il few bus factor, come possiamo chiamarlo, no? In quel caso avere delle persone nuove che intanto sono volontari.

Non è da trascurare questo passaggio che è importante, no? Che dedicano il loro tempo.

Poi nel nostro caso, nel vostro caso, c'era anche un engagement di tipo lavorativo, perché la vostra società vi finanziava quel volontariato, ok? Che era volontariato da parte della società comunque, perché era un investimento da parte della società in quella direzione.

E alla fine serve per fare in modo che il progetto possa sopravvivere, altrimenti crolla come tanti progetti che abbiamo visto, visto che siamo così impegnati a fare altri sette run time nello stesso tempo.

Sì, sì, non ho questo disegno.

In realtà il punto, se mi permetti di correggere, non è tanto per riservare la tecnologia, ma proprio la comunità.

La tecnologia va via, la comunità resta.

Cioè, il team di Node sa che se il volesse avresse una comunità sana in cui potessi creare nuovi progetti, sostituire parti intere di Node senza abbattere il ciglio.

La butto lì, Yagiz ha appena sostituito, Yagiz, oddio non riesco a pronunciare, comunque Yagiz, un altro collaboratore di Node, ha appena sostituito il loro URL parser di Node, da zero.

Perché? Perché si è trovato una comunità sana in cui lo può operare.

Direi vabbè, se io propongo di sostituire un pezzo intero di Node, loro non battono ciglio, mi fanno la review, se la cosa va bene, entra, fine.

Quindi il discorso è creare quell'ambiente sano.

Un po' come le società, no? Il discorso, molte società dicono, non è tanto il progetto ma il team.

Il team rimane, può finire un nuovo progetto.

Il progetto senza il team non serve a niente.

Cioè sono le persone alla fine.

Certo, certo.

Su questo aggiungerei anche che, per esempio, ci sono i working group che sono pubblici, cioè i meeting sono pubblici, quindi se sei interessato alla performance o alla sicurezza, come nel mio caso faccio parte del security working group, o Paolo mi sembra tu del performance, se vi interessa la sicurezza o la performance di Node, partecipate.

Ci sono i working group pubblici a cui ognuno può partecipare e può vedere come si lavora dentro Node, quali sono le proprie iniziative e si può discutere.

Cioè è molto aperta la comunità, quindi chiunque può partecipare.

Questo è fantastico, secondo me.

Chiaro, guardavo l'orologio e il tempo vola e quindi siamo arrivati al momento tipico e topico del nostro podcast.

Il momento in cui i nostri host, ma anche il nostro guest, condivide con noi un libro, un podcast, un vino, un articolo, qualunque cosa abbia catturato l'attenzione e che si pensa valga la pena essere condiviso all'interno appunto della nostra community.

Quindi la mia domanda è, partiamo da Paolo poi Marco, avete qualcosa che vi fa piacere condividere con la nostra community? Vi conduco nel paese dei balocchi! Ah, il paese dei balocchi! Sì, io racconto un aneddoto agli spettatori non so, a Mauro se tu lo ricordi.

È una cosa che gli ho promesso a Mauro avrei fatto in iso puntata e lo farò perché non ho altre idee, vi dico la verità, per motivi personali non sono riuscito a pensarci tanto su, quindi vi condivido questa.

Se siete come noi, ultra trentenni, più vicini ai quaranta e sentite il peso dell'età che avanza, vi rivelo un medicinale importante che non può mai mancare nella vostra trus da viaggio, ovvero il Gaviscon, perché non si può sopravvivere senza.

E vi racconto questa, in una Nier Fest mi disperavo del fatto che non mi ero portato il Gaviscon, me l'ero scortato a casa, eravamo alla tavolata di tutti il gruppo italiano di Nierformer, una quindicina di persone, vi posso giurare che tutti e quindici avevano il Gaviscon in tasca, perché eravamo circa della stessa età, non c'erano ancora i giovincelli tipo Marco, quindi se siete sviluppatori ultra trentenni, Gaviscon, gusto menta nel mio caso, compresse oro masticabili da 500 mg.

Detto fatto, Mauro, te l'avevo promesso.

Bellissimo, mi hai portato a galla uno, uno, uno, mamma mia, che bei ricordi.

Ciao, siamo divertiti là.

Marco, hai qualcosa per noi? Ma io vorrei citare un po' il talk di Matteo Pollina, quello su il lavorare nell'open source, ovvero di come l'open source possa essere una fonte di carriera.

A me ha ispirato molto quel talk, perché alla fine lo sto un po' facendo mio, ovvero sto lavorando sull'open source e vengo finanziato appunto per fare questo.

Quindi vorrei un po' spingere le persone che ci ascoltano a contribuire, a provarci ai progetti che più la appassionano, o ai tool che usano tutti i giorni, perché alla fine dietro questi progetti che sembrano chissà che o di una complessità, alla fine ci sono persone super normali, super tranquille, che da qualche parte hanno iniziato e semplicemente poi con un po' di fatica, un po' di costanza sono riusciti a portarli avanti.

E questo non solo ti dà opportunità lavorative, ma ti fa conoscere persone molto importanti e persone che poi ti insegnano tanto e ti danno tanto anche a livello umano.

Io sprono a contribuire all'open source.

Questo è un po' il mio messaggio di stasera.

È un bellissimo messaggio e secondo me casca a pennello qua su Gitbar.

È uno di quei messaggi che ripetiamo sempre.

Io ho due cose.

Una non mi ricordo se ve l'ho già condivisa.

Si tratta di un libro bellissimo, forse ve l'ho già condivisa, ma ve lo ricondivido.

Il libro si intitola Working in Public.

The Making and Maintenance of Open Source Software di Nadia Ekbal è un capolavoro.

È veramente fantastico questo libro, quindi recuperatevelo se avete tempo.

E poi un altro è un piccolo computerino che è diventato il mio server domestico nel quale ho installato Umbrel, che non è altro che un'interfaccia grafica a un docker che con due clic potete lanciare una serie di container che sono utili in casa.

Un Gitea se volete avere un server Git in casa come ce l'ho io.

Io ho il Bitcoin full node, ho un altro paio di cose.

Il computer è un Fujitsu Esprimo Q920 Mini.

È una robina veramente 10x10 cm, silenziosissimo, consuma pochissima corrente, io ce l'ho nel mio rack elettrico.

È una figata pazzesca, 8 GB di RAM, mezzotera di SSD.

Viaggio che è una bellezza come computerino domestico.

È davvero, davvero tanta roba.

Insieme a questo però, che era una nota a margine, volevo condividere con voi un'altra cosa, se riesco a accedere, perché naturalmente io mica me le preparo le cose.

Ovvio! Non puoi fare peggio di me, dai, che ho improvvisato.

Ok, voglio parlarvi di Tailscale.

È una roba tipo VPN, un servizio super figo.

La cosa veramente figa è che io a il mio socio ho dato accesso al suo account Gmail, quindi con la sua email si installa Tailscale.

Si autentica con il suo account Gmail e lui può accedere alla porta esposta dove c'è Gitea.

Quindi il mio server non è esposto al pubblico, però lui può accedere a Gitea.

Non può accedere a tutti gli altri servizi.

E questa roba mi piace tantissimo.

Quindi buttateci un occhio perché secondo me un serverino domestico può essere un po' sempre comodo.

Come sempre, ragazzi, io non so perché vengo sempre messo in mezzo a questa cosa, probabilmente perché sono l'unico che non si vergogna a parlare di soldi, ma non vedo perché vergognarsi a una cosa così bella, parlare di soldi, perché i soldi sono veramente la cosa più bella del mondo.

Quindi donate perché dobbiamo fare una scena da massimo bottura con i vostri soldi.

Quindi è una cosa molto importante e siamo molto poveri, quindi donate copiosamente, veramente in tantissimi.

Mi raccomando, dateci i vostri soldi e noi ne faremo l'uso più responsabile che se ne possa fare, ovvero metterli su delle cripto uscite da mezz'ora.

Quel fattocrati è in mezzo all'ombra e non sape più da venti giorni e non c'è un aleto di vento che ha tanto caldo quanto ha sete.

Ja ja ja Portaci da bere uno shot di birra, ma presto portaci da bere uno shot di birra frutta con o senza schiuma scuro o chiara ma che sia una birra.

Una birra, per favore! Oh, sì, signore.

E' arrivato il momento di ringraziare chi si prende in carico Gitbar, chi fa sì che, in qualche modo, possiamo pagare le bollette offrendoci delle birre o attraverso una donazione.

Questa settimana sono due le persone che ci sostengono.

In primis abbiamo Gilberto Macacaro, spero di averlo pronunciato bene, che ci manda un messaggio dicendo alla salute e lunga vita al Gitbar, Gilberto da Verona.

Grazie, Gilberto, grazie di cuore.

E abbiamo anche Alberto Bini che ci offre cinque birre scrivendo spero che questo messaggio vi arrivi.

Dannato Paypal che non fa aggiungere l'elettricità.

Volevo ringraziare te e tutto il team di Gitbar per avermi mostrato la mia professione di software engineer con una luce diversa, spronandomi anche a provare nuove sfide lavorative.

Grazie per tutto quello che fate e spero che berrete un po' anche alla mia salute.

E infatti proprio alla salute di Gilberto e di Alberto noi brindiamo sollevando i calici.

Cheers! Bene, bene, bene.

È stato super figo andare a esplorare il percorso che hanno fatto Marco e Paolo perché dal mio punto di vista questa cosa può essere come stessa come stimolo anche per altri e quindi è veramente importante dirlo in pubblico, condividerlo in pubblico e perché no anche festeggiarlo in pubblico l'achievement ottenuto.

Quindi mi approfitto di nuovo per fare le congratulazioni a Marco e per fare i complimenti e anche i ringraziamenti a Paolo per l'effort che ha messo in questo percorso perché prima del codice ci sono sempre le persone.

E detto questo noi vi diamo appuntamento alla prossima settimana.

Ciao a tutti! Grazie Paolo, grazie Marco! Ciao, ciao! Ciao!.