Bene e benvenuti su github nuova settimana e nuovo episodio Oggi abbiamo un ospite speciale però come sempre io tengo il segreto E intanto prima di presentarvi l'ospite vi presento un padrone di casa ciao leo come va tutto bene E ciao anche al nostro ospite segreto so che eri in preparazione per un talk giusto per il laravel day è possibile? Sì, fatto stamani, è andato tutto bene, 100% live code, dove non ho fatto niente proprio a parola, però i dei delle demo mi hanno premiato.Ah, fantastico.Ti chiedo solo la cortesia di spegnere la cam, perché io, come ormai sai, sono in una condizione internet iperprecaria, e quindi è meglio così.quindi è andata alla grande, fantastico.Cos'hai portato? Ho parlato di Laravel Blade, siamo andati a vedere come funziona anche negli internals di Laravel quindi spuntiamo il tag PHP anche per questa puntata di Ipad e lo abbandoniamo e passeremo ad un altro argomento in realtà so che in fondo tu hai un doppio amore, sei poligamo ami JavaScript, ami PHP insomma - C'ha detto che hamo java script, aspetta, questo non l'ho mai detto - Te lo dico io - Ok, forse l'ho detto qualche sera fa - Eh, però prima di presentarvi il vero ospite della puntata, devo ricordarvi i nostri contati, info@gitbar.it o @brainrepo su Twitter, sono i modi canonici per contattarci E poi abbiamo un modo più moderno, mi aspettavi che dicessi questo, un modo più moderno che sarebbe il canale Telegram In pratica Brain Refo non vi risponde né su Twitter né via email, c'è solo su Telegram, mettiamola così, va bene? Esatto, su Telegram ci trovate aprendo il vostro client Telegram e scrivendo GitBar, di lì entrate sulla nostra community, un pozzo nero dove ci sono tantissime chiacchiere e siamo quasi 500, credo ne manchino una o due persone ad oggi, quindi stiamo crescendo a vista d'occhio.Se non l'avete ancora fatto mi raccomando fatelo perché credo che sia il posto migliore dove confrontarsi, una sorta di barra a tutti gli effetti.Comunque, bando alle cianci, io direi che possiamo iniziare.Benvenuti su Gitbar, il podcast dedicato al mondo dei fullstack 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.Oggi abbiamo ospite con noi Nicolo Ribaudo, di giorno studente di matematica, di notte maintainer di uno dei progetti open source più famosi in assoluto un progetto che ha solamente 32 milioni 200 mila spanne di weekly downloads quindi stiamo parlando di Babel JS ciao Nicolo ciao Mauro grazie per avermi invitato qua oggi grazie a te di essere venuto da noi a trovarci intanto c'è una birra fresca per te visto che essendo un bar qua la birra mai manca.La prima domanda che voglio farti è ad oggi chi è Niccolò? Niccolò è un po' di cose come detto sto studiando adesso e lavoro a Babel, non è tutto quello che faccio sono anche diciamo sto anche lavorando ad altri progetti all'interno di JavaScript contribuendo di più al linguaggio di per sé negli ultimi mesi e al di là di questo sì comunque la mia cosa preferita probabilmente quello che studio quindi la matematica che so che a molti in realtà non piace.E hai aperto un capitolo.Intanto credo che la matematica non piaccia, almeno non piaccia finché non ci si fa rapire dalla matematica.Una volta che la matematica rapisce credo che ci siano ben in poche vie di scampo.Allora la mia domanda è una cosa secondo te porti del mondo della matematica nel codice che scrivi? Probabilmente più che nel codice che scrivo lo porto in come penso che dovrebbe essere fatto il codice quindi negli aspetti più teorici che ci stanno dietro io sono appassionato di algebra di logica e sono concetti che ritrovo poi applicati praticamente nel codice, nelle discussioni sul codice che faccio normalmente.Mi piace ad esempio molto la programmazione funzionale, anche se forse è un po' banale dirlo, essendo che mi piace la matematica, ma mi ritrovo anche a cercare di fare magari trovare strutture matematiche in magari stranezze del linguaggio, riuscire a spiegare perché una certa cosa ha senso anche matematicamente parlante o quando potrebbe sembrare che in realtà non ne abbia assolutamente.Essendo che lavoro in JavaScript so che ci sono moltissime parti del linguaggio e che la gente possa sembrare che non abbiano senso.Quindi mi piace riuscire a spiegare, a trovare un senso in quello che sembra non averne.Aspetta, ho una domanda.Quindi te riusciresti adesso a fare la matrice dell'uguaglianza tra i vari tipi di JavaScript senza vederla intuendo come funziona, oppure anche quella è un'incognita anche per te? Una parte, forse.Diciamo che...La diagonale, quella dove è sempre...La diagonale, ovviamente.poi alcune cose magari non so proprio se una cosa viene convertita prima in un numero o prima in un booleano, non so esattamente l'ordine delle cose.Siamo tutti sulla stessa barca? No.Ti è mai capitato di avere...allora tu dici io riesco a utilizzare alcuni modelli per capire alcune stranezze del linguaggio.Una parte del nostro lavoro è anche la comunicazione.Questi meccanismi, no? Questo portare la matematica nel linguaggio, ti viene agevole raccontarlo, spiegarlo ai tuoi colleghi, co-contributor o hai difficoltà a trovare dei meccanismi per comunicarli in modo fruibile? Allora, in realtà ritengo che non sia il modo più accessibile possibile del parlare di un linguaggio, del parlare di informatica, quindi tendo a utilizzare una certa terminologia, un certo modo di strutturare i miei pensieri e argomenti solamente quando parlo con persone che per prime utilizzano questo modo di comunicare, se no normalmente cerco di evitare il più possibile gli aspetti più teorici e mostrare o parlare degli aspetti più pratici di un linguaggio o di un programma scritto in tale linguaggio.Sai cosa mi stupisce però del fatto che da matematico hai approcciato a JavaScript che in realtà è un linguaggio che...prima hai parlato per esempio di programmazione funzionale, sì si può fare, però per esempio essendo un linguaggio non tipato tutta la parte dell'algebra sui tipi, non si può fare.Perché hai scelto JavaScript? Allora, JavaScript probabilmente l'ho scelto prima di appassionarmi alla matematica.Almeno mi piaceva già la matematica, ma non avevo idea di cosa fosse la matematica, diciamo, vera, la matematica bella.Perché io ho iniziato a programmare JavaScript quasi per sbaglio quando ero ancora piccolo.Sì, posso dire piccolo, perché ero forse in terza media.un mio amico mi aveva convinto a creare un competitor per Facebook.Non abbiamo assolutamente avuto successo, però così mi sono avvicinato alle linguaggi del web e alla fine JavaScript è quella a cui mi sono più affezionato.E allora, visto che comunque oggi col tuo bagaglio di know-how utilizzi JavaScript, secondo te cosa manca dalla tua prospettiva, dalla tua visione e con il tuo bagaglio di competenze? Cosa manca a JavaScript? È una domanda difficile perché io a me piace, potevo pensare a cosa manca al linguaggio, cosa bisogna aggiungere al linguaggio e sto personalmente lavorando ad alcune possibili funzionalità che mi interiano molto.Quindi io subito così ti direi quello che manca sono il pipeline operator, ossia diciamo tradizionalmente nei linguaggi funzionali hai un operatore binario per applicare le funzioni, diciamo scrivendole in modo lineare anziché una all'interno degli argomenti dell'altra e strutture dati mutabili fatte bene, quindi supportate nativamente dal linguaggio, che sono due delle cose a cui io sto lavorando di più affinché vengano alla fine introdotte.Direi queste due, probabilmente ci sono molte altre cose che mi farebbe piacere avere, ad esempio essendo appunto che mi piace la programmazione funzionale mi piacerebbe tantissimo un operatore di composizione di funzioni o una sintassi dei nuovi operatori, della nuova sintassi più simile a quello che si può trovare nei linguaggi come magari Haskell o simili.Però capisco che non centrino molto con quello che è JavaScript adesso e quindi potrebbe non essere una buona idea effettivamente immaginare come sarebbe JavaScript con queste altre funzionalità.E tutto l'ecosistema dei tipi invece? Ne hai mai sentito l'esigenza? Ti sei mai sentito attratto dal mondo TypeScript? Sì, io uso TypeScript.Anzi, proprio in questi mesi, forse, stiamo migrando, ad esempio, tutto il codice di Babel da Flow a TypeScript.molto lentamente perché siamo riusciti a permetterci una migrazione graduale quindi avendo certi file in Flow e altri file in TypeScript e mi piacciono, almeno ritengo effettivamente utili i tipi e soprattutto in grandi progetti mi aiutano tantissimo.TypeScript devo dire che non è il mio preferito perché almeno da un punto di vista teorico TypeScript non è il mio preferito perché non ha certe garanzie, certe garanzie di correttezza formale, è ad esempio Flow Up o ci sono delle altre cose, uno nuovo si chiama Hagel che è il formalmente più corretto di tutti, tuttavia TypeScript pur non essendo teoricamente corretto è quello con cui riesco ad essere più produttivo perché è quello con un che funziona meglio e quello con dei tipi che magari apposta cercano di non essere del tutto corretti per non rompermi le scatole mentre cerco di utilizzarlo.Chiaro, chiarissimo.Beh, citando TypeScript, sento molto l'impatto della parte funzionale.Io, come ormai gli ascoltatori sanno da wannabe functional developer, completamente incapace questo.lo devo ammettere, ho sempre guardato con particolare attrazione TypeScript per la sua tutto sommato semplicità perché in realtà ho percepito che non snatura troppo il JavaScript che ci sta sotto come altri altri linguaggi come può essere Reason, ML o simili e allo stesso tempo ti permette di fare delle cose che in qualche modo ti fanno un po' portare la codebase verso una situazione pseudo funzionale.Naturalmente sotto il cofano abbiamo sempre javascript quindi alcune cose come dici tu formalmente corrette a runtime potrebbero non esserlo giusto? Tuttavia, in teoria, programmando in modo funzionale non hai bisogno di qualcosa che controlla il run time, con un codice lineare nel senso relativamente semplice in ogni sua piccola parte, dovrebbe essere sufficiente avere dei tipi statici che garantiscano che tutto è corretto, matematicamente.Io proprio devo essere becerissimo quale sono solitamente.Una cosa che mi mancava e che mi manca tantissimo è un modo facile, veloce e rapido per fare un buon pattern matching con TypeScript.Forse sarò io malato, ma...Vero, e tra l'altro c'è una proposta per JavaScript, per una nuova funzionalità che probabilmente è tra le più amate, tra quelle che ci sono adesso, che si occupa di appunto introdurre un costrutto per fare pattern matching.Ah, fantastico, non lo sapevo.E tra l'altro io ritengo che queste cose appunto debbano essere introdotte in JavaScript e non in TypeScript.Idealmente io vorrei vedere TypeScript proprio solo come JavaScript con aggiunti tipi e non con altre funzionalità.Concordo, però credo che in realtà il pattern matching abbia a che fare anche quei tipi, vabbè, tu dirai, col duck typing, forse boh...Sì, sì, si basa proprio su quello la proposta che c'è, perché è l'unico modo in cui effettivamente lo si può fare in JavaScript.E poi soprattutto il pattern matching è una cosa comunque molto complessa, per cui averla in un linguaggio che tu poi devi compilare javascript e quindi non avrai il rossoportato nativo rischieresti di avere delle performance pessime perché devi introdurre molta complessità nel codice javascript mentre se è una funzione interattiva del linguaggio lo implementi magari in C che su certe cose funziona meglio.Chiaro, chiarissimo.usciamo per un secondo dai tecnicismi ma vi prometto che ci rientriamo e proviamo a capire un po' in realtà la mia domanda ha proprio quell'obiettivo il percorso che si fa da prima da classico sviluppatore poi contributor e poi maintainer di una libreria open source nel tuo caso di una mega libreria open source qual è il percorso il sentiero che hai battuto, quanto tempo ci hai messo e quanto effort nel percorrerlo? Allora, io ho diciamo il difetto che non sono in grado di creare un progettino mio, mi annoio, mi stufo nelle fasi iniziali, mi piace molto di più trovare del codice scritto da altri, già funzionante, e lavorare su quel codice già esistente, perché diciamo le fasi iniziali prototipazione, non mi sento attratto da quella parte dello sviluppo.Per cui poco dopo avevo finito quel progetto che avevo detto prima, che avevo fatto con un mio amico che mi aveva fatto avvicinare al JavaScript, io subito, non mi ricordo esattamente come, ma ho scoperto dell'esistenza di questo mondo open source, forse tramite plug-in jQuery, ma non ne sono sicuro.e ho avuto quindi l'occasione di lavorare a codice non mio, ma di lavorare a codice di altri.La prima cosa che ho fatto era stata aggiungere, credo, delle funzionalità alle cose che utilizzavo tutti i giorni.A quei tempi usavo l'editor Adobe Brackets, non so se lo ricordate.Sì, penso...l'ho visto, però non l'ho usato perché...Mi ricordo che avevo iniziato contribuendo ad alcuni plugin per quest'editor traducendoli in italiano e perché avevano magari supporto alle traduzioni e mancava l'italiano allora io ho detto "questo è qualcosa che posso fare" e l'ho fatto e così ho iniziato a capire più o meno come funzionavano le cose su github che è la piattaforma su cui passo la maggior parte del mio tempo.Da lì poi sempre spostandomi di progetto in progetto ho continuato a contribuire a cose che io stesso utilizzavo.Ad esempio per un po' ho contribuito a JS hint che era un linter per javascript che non so quanto sia ancora utilizzato ma era molto utilizzato un po' di anni fa.Poi ho iniziato a imparare altre cose, a un certo punto mi sono ritrovato ad utilizzare bubble e ricordo che avevo provato a fissare un bug in bubble, non un bug che avevo trovato personalmente o che mi creava problemi personalmente, però avevo ormai capito che mi piaceva così contribuire a progetti open source, mi piaceva contribuire anche a progetti grandi perché sono alla fine quelli che ti danno più gratificazione e ho provato a sistemare questo bug e alla fine è stato chiuso la mia pure quest dicendo questo è il modo sbagliato per farlo e mi sono un po' demoralizzato.Dopo un anno ho provato di nuovo, ormai erano cambiate le persone che ci stavano dietro e forse anche ero migliorato io, almeno nelle mie capacità di fare quello che serviva.Dopo un po' che contribuivo così da esterno mi è stato poi chiesto se volevo entrare nel team e da lì è iniziato il mio percorso all'interno di Babbel.Vabbè, volevo chiedere una cosa.Vai, Leo.Quando hai parlato, mi sono ritrovato molto quando hai detto "non sono attratto dal scrivere codice da zero, ma preferisco contribuire a qualcosa".Io ho la stessa, diciamo, poca attrazione, più che altro perché al di là di quando si va a mettere codice pubblico, ci si espone molto, quindi si espone anche le nostre skill tecniche.Ho un po' un blocco perché dico "ok, c'è 100.000 modi di farlo, questo potrebbe essere il più sbagliato" e sto facendo vedere a tutti che sto sbagliando.Mentre se mi appoggio a qualcosa di già fatto, non posso, diciamo sì, mi possono chiudere la pull request, però insomma mi baso su qualcosa, anche su un certo tipo di sintassi che i "grandi" hanno messo.Anche te hai questa sensazione o ci sono altri motivi? No, più che altro il mio problema è che se l'obiettivo è lontano, diciamo mi perdo, inizio magari a divagare su altre cose e alla fine non raggiungo mai l'obiettivo che mi avevo prefissato, se questo è troppo lontano.Iniziando un progetto da zero è sempre difficile esattamente vedere dove si arriverà.Su quello che ricevi, in realtà, ti dico, io ho visto tantissimo codice open source perché lavorando a Babel mi capita spesso anche di dover magari toccare dei progetti che in qualche modo interagiscono con Babel o magari della gente ha dei problemi con Babel nel loro progetto e allora io vado a vederlo.E ti garantisco che quando si trova del codice che magari è scritto male, chi legge il codice pensa "magari sono solamente io che non capisco cosa sta succedendo", non si pensa "chi ha scritto questo codice non ci capisce niente".Sì, sì, è vero.Come dire, siamo in tanti a vedere quel codice, tutti pensiamo la stessa cosa ma nessuno lo dice.Dice "Vabbè, se è lì forse l'ha fatto così e sono io che non conosco questa super tecnica".Esatto.E allora mi state portando a fare una domanda che in realtà sto facendo un po' a tutti questo periodo, anche perché sto provando a capire le varie tecniche.Leggere codice di altri.Il codice, alle volte, può anche essere contenuto in un progetto grande, enorme, la cui struttura e la cui architettura non necessariamente è documentata alla perfezione.E allora, Nicolò, la mia domanda è come ci si orienta in queste codebase così gigante, giganti? Allora, la risposta è che non ci si orienta, almeno.Quando io ho bisogno di entrare in un progetto che non conosco ancora, di solito c'è magari un motivo per cui ci devo entrare.C'è qualcosa che non funziona o non capisco perché qualcosa fa così.Quello che faccio io è subito, magari ancora prima di leggere il codice, se è un progetto che ho clonato in cui devo scrivere qualcosa, subito provo a eseguire magari una demo e faccio partire un debugger, un po' a caso.Ho tirato un pugno al tavolo, scusate.Capisco benissimo.Parto un po' a caso e a un certo punto mi stoppo quando magari, soprattutto se c'è un problema che devo risolvere, c'è magari un errore, vedo più o meno dove devo stopparmi, dove almeno la zona in cui devo partire.Mi fermo lì e capisco solamente quella zona.Tutto il resto del codice, scatola nera, spero di non doverlo guardare.Mi ricordo che quando ho iniziato a contribuire a Babel, in realtà per fortuna Babel è un'architettura relativamente facile da approcciare perché è strutturato in tantissimi pacchetti, tantissimi plugin.Mi ricordo che io avevo iniziato a...ad esempio c'era un bug nel parser, quindi quello che legge il codice e capisce, diciamo, cosa significa.e mi sono fermato lì dentro per magari sei mesi.Tutto il resto del codice ho fatto di tutto per evitare di guardarlo.Una volta che mi sono trovato a mio agio con la piccola parte che conoscevo, ho iniziato lentamente a espandermi in parti strettamente correlate.Poco per volta così poi sono arrivato ad aver visto tutto il codebase, però è stato un processo molto lento e all'inizio io sempre mi chiudo in una piccolissima parte e spero di poter rimanere lì dentro il più possibile.Chiaro, un po' come quando vai a bere in una città enorme e magari vieni in una città più piccola che dici "ok, come faccio a orientarmi qua?" Beh, intanto uno comincia a frequentare il proprio quartiere e poi dopo viene quasi naturale capire come funziona la città, ora mi è venuto in mente questa...questo paragone.Cioè, inutile stare a dire "ok, adesso faccio tutte le strade così so che qui c'è questo, qui c'è quest'altro, uno non avrebbe il tempo e poi dice "ma che senso ha?" Esattamente.Quindi a livello di onboarding, alla fine semplicemente una good first issue e provare a orientarsi, niente di più? Allora, quello che faccio io, essendo che comunque mantengo un progetto così grande, cerchiamo sempre di attirare nuove persone che contribuiscano.Ogni volta che c'è un bug, magari relativamente semplice da sistemare, magari che per me sarebbe una cosa quasi banale, perché io conosco esattamente già come è strutturato tutto il codice, so esattamente dove andare a vedere, quello che faccio è indicare dove è il problema e lasciare che qualcuno che magari ha poca esperienza o ha zero esperienza, sapendo il punto nel codice dove potrebbe essere il problema, magari il file o la funzione, possano da da soli a esplorare un po' quella funzione o quel file così da non dover capire dove iniziare.Io faccio però solo questo e poi lascio sempre che siano loro un po' ad giustarsi e capire dove mettere le mani lì dentro.Chiaro.Allora c'ho un'altra domanda perché alla fine quando si diventa maintainer di un progetto, specie se il progetto è molto grande, comunque bisogna confrontarsi con delle altre persone.Spesso la comunicazione con altre persone diventa un lavoro molto impegnativo.Mi è capitato di vedere in diversi progetti open source nei quali ho contribuito delle issue aperte che magari spottavano un qualche problema e chiedevano al mantenero, ai vari contributor, di fissarle con una comunicazione che ne so passivo aggressiva del tipo "questo bug c'è da x tempo, non è ancora stato fissato, perché non vi muovete, cose di questo tipo".Come ti approccia questo tipo di comunicazione? Allora, anche ci sono molte persone che minacciano "se non lo metti a posto io smetto di usare Babel".All'inizio un po' ci rimanevo male e magari davo loro retta, nel senso mi sentivo in dovere di effettivamente fare quello che mi dicevano perché avevo dei problemi con il mio progetto, con quello che lavoravo io.Adesso me ne frego abbastanza, soprattutto perché spesso, quando la maggior parte di questi problemi capitano, almeno la maggior parte delle persone arrabbiate o esasperate è perché magari hanno un piccolo caso limite che riguarda solamente loro, perché magari stanno usando il progetto non esattamente come dovrebbe essere usato e allora lì si prova a dire ok se non funziona anzi che così fai un attimo così e tinerò lo stesso risultato e dovrebbe andare bene lo stesso finché non è messo a posto.Cerchiamo diciamo di non ignorare mai almeno, una risposta la diamo sempre.Spesso però quando la gente è aggressiva ti passa anche la voglia di dare irretta e e magari il bug rimane lì e nessuno del team ha la forza mentale di metterci se sopra, di darla vinta a questa persona, dirle "va beh dai sei stata cattiva, ma comunque facciamo quello che ci chiedi".Sì, anche perché comunque si sta parlando di open source, quindi quello che tu stai chiedendo lo stai praticamente chiedendo dalle nostre parti, si dice "a conto di console", e nessuno lo paga.Allora a quel punto per esempio una buona tecnica che ho visto utilizzare è quella di "ok hai individuato il problema, ti posso dare qualche informazione in più, fai una pull request".Sì, anche noi adesso per tutti gli issue abbiamo un template che la gente deve compilare e la prima domanda e vorresti provare a risolvere tu questo problema e ho notato che da quando abbiamo aggiunto quella domanda la maggior parte della gente risponde di sì e molti di quelli che rispondono di no comunque magari si scusano quasi, dicono scusate ma non ho tempo perché credo che il problema è che la gente magari non realizza neanche che possono provare in qualche modo a sistemarlo loro.È un software che utilizzano gratuitamente e quindi non c'è nessuno che ha la responsabilità di fare questo lavoro al posto loro e quindi anche solo ricordandoglielo che c'è questa possibilità, molti si approcciano poi in modo diverso.Sì, pensavo al fatto che aprire una pull request o un issue gratis, uno clicca scrive due cose e va avanti, quando comunque gli chiedi di mettere un minimo sforzo cognitivo anche solo di riempire un modulo o se ne apre meno oppure si ha un po' più di consapevolezza e dire ok, ragioniamoci un attimo e allora forse uno in fondo in fondo è un po' più disposto a farlo, comunque si ferma due minuti a ragionare di quello che sta facendo, che fondamentalmente sta chiedendo a voi mettete un altro po' più di sforzo in questa cosa che uso gratuitamente.Esattamente, poi in realtà ogni volta che dico Babbel è un progetto gratuito mi sento un po' in colpa perché in realtà noi riceviamo donazioni, però non capita mai che chi dona si senta diciamo… di solito le persone che si sentono così più che hanno diritto al nostro lavoro non sono mai le persone che donano o che seguono il progetto, sono sempre tra virgolette sconosciuti.Beh sì, anche perché le donazioni sono la misura del vostro effort, ma non siete consulenti poi della persona che ha problema, specie se un edge case la persona se lo potrebbe risolvere, perché come diceva Leo, dimostra lo spirito d'iniziativa e disponibilità e anche importanza del problema che sta spottando, cioè se per me il problema è importante io mi siedo il sederino sulla sedia e mi ci metto a lavorare, poi farò del codice schifoso, farò una bella pull request Nicolò mi dirà "guarda hai sbagliato qua qua qua" e fondamentalmente mi sta facendo tutoraggio gratuito.Esattamente, tra l'altro anzi io preferisco fare così tutoraggio che sistemare il codice da me per due motivi.Uno è che magari poi questa persona che io aiuto rimane, rimane ad aiutare e due è che essendo che io non faccio solo questo tutto il giorno, comunque io studio, quindi magari faccio un'ora di pullman per arrivare all'università non sono sempre davanti al computer.Queste cose di aiutare le persone io posso anche facilmente farle magari da un tablet, da un cellulare, mentre per farlo io da solo di scrivere il codice devo essere a casa seduto su una scrivania con il computer davanti.Allora la mia domanda dopo tutta questa premessa è come ci si sente a essere il responsabile di un progetto così grande? responsabilità diventa schiacciante o ci sono delle tecniche per gestirla in modo salubre? Allora all'inizio era fighissimo perché ero magari diciamo il componente più nuovo, inesperto del team, quindi io non mi sentivo nessuna responsabilità su di me e mi sentivo solo di avere un impatto grandissimo.Adesso io sono tra le persone nel team che hanno più responsabilità.sono state controllate da me, mi occupo io di pubblicare nuove versioni e con tutta questa responsabilità in realtà spesso ho paura di sbagliare.È capitato ad esempio qualche volta che ho accettato una pure request, magari ho scritto io stesso una pure request che poi una volta rilasciata ha fatto un sacco di danni, ad esempio abbiamo fatto smettere di funzionare React Native una volta, un'altra volta abbiamo credo fatto smettere di funzionare Gatsby, che è un generatore abbastanza popolare per siti web, tipo Wordpress ma di JavaScript credo.E quando succede qualcosa di così, che magari ti svegli la mattina e c'è un issue su Github con 50 commenti e 100 pollici su, non è bellissimo.Per fortuna, quando succedono queste cose, tutte le persone con cui mi capita di interagire direttamente sono tutte persone che, bene o male, sono nella stessa situazione, perché io non interagisco con i loro clienti arrabbiati, ma interagisco direttamente con il progetto grosso che è capitato di rompere.E quindi sono sempre persone che mi capiscono e non mi fanno pesare il problema.Poi cerco anche sempre di ricordarmi che ogni volta che c'è un problema, le persone che hanno trovato questo problema avrebbero avuto modo di prevenirlo, ad esempio non aggiornando automaticamente Babel ma fissando nella versione nel loro package manager.Quindi alla fine sempre responsabilità condivisa e aiuta a diminuire la pressione.Ogni tanto però comunque capita che mi senta per una o due settimane completamente senza energie dopo che è successo qualcosa di molto grosso.Sì, anche perché spesso chi usa le librerie colpevolmente, mi viene da dire, non ha consapevolezza di cosa sta usando.Quindi alla fine tutta quella responsabilità ce l'hai te, ma alla fine la colpa hai di chi usa le librerie.Questo è giusto per evidenziare il fatto che forse dovremmo prenderci 5 minuti in più e dare un'occhiata al codice che stiamo facendo girare nei nostri progetti per capire come funziona senza delegare ciecamente responsabilità delle persone che poi vengono schiacciate da questa responsabilità, no? Sì, in realtà per quanto una persona possa controllare le librerie che utilizza, deve avere un modo di dire "ok di questa libreria mi fido, di questa libreria non mi fido" e suppongo, mi aspetto, che una libreria come Babel diciamo, trasmetta fiducia.Se tu dici "ok, io faccio Babel, ma Babel è utilizzato da tantissime persone, è mantenuto attivamente, quindi è una libreria di cui mi posso fidare".Quindi per quanto si controlla può capitare sempre che succeda qualcosa di male.Ci sono modi di evitarlo, ad esempio i package manager per JavaScript tutti, NPM o Yarn o PNPM, permettono di bloccare la versione di tutte le librerie che si usano o delle librerie utilizzate dalle librerie apposta per evitare questi problemi e permetterti di fare magari aggiornamenti graduali così che non ti smetta di funzionare all'improvviso la tua applicazione.Ricordo ad esempio un anno fa più o meno mi ha scritto un issue su github incavolato nero uno sviluppatore di una banca italiana perché non riuscivano più a aggiornare qualcosa in production e io ho detto...gli ho risposto un po' male perché mi ero sentito attaccato, mi aveva scritto in modo molto aggressivo, però la mia risposta è stata più o meno "fatevi furbi, avete i modi di...avete il modo di evitare che quando noi facciamo un casino il casino vi si rifletta addosso direttamente, fatelo".Scusa, una domanda, quanti anni hai te? Tra cinque giorni ventidue.Stavo pensando, io a 22 anni, responsabile di rompere Gatsby, o l'equivalente di Gatsby, o React Native, nel senso sei molto giovane per avere questa responsabilità e tutto sommato la prendi quasi di tacco, nel senso non ti pesa.Congratulazioni per questo.Ti volevo chiedere, visto che sei già in età, nonostante tu stia studiando, c'è qualcuno che ti approccia a livello lavorativo, tipo "vieni a lavorare per noi perché sai mantenerti questo" o...Sì, sì.La prima volta mi è capitato che ero in quinta superiore e in realtà non avevo molto interesse effettivamente a farmi assumere, però ero curioso di vedere come funzionava tutto, come funzionavano i processi di assunzione e così, allora sono anche andato a fare un colloquio, diciamo, conoscitivo.Poi in realtà ho realizzato che posso, a me piace una parte, diciamo degli argomenti molto di nicchia e ho una conoscenza tale di questi argomenti che io posso abbastanza facilmente scegliere di lavorare solamente in questi ambiti senza dover accettare la prima cosa che capita.Infatti in realtà adesso io sto anche diciamo lavorando in un'azienda, tecnicamente un Ruccini, inizialmente mi aveva inchiesto se volevo essere assunto, almeno un po' di dipendenti mi ha inchiesto se volevo essere proposto da loro, non me la sento ancora di lavorare per un'azienda, quindi per ora preferisco cose occasionali, almeno da poter avere nel curriculum del lavoro anche fatto proprio in un'azienda, perché lavorare a un progetto grande open source dimostra che hai certe capacità tecniche, certe capacità comunicative, non è tutto quello che poi ti serve.Chiarissimo.Però siamo già quasi 40 minuti che parliamo di Babel, la vostra creatura.Allora la mia domanda è, cosa è Babel e come funziona? Allora Babel è proprio come definizione, io dico che Babel è un compilatore JavaScript, che è una definizione molto vaga perché potrebbe anche essere V8, Chrome, Spider Monkey, dei compilatori javascript, quindi aggiungo sempre che Babel è un compilatore da javascript a javascript e spesso la gente che magari non ha mai usato qualcosa del genere è un attimo confusa perché per compilatore magari si intende qualcosa che genera del bytecode o del codice ineseguibile e quindi Babel è un compilatore da javascript a javascript perché prende in input javascript nuovo, almeno di default, o il modo più comune di usarlo, prendi un input del javascript nuovo e ti restituisci del javascript che utilizza solo sintassi più vecchia, così che possa funzionare su browser vecchi.E questa cosa, credo, esista quasi solo per javascript o per pochi altri linguaggi esiste qualcosa di simile per il css, perché il web è una delle pochissime piattaforme dove chi sviluppa un'applicazione che scrive il codice non ha poi il controllo su dove questo codice verrà eseguito, quindi magari qualcuno ha degli utenti che utilizzano Explorer 11 e hanno ancora bisogno di utilizzarli, quindi la scelta è o io non posso utilizzare tutte queste nuove funzionalità di linguaggio affinché il codice che scrivo sia "antico" e funzioni per tutti i miei clienti o per una certa percentuale di miei clienti per che mi serve e che funzioni, oppure io scrivo codice nuovo che oltre ad avere più funzionalità spesso magari più semplice perché è un motivo per cui si aggiungono cose al linguaggio per rendere più semplici delle cose che prima erano difficili.E anche devo ammettere che per uno sviluppatore, almeno per me, utilizzare caratteristiche nuove di un linguaggio è anche gratificante.Direi "wow, c'è questa cosa nuova, mi piacerebbe usarla".Babel ti permette effettivamente di usarla, tra virgolette fregandotene del codice che effettivamente tu hai bisogno di mandare ai tuoi clienti, proprio perché traducendotelo fa funzionare codice nuovo su browser vecchi.La domanda che spesso ci si fa quando si guarda Babel è "Ma allora come funziona sotto il cofano? Cioè ci sono delle mega regex grandi come una casa oppure funziona in un modo diverso?" Allora, quello che fa Babel, ci sono diversi step all'interno.Per prima cosa, intanto Babel lavora su ogni singolo file individualmente.Prende quindi un certo file come input, che quando noi scriviamo del codice pensiamo al file come avendo una certa struttura.Ci sono delle espressioni, ad esempio magari degli if, dei cicli, una certa struttura.Però di fatto è semplicemente una serie di caratteri.Per prima cosa Babel prende questa serie di caratteri e cerca di darle un significato.Costruisce quello che si chiama Abstract Syntax Tree, ossia un albero che descrive la sintassi, la struttura del programma.Ad esempio, se abbiamo un'espressione che potrebbe essere 1+2x3, l'albero corrispondente e la somma fra un nodo figlio della somma è l'uno e l'altro nodo figlio della somma è il prodotto fra altri due nodi, ossia il due e il tre.Quindi per prima cosa costruisce questo albero per dare un senso alla struttura del programma.Dopodiché ci sono tantissimi plugin in Babel come struttura sia interna che esterna, diciamo, ossia ogni singola funzionalità di JavaScript ha un plugin corrispondente per tradurla in sintassi più vecchia.Quindi Babel poi prende tutti i plugin che sono stati abilitati, controlla, prende la lista di tutti i tipi di nodi che i vari plugin vogliono trasformare, ad esempio ci sarà un plugin che vorrà trasformare il nodo di tipo classe, un plugin che vorrà trasformare il nodo di tipo, ad esempio, l'operatore di potenza, e inizia, una volta che sa quindi a cosa sono interessati i plugin, inizia a visitare tutto l'albero e ogni volta che c'è un nodo che interessa qualche plugin attiva il plugin, il plugin fa la sua trasformazione e poi Bubble prosegue a attraversare tutto l'albero e a chiamare tutti i plugin necessari.Se un plugin ti restituisce un nuovo pezzo di albero, perché i plug-in non sostituiscono string e costring ma appunto pezzi di albero con una certa struttura quindi che poi corrisponde al codice, li sostituiscono con una nuova struttura.Se necessario Babel visita anche questi nuovi pezzi inseriti così che se un certo plug-in ad esempio inserisce una variabile utilizzando let o const, poi c'è anche un plug-in che si occupa di trasformare let e const a var che funziona anche su browser più vecchi, siamo sicuri che possiamo avere diverse step di compilazione, ossia i plugin più nuovi generano un codice più nuovo e se necessario questo codice viene ancora trasformato in codice ancora più vecchio.Dopodiché, dopo che tutto il codice è stato trasformato, non il codice, dopo che tutta questa struttura corrispondente al codice è stata trasformata c'è l'ultimo pezzo di Babel che prende tutta questa struttura e la trasforma di nuovo in una stringa di codice.Ad esempio, di nuovo, se c'è il nodo più con i figli 1 e 2, stamperà prima il figlio 1, poi stampa più e poi stamperà il figlio 2 ricorsivamente, così da avere un programma completo.E per l'altro questa strategia, ossia di prima costruire un albero corrispondente al codice, magari faccia le trasformazioni, magari no, e poi rigenerare del codice, è quello che è utilizzato dalla maggior parte dei tools che ci sono adesso per javascript, ad esempio islint, il linter, genera la struttura del codice con magari informazioni diverse rispetto a quelle che attacca babbel in questa struttura perché hanno obiettivi diversi, però genera quest'albero, controlla che quest'albero rispetta tutte le varie regole e se necessario fa degli errori, oppure prettier che è il formattatore più famoso, credo scritto "formattatore" in italiano, più famoso per JavaScript, anche questo genera un albero aggiungendo anche informazioni, ad esempio, non puramente sulla struttura sintattica del programma, ma anche sulla formattazione, ad esempio gli spazi, i commenti, tutte queste cose che non influiscono sul programma, ma influiscono sul suo aspetto e poi stampa quest'albero formattandolo.e ci sono tantissimi altri tools che appunto si basano su queste strutture date interne.Chiaro e naturalmente quando si lavora con gli Albel la mia domanda è complessità e performance, nel senso quando lavorate su Babel le performance sono un elemento che monitorate, sono una fissazione Oppure, girando fondamentalmente a transpiler time, compile time, siete un po' più distesi da quel punto di vista? Allora, diciamo più o meno, nel senso, Babel, come complessità, come complessità, complessità quella teorica, diciamo, è assurdamente alta, perché deve attraversare tutto l'albero più volte, magari perché tu non solo devi attraversarlo per fare tutte le trasformazioni e magari riattraversare delle parti che vengono cambiate o sostituite, ma anche magari tu stai un certo plugin modificato il codice e gli serve sapere un'informazione su una certa variabile, tipo dove è stata definita o se è mai stata riassegnata e quindi bisogna di nuovo attraversare, magari in anticipo quando è necessario, comunque e non attraversare un'altra volta parte dell'albero per trovare le informazioni necessarie.Quindi come complessità è molto lento.Cerchiamo, quando possibile, di ottimizzare cose, spesso magari concentrandoci su alcune parti di Babel, non su Babel completo, dove queste ottimizzazioni hanno più impatto.Ad esempio nel parser, ossia quello che trasforma la stringa di codice in input in una struttura, perché utilizzato anche da molti altri progetti.oppure nella parte di Babel che si occupa di far funzionare insieme tutti i plugin, perché questa parte è sempre utilizzata.C'è anche da dire che ormai ci sono molti progetti che lavorano più o meno nello stesso spazio in cui lavora Babel e che sono magari...Ah, è importante da dire Babel e Script sono stessi in JavaScript.Ci sono altri progetti, ad esempio uno che si chiama SVC, non so come si pronuncia, SWC, che è nato come una copia di Babel, ma è iscritto in Rust.O ce n'è uno, YesBuild, scritto in Go, che più o meno fanno quello che fa Babel, magari fanno di meno, però lo fanno molto più velocemente, di diverse ordini di grandezza.Quindi, spesso noi ci concentriamo più che sulla performance in sé, sulla correttezza di quello che facciamo, perché tradurre una funzionalità nuova in una funzionalità vecchia è molto difficile perché devi fare attenzione che funzioni esattamente o il più possibile esattamente come dovrebbe funzionare.Quindi noi ci concentriamo molto sulla correttezza e sul rendere facile, ottimizzare non il processo di compilazione ma poi il codice generato.Ad esempio, ad esempio, java ha scritto certe regole per cui se tu, ad esempio, traduci le classi in sintasi più vecchia viene fuori un sacco di codice.Viene fuori un sacco di codice per delle cose che magari in realtà non ti servono, perché sono magari degli edge case dei quali più di tanto non ti importa.E' molto importante che il comportamento default sia corretto così che quando tu, abbastanza dei tuoi tenti al genero browser tu puoi permetterti di compilare di meno, il tuo codice continua a funzionare perché se cambia il comportamento del codice è un rischio, quindi la correttezza è nostra priorità.Tuttavia abbiamo magari anche ad esempio delle opzioni per dire al compilatore "Ehi, guarda, lo so che dovrebbe essere questa cosa fatta così, ma preferisco se lì sei un po' meno corretto e generi del codice più piccolo o più veloce" oppure abbiamo un modo per compilare il meno possibile dicendo a Babbel anziché compila queste funzionalità gli dici guarda compilami per questi browser ad esempio ne so Chrome 80 e Firefox 75 a caso e Babbel automaticamente compila il meno possibile generando del codice funzionante su quei browser e poi magari a parte tu puoi dire ok adesso compila per explorer 11 e per Chrome 30 ad esempio e quindi noi più che sulle performance ci concentriamo su come, ovviamente la correttezza come ho detto e poi come rendere più semplice, il più semplice possibile per i nostri utenti generare del output di Babel piccolo o veloce perché poi di fatto questo è quello che dovranno mandare al browser, che verrà eseguito sul browser, quindi dove è molto più importante che le cose funzionino in modo comodo diciamo.chiaro, avevo una domanda in realtà in merito a il modo con cui voi capite che questa funzionalità che state traducendo in qualche modo funziona anche su browser obsoleti, come li testate tutti questi browser quando sono un gozziliardo? immagino che ne so, ho visto io uso Babel e con browser list per esempio gli puoi dire questa funzione deve funzionare su browser morti come Blackberry, te giusto per dirne una? Esatto, allora in realtà noi ci affidiamo a un progetto esterno che si chiama Compact Table, probabilmente cercando tipo Compact Table JavaScript o Ecmascript su Google la si prova, e è una tabella di compatibilità dove ci sono tantissimi browser vecchi, cioè nuovi e vecchi, vecchi, ogni versione ha i browser nuovi, ma credo che ormai abbia 15 anni come progetto, quindi c'è veramente tantissima roba e contiene tutti i dati su cosa funziona e cosa no testati a mano.Poi in realtà una volta che tu sai che una certa cosa non funziona su un certo browser sei tranquillo, o che una certa cosa funziona su un certo browser, sei abbastanza tranquillo, perché per fortuna in realtà i bug nei browser sono relativamente rari, a meno, sì, sono relativamente rari e soprattutto sono per le funzionalità nuove, quindi magari l'ultima versione di Firefox introduce una certa funzionalità e un bug, ma tu devi supportare anche tanto le versioni prima, quindi di quel bug non te ne accorgi neanche perché tu compileresti prescinde anche se in teoria quella funzionalità assoluta di Firefox è supportata.Quindi noi ci affidiamo a questi dati esterni sui quali in realtà non abbiamo mai, quasi mai, avuto problemi e nel dubbio, ossia quando mancano i dati, noi supponiamo che le cose non funzionino, così di default quello che noi generiamo come output della compilazione funziona.chiaro? quindi worst case di default.esatto.leo so che avevi una domanda al di là del discorso.si lega un po' al fatto del progetto coin source.immaginiamo che tu, vedo questa posizione diciamo importante come maintainer, a un certo punto per qualsiasi ragione non per forza negativa, devi andare via dal progetto.Che tipo di handover devi dare? Nel senso, è già tutto documentato, quindi te puoi uscire e già tutti sanno, oppure c'è qualcosa che qualcuno deve sapere e non è scritto da nessuna parte, cioè hai del...come si può chiamare debito tecnico, non lo so, c'è qualcosa di accumulato che comunque devi comunicare.Come funzionerebbe secondo te? Non che te lo auguri, eh, suggerisco.In realtà ci ho pensato non a mollare il progetto, almeno per ora, ma a cosa succederà quando io non ci sarò più.Sembra triste detto così, non che mi succeda qualcosa, speriamo, però a un certo punto non credo che per tutta la vita lavorerò a questo.Noi come team, che in realtà siamo un team relativamente piccolo, di persone diciamo sempre attive, siamo 4 o 5, poi non è proprio ben definito il team perché magari c'è tanta gente che diciamo tengono d'occhio il progetto, contribuiscono ogni tanto, magari una volta a settimana, una volta al mese e essendo che magari sono persone che seguono il progetto da due o tre anni comunque è molto importante avere anche la loro opinione, anche se non sono diciamo il team principale.Comunque abbiamo una regola, ossia che per tutte le pull request, tranne se magari c'è un typo o qualcosa che ovviamente è sbagliato e non è così come doveva essere, ma non ad esempio per i bug, per quelli mai, per tutte le pull request almeno due persone del team, diciamo del team esteso, devono approvarle e facendo così magari ovviamente controllando tante pull request non ti ricordi tutto, però su due persone che leggono tutto il codice che scrivi c'è sempre poi qualcuno che comunque sa come funziona.Ci sono delle parti un po' più, diciamo, meno condivise come conoscenza, ad esempio tutto il processo di pubblicazione.Abbiamo automatizzato le release di Babel così da non...Perché una volta era veramente tragico, dovevamo tipo andare nella cartella Node Modules e modificare manualmente come funzionavano alcune delle librerie che utilizzavamo per riuscire a pubblicare come volevamo noi.Adesso abbiamo sistemato tutto, automatizzato tutto e ad esempio quella è una parte che ho scritto io quasi da solo e su cui non credo che tutto il team abbia una grande conoscenza, però alla fine io scrivo codice con questa persona da anni e sono abbastanza tranquillo sul fatto che se necessario possano riuscire a capire cosa avevo in testa quando ho scritto quella cosa e riuscire a capire come metterci mano.Ok, grazie.Sì, è comunque un mondo quello dell'open source e tra l'altro sul fatto delle code review ci sarebbe da parlarne per ore, dimostra il fatto, quello che dici dimostra il fatto che le code review oltre a essere una rete di salvataggio per il codice che si rilascia sono anche, credo, il miglior modo per condividere la conoscenza.Tra l'altro ogni tanto mi da un po' fastidio dover aspettare che due persone approvino il mio codice e lo controllino, però alla fine è sempre risultata essere una buona idea e soprattutto anche facendo così, quando qualcuno sbaglia la responsabilità è condivisa e questa soprattutto perché, come prima ne parlavamo, abbiamo una grande responsabilità, il proprio sentirla condivisa con altri è molto importante.chiaro, chiarissimo, però so che in realtà Babel non è l'unica cosa che fai, ma so anche che sei stato un esperto nominato dal TC39, allora la mia domanda è che cos'è TC39, qual è il suo ruolo, il suo compito e in realtà come si collega a Babel e qual era poi alla fine il tuo ruolo in questo tipo di lavoro? Allora, TC39 è un gruppo che tra l'altro mi fa strano perché quando ne parlo con qualcuno lo dico perché so che è il modo giusto, ma nella mia testa è TC39.Comunque, è un gruppo di persone, di rappresentanti, la maggior parte rappresentanti di aziende che hanno come compito il progettare JavaScript, ossia lo sviluppare, le funzionalità, il trovare se ci sono dei problemi del linguaggio che si possono riuscire a correggere, il controllare che nuove funzionalità del linguaggio non possano creare problemi di qualunque tipo, ad esempio un sito smette di funzionare o si introduce un problema di sicurezza, quindi si fa questo.Questo gruppo si occupa di progettare JavaScript.Ogni volta che c'è una nuova funzionalità, ad esempio sono appena stati accettati i class fields, le proprietà nelle classi pubbliche e private.Ogni volta che c'è una nuova funzionalità del linguaggio arriva da anni di lavoro fatti da questo gruppo e quando dico anni intendo veramente anni, ogni tanto magari capita che qualcosa ci metta sei mesi ma di solito si parla di 4-5 anni anche di più.La maggior parte delle persone in questo gruppo sono rappresentanti di aziende che devono pagare una certa commissione annuale in base a quanto fatturano queste aziende.Ad esempio, so che le non profite entrano gratuitamente.Ci sono alcune persone, credo che siamo una decina, per capire questo gruppo sono più o meno credo un centinaio di persone, credo che una decina quasi o poco di meno siamo persone che sono state invitate a partecipare appunto come esperti di qualcosa, ad esempio c'è una persona che lavora allo standard di WebAssembly e allora è stata invitata come esperto in DC39, oppure io e un altro ragazzo del team di Babel che essendo che noi lavoriamo con il linguaggio stesso e spesso siamo il primo punto di incontro fra gli sviluppatori e le nuove proposte per il linguaggio perché noi le implementiamo molto prima che le implementi nei browser.Quindi noi essendo questo punto di incontro diciamo tra gli sviluppatori e le nuove funzionalità siamo stati invitati anche come esperti per poter darla nostra opinione, per poter aiutare.Quello che facciamo, noi abbiamo, credo, in realtà non sono molto ferrato su queste cose, ma credo abbiamo gli stessi diritti di chi invece li è rappresentando la propria azienda, forse tranne ad esempio sulle discussioni riguardanti i soldi o cose così, però almeno sulle decisioni per il linguaggio abbiamo gli stessi diritti di tutti gli altri, dove in realtà l'unico diritto che tutti hanno è dire di no, perché...Dopo magari spiego come funziona quando si introduce una nuova funzionalità.E soprattutto io aiuto, ad esempio, non mi ricordo se l'ho già detto, che sto lavorando con altre persone a due proposte per JavaScript, che sono l'operatore di pipeline e delle strutture dati immutabili che si chiamano records and tuples.A me il nome della proposta è records and tuples.Essendo che io sono, diciamo, si chiama "invited expert" nel mio status, posso partecipare alle riunioni di questo gruppo dove si parla di queste funzionalità.Tra l'altro ormai sono quasi tre anni, credo, che sto collaborando su diverse cose.Avevo iniziato lavorando ai decorators per le classe, che è stato tragico.Mi ha fatto completamente passare la voglia di lavorarci perché credo sia state riscritte completamente da zero quattro o cinque volte come proposta.Però in realtà mi piace molto questo aspetto, ossia il riuscire a trovare una funzione, a progettare una funzionalità che piaccia a tutti.Infatti spero in futuro di riuscire a farlo sempre di più.Cioè a me andrebbe bene anche in un ipotetico futuro dopo di Babel, mi piacerebbe lavorare quasi solo su questo.Chiaro, come funziona in realtà l'approvazione poi di una nuova funzionalità nello standard? Ah, giusto, ho detto che ne avrei parlato.Pensavo che me ne fossi dimenticato, vero? Allora, c'è un processo che tutti, tutte le nuove funzionalità devono seguire, basato su quattro stages.Ognuno di questi ha un certo significato, che vuol dire un certo significato per la community, ossia il primo si chiama stage one, ovviamente, si chiamano stage one, stage two, stage three e stage four.Il primo vuol dire, non è ancora una proposta, è un "ok, abbiamo un discusso e effettivamente abbiamo realizzato che c'è questo problema, c'è questo spazio in cui manca qualcosa e iniziamo a capire un attimo come si potrebbe colmare questo spazio.Praticamente quasi sempre quando una persona all'interno di TC39 propone qualcosa, quasi di sicuro viene approvata per questo stage one.Dopodiché si inizia effettivamente a studiare il problema, a cercare di capire quali sono in modi in cui si potrebbe risolvere.E questo lavoro non lo fa tutto TC39, ma ogni proposta ha una persona o più persone chiamate champions, che si occupano di sviluppare e portare avanti ogni proposta.Dopo aver studiato tutto lo spazio, si inizia a scrivere una bozza, una bozza di come funziona questa funzionalità, e si prova a chiederlo stage 2.Stage 2 vuol dire "ok, questo è possibile che sia la soluzione, vediamo adesso se effettivamente questa soluzione può funzionare".Non ha ancora tutti i dettagli scritti, giusto un'idea generale di quale ad esempio potrebbe essere la sintassi o quali potrebbero essere, o se non è sintassi ma sono delle nuove funzioni da aggiungere, che tipo di funzioni potrebbero essere.e in questo momento, in questo stage, si inizia a scrivere effettivamente una proposta di specifica perché JavaScript non è basato su un'implementazione particolare, ma è un lunghissimo documento in pseudocodici, diciamo, che descrive ogni singola cosa come deve funzionare.Quindi a questo punto si inizia a scrivere questa specifica.Dopodiché si prova a chiedere al committee, al TS39, al gruppo, si prova a chiedere stage 3.A questo punto stage 3 vuol dire "ok, ne siamo abbastanza sicuri che questo sia così come deve essere".Abbiamo ascoltato tutte le opinioni, raccolto tutte le informazioni che potevamo e questo è il meglio che siamo riusciti a fare e siamo convinti che sia un buon prodotto.A quel punto i browser iniziano a implementarlo e controllano se effettivamente si può implementare perché possono esserci due tipi di problemi.Uno è che, ad esempio, questa funzionalità sia troppo lenta e non possa essere ottimizzata in nessun modo o non possa essere ottimizzata abbastanza.Oppure, semplicemente, questa funzionalità aggiunge troppa complessità all'engine javascript del browser e uno potrebbe dire "Vabbè, voi siete delle persone che lavorano a questo tipo di progetti siete in grado di gestire questa complessità, però con una complessità maggiore possono esserci più bug, più problemi di sicurezza o in generale più cose che più problemi.E ultimo, che in realtà è il problema più importante, potrebbe accadere che una nuova funzionalità faccia smettere di funzionare alcuni siti web e TC39 come slogan, diciamo, come mantra ha "Don't break the web", ossia i siti che funzionavano 20, ormai JavaScript da 25 anni quasi, quindi 25 anni fa devono continuare a funzionare adesso.Magari se uno o due siti smettono di funzionare, vabbè, però già se lo 0,01% dei siti smettono di funzionare è tantissimo, è qualcosa di inaccettabile.Tutto questo processo serve per assicurarsi che le cose funzionino bene e funzionino bene col codice vecchio, perché non possiamo supporre perché tutti i siti vengono aggiornati.Ad esempio so che c'è un sito di Space Jam che ormai ha non so quanti anni e credo sia uno dei siti più vecchi di cui si ha ancora traccia e questo sito viene spesso utilizzato ad esempio nei test automatici dei browser per controllare.In realtà è un sito relativamente piccolo, però è molto simbolico che uno dei siti più vecchi che si conosca continui a funzionare ancora adesso, che è una garanzia che c'è sul web e che non c'è su moltissimi altri linguaggi, ad esempio più banali di tutti è da Python 2 a Python 3.Comunque dopo che si è controllato che tutto può funzionare, dopo che almeno due browser l'hanno implementato e l'hanno abilitato di default, una funzionità può passare a stage 4, che vuol dire di fatto che è accettata nello standard e una volta che è accettata nello standard di fatto è parte di JavaScript.Tecnicamente lo standard viene pubblicato una volta all'anno, mi sembra a luglio, però di fatto quello che conta è quando le cose sono già utilizzabili perché quando sono già nei browser.E' molto importante che a ognuno di questi avanzamenti di Stage devono essere tutti d'accordo in PC39, virgolette, nel senso non ci deve essere nessuno che dica di no, perché è importante cercare di ascoltare le preoccupazioni di tutti quando si fanno queste cose, perché javascript è usato da tantissime persone, ci sono tantissimi sviluppatori e ci sono tantissimi utenti, credo, sono abbastanza sicuro che ci siano miliardi di persone che hanno un dispositivo sul cui gira JavaScript.Quindi è importante cercare di avere un'opinione il più eterogenea possibile, cercare di ascoltare tutti i punti di vista e cercare di capire effettivamente se ne vale la pena di introdurre una certa cosa, perché magari certe cose ad alcuni sembrano belle, molta gente se ne entusiasma, però creano dei problemi talmente grandi in qualche ambito che potrebbe non valerne la pena.Quindi una delle caratteristiche di TC39 è che tutti devono essere d'accordo, o almeno se qualcuno non è d'accordo deve non bloccare la proposta perché ritiene che non è magari la cosa migliore che ci possa essere, ma comunque va bene, non crea problemi di qualunque tipo, che possono essere problemi tecnici, problemi di insegnare il linguaggio, problemi di parlare del linguaggio e così via.Allora, spieghiamo che cosa è successo.Ad un certo punto Mauro è sparito dal Google Meet in cui stavamo registrando e poco dopo mi ha scritto che in pratica gli era esploso il Mac, che si era spento e riavviato e quindi non poteva più registrare.Siamo andati avanti io e Nicolò una decina di minuti, non di più a parlare, più che altro di come quel famoso sito del 96 poteva essere una specie di benchmark per l'evoluzione di JavaScript e cosa sarebbe successo nel caso fosse sparito, cioè che il linguaggio sarebbe andato avanti senza più preoccuparsi di quel tipo di compatibilità.E siamo andati a finire anche sul discorso che magari Google ha una potenza di fuoco maggiore perché nel momento in cui decide magari su Chrome di disabilitare una funzione, di defrecare una funzione di JavaScript, hai voglia a te a continuare a svilupparla e a mantenerla ma se poi il browser più diffuso non te la fa girare è tutto inutile.Quindi abbiamo perso questa piccola parte, purtroppo Nicolò ha perso la sua registrazione e quindi sono qua a spiegarvi questo successo.cose che succedono cercheremo di fare in modo che non succeda più.Se questo argomento vi è sembrato interessante comunque Nicolò è nel nostro gruppo Telegram e quindi possiamo continuare la conversazione di là.Eh sì, è tutto esploso questa volta, non me l'aspettavo.Vabbè, comunque mi sono già attrezzato con un setup nuovo di pacca, sto solo aspettando me lo consegnino.Nonostante tutto io devo fare una cosa importantissima e volevo farla di persona.Come ben sapete GITBAR ha un suo momento dove ringraziamo chi ci offre la birra e questa settimana abbiamo Andrea Rapponi che ci ha offerto 5 birre per cui lo ringraziamo anche perché ha fatto in modo che le nostre ugole non si seccassero ma l'ha fatto anche lasciandoci lasciandoci un bellissimo messaggio che adesso vi leggo vi ringrazio per la mole di informazioni per la compagnia nei lunghi tragetti in macchina per le risate e per avermi dato l'ennesima conferma che la vera skill che tutti i professionisti dovrebbero avere è l'umiltà.Un brindisi a voi e noi con queste bellissime parole di Andrea Rapponi solleviamo i calici e beviamo queste cinque birre che ci sta offrendo quindi grazie Andrea anche perché grazie alla tua donazione riusciremo a pagare una parte delle bollette di quindi grazie grazie di cuore e prost! Vi conduco nel paese dei balocchi Ah il paese dei balocchi! Buonanloro, come balocco posso portare uno strumento di un debugger a cui sta lavorando mio amico si chiama Replay e in pratica ti permette registra tutto quello che avviene durante l'esecuzione esecuzione del codice javascript e ti permette di eseguirla in avanti e andando indietro e riuscire a capire più o meno tutto quello che succede e che è successo e l'ha appena pubblicato è un programma gratuito ho provato a usarlo qualche volta ed è stato spettacolare diciamo sono rimasto stupito perché sono abituato come detto prima mi piace io sono abituato a debuggare molto ma non ho mai avuto uno strumento di questo tipo e sono rimasto piacevolmente sorpreso a vedere come funzionava quindi replay se vi interessa si chiama io ho recentemente cambiato il NAS, quindi il NAS è un network attached storage perché mi si è rotto il disco su quell'altro ne ho preso uno un po' più potente perché lo volevo utilizzare anche come serverino In realtà ho installato per esempio docker perchè docker su mac funziona ma non funziona e volevo vedere se riesco ad utilizzarlo su questo NAS per esempio per far girare Linux.Il NAS ricordiamo non è un dispositivo di backup, è solo storage.Quello che è sul NAS poi lo dovete backupare perchè essendo che è accanto al vostro computer non è in un'altra location.Il NAS che ho scelto è il Synology DS720+ metterò il link in descrizione.Viene venduto anche senza dischi quindi i dischi ve li comprate voi.Fate attenzione, se possibile, di comprare dischi o da due venditori diversi o chiedere due lotti diversi così che diminuiamo la probabilità che entrambi i dischi si rompano.Perché se se ne rompe una a seconda del ride si può recuperare, se no, no.Quindi questo è quello che condivido io.Benissimo, Nicolò, allora, siamo arrivati in fondo.Mi scuso da parte di Mauro che, purtroppo, non ci sta sentendo, ci stiamo scrivendo su Telegram per coordinare la chiusura.Ti ringrazio tantissimo da parte mia, da parte di Mauro e di tutta la community di Gitbar.Come diciamo sempre, Gitbar è adesso anche un po' tuo.Siamo un bar, siamo aperti, vieni quando ti pare.Se non sei già dentro al gruppo Telegram, ti invitiamo a entrare.Tra l'altro, se entri in questo momento, saresti il numero 500, quindi sarebbe anche una bella pietra milare.Milare, a meno che qualcuno non si infili in questo momento.e niente i contatti sono sempre gli stessi sono Brain Repo su Twitter Info@github.it, il gruppo Telegram dove troverete anche Niccolò che è entrato, lo vedo adesso live e quando vuoi tornare, quando hai qualcosa di cui vuoi parlare alla community, noi siamo qua, ti aspettiamo, abbraccio aperte perché è stata una conversazione super interessante.Volevamo rientrare in un'ora, non ci è riuscito perché siamo stati presi da questo flusso di coscienza e quindi ti ringraziamo tanto per tutte le informazioni che ci hai dato.È stato un piacere, un onore e ci sentiamo presto allora.A tutti gli altri, ci sentiamo alla prossima puntata.Ciao a tutti da Brain Repo, da Leonardo e da tutti gli altri miamutinani.Ciao! GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.
