Bene e benvenuti su Gitbar, un'altra settimana e un altro episodio qua nel nostro bar degli sviluppatori Questa volta è un'intervista, ma non sono solo, ho prelevato forzatamente dagli ammuttinati Leonardo per farmi compagnia.Ciao Leo! Ciao a tutti gli ascoltatori Guarda, da quando diciamo si è costituito il gruppo degli ammuttinati io non mi sento più solo e questa cosa è ma oggi non siamo solo noi due, vero? No, oggi non siamo solo, è venuto a trovarci una...non so come definirlo...uno sviluppatore, no, un patito dell'open source...Ah io non lo so, forse lo sviluppo più, forse, non lo so...Eh infatti, io lo chiamerei solo Matteo, però non lo so, qua lo faccio introdurre a te.Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.L'avete già sentito? Ma prima di dirvi nome, cognome e indirizzo di casa, vi ricordo i nostri contatti.Info@gitbar.it o @brainrepo per scriverci.Naturalmente come Leo? come si sol dire abbiamo? Abbiamo un gruppo Telegram che sta raggiungendo i famosi 300 iscritti dopo i 300 ci sarà una sorpresa quindi Mauro l'ha scoperto poco fa.Venite cercate Gitbar su Telegram e ci trovate.Assolutamente sì però bando alle ciance e iniziamo subito.Abbiamo con noi Matteo Collina technical director per NearForm, TSC member per Node.js, IoT expert, conference speaker, PhD e chi più ne ha più ne ha.Insomma abbiamo con noi Matteo.Ciao Matteo come va? Ciao ciao ciao Mauro ciao Leonardo ciao sono molto contento di essere qui sì ecco sono technical direttore a NearForm, faccio open source, faccio conferenze, ogni tanto scrivo codice.Guardavo adesso, sono a 5.000 commit nell'ultimo anno su GitHub.Guarda, io prima di fare questa puntata stavo cercando la fesseria da dire e l'ho trovata.Sono entrato nel tuo GitHub e ho guardato il grafico, quel bellissimo grafico con i pallini.Ecco, vai bellissimo, sì.Io la chiamo "la camminata della vergogna però questo è un...potremmo scrivere un libro o fare un film "50 shades of green" perché praticamente è tutto verde io ho contato e mi è venuto facilissimo 7 quadretti bianchi in un anno quindi credo che sei cintura nera di commit e di contribution in realtà questi qui sono contribution perché molto spesso sono le mergiare una pull request conta e siccome io sono su qualche migliaio di repository, probabilmente in giro nel mondo, in realtà ne emergono parecchie e quindi le emergono tipicamente dal telefono.Anche quelle contano, quindi spesso e volentieri, un po' come uno legge le notizie di Facebook, c'è gente che scrolla Facebook per rilassarsi, scrolla Instagram, io normalmente scrollo le notifiche di Github sull'app del telefono e premo Merge.O lascio commenti caustici, ecco questo era l'altro aspetto.Però c'è da dire che il 25 dicembre ha zero contribution, quindi nel senso anche un'etica professionale.Sì, ma guarda il 31.Non è uno malato che fa tutto.Ti sfida a guardare il 31, Leo.Sta controllando e vedrà che è verde.Eh, è certo dove recuperare quello che non ha fatto a Natale eh ma no ci sta cioè il 31 vediamo cosa ho fatto il 31 il 31 ho lavorato su notecore e su fastify ah te lo ricordi? no perché se clicchi si vede ti dice cosa ho fatto ho fatto la review di 8 pull request e ho fatto la merge di 1 su pino insomma ti sei portato la giornata lavorativa sì la cosa inquietante ecco è meglio non dirlo a mia moglie perché a quel punto, ecco la mia moglie, ciao, stavo registrando cara, ma comunque, è passata mia moglie che sta uscendo con mia figlia e appunto stavo dicendo che il giorno che è nata mia figlia in realtà ho scritto del codice ecco e quindi ho risposto a qualche commento, a qualche cosa.Devo dire la verità, aspettare fuori nel tempo di Covid è veramente brutto, quindi è stato un po' un passatempo in quel momento.Assolutamente sì.Allora, oggi la prima domanda è sulla carriera, perché sono veramente curioso ed è una cosa che sto chiedendo un po' a tutti gli speaker o comunque alle figure internazionali che vengono a visitarci.La mia domanda è qual è il percorso che porta uno sviluppatore normale, anche un senior, a proiettarsi in un ambiente, in un ecosistema internazionale, quindi ad agire non più a livello locale ma aprirsi al mondo? Allora, questa è una domanda abbastanza interessante e carina Devo dirti, la cosa che per me è stata il punto di svolta è stato l'open source.Quindi dal mio punto di vista io non avrei fatto niente di quello che...dei successi che ho avuto nella mia carriera, di tutto.Se non fosse stato grazie all'open source.E quindi io a questo ne posso essere...sono fermamente convinto di questo aspetto.per me è stata la cosa più che mi ha dato di più nella nella mia carriera scommettere su No JS è stata la scommessa vincente della mia carriera e sono estremamente contento di averla fatta ho iniziato a lavorare con Node quando Node era 0.2 cioè stiamo parlando di roba vecchissima e quindi niente basta la scommessa è stata quella dopodiché è stato continuare nel senso che cercare sempre occasioni di migliorare i commons se vogliamo migliorare le librerie open source che si usano le cose pensò le librerie le framework ragionare capire cosa stava manco cosa mancava e costruire quello che manca.Detto questo è un po' un'arte, nel senso che spesso e volentieri uno deve anche pensare, ci sono un paio di libri molto interessanti sull'argomento, per esempio i vari libri della business model generation, value provision design, business model of youth, c'è tutta una serie di ragionamenti su come approcciare la creazione di valore e uno deve capire in che punto sta dell'ecosistema economico in cui vive e capire qual è il modo migliore per uscire da questo, per arrivare dove vuole arrivare.Uno può anche essere tranquillamente felice dove è, io dico sempre che qualunque lavoro ed è degno di rispetto, è degno di rispetto ed è degno della più totale stima.Quindi uno può tranquillamente non voler fare carriera ed è la cosa più giusta del mondo.Quindi dipende molto da uno dove vuole andare a arrivare.Dimmi Leonardo.No, volevo chiedere se, visto che hai parlato sulla scommessa di No JS, se No JS non avesse ha vinto la scommessa quindi non avesse raggiunto la popolarità che ha ora.Non avresti raggiunto forse lo stesso numero di persone ma probabilmente ti saresti buttato su un'altra tecnologia.Mi sarei buttato su un'altra tecnologia.Nel senso a forza di provarci poi uno la trova.Non è il tipico overnight success ecco nel senso all'ennesimo tentativo al 42esimo tentativo qualcosa è successo, è l'approccio il discorso, è l'approccio con cui mi sono approcciato alle cose.Capire una delle cose fondamentali è stata una dinamica molto importante del del settore IT che è un po' che tanti anche spesso da, soprattutto in Italia, non fanno fatica a capire spesso o fanno fatica a immaginare.Il mercato dello sviluppo software, ma è già da 15-20 anni, che si sta sempre di più polarizzando tra chi costruisce feature e chi sviluppa tool.Il discorso, e purtroppo questa è un'altra di quelle cose che non viene, non c'è niente di male a costruire feature, si crea tal valore, enorme valore nel costruire feature una dopo l'altra, ma se vedete tutte le persone, tutte le varie personalità del mondo IT, gli autori, gli speaker, chi fa podcast, chiunque è diventato a un'opinione in quanto autore o maintainer o parte del team che sviluppa o mantiene un qualche tipo di strumento.Questo è un trend dal mio punto di vista inequivocabile.Per cui se vuoi essere rilevante e se vuoi avere attenzione da parte del mercato, se vogliamo, devi essere uno che crea tool, uno che fa strumenti o che lavora strumenti già esistenti.Perché non ho scritto io NOD, non l'ho fatto io, centro niente, sono arrivato molto dopo, sono nel TSC ma non l'ho fatto io.Costruirsi l'esperienza richiede parecchio lavoro, cioè creare una internet persona se vogliamo all'interno di una community è qualcosa che richiede sei mesi, sei mesi un anno di lavoro, è un sacco di lavoro, non è minimamente un overnight success, è proprio tanto lavoro.E' tanto lavoro mantenerla, quel tipo di attività.ecco quindi poi secondo me anche tanto lavoro non focalizzata nel voler esserci per forza ma avere un altro tipo di drive nel senso mi piace l'open source mi piace contribuire condivido questa cosa e nel frattempo si crea questo circolo perché se non lo si lo per essere per esserci sì non ci puoi se ci lo fai solo per esserci non funziona perché finisce il carburante prima ovvio e finisce il carburante prima, non hai il ritorno, non ti dà la dopamina se vogliamo.Devi avere qualche tipo di ritorno nel breve periodo, qualcosa che ti dà la solita dopamina di turno, che ti fa a partire un po' di...che ti dà un po' di carica.In realtà la community JavaScript è una community, ma non solo la community JavaScript, poi, è una community, ci sono alcune community che sono molto aperte alla sperimentazione, ai nuovi approcci, alle nuove cose.Quindi il mio, in generale, la mio approccio in tutto questo mondo è di raccomandare, andare a proporre cose nuove, di fare cose nuove o di fare i contributi su cose nuove all'interno di un progetto esistente e andare poi a proporlo tramite conferenze, eventi e cercare di creare, vedere com'è quello che viene presentato, che feedback si riesce avere questo ti crea il circolo virtuoso perché il software oggi è troppo complesso per sviluppare una persona sola quindi devi svilupparlo in 2 3 10 20 30 quindi devi per forza garantire questo tipo di flusso.Scusami ma Express non è sviluppato e mantenuto da una persona sola.Bellissimo.Cerchi il flame maledetto.No, Express è mantenuto da una persona sola sviluppato sul mantenuto esporrei qualche avrei qualche dubbio sul sul mantenuto avrei qualche dubbio e sullo sviluppato posso dire che non viene sviluppato da nessuno diciamo custodito da una persona viene custodito da una per questo il termine corretto è custodito da una persona sola mi dispiace dag ti voglio bene se ci guardi vedi una traduzione se ci stai stai ascoltando Doug, ti voglio un sacco di bene, nessuno se la contesta.Però bisogna avere, soprattutto quando si è custodio di un progetto open source, l'unico modo che si ha oggi per sviluppare qualcosa di open source fatto bene o è un prodotto di un'azienda che è un altro discorso o altrimenti devi creare una community di aziende e persone che vogliono contribuire, sponsorizzare quello che vogliono.Secondo me ha introdotto una serie di domande che io e Mauro ci avevamo detti prima nel backstage, vai pure te Mauro.No, allora io prima ancora di parlare di open source vorrei tornare su JavaScript perché tu hai usato una...hai rappresentato in qualche modo la tua scelta di Node per costruire su questa tecnologia la carriera come un po' una scommessa no? Hai detto che ti sei avvicinata a Node veramente ai primordi.Che cosa ti ha suggerito che quello potesse essere il runtime, la piattaforma, l'ecosistema vincere? Due cose, due cose completamente scorrevate.La prima è ha delle ottime prestazioni ed è di basso ed è di relativamente basso livello posso manipolare le socket.Non puoi fare le stesse cose in Python o Ruby per esempio, o PHP o altri linguaggi di scripting insomma.A me piacciono i linguaggi di scripting perché garantiscono molta velocity in termini di scrittura del codice, cioè nel senso che si riesce a...sono più produttivi o perlomeno io sono più produttivo nei linguaggi di scripting rispetto ai linguaggi compilati, o perlomeno rispetto a java e dotnet.Il motivo per cui non php, non python e non ruby...ho fatto tanto ruby nel passato, ho fatto un po' di python e ho fatto un po' di php, quindi li ho fatti tutti.Nessuno di questi smarca tutte le cose che smarcano.Non sono abbastanza di basso livello, non posso fare abbastanza cose che voglio a livello di di socket e livello di networking per esempio e sono più lenti, infinitamente più lenti, non c'è credo sia un ordine di grandezza di differenza, mentre Node più o meno è solo due volte più lento del C, che se lo consideriamo con il fatto che è scripted è un grandissimo è un grandissimo risultato e quindi è ottimo.Questo più o meno il primo punto.Il secondo punto non c'entra niente con con Node.Il secondo punto non so quanti dei nostri degli ascoltatori abbiano lavorato su java prima nel passato.Spero di vedere tante mani alzate, capito? Ok, il motivo per cui io ho riconosciuto immediatamente che Nod sarebbe stato un successo mondiale è quando per la prima volta ho visto NPM.NPM risolve il problema dei class loader in Java.Non so quanti di voi abbiano avuto a che fare con i class loader in Java, il problema principale di di Java come linguaggio è che non si può caricare la stessa libreria in due versioni diverse.Questo è il principale problema dell'ecosistema Java che ne limite il riuso delle singole librerie, per cui una libreria deve essere compatibile con le altre librerie, con la stessa libreria, cioè se un altro dipende dalla stessa libreria, le tue versioni devono essere compatibili tra di loro.Questo limita fortemente il riuso del software, quindi è molto difficile riusare il software in mondo Java.In .NET c'è un problema analogo, perché comunque si parla di binari.La soluzione di Node è estremamente elegante, l'estruzione di NPM è estremamente elegante e risolve il problema dello riuso nello sviluppo software.Se pensiamo che prima di NPM nessuno era riuscito a creare un sistema di riuso del software mondiale, poi siamo arrivati qui, il risultato lo vedete sotto gli occhi di tutti, NPM è la community di riuso del software più grande al mondo con non so quanti miliardi di moduli dall'interno e la cartella NodeModules è l'oggetto più pesante dell'universo.Il buco nero.Il buco nero dell'universo ecco io purtroppo sono realista e quindi anche questo è il problema.Un progetto tipo a 1500 dipendenze, cioè parliamo ne capito perché sono 1500.Sì, beh molto viene anche da come scriviamo il codice che alle volte siamo portati a scaricare dei moduli per fare cose che potremmo fare con due righe.Ma certo, ma questo è rilevante, ma il problema, l'idea di vedere lo sviluppo software come l'assemblaggio, come non reinventare la ruota tutte le volte, ma assemblare pezzettini di Lego è un approccio completamente innovativo, se mi passate il termine, ma che risolve poi il problema che era un po' il limite principale dello sviluppo Java su larga scala.Non so quanti di voi...il problema enorme era che a un certo punto ha avuto il guaio che Android metteva dentro il suo sistema una versione di Apache HTTP, pensate che mi ricordo pure questa roba, di Apache HTTP, che però era nella versione 0.qualcosa e l'ultima è la versione 1.E non potevi utilizzare nessun'altra libreria che avesse dentro l'Apache HTTP in versione 1, perché non era compatibile con la 0.9 e non la potevi usare su android.Dopodiché hanno risolto questa cosa.Questo era android 1.5 stiamo parlando di memorabilia.Poi l'hanno risolto per fortuna.Credo che l'abbiano tolta proprio però non vorrei...era un problema appunto dei class loader, dei fantomatici class loader di java.noi abbiamo citato java e si è unita a noi anche mattia ciao mattia ciao mi avete evocato avete detto java, mi schiavano le orecchie, i miei sensi di ragno mi hanno detto che dovevo essere il genio della lampada e quindi abbiamo avuto due i due motivi appunto che per cui nojs secondo me aveva tutte le carte per essere una tecnologia di successo mondiale erano queste due, la relativa velocità rispetto al resto nell'ecosistema e il sistema dei moduli.Node.js è diventata insomma una tecnologia di uso di massa, una tecnologia super usata, ma all'orizzonte si affacciano anche i figli, i bambinetti giovani che vengono proprio da quel mondo.Parliamo di Dino, come vedi l'arrivo di Dino? Questa è una domanda che mi è venuta adesso proprio mentre parlavi di Nod.Come vedi l'arrivo di Dino secondo te può essere un game changer? Allora ho svariati se vogliamo è una domanda con...ne potremmo parlare per un'ora ecco di questo tipo di questo tipo di domanda per dare appunto la più totale la visione più completa.Il primo aspetto è che secondo me è una cosa estremamente positiva perché l'avvento di Dino ha avuto un risultato molto importante nel progetto NoGS di refocus su quelle che sono le caratteristiche fondanti.Quindi dal mio punto punto di vista la cosa è estremamente giusta, è una delle cose più… ha fatto del bene a Nod, questo è il primo aspetto.Questo è la prima cosa, nel senso che per il mio punto di vista va benissimo.In generale l'approccio del marketing di Dino non mi è piaciuto e si sono in generale comportati a livello di quasi come fossero dei troll in molti casi.spesso non dal team di Dino ma dalla community delle persone che utilizza Dino quindi io mi dispiace ma se oggi fai front end o back end con OJS e utilizzi OJS tutti i giorni fare un blog post o un articolo o un tweet dicendo "destroy node" con l'edificio che va in pezzi è come minimo ipocrita e mi dispiace io a questa cosa qui non l'ho mandata giù, difficilmente la manderò giù.Tante persone che ho visto fare questo tipo di commenti mi hanno lasciato molto l'amaro in bocca perché appunto non me l'aspettavo come direbbe la mia nonna sputare nel piatto in cui mangi.Non si azzanna la mano che gli va da mangiare, è il solito discorso.Del Il progetto Dino non condivide tantissime cose, in particolare dei loro annunci vari.Dicono che loro volevano fare delle cose con noi e non gli è stato concesso.La realtà è che loro se ne sono andati perché hanno venduto le loro aziende e le loro proprietà per fare dei soldi e si lamentano che poi il progetto non ha fatto quello che volevano loro.Io ho delle parole, io lascio questi fatti agli altri per decidere che cosa pensare di questo tipo di commedi, di annunci.Io se fossi io non li farei.Direi cose leggermente diverse.Credo che da come è raccontato la vicenda proprio traspaia in modo evidente che dietro ogni riga di codice c'è un uomo.Certo, assolutamente.Si sentiva proprio dal tono come raccontavi la vicenda perché fondamentalmente non potrebbero esistere queste librerie, questi ecosistemi senza le persone come dicevi prima.Esatto, ma guarda la storia di Nod è fenomenale da questo punto di vista.Tanti geni hanno creato l'ecosistema Node, da Ryan Dahl, Isaac Schroeder, Bert Belder, Bernard Hausen, Fedor Indutny e parecchi altri di cui posso dimenticare il nome.Tutti questi hanno lasciato i loro...Alcuni di questi hanno aperto delle aziende o per esempio Ryan ha venduto Node.js a Joint e dopo un po' se n'è andato da Joint dopo aver venduto il progetto.Ok...Boh...Non lo so...Io su questo punto ce lo...Io adesso creo un'azienda perché ne fa un altro L'altro co-founder è Bert Belder che non so se vi ricordate ha fatto Strongloop è stato uno dei founder di Strongloop che poi è stato acquistato da IBM quelli che hanno fatto Loopback che alcuni di voi possono aver usato Ecco, Loopback è nato da loro che è stato poi acquisito da IBM sono stati comprati da IBM Quindi uno ha venduto nod a joint l'altro ha venduto strong group a IBM e adesso hanno aperto un'altra azienda con soldi del venture capital.Tra l'altro hanno preso soldi da Mozilla che l'anno scorso ha lasciato a casa tante persone.Scusatemi ma ce ne ho per quando mi fai queste domande ce ne ho per tutti.E colpa mia è responsabile.Io non mi dispiace ecco.Sto raccontando solo fatti pubblici.queste sono cose note, sono fatti pubblici.Quando comincio a collegare questi dettagli, io non avrei fatto un annuncio dicendo che No JS è lento perché ha un comitato o perché noi abbiamo creato Node e poi non dici perché te ne sei andato.Quindi non sei salvatore, ecco, non ti puoi etichettare come salvatore, il messaging non è per me corretto.Dopodiché, senza togliere il lato tecnico di Dino che c'è, è un progetto fenomenale, ha delle caratteristiche tecniche veramente ottime, soprattutto lato sull'isolation, su come vengono fatte determinate cose, è veramente moderno, mentre No JS ha in quelle stesse aree del debito tecnico enorme.Detto questo c'erano probabilmente fondi di Venture Capital per fare qualcosa di nuovo, non c'erano fondi di Venture Capital per sistemare Node.Rimaniamo sempre nel mondo dell'open source dove in realtà come ben descrivi la situazione non è certo un mondo fatto da fiumi di latte, miele, rose e fiori ma è una rappresentazione, del mondo reale e delle persone reali.Però voglio spostarmi su un altro progetto, voglio spostarmi su Fastify.Se ne parla tanto ne riconosciamo la tua paternità.È un framework javascript che è stato un po' game changer nel mondo dei framework javascript.Assolutamente, è stato un fantastico overnight success durato quattro anni.Che cos'è Fastify e in cosa si distingue dagli altri? Ok questo è facile grazie dell'assist.Allora questo è più facile di quella precedente perché in quella precedente hai toccato un nervo.Questo è facile grazie dell'assist.Allora, cosa fa Fastify? Lo possiamo utilizzare per creare server web con NoJS, API tipicamente.Perché è un game changer? Fastify nasce dalla mia esperienza nel mettere in produzione software NoJS da lontano 2011, quindi diciamo che è stata accumulata nel tempo In particolare ho fatto svariati progetti con Node, usando tutti i framework possibili e immaginabili e anche usando semplicemente Node Core, cioè frameworkless.Il risultato di quell'approccio è stato che il sistema che avevo fatto era estremamente veloce, scalabile, ma relativamente poco manutenibile, di difficile manutenzione.Per me era facilissimo, però gli altri sviluppatori non lo trovavano altrettanto facile, quindi forse non avevo fatto un buon lavoro.Il problema di fondo nasce da...perché c'è tanta attenzione oggi su Fastify? Perché, l'ha menzionato Leonardo, Express non si è voluto.L'ultimo rilascio di Express stato fatto sette anni fa, l'ultima major, nel mentre abbiamo guadagnato le promise, Sync Await, è cambiato il modo in cui sviluppiamo software in Node e Express non è cresciuto con Node, Express è rimasto lì e quindi il problema è che Express non essendo cresciuto con Node ha mantenuto quella che era l'impianto di fare Node quando Node aveva solo le callback e questo è secondo me l'aspetto, ma non solo questo, ci sono tutta una serie di cose che sono state fatte.Per esempio il modo in cui sono fatti gli internals di express sono fatti male, mi dispiace dirlo e lo dirò infinite volte, perché si banano sul monkey patching.Quando tu ti basi sul monkey patching degli internals stai facendo una porcata, il termine brutto italiano, me ne frega niente, stai facendo una roba brutta perché vuol dire che se gli internals cambiano tu ti rompi e non ti stai basando su un'interfaccia pubblica, stai proprio basandoti sul cambiare della roba all'interno, cioè cambiare il funzionamento di oggetti che ti arrivano.Questa è una pratica che viene dal mondo Ruby, se vogliamo, ed è uno dei...mentre in Ruby però questa cosa, a girare questo problema è molto facile per via del linguaggio che è molto dinamico.In JavaScript e non JS questa cosa non è semplicemente possibile.Method missing, non so se qualcuno di voi ha fatto Ruby che sa che cos'è il method missing, tutti sorridono.Ecco in Ruby c'è questo fantastico method missing che in JavaScript non c'è e questo e quello è l'asso che ti tira fuori dai problemi.In questo specifico caso siamo nei guai perché Express dipende da tanti degli internals di Node che tra l'altro non possiamo cambiare perché se li cambiamo rompiamo Express che è uno dei maggiori utilizzatori, è usato da tutti e non c'è quasi nessuno che lo sta sviluppando oggi.Quindi è proprio un problema enorme.Questa è un po' l'opportunity, nel senso che tante persone non stavano usando, non c'era più innovazione.In particolare abbiamo da un lato Express che non era manutenuto, dall'altro lato c'era Api che vedeva manutenuto da una sola persona in una modalità mista open source commerciale.Era bravissimo, era tanto di cappello, ma aveva degli evidenti limiti da un punto di vista di progetto, nel senso che non è riuscito a far decollare questo business su Api.Il terzo aspetto è che li ho menzionati due, i due terzi contendenti sono Coa e Restify.Coa e Restify è morto, simile a Express, è un progetto morto.Se vedete non ha fatto rilasci di recente proprio K.O.Perché l'unica azienda che lo usa in produzione è Netflix.Va bene per quello che ci devono fare, non lo stanno sviluppando anteriormente.anche lì il progetto ha avuto dei limiti evolutivi relativi a Async/Await, le promise e tutta una lunga serie di cose.Netflix ci ha messo tantissimo ad adottare le promise per esempio e Async/Await tra le altre cose.L'ultimo aspetto è Koa.Tecnicamente non l'ho mai inquadrato, ci sono delle differenze enormi da un punto di vista di prestazioni, struttura del codice, struttura del framework che non mi tornavano completamente.Il risultato finale è che non c'era un framework che mi andasse bene per uno di qualunque di questi motivi.Nel 2016 mi sono messo lì e ho cominciato a lavorarci.Ho iniziato a lavorare su due aspetti.Il primo aspetto stato lato...il problema tecnico mi era noto, mi era nota anche la difficoltà del problema tecnico.Mantenevo già HTTP dentro node, è una cosa difficilissima, cioè stiamo parlando, ci sono mille aspetti da considerare in termini di prestazioni, sicurezza, denial of service, scalabilità del router e anche concerni aggiuntivi tipo l'osservabilità, il logging, l'autenticazione, la sicurezza, tutta una lunga...stiamo parlando di la connessione ai database, per esempio, per non dimenticarsi del testing che è sempre una di quelle cose che viene lasciata per ultima, ma è fondamentale.Tutte queste cose hanno portato ad avere Fastify e, come dicevo, un overnight success clamoroso perché in realtà io facevo un corso a Bologna con la Vasco Perta.Ciao Brando! Facevo un corso a Bologna con la Vasco Perta e Thomas, Thomas della Vedova, era uno dei partecipanti.Mi ha chiesto "ma io vorrei fare carriera in questo settore, come devo fare? Sembra che tu abbia successo, quindi fammi capire cosa facciamo"."Guarda, devi metterti a fare open source".Mi ha chiesto "ma cosa faccio?".Io ho sviluppato questo moduletto che fa il rendering dei JSON in maniera estremamente veloce.Ho sviluppato questa nuova tecnologia che è il FastJSON Stringify, che è ancora lì tra l'altro.Sono stato molto contento di averlo potuto...di averlo potuto...sono anche riuscito a presentarlo di fronte a...Crockford e l'ho anche presentato in un talk a Londra davanti a Crockford vabbè, aperta tutta la piattaforma XJaparentis Volevo fare una domanda su...dato tra le cose che hai elencato di Express che ora purtroppo prendiamo come capo rispiatorio è il fatto di essere mantenuto una persona sola.Però anche te quando hai iniziato Fastify eri una persona sola.Sbagliato, non corretto.Io ho fatto l'onboarding di Thomas, abbiamo iniziato da scritto la prima riga di codice di Fastify quando c'era già Thomas.Ok, quindi è iniziato perché c'era Thomas? È iniziato perché c'era Thomas.Ok, quindi non volevi fare una cosa gestita solo da te? No, l'idea era mai fare una cosa da me perché non volevo essere il bottleneck.Per rispondere brevemente alla tua domanda è costruito in modo tale che mi sopravviva? Che credo sia uno degli elementi principali quando vuoi creare qualcosa che vada oltre te.Esatto.Qua in realtà era una cosa che volevo volevo chiederti dopo però proprio la mia domanda era come vedi tu e il codice? Il codice ti rappresenta? Il codice è un tuo artefatto? Il codice ti appartiene o il codice è un po' come un'amica poetessa mi diceva io faccio un'opera, una parte dell'opera, una volta che realizzata il codice prende vita, deve vivere da solo, quindi la mia opera deve vivere da sola, deve vivere nei menti dei lettori, in caso di una scrittrice, e non mi appartiene più.Mi piace questa metafora artistica, vorrei avere una metafora artistica, io invece una metafora molto più terra terra e mi dispiace.Sibele Lonardo me l'ha già sentita dire, quindi non è una novità e la sentirete dire tutti adesso perché questo podcast è un bar e quindi si fanno chiacchiere da bar, dicevamo.Penso che il codice sia cacca, che tutto il codice sia cacca, sono tanti strati sodilificati di merda.Quello che scrivo io può anche essere oro oggi, nel senso che puoi essere soddisfatto di quello che tu produci qualcosa come un ingegnere, un artista, produci qualcosa, ma mentre le parole scritte, le poeri mantengono la loro bellezza nel momento in cui in maniera imperitura o quasi o per moltissimo tempo, il software si deteriora a una velocità impressionante.Quindi tu hai fatto qualcosa che può anche essere bellissimo oggi.Ma inevitabilmente.Finirà per essere la cosa più bella che puoi sperare quando tu scrivi un pezzo di software.La cosa più bella che puoi sperare di diventare il software legacy della generazione successiva.Cioè nel senso devi pensare e tu cosa pensi quando devi lavorare con la code base legacy che.E quindi tu in realtà, quando il software legacy che tu pensi sia poco bello, e questa è una cosa che ho imparato con l'esperienza, il software legacy che pensi che sia brutto in realtà era il software meraviglioso della generazione precedente.Ed è quello che ha sopravvissuto, perché se non avesse avuto successo, se non avesse fatto quello che doveva fare, sarebbe morto.Quindi ha tantissime cicatrici e tantissime cose belle all'interno, ma è sostanzialmente cose che si stanno disfacendo.Il fattore di putrefazione del codice è una cosa impressionante.Una delle metafore che mi raccontava mio padre per parlare di questo tipo di fenomeni.Mi piace raccontarla perché è interessante.Mio papà lavorava, era molto appassionato di barche e mi raccontava che una delle grandi innovazioni della seconda guerra mondiale erano gli U-Bot tedeschi, che erano queste meraviglie della tecnologia.In realtà gli U-Bot tedeschi non funzionavano, c'erano costantemente a turno dei meccanici che oliavano varie parti, riparavano le cose che si rompevano costantemente per far vivere tutti, per non farli affondare e ogni tanto qualcuno ci lasciava le penne.Oggi tutto il software che sviluppiamo è molto simile a un U-Bot.Il fatto che funzioni è un miracolo quasi.Lo stato finale del software è di disfatta completa.Lavoriamo costantemente si parla di maintenance, si parla di per tenerlo in piedi e tenere il castello in piedi ecco non puoi fermarti, sei uno squalo non puoi fermarti, devi sempre nuotare e questo è uno dei problemi principali che tante aziende e tante realtà non capiscono del mondo IT e quindi mi piacerebbe paragonarlo all'arte capito io sono molto più terra parlo di cacca d'artista, però la realtà è che è qualcosa che, se vogliamo paragonarla dell'arte, è come fare i castelli sulla sabbia.Puoi fare delle composizioni bellissime, ma poi un domani non ci sono più.A meno che non stai lì e la rifai tutti i giorni, e questo è un un po' il problema dello sviluppo soft.Mi viene in mente un'analogia su questa cosa perché allora ho pensato, ma allora quei sistemi che dicono "guarda questo è 20 anni che funziona, non lo tocchiamo".Il problema è proprio che non lo tocchiamo perché nessuno vuole toccare una cacca che è ferma da 20 anni.Per cui mi viene in mente che anche se fai una cosa che pensi sia bella perché sta su da 20 anni poi nessuno ci vuole mettere le mani per quel motivo lì.Esattamente, nel senso che non è Fancy, se guardi al software più di successo di tutti i tempi è Kobol.Kobol è una cosa di più di successo di tutti i tempi eppure nessuno di noi, me incluso, vuole lavorare su Kobol.ma la realtà è che COBOL è uno dei linguaggi di programmazione più di successo al mondo da questo punto di vista, più longevo, che vuol dire che è sopravvissuto tante generazioni e tanta gente che lo voleva eliminare.Nessuno ci sta riuscendo comunque, tuttora oggi gli sviluppatori COBOL sono tra i più ricercati, l'America di recente ha dovuto risumare gli sviluppatori COBOL in pensione per sistemare...praticamente un po il Kate Richards dei linguaggi di programmazione.Cioè nel senso stai parlando di una roba che è veramente brutta.Environment division, data division.Io ci ho programmato in Kobol a suo tempo quindi ricordo l'obrobriosità della lingua.Però bisogna capirle le cose, capito? bisogna...quindi lo scopo, l'obiettivo, se vuoi chiedere qual è l'obiettivo tuo di Fastify, l'obiettivo tuo di Node quando fai queste cose è di diventare legacy e quindi l'obiettivo è di diventare legacy e questo è diventare la merda che gli altri vogliono rimpiazzare.Nel momento in cui diventi questo in realtà vuol dire che la tecnologia su cui hai sviluppato è una tecnologia che ha avuto un grande successo.In realtà non l'avevo mai inquadrata da questa prospettiva, proprio il lavoro che facciamo è l'obiettivo al quale andiamo, però è assolutamente una prospettiva interessante.A proposito di cacca sulla quale mettere le mani, io voglio rimanere sull'argomento.Un po' coprofagica questa puntata, ma il rischio appunto di creare del software non buono che si ha quando si sviluppa un framework, o per meglio fare la domanda come si gestisce lo scope creep quando si realizza un framework? Cioè il rischio di mettere tutte queste feature, anche perché stai sviluppando un tool che altri dovrebbero usare, quindi come si gestisce questo trade off? Lo metto o non lo metto? Questa è bellissima come domanda.Tu hai due aspetti che devi considerare sempre.Gli aspetti sono da un lato la developer experience e dall'altro lato la, così detta, io la chiamo operation experience, ma la puoi chiamare come ti pare, che è la parte, se vogliamo, che vedono la parte di operations della tua azienda, cioè come si comporta il tuo framework all'esterno, quando viene messo in produzione.Sono questi due aspetti.Il terzo aspetto tangenziale, se vogliamo, ma è la terza direzione, è la sicurezza.Perché anche questa è da considerare.Però sono tre aspetti disgiunti.Il tuo framework si deve orientare.Non so se vi ricordate quando io all'università giocavo a Pre-Evolution Soccer con i miei colleghi universitari, i miei compagni di casa, i miei inquilini.La partita a quattro con la play a Pre-Evolution Soccer era un classico del pomeriggio.E poi non so voi, ma era un classico anche della mattina.A Bologna in realtà lo chiamavami in un altro modo ma non si può dire questo.Mentre posso dire merda o cacca, l'altra cosa non la posso dire.Mi arriva la censura, mi autocensuro.Se volete, quando non registriamo più, poi ve la racconto.Lavoriamo di immaginazione nel frattempo.A Bologna soprattutto.A Bologna.A Bologna come si potrebbe...Potete immaginare.Comunque, In Pro Evolution Socks c'è il diagramma delle caratteristiche del giocatore.Un po' i vari framework, tu puoi immaginare che i vari framework abbiano determinate caratteristiche.Tu puoi avere una developer experience da panico, da paura, bellissima, ma una production experience orribile.e non vorrei fare troppi esempi in questo argomento, ma ce ne sono parecchi nella nostra community.Dall'altro lato ci sono framework sicurissimi e framework che non sono sicuri per niente.Quindi dipende molto da come vogliamo il design, l'architettura del framework, framework, c'è molto da decidere se vogliamo.A che cosa mi sono ispirato? In prima battuta è il… adesso io non vorrei… adesso dirò delle cose da già vista convinto, ok? Il principale principio, se volete qualcuno mi criticherà, in realtà stiamo parlando del buon vecchio SOLID, il Single Responsibility Principle, Open Causal Principle, List of Substitution, Interface Segregation and Dependency Inversion, ed è bruttissimo da dire, ma Fastify basa quasi interamente su tutti questi concetti in un modo o nell'altro, dopodiché tu spesso volentieri non li vedi, non te ne rendi neanche troppo conto che queste cose esistono all'interno ed è molto con un approccio molto intuitivo se vogliamo nella gestione del framework stesso.Per esempio una delle cose fondamentali, per me è quello che mi piace di più, è il principio open/close che vuol dire che software entities should be open for extension but closed for modification.Cosa vuol dire questo principio? Vuol dire che quando progettiamo un framework o una libreria o qualunque altra cosa non vogliamo che per aggiungere una nuova feature o qualunque altra cosa, tu debba modificare il mio codice.Devi far in modo che la cosa si possa fare estesa.Tipicamente questa cosa, in un linguaggio parzialmente funzionale come è JavaScript, come è JavaScript, che ha questa doppia anima se vogliamo che ci viene dall'ISP.Abbiamo questa cosa che viene fatta tramite l'istruzione di funzioni, quindi tu ti viene passata una closure per fare cose e questo è una delle cose fondamentali di JavaScript e quindi il principio di Fastify è se qualcosa può essere un plugin deve essere un plugin.Questa è la caratteristica principale di Fastify.L'altro aspetto che ha Fastify è che questo plugin system in realtà ti consente di gestire anche gli scope boundary, quindi io posso creare degli sottoalberi, delle micro applicazioni che non condividono niente con l'applicazione padre.Questa è un'altra delle cose fondamentali che ho aggiunto nel framework, tant'è che Fastify, stiamo lavorando alla versione 4, il plugin system è la versione 7, pensate, c'è stato lo stacco, è notevole.E' nato prima, tra l'altro, è nato prima il plugin system di Fastify, per darvi un'idea.Stavo già lavorando al plugin system quando ho iniziato a lavorare con Fastify e con Thomas, è un modulo separato.che ha una storia interessante anche lui, nasce dalle ceneri di altri framework, di altre cose, come sempre gli overnight success di 4 anni.Quindi in sostanza in Fastify tutto quello che poteva essere un plugin è un plugin e questo lo facciamo anche creando appunto delle cosiddette interfacce o altre cose che ci consentono appunto di rimpiazzare componenti interni del sistema.Questo è un approccio.L'altro approccio però se tu vuoi avere una determinata user experience determinate cose le devi fornire quindi non puoi fare che tutto è sostituibile non puoi fare che tutto è rimpiazzabile quindi devi essere opinionated.Dove siamo? Dov'è opinionated Fastify? Fastify è opinionated sulle cose fondamentali.Primo il router.Fare routing è una caratteristica fondamentale di un framework open source, non possiamo fare routing senza...di un framework web, non possiamo fare routing senza sapere come è strutturata la mia...come faccio routing è una componente talmente chiave del mio progetto che non può essere sostituibile.Il router però ha tante opzioni che si porta dietro, quindi in realtà c'è uno scope creep limitato all'interno delle feature del router, purtroppo.L'altro aspetto che è uno scope creep è il logging.La prima cosa che fanno tutti quando utilizzano un framework web è aggiungere il logging, quindi non si capisce perché non debba essere una qualcosa su cui ho un'opinione.Quindi Fastify utilizza un progetto che ho fatto precedentemente che è Pino e che è il mio logger che uso.E anche lui ha un po' di scope creep relativo al login.A vale di questo ci sono tutta una serie di feature collegate a questi vari aspetti che fanno un po' parte dello scope creep del framework ed esiste e lo potete vedere perché quando andate su www.fastify.io nella documentazione aprite per esempio la documentazione del server vedete che ha una batteria enorme di opzioni veramente tante ok In particolare anche delle cose che tu non ti aspetteresti.Per esempio Fastify fa il parsing dei body internamente.In Express lo devi aggiungere, in CoA lo devi aggiungere.Fastify lo fa internamente perché non farlo internamente ti porta a tutta una serie di problemi che poi non vuoi dare in mano agli utenti da risolverlo.In particolare fare body parsing, farlo fatto bene, non è facile.Per quanto tanti possono pensare, la maggior parte delle applicazioni che utilizza Nexpress è vulnerabile a uno specifico tipo di attacco sui dati JSON che vengono inviati.la maggior parte di queste applicazioni non risolvono, non proteggono da questa cosa.L'unico framework che lo fa era API fatto da AiraNummer e dopo di che noi abbiamo preso quella stessa idea e l'abbiamo anche implementata in Fastify che è la protezione contro il prototype poisoning, quindi ha una protezione integrata per il prototype poisoning, per esempio.Perché facciamo parsing internamente dei JSON? Ecco lo facciamo internamente perché se non lo facessimo se lo facessimo fare agli utenti o tramite un mid o qualunque altra cosa sarebbe un macello.Pensiamo che ci sia una linea decisamente marcata su queste sulle cose che stanno dentro e stanno fuori.La linea c'è però ci sono molte più cose dentro rispetto ad altri framework perché l'approccio è di fornire qualcosa che non consenta agli sviluppatori di spararsi nei piedi, come si dice in inglese, in mondo anglofono.Non voglio spararmi nei piedi.Assolutamente sì.Ho una domanda.Vai Mattia.Tu hai detto io sono 110% d'accordo che è giusto che un framework su su alcune cose sia opinionated, che soprattutto su quali feature sono parte dello scopo e quali no.E quindi quando tu dici che tracci una linea su cosa sta dentro il framework e cosa no, tracci una linea che dice anche che cosa non fa parte del tuo framework.Ma allora, da maintainer di un framework open source, come ti comporti nel caso che, immagino, ti sia capitato in cui ti arriva un issue o addirittura una pull request con una richiesta di feature o un'implementazione di feature che secondo te non fa parte dello scopo del framework.Normalmente ci sono due possibilità ed è capitata di recente una.Ci sono due possibilità.La prima è può essere implementata fuori dal framework.Se credo che possa essere implementata fuori dal framework, normalmente raccomando che implementata fuori dal framework.Se manca un hook internamente per farlo, ti do un hook internamente per farlo.Spesso e volentieri in fastify vedi che ogni tanto si prendono delle funzioni e dici "ma perché questa?" perché qualcuno in quel momento ha bisogno di far girare del codice lì.Cioè in particolare c'è un hook nella fase di life cycle del dato che non ha senso, cioè quasi borderline senza senso, che è il look di pre-validation, cioè abbiamo fatto il parsing del dato non l'abbiamo ancora validato.Ecco questo qui dici ma perché tu vorresti far girare del code su dei dati sporchi? Beh lo sono chiesto eh! Te lo sei chiesto, vedo che...ecco, è un look inutile, ci dovrebbe essere scritto se lo usi c'è qualcosa di storto nella tua architettura, però in realtà per implementare un certo tipo di API è necessario.In particolare c'è tutto uno schema di invio del body che consente sostanzialmente sostanzialmente di inviare un body firmato per cui tu fai viaggiare il body assieme alla firma digitale, sostanzialmente un hash del body stesso.Quello che vuoi andare a validare nella fase di validazione è il contenuto, non la firma, e quindi la firma la vuoi validare prima del contenuto questo è il caso d'uso per cui è stato implementato quel pre-validation ecco, quel pre-validation hook questo è un caso positivo, abbiamo aggiunto la feature caso negativo in Fastify Fastify è opinionated e seguiamo molto gli RFC di HTTP alla lettera cioè siamo abbastanza rigidi su implementazioni di HTTP storte In particolare HTTP è case insensitive.Non so quanti di voi sappiano che HTTP è case insensitive.Quindi quando mandi fuori un header, HTTP, può essere tutto con le C maius, tipo Cache, Control, con la C maiuscola, ma può anche essere tutto minuscolo.Fastify utilizza come struttura dati internamente per gestione degli header, bypassa quella di node e utilizza una struttura dati completamente case e completamente lower case tutti gli HTTP header vengono gestiti e inviati lower case perché questa cosa qui semplifica enormemente e migliora significativamente le prestazioni del framework senza girarsi senza girarsi troppi pollici, ecco, migliora le prestazioni del framework in maniera importante questo è un po' il motivo, una feature che è capitata, una domanda che va di recente ma io vorrei che non lo facesse vorrei che continuasse a ecco questa feature che c'è è aperta eccetera è un po stato un po un crucio perché appunto è contraria a quelli che sono i principi nel senso che tu stai dicendo che è qualcosa che va contro gli rfc e detto questo però è una feature che ancora lì non è stata implementata e vedremo cosa succederà.Ad oggi normalmente se ci metti del tempo e dell'effort è veramente difficile che ti mandi an via e quindi se in generale vuoi implementare una feature ti diciamo ma se la vuoi implementare non deve causare una regressione nelle performance.Se questo è il caso tipicamente non diciamo di difficile che diciamo di no a una cosa di questo Fantastico.Altra domanda.Quando si sviluppa un framework come si gestisce il trade-off tra utilizzare una libreria di terze parti o sviluppare la porzione, la soluzione in casa? Parlo per esempio del router o di alcune funzionalità.Non siamo partiti con un router nostro, Siamo partiti con il router di Yoshua Wayfarer, si chiamava.Ciao Yosh! Stiamo partiti con un router di altri, dopodiché l'abbiamo cambiato perché aveva dei problemi di prestazione.Era il bottleneck principale e quindi l'è stato cambiato.In realtà probabilmente lo cambieremo ancora sinceramente mi aspetto che cambieremo, toccheremo il router prima o poi perché il codice non è particolarmente bello all'interno del router per cui mi piacerebbe molto portarlo su WebAssembly se volete però vedremo.La mia domanda era proprio qual è il driver che ti spinge ad adottare una soluzione già pronta? Il router è qualcosa, premesso che io volevo un certo tipo di struttura dati che è una struttura dati ad albero e non una struttura dati a non so quanti di voi sanno che express per esempio ecco uno dei modi che fanno con cui fanno routing e fanno routing una testando tutte le varie regole expression le rotte una per volta una dopo l'altra quindi se ne hai 120 fai 120 match di regola di expression quindi se sei sfigato che l'ultima che deve andare è la tua, sei alla 120esima, da cui capite che al crescere della complessità di un progetto express le prestazioni dello stesso crollano e non scala con la complessità.Poi il tutorial probabilmente è bello uguale, ma al crescere della complessità quest'approccio non può funzionare, perché dire che hai un array 120 elementi che processi tutte le volte che passa una richiesta capisci che non è proprio poco.E questo volevamo una struttura dati che era ad albero e detto questo è stato fatto abbastanza di iterazione, è stato fatto un ragionamento iterativo.A un certo punto Thomas se me so di se l'è scritto e l'abbiamo usato quello che ha scritto lui, ma se un domani viene fuori un altro router useremo un altro router ecco è molto probabile che lo riscriviamo un altro noi perché non vedo movimenti da un punto di vista nel mondo ecco da questo punto di vista quindi è molto probabile che scriveremo un router con Assembly Script o Rast o qualcosa di questo tipo.Ragazzi voi avete qualche altra domanda su Fastify? È stato super super eloquente.Leo? Io ho una domanda più che altro sul lavoro, visto che sono stati quattro anni di lavoro di sviluppo, ma oggi ho visto anche il grafico a croce che c'è su GitHub.Tu non scrivi più tanto codice più che altro fai verifica, pull request eccetera.Volevo capire come avviene questa transizione, come ti è capitata a te, cioè ti sei staccato volontariamente dallo scrivere codice o avevi troppo codice da mantenere, da gestire e quindi non avevi più tempo per scriverlo, perché poi alla stessa maniera la community intorno a Fastify evidentemente è cresciuta e ha cominciato...Normalmente è questo, principalmente è questo, nel senso che principalmente faccio il review di codici di altri perché ce n'è talmente troppo che appunto normalmente quando fai un bug report a fastify ti chiedo "fixatelo, fixatelo".Questo è un po' la self serve, è open source self serve, support self serve, fixatelo, arrangiati.Brutto da dire ma non paghi e quindi se paghi te lo fixo, se non paghi non te lo fixo.La linea è quella.Sappiatelo.La linea è quella lì.A livello di community, oltre alla gestione del codice, ci sono altre cose che un maintainer deve fare? Talk, documentazione, sito, promozione, moderation, code of conduct, partecipazione in gruppi standard di altro tipo eccetera eccetera.Comunque tornando al codice, sto lavorando a Fastify v4 al momento, in realtà non lo vedi molto, ma fino a qualche settimana fa poi mi sono fermato perché ho dovuto fare altro.Ho lavorato nello sviluppare Pino, la nuova versione di Pino perché è tutta una catena, capito? E quindi c'è la catena che ci vuole la versione nuova di Pino e la versione nuova di Pino richiede una...la versione nuova di Pino mi richiede un...abbiamo cambiato una feature, abbiamo aggiunto una feature nuova che consentire lo sviluppo, il transito dei dati verso le destinazioni, transport, eccetera, usando un worker thread.Ho scritto un modo che si chiama thread stream, se guardate il codice è abbastanza denso e impegnativo e quindi magari ho scritto questo pestettino di codice che è fatto da Enabler per tante altre cose.Il problema è che non si vede le mie attività di scrittura di codice perché viene perso in una marea di GitHub pull request issue che gestisco.In realtà c'è, è solo che non si vede poco rispetto al resto, ma perché spesso e volentieri il resto lo faccio dal cellulare o dall'iPad o mentre sono in un meeting un po' noioso.Confermo di averlo visto a colazione in hotel durante una trasferta a scrivere.Insomma aveva l'iPad davanti e stava scrivendo quindi fosse stato anche una full request.Era una git blame, io lo so.Quando uno dice che lo verrà in successo è fatto anche di 16 ore di lavoro.Ecco, spesso e volentieri è questo.In generale l'altra cosa è, per l'ultima settimana ho lavorato sul rilascio di node 16 e quindi c'è stato un problema importante relativo alla prestazione di HTTP, per cui c'era stata una regression da panico e invece che ho lavorato come un 20% di prestazioni perse, lasciateli sul tavolo, ecco.Ho lavorato come un matto per capire cosa fosse successo.Sono venuto fuori 4 o 5 pull request, alcune mie, alcune di altri, insomma è stato un po' il lavoro anche di di concerto, ma alla fine siamo riusciti a riportare Node 16 alla stessa velocità di Node 14, cosa che è stato per me un gran traguardo, che è tra l'altro più veloce di Node 15, cosa che volevamo almeno ottenere questo, perché Node 15 era peggiorato in maniera importante nel tempo.per cui questo è tutto qua.Domanda nel tuo ventaglio di progetti e di librerie ne spicano diversi Pino, il Logger, Fastify, il Framework ma c'è anche Autocannon che ha in qualche modo attirato la mia attenzione.Cosa fa e come è nata l'esigenza di realizzare un tool come Autocannon? Come è nato? È nato che ci ho provato e ce l'ho fatta.Questo è nato.È nato che ero seduto sul divano e in realtà dovevo preparare un corso sulle performance in ambiente Windows e dovevo far installare un load tester in ambiente Windows, qualcosa che si installasse facile e non richiedesse l'allineamento della luna.E a un certo punto mi sono chiesto "ma non lo scrivo in Node? Ho provato con il modulo HTTP, il modulo HTTP era lento come un paracarro e quindi ho iniziato a lavorare con, ho iniziato a giocare un po' con un po' di pezzi di codice, ho visto che in realtà poteva essere molto veloce e ho capito dove era lento il client HTTP di Node e ho creato appunto questa libreria che si chiama AutoCannon per fare l'hottesting da Node.js, esiste, è lì.Altre librerie in altri linguaggi sono forse un po' meglio in termini prestazionali, però funziona molto bene, supporta anche alcune feature che altri non supportano, quindi anche lì è una questione di buono o cattivo, nel senso che dipende da quello che ti serve.AutoCannon però è molto veloce e l'ho scritto perché mi serviva.Dopodiché anche altri l'han trovato utile, l'ho continuato a manutenere e il fatto che sia programmabile in JavaScript, è molto semplice da manutenere, è qualcosa che per me è fondamentale e quindi l'ho trovato molto molto utile dal mio punto di vista manutenerlo.Dopodiché tanti altri ci hanno messo le mani sopra.Diciamo che vive un po' della sua piccola community di gente che gli piace questa roba.La cosa interessante è che il learning che ho fatto su AutoCanon in realtà è confluito in un altro progetto che mi piace molto parlare, si chiama Undici, che è una libreria open source, è il nuovo HTTP client di Node.js che è appunto nato sullo stesso divano sostanzialmente, è nato con gli stessi principi, poi si è evoluto enormemente, tanti altri anche qui ci hanno messo le mani, stiamo preparando la versione 4, è più veloce, più stabile, più rispondente alle specifiche HTTP di quello di Node Core, in teoria è semplicemente meglio di quello di Node Core.Come scriveremo il client HTTP di Node Core se lo potessimo scrivere oggi? Funziona molto bene, devo dire la verità, l'abbiamo usato in produzione in tantissime circostanze, è molto più affidabile di quello di Core ad oggi.Quindi aggiungeremo altre feature, per esempio già integrato il sistema di mocking, cosa che tante cose non è un add-on basato sul monkey patching che fai dopo ma è qualcosa che è supportato internamente quindi puoi già moccare di tuo determinate rotte se le vuoi moccare per i test.Il supporto ai redirect nell'ultima versione il Httpverse si basa su WASM, Sclatting Web Assembly per darvi un'idea dell'idea della complessità anche di alcune cose e supporta il pool di connessioni supporta il Keepalive live ed è performante.È stata fatta di recente un benchmark, abbiamo addirittura una libreria sopra che si chiama 11fetch che è l'implementazione della libreria fetch sopra, ha 11 che mi sembra una volta e mezzo o due volte più veloce di nodefetch, qualcosa di questo tipo.C'è una misurabile differenza tra i due e tra l'altro anche di affidabilità perché appunto è un client che è genericamente più affidabile di Cordo.Quindi il ventaglio di librerie sono grandi.Io voglio farti una...Scusate, qua a casa sta succedendo il finimondo.Non solo da te, quindi dobbiamo...Siamo tutti chiamati alle rispettive famiglie, mi sembra.L'ultima domanda molto rapida, questa domanda se Leo o Mattia hanno qualche altra domanda, rapidamente, giusto uno shot perché questa cosa la sto chiedendo a tutti per farmi un'idea, non ho ancora le idee chiare.E forse anche una provocazione questa, però è una cosa che mi sta girando in testa da un po'.Oggi buona parte del nostro codice risiede su GitHub, quindi diciamo che GitHub è un accentratore di knowledge, che quindi diventa un pillar fondamentale per la distribuzione e la custodia dell'informazione anche in un' ottica di futuro.Pensi sia un pericolo che questa custodia sia unica centralizzata ed appartenente a un'unica società per il mondo open source? Bellissima domanda, grazie.Mi piacerebbe essere bello, anarchico e naivo e dire che è il male assoluto e che bisogna spostarci tutto in maniera decentralizzata.La realtà è che la community open source in generale si basa sulle cose gratis e quindi se non paghi per qualcosa tu sai il prodotto che qualcun altro vende.È evidente che qualcuno ci debba guadagnare dall'avere tutte queste librerie.Il problema principale è che cosa avrebbe Microsoft da perdere nel chiudere GitHub? Parecchio in realtà, le cose più grave difficilmente il modello cambierà, anzi la cosa più possibile è che GitHub si pieghi a voleri di, e Microsoft si pieghi a voleri di governi di varie affogge colore per semplicemente motivi di business cioè essere lì.Non lo so, la risposta giusta è che bisogna guardare al ciclo economico del valore e ad oggi non c'è una soluzione migliore di questa.Sì questa domanda mi viene da quello che è successo a PHP qualche giorno fa.gestivano i loro server github in casa hanno avuto una grossa vulnerabilità e un attacco e hanno deciso di migrare tutto verso github e mi chiedo a quel punto stai centralizzando tutto su un'azienda che per quanto sia apprezzabile lo sforzo di microsoft negli ultimi anni verso l'open source stai comunque mettendo in mano tutto il knowledge di un periodo storico? certo però ad oggi non c'è c'è alternativa.La domanda è se non fai così che cosa fai? E la risposta oggi non c'è.Chi ti dice che siamo tutti distribuiti, decentralizzati e ci scambiamo cripto, spesso e volentieri si sta scordando di qualcuno che queste cose non le fa e gli consente a a lui di fare quello che fa.Da qualche parte i server devono girare, qualcuno li paga, chi li paga? Che cosa ci guadagna? Quindi in pratica chi ti dice che si ospita tutto nell'internet decentralizzato ti sta dicendo che qualcuno sta finanziando l'ospedale.Qualcun altro, che tu magari non sai o non vedi, sta finanziando l'hosting di questi repository, se stessero da qualche altra parte.Non credo che si possa avere più di una sola azienda che faccia questo, c'è un effetto rete mostruoso è un po' come Facebook o Instagram o Twitter, non esiste avere un'altra platform che fa la stessa cosa, è un settore che porta al monopolio e per quanto GitLab ci stia provando in maniera egregia e stia facendo un ottimo lavoro, però è un settore di monopolio, quindi che porta molto al monopolio.Per cui alla domanda che cosa vorresti fare altrimenti, forse GitLab, sì potenzialmente potrei metterli su GitLab gratis.Che vantaggio ho? Sostanzialmente nessuno, stanno in mano a un'altra azienda, non la trovo particolarmente una cosa interessante da questo punto di vista.Praticamente è la conclusione alla quale sono arrivato anch'io.Se ci fosse una soluzione, in una soluzione ottima avremmo un'economia di scala differente per cui gli utenti di una libreria open source ti pagano dei denarini, che vanno a contribuire al pagamento di un hosting per questa piattaforma, alla CIA e a tutti i costi associati.A quel punto tu hai un prodotto commerciale che si sostiene e paga il suo hosting e paga le sue cose.Ma fin tanto che è gratis qualcuno deve pagare.Quindi se qualcuno deve pagare vuol dire che quello che metti lì sei il prodotto.Però se posso aggiungere due cent e cercare di vederla un po' costruttiva, secondo me il fatto che il materiale che sta su Github sia open source e con tutto quello che comporta fa sì un po' di più che nel momento in cui l'azienda che lo gestisce diventa completamente evil ed è necessario per tutti spostarsi su un'alternativa, è un po' meno complicato rispetto ad altre piattaforme, per come la vedo io, nel senso che se penso a piattaforme che hanno lo stesso network effect di cui parlava Matteo, come Facebook o Twitter, e quindi a un certo punto diventano monopoliste.Mi sembra difficile spostarsi da lì a un'alternativa nel momento in cui Facebook di turno diventa full-level, mentre farlo con dei progetti open source mi sembra un pelo più semplice.- Spero di no.- Guarda, adesso...Ti dico di recente cosa è successo, ok? Una community di cui io sono parte, una community storica del mondo Node, la community level, non so se avete mai sentito parlare, modulo che si chiama Level, LevelDB, LevelUp, qualcuno ne avete sicuramente visto un talk nel passato remoto.È un database embedded per cui ti puoi tirare su il tuo piccolo Key Value Store embedded in Node usando LevelDB.Funziona benissimo tra l'altro.Questa community non ha molti maintainer, ecco, in generale.È una cosa un po' storica, è nata, abbiamo fatto l'unico meetup della community Level al NodeConf U 2013, ci stiamo parlando di un po' di tempo.Tutte le persone in quella riunione, in quella call, sono tutte persone fondamentali della community JavaScript dell'epoca, quindi c'eravano tutti lì dentro.Era l'innovazione.Tra l'altro abbiamo anche inventato il modello di governance di NodeCore all'interno di quella community, quindi proprio è stata un incubatore di quello che è Node oggi, è un pregresso di quello che è Node oggi.Questa community si basava per tutta l'integrazione, tutta parte di CI con su Travis.Non so se conoscete Travis, se l'avete usato.Travis è diventato completamente evil, è stato acquistato da qualcuno e l'ha trasformato in un prodotto interamente evil.Per tenere su Travis e fare gli ultimi rilasci che abbiamo dovuto fare nell'ultimo periodo, abbiamo...c'è stata una fattura importante su Travis che Travis ha mandato sulla carta di di uno dei collaboratori, perché appunto il numero di runner che serviva non era adeguato a tenere in piedi la baracca.Vi chiederete perché non siete passati a un altro servizio gratuito? Perché richiede lavoro? Il lock-in è nel lavoro delle integrazioni.GitHub, se infatti vedete, ha aggiunto le actions, ha aggiunto le app, ha aggiunto e non è facilissimo spostare le issues per esempio o le pull request.In realtà tu credi di poter tranquillamente uscirne in maniera facile, ma richiede uno sforzo che molti progetti open source non possono, non hanno il tempo di fare, cioè è lavoro noioso per cui non vuoi farlo.Quindi in realtà le possibilità di spostarsi sono bassissime.Altissimo.Non avevo considerato tutto il lavoro che c'è dietro perché io la pensavo rispetto a una cosa che è successa recentemente nell'ecosistema Java con Jcenter, che è un repo di artefatti come può essere l'EPM, che ha chiuso manualmente e quindi da lì bisognava spostarsi altrove e nella maggior parte dei casi era relativamente semplice.Però è in effetti un caso...è un lavoro? No, è un lavoro insieme.Cioè il problema è...quello che devi fare che adesso sta solitamente.Esatto, ma è un lavoro.Fintanto che non diventa totalmente o evil, per cui è sopportabile, deve chiudere.Deve avere la spinta a chiudere.Se non si chiude non arriviamo al risultato.piccola interruzione per ringraziare i donatori di questa settimana in realtà saverio menin ci ha offerto una birra quindi lo ringraziamo sto andando alla ricerca del messaggio che ci ha scritto perché se non ricordo male ha lasciato un messaggio esatto il messaggio è complimenti quindi grazie saverio per averci offerto questa birra e cin cin ragazzi qualche altra domanda - Se fossi io, ho la mia ultima domanda, che mi è venuta in mente quando parlavate di Autocannon e di Undici.Nel senso che in entrambi i casi tu hai detto "poi altre persone sono intervenute, ci hanno messo le mani e i progetti hanno preso un po' la loro strada".È una domanda che ti faccio da maintainer di un progetto open source su cui vorrei che qualcuno mettesse le mani.Nel senso che ho dozzilioni di show aperti e mi farebbe a comodo delle pull request.come la incentivi questa cosa? In generale normalmente io chiedo alla gente che fa le app reissue di fixarsele.Quindi io ho imparato purtroppo per storie passate personali che ad aiutare la gente gratis non ci si guadagna niente.quindi per quanto mi piace condividere le cose che faccio eccetera non posso aiutare tutti.Se un bug mi interessa lo risolvo e se mi piace aiutarlo ti aiuto ma non c'è alcun tipo di responsabilità per me nel dover risolvere tutti i bug che arrivano quindi io non li risolvo e ti chiedo se usi sto software non lo paghi giustamente e fixalo.Il minimo che puoi fare risolviti il tuo problema se no non è un problema compelling non è un problema abbastanza sentito per portare a risolverlo ok sostanzialmente non so se mi spiego sulla metici dell'effort tu puoi al massimo le dritte te le do però intanto dimostrami che a un dimostra che sei serio dimostra che sei serio e questo ti crea una community perché fin tanto che tu fai l'accentratore e dici sono l'unico che risponde ai problemi, poi non deleghi mai nessuno.Invece i contributor te li devi far crescere.Per cui una volta che vedi che una persona ha mandato un po' di pull request, ha mandato, ha collaborato un po', ha risolto un po' di bacchi, gli dai il commit bit, lo fai entrare come maintainer.E a quel punto la cosa si autoalimenta perché poi lui lo farà...cioè hai creato una community che si autoalimenta sostanzialmente.Per cui se lo continui a fare e lo crei come valore fondante della tua community, in realtà hai un modo per assorbire nuovi collaboratori all'interno del gruppo.E a quel punto passi da 1 a 2 che è un passaggio enorme, non è come passare da 20 a 21.Prima di lasciarti, l'ultima cosa ti prego, so che tua moglie poi verrà a picchiarci.Eh, sono… Anche la mia.Il Paese dei Balocchi, il nostro momento dove condividiamo con gli ascoltatori un libro, un video, qualunque cosa abbia segnato e caratterizzato la tua esperienza lavorativa.Hai qualcosa da proporci? "E conduco nel paese dei balocchi" "Ah, il paese dei balocchi" Se non l'avete letto dovete leggerlo tutti.Sostanzialmente il miglior libro di software development degli ultimi dieci anni.È fenomenale, è un approccio completamente diverso rispetto allo sviluppo software di come ne avete sentito parlare.è bellissimo e vi dice come fare software fatto bene ecco e cosa in poco qual è la cosa più importante e non sono gli story points io voglio aggiungere un altro balocco rapidamente è adventure in node land che è la nuova newsletter di matteo che è sempre così modesto non parla dei suoi progetti è una newsletter bellissima mi raccomando se non l'avete fatto iscrivetevi.Un'altra cosa scusate sono te che hai detto la NearForm e stiamo assumendo come dei matti ecco stiamo assumendo tanta gente in questo periodo quindi se volete lavorare con noi nearform.com/careers ci sono tante posizioni aperte quindi veramente venite.Matteo, io non so come ringraziarti a nome mio, a nome di Leo e Mattia, che possono ringraziarti anche personalmente, ma anche a nome di tutta la community.Grazie per averci dedicato questa abbondante ora e mezzo.Da oggi Git Bar è anche un po' il tuo bar, quindi quando vuoi berti una birra con noi, vieni pure a trovarci.sempre un bicchiere in fresco per te.Grazie mille, ciao ciao ragazzi! Ciao ciao! Ciao ciao! Gitbar, il circolo dei full stack developer.Una volta a settimana ci troviamo davanti a due birre e combrir repo, parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.[Musica] [Musica]
