Dovremmo un po' trovare un modo per ottimizzare il focus ma comunque quando ero piccolino andavano di moda le pillole all'omega 3 quel veleno che negli anni 80 ci somministravano per farci sembrare più intelligenti ma in realtà eravamo stupidi e siamo rimasti quindi...- Il fottu...- Io guardando i bambini di oggi mi chiedo...mi continuo a chiedere come siamo sopravvissuti noi degli anni '80 perché la domanda comunque rimane.- Ora ci parliamo.- Siamo noi quelli che leggendo il codice cercano lo stronzo che ha scritto quello schifo.Ma ahimè, lo stronzo è mai medesimo, ma l'ho scritto giusto ieri.- And I'm sorry.- Siamo quelli che santificano il nuovo framework JavaScript preferendo segretamente jQuery, gli stessi per il quale il testing è importante, infatti la nostra codebase ha solo due test e flake pure.Siamo noi quelli che il tuo linguaggio fa cagare, ma il mio è peggio.Quelli che la chiarezza nei commit message prima di tutto, e dentro ce l'appella tutti i santi.- Se no bestemmio guarda.Quelli che in call parlano per 5 minuti prima di accorgersi che il mic è muto.Quelli che non si può fare di default, diventa velocemente un tutto e possibile sia le risorse, tempo e budget ilimitato.Siamo noi quelli che l'AI va regolamentata, mai visto questo nuovo modello che disegna gatti di funambuli? Quelli che il dipende e unisci gratis la prigione.E quelli che la RAL...no vabbè, fa già ridere così.Siamo quelli che fanno lo slalom tra le specifiche che cambiano costantemente, ormai rassegnati che la definition of ready è solo una più illusione.Quelli che si sentano dire "ho un'idea per un'app" ed è subito l'ennesimo social come Instagram ma meglio.Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al geek bar e davanti a una birra tutto ci sembra un un po' meno grave.Bene e benvenuti su Gitbar per questo Gitbar pomeridiano, quindi la birra subito dopo pranzo ci sta benissimo e per bere questa birra io ho due ospiti nonché amici e ve li presento subito dopo la sigletta.Ma prima di far partire la nostra bellissima sigletta fatta con i nostri potenti mezzi di Gitbar, vi devo velocemente ricordare i nostri contatti.Info che ho c'ho la gitbar.it e @brianrepo su Twitter, sono in modi canonici per contattarci.Il gruppo Telegram ormai lo conoscete per cui calchiamo play.[Musica] Abbiamo con noi due amici che sono già venuti diverse volte qua a Gitbar.Abbiamo Matteo Colline e Paolo Insogna direttamente da Platformatic.Ciao ragazzi! Buongiorno a tutti! Buon pomeriggio! Ciao, sono molto contento di essere qua.- E' pomeriggio Paolo.- Io vedo il tramonto.- Tu lo sai che io devo avere ragione.- A che ora avete iniziato a lavorare? Perché se Paolo vede il tramonto vuol dire che avete iniziato particolarmente presto.- Il mio capo è meglio che non lo sa.Io posso dirlo senza ombra di dubbio, mi ha svegliato mia moglie alle sei e mezza e poi alle sette era operativo e quindi così.Nel mese sono venuti gli elettricisti a casa quindi c'è stato un po' di rischio che quella puntata di oggi non si facesse però in realtà ci siamo tutti qua insomma quindi è tutto bene.Io ho la prima domanda che voglio farvi è tranchant ed è un po' off topic.Siccome venite tutti e due dal mondo della consulenza, io amo definire la consulenza con la C maiuscola, cosa cambia nel lavorare in prodotti/prodotto e soprattutto cosa ha cambiato nel lavorare in una startup che come è noto le startup spesso fanno pivoting e vedono luce in alcuni ambiti? Beh, io lo risolvo...Vuoi che cominci io Paolo o cominci tu? Questa è la domanda.Io lo risolvo in una frase, facile facile.La grande differenza tra prodotto e consulenza è che nel prodotto scegli tu come farti del male, praticamente.ovvero quando sei in consulenza, si grosso modo ti scegli clienti ma quello che ti arriva dipende in buona parte dal cliente, nel prodotto scegli tu come vuoi farti veramente del male e puoi farsi molto molto male.Tutto qua.Mi piace Paolo la visione.Io ho una visione rispetto alla consulenza con la C maiuscola, insomma quella che facevo prima, la differenza è tipicamente significativa sull'orizzonte temporale, cioè normalmente l'orizzonte temporale è più esteso in questo momento o è comunque una visione definita.Noi siamo una startup, abbiamo chiuso un round di funding, sappiamo quanti soldi abbiamo in banca, sappiamo quanto è il burn e sappiamo per quanto tempo possiamo pagare gli stipendi a tutti, ecco, questo è un po' brutale, è una realtà brutale, ok? E vuol dire che c'è la ticking bomb, ok? Il contatore all'esplosione, capito? Quindi o fai revenue o cominci a far girare il motore, o se no scoppia questa realtà.Quindi questo è probabilmente la cosa principalmente diversa rispetto a fare startup piuttosto che lavorare in consulenza.In consulenza Arpanne, se sei relativamente bravo, quel che entra esce.Fai revenue, fai profit nel mezzo, ma nella realtà fai un po' di workshops, metti da parte un gruzzoletto, e quindi magari ti puoi permettere delle cose in più, però alla fine il ciclo di cassa è relativamente facile da capire.Il ciclo di cassa di un prodotto ha potenzialmente degli upside molto migliori, perché appunto scala meglio rispetto alle persone, ma dall'altro lato è molto più difficile da far partire, ecco, e quindi o perlomeno far partire ai livelli a livelli richiesti.Quindi è un po' questa, secondo me, la differenza principale tra le due cose.A livello di lavoro, ok, quantità di lavoro immane, te lo dico io che faccio io tre cappelli in azienda e entrambi più o meno a tempo pieno, ok? E mi si chiede tutti come fai a fare, sono anche papà e qui c'è anche una bimba, quindi anche lei è un altro cappello, ok? E questo è un po' la cosa, c'è molto lavoro, molto molto lavoro, molto molte cose da fare, ok, però è molto divertente.Secondo me un'esperienza fantastica che volevo tanto fare e sono contentissimo di aver fatto lo switch.Ma perché è un'esperienza che volevo fare.Sì, cambiano anche i livelli di adrenalina secondo me.guarda è alti alti alti alti alti bassi bassi bassi ma bassi ma veramente capito.Proprio guarda e lo dicono che è un emotional roller coaster ma soprattutto quando sei al comando insomma quando sei al sidi di guida è molto è molto molto molto dura anche perché c'è il peso delle responsabilità di tanti e non è come essere line manager o… là veramente c'è la responsabilità di tirare fuori gli stipendi e di dire dobbiamo dare questa feature anche se non mi sento di dirgli la mettiamo o non la mettiamo questa può aumentare può… è complicato.Ti faccio e vi faccio l'ultima domanda promesso riguardo a startup perché questo potrebbe essere un altro episodio ma E la domanda riguarda startup e open source.Inizio voglio voglio dirlo senza senza senza esagerare però a questo punto.Faccio un faccio un preambolo.Questa è una bold opinion ma inizio ad avere un po le palle piene di open source come mito da sventolare e come soluzione a tutti i mali.Open source sì però ragazzi adesso qualunque cosa si dica è open source.Allora mi piacerebbe ragionare con voi velocemente su qual è la complessità di fare tanto open source in una startup che poi ha il profit come...La prendo io Paolo, poi ti faccio un aggancio e poi te la passo.Capito? Allora ti racconto il problema di fondo.Prima di tutto noi sentiamo open source come tema.In realtà si tratta di, tipicamente tu dici open source sì, open source no.In realtà si tratta di un diagramma su tre assi.Quindi tu in realtà tu lo vedi come se fosse uno solo l'asse, in realtà sono tre.Quindi è un oggetto tridimensionale dove ti collochi come azienda.Open source è qualcosa di licenza, è una licenza.La definizione è una licenza.La licenza è open source o non è open source.Distribuisci codice open source, la licenza è questa.Questo è il primo aspetto.Easy da capire, lo capiscono tutti.Guardano il file di licenza.ok se guardi la mia tv di là c'è scritto che utilizza nojs dentro e c'è il file di licenza di nojs dentro la tv ok facilissimo ok facile da capire immediato eccetera eccetera l'altro aspetto è l'aspetto di governance ok quindi hai l'open source e hai la governance ok cosa vuol dire? Semplicemente chi comanda? Chi comanda in questo progetto? Chi è che decide cosa si fa? Chi è che gestisce i rilasci? Chi è che coordina il lavoro? Ok, prendiamo un progetto, alcuni progetti open source molto noti.Ok, adesso secondo la visione dei più, Android e open source.Il ciclo di collaborazione è molto stretto.Io ho una domanda.Quanti cellulari android senza google play store trovi in giro? Veramente pochi.Ci sono i Xiaomi e i non branded con versioni custom di android.Sono veramente pochi.Tanto che l'altro giorno si aveva un discorso nel gruppo telegram di non ricordo quale applicazione nazionale che non gira su...Io con l'IT Wallet si l'ho letto con la roba.Questo è il secondo problema, ovvero chi comanda.Questo è il secondo aspetto.Puoi avere il codice open o open source, ma nella pratica chi comanda è uno solo.E quindi si tratta comunque di un prodotto aziendale, perché chi comanda è uno, quindi puoi avere da un lato che sei un prodotto aziendale, dall'altro lato puoi avere un sistema pseudo oligarchico di una o più persone che sono al comando, per meriti tipicamente, meriti acquisiti, ok? O per numero di contributi fatti, puoi cominciarla come vuoi, ok? Questo è il secondo asse, ok? Per esempio Chromium, tutti voi sviluppatori sapete che c'è Chromium, ok? Chromium è un fantastico prodotto, ok? Lo usiamo tutti.Google Chrome, aspetta, ma c'è Chromium e c'è Google Chrome, qual è la differenza? Ok? C'è il mondo di differenza tra i due ok google chrome ha determinate feature che chromium non ha chromium open source google chrome non lo è ok questo è un altro aspetto in questo mondo l'ultima cosa è il commerciale ok la maggior parte del software dentro red hat è open source giusto quindi ti danno i sorgenti cosa ti vende red hat però ti vende i binari, ti vende i binari e il supporto e quindi c'è il livello di commerciabilità del prodotto ok? Quindi ci sposta anche un asse sulla commerciabilità.Tu quando vi realizzi un'azienda devi sostanzialmente andare a posizionare la tua azienda la tua startup eccetera in questi in questi assi ok? E notate che anche la consulenza con la maiuscola sta in questi assi volendo ok perché uno può dire un business model che funziona per le aziende di consulenza e ha funzionato per un certo lungo periodo insomma funziona tuttora è faccio un framework open source e vendo supporto ok questo è se vogliamo comunque un'attività non di prodotto che vendi supporto ok non scala come una licenza se vogliamo non scala come un SaaS ma ma a scala può funzionare.Comunque devi assumere tanto personale per gestire tutto il supporto, formarlo eccetera.Per darti un'idea della cosa.Questa è un po' secondo me come devi interpretare una startup e come devi vedere una startup.Per esempio React, lo usate tutti, voi qui che ci seguite."Avverto della colpa implicita nelle tue parole" Beh no, ok? React non ha Open Governance, ha un capo, ok? Bellissimo il capo di React, ok? Ha un capo.Così come Next, che anche voi tutti usate, insomma.Uno e due.Aspetta, ma ti dirò di più.Così come TypeScript, che vi piace sicuramente a tutti, ok? E quello è colpa mia Paolo purtroppo.Appunto.Che vi piace a tutti TypeScript, ma TypeScript non ha alcun tipo di Open Governance.E non è commerciale, cioè non ha una...è completamente open source, completamente sviluppato open, ma non ha alcun tipo di open governance.Tu sei assunto dal team di TypeScript, c'hai una posizione aperta nel team di TypeScript per andare a lavorare lì, come nel team di React eccetera eccetera eccetera.Questo è un po' il discorso, quando si fa startup nel mondo open source bisogna pensare alla sostenibilità, quindi qualcuno alla fine ci deve guadagnare.Quindi la domanda che uno si deve fare quando adotta una soluzione che può essere anche platformatic ma piuttosto che TypeScript, piuttosto che Visual Studio Code, piuttosto che GitHub, piuttosto che Next.js, piuttosto tutto quello che non paghiamo sostanzialmente qualcuno alla fine della fiat ci guadagna, ci deve guadagnare, semplicemente perché il pane non è gratis, questa è la realtà dei fatti.Il livello di supporto e difficoltà richiesto è tale per cui qualcuno deve pagare, più o meno uno può fare le decisioni.Ok, vi ho parlato tanto, lascio parlare a Paolo di come funzionano JS e la leadership per spiegare un po' quali sono le cose che facciamo noi dentro Node.js.Allora, in realtà, prima di arrivare lì, aggiungo anche un tu ce ne hai messi tre, se non ricordo male, un quarto asse che secondo me andrebbe anche considerato che è l'autonomia di questo software rispetto alla sua commerciabilità.ovvero spesso ci sono delle aziende che fanno open source solo come bait totale per dire "questo prodotto ti diamo la minima parte della funzionalità come open source" ed eventualmente c'è il modello in cui dice "se vuoi qualcosa di più utile, buttati sulla licenza, buttati sulla parte commerciale che è magari closed source e robe varie".Ci sono anche esempi di questo, in cui i software non sono totalmente autonomi.Comunque, detto questa brevissima partesi su un altro aspetto della commerciabilità, ci sono software che sono davvero davvero open source, vedi node, in cui la governance è aperta.Poi è un caso totalmente non biased il fatto che sia io che Matteo siamo premiri del TSE, assolutamente no.In realtà il problema paradossalmente che per come è strutturato il TSE è difficile spiegare all'esterno cosa cavolo facciamo, la governanza aperta, perché spesso molti pensano "questi fanno il TSE, sono loro a decidere cosa entra e non entra sul node, sono loro a decidere su cosa si lavora sto stemestre, quel che cavolo è", ma dopo non è così.Noi stiamo davvero una governanza aperta nel senso di una sotto specie di moderatori più o meno quindi stiamo qui a dire va bene il progetto non è che può rompere l'ecosistema in realtà la cosa di cui ci occupiamo sempre non dobbiamo rompere l'ecosistema appunto sono quanti mesi sono attraverso il tsi otto mesi abbiamo parlato solo del breaking breaking changes breaking changes rompiamo tutto adesso prossima release rompiamo tutto Nota che cambiamo una property per errore, senza nemmeno discuterla, e ci sono i forconi alla porta.Dove i forconi non sono i contadini, sono gente che clicca fork su un'equità.Sono i forconi pronti a partire, a bruciarci tutti i vivi in quanto erettici, come abbiamo usato noi e rompere qualcosa senza contattare queste persone.Da un anno c'era il breaking change.Sì, ovviamente.Va tanto l'unso.Tutte le volte, capito? Poi ovviamente non era voluto, quindi abbiamo fatto il revert, la cosa si è sistemata, capito? Però la realtà è che appunto si rompe.Non si può rompere niente, ok? Io vorrei rompere tutto il Node.Il principale punto di Node è che noi non possiamo smettere di supportare il passato per cui se io smetto di supportare il passato potrei fare un node che consuma meno memoria che è più veloce che alla metà dei bacchi che ci possono sistemare tutto capito il problema è che come dire se rompi se rompi il passato poi non è più node e quindi se smetti di supportare per esempio Express, io posso fare un sistema HTTP probabilmente il doppio più veloce oggi, togliendo il supporto Express.Scusa, non era Dino questa roba? Il punto qual è? Perchè mi ha beccato il Codemotion che mi chiedeva "ma perché c'è Dino, c'è BAN?" Ragazzi questo è il problema, Nod ha 15 anni noi dobbiamo supportare Oba, che di non si vuole Oban, ma anche senza nessuna polemica verso i drabbi.E' quello il motivo.Quelli fanno open source partendo da un altro punto di vista, soprattutto commerciale, questa è un'altra grossa differenza.Nod non cerca la commercialità, abbiamo una foundation che ci tutela nello sviluppo anche in alcuni casi in ambito economico su infrastrutture e robe varie.Per il resto siamo totalmente volontari, tutti quanti, c'è chi più o meno è è indirizzato dalla propria compagnia, chi no? Ci sono tutte le situazioni.La compagnia è la company, ok? E l'azienda è italiano.Però noi l'italiano non lo usiamo mai.Quindi non usandolo mai, capito, siamo diventati...La compagnia fa molto signore agli anelli, avete ragione.Ah, molto quello! O compagnia delle indie! O compagnia delle indie, secondo me.Dipende quanto coloniale ti senti in realtà.però diciamo l'azienda ti direziona o meno sul node oppure no, oppure ci vai tu, oppure ci vai sacrificando un aperitivo con tua moglie che ti farà scontare, true story, e così via.Ci siamo passati tutti.Quello è proprio open source più puro, poi da quello che è il più puro possibile, mano a mano, come diceva prima Matteo, a seconda di come tu muovi sui 3,5 assiti che abbiamo parlato diventa più closed source oppure quello che io definisco il peggio probabilmente il falso open source ovvero available sources ma il software non è open source ci dovrebbe un altro nome d'accordo? questo è.Io credo che un po' di bold opinion sono uscite in questo in questo blocco ci sarebbe da parlare tantissimo, specie proprio sulla parte etica e commerciale, se esiste un vero punto d'incontro.Guarda, non è tanto la parte etica...Uh, la telecamera si è impazzita, aspettate.Va bene, tanto vado io, andrei a battere la sistema.La parte etica è estremamente soggettiva, quindi quello che può andare bene per me a livello etico magari non va bene per te, ma poi il punto è in qualunque punto tu ti muovi negli assi, la prima cosa secondo me in generale è che tu sia limpido verso i tuoi utenti, per esempio.Nel senso che io non posso spacciarti un software come open source quando in realtà è solamente un bait verso la mia parte commerciale e ti faccio un vendor lock-in appena tu ci metti piede che poi sei costretto a passare alla mia parte commerciale.Se prevedete dei riferimenti ai cloud non è assolutamente così, ci mancherebbe.però vuol dire quella anche etica dubbia chiaro che strategia di marketing chiaro che il marketing e l'etica sono due cose totalmente agli antipodi altrimenti saremmo in paradossi strani il marketing è ovvio che cerca di fregarti tranne che tu entro certi limiti sai che ti puoi far fregare d'accordo il problema è quando l'etica è dubbia ed è effettivamente pensata in troppo in malafede, cioè ai limiti di una truffa, dicendo "ah guarda, perché il nostro software è free?" Poi due minuti dopo "oh facciamo il cambio di licenza e sei fottuto" e poi partono i fork, per esempio.Ah lì, eccoci.Eccoci qua, siamo tornati in vita.Questo è il discorso, l'etica è...Guarda, il problema principale secondo me non è nemmeno di etica, oggettivamente il problema secondo me è più più terra terra in è dalla parte di chi vede le cose per cui secondo me c'è chi si rende conto che il software lo deve pagare in un modo o in un altro e chi è un vampiro ed è brutale io li chiamo i vampiri ok i vampiri c'è l'aglio e il paletto di frassi, ma la realtà è che ci sono i vampiri, quindi dai vampiri bisogna più che star lontani.C'è anche l'etica di chi produce le cose, chi ti racconta delle favole, eccetera, eccetera, eccetera, che puoi leggerle o non leggerle, capirle, fare quello che vuoi, ok? Ma dall'altro lato c'è l'etica di chi legge, ok? E di chi pensa che qualcuno ti regali, secondo me a questo mondo non ti regala niente a nessuno, capito? e quindi tutto quello che ho l'ho litigato con gli unghi e con i denti quindi siccome tante persone invece pensano che tante cose arrivano gratis, capito? e che uno non debba faticare, non debba fare niente per per averle quindi il problema è sussistito - e poi porto un tratto di Matteo su Ex una volta al mese ne metti uno del genere, esattamente - Chi lo segue lo sape.- Una volta al mese sei stato generoso.- Io mi raccordo io perché non capisco la timeline di X, però diciamo che me ne accorgo una volta al mese.- C'è stato un periodo che sbroccava una volta a settimana a riguardo.Adesso è un po' meno.- Però è bello il concetto del consumo/utilizzo di open source consapevole.Ci si potrebbe fare un lungo ragionamento su quello.secondo me è una delle cose che andrebbe divulgata al posto di sventolare la bandiera dell'UPSR, sta al quale o come concetto astratto senza nessun ancoraggio alla realtà che spesso si fa.Quindi secondo me, ve la butto là, un talk sul topic secondo me ci starebbe...Se qualcuno mi prende un keynote io lo faccio, questo lo dico, io sono sempre a disposizione per fare un keynote al riguardo di questo argomento.Però mi prendete per un keynote, se no non vengo.Ascolti facciamo un altro episodio io, te, Matteo e padre Beranti, sa che ci divertiamo tanto, parliamo per 6-7 giorni credo.Open source consuma responsabilmente.No, però adesso parliamo di cose tecniche.L'altro giorno guardavo il vostro blog, ho visto il lancio di VAT e poi ho letto "application server" e in quel momento alla mente mi è ritornato JBoss e ho detto "Oh mio Dio, cosa sta succedendo?" Adesso te lo racconto in maniera facilissima.Ti racconto il problema e poi ti racconto come lo risolviamo.Il problema che abbiamo osservato, siamo da due anni e mezzo in vita come azienda, più otto anni in consulenza, quindi forse qualcosa abbiamo visto.Che cosa abbiamo osservato.Node.js ha favorito questa creazione di cose bellissime, i microservizi, non solo i microservizi ma anche le funzioni serverless.Allora parliamo dei microservizi e poi parliamo delle funzioni serverless.Microservizi, maggior parte delle applicazioni che sviluppiamo normalmente sono applicazioni che hanno poco traffico però io ho un microservizio e le regole di alta fidabilità e altre cose dicono che lo devo deployare in tre copie quindi ho questo microservizio con fai conto non lo so mille righe di codice 10.000 righe di codice fai conto è micro, se non è micro è piccolo e quindi io l'ho deploiato ok e a questo punto l'ho deploiato in tre copie ok di questi qui io però ce ne ho 30 ok fai conto che 30 per 3 vuol dire che sono 90 microservizi che girano ogni microservizio gli devo allocare fai conto un giga di ram, quindi io sto usando, fate voi i conti, 90 giga di ram sul mio cluster Kubernetes.Ora, proprio per renderci chiari, in realtà nessuno ha un solo cluster Kubernetes o un solo sistema, in realtà la maggior parte delle aziende ne hanno almeno 3 o 2 o 3, hanno uno di development, uno di staging e uno di produzione.Ora aggiungiamo, quindi lo moltiplichiamo almeno per tre dai ok e lo arrotondiamo facciamo 300 giga ok posso anche abbonartene un po facciamo 256 ok e ribadisco la maggior questa la maggior parte delle applicazioni che gli diamo un giga di ram senza parlare del problema delle cpu poi perché alcuni come io però voglio anche allocare una cpu per ogni servizio sono mezzo cpu un quarto di cpu ok ora se tu prendi un micro servizio gli dai un quarto di cpu vuol dire che questo coso è è fermo, capito? Quindi che cosa cosa lo devo io a fare? Perfetto! Questo è un po' il punto del problema, il primo problema.Ora se io ho tutti questi micro servizi però, cosa succede? Che quando devo fare una chiamata, devo fare delle chiamate di rete.Chiamate di rete normalmente se siamo interne abbiamo HTTPS nel mezzo, perché se non abbiamo HTTPS nel mezzo, ma non lo so, il business dice che non siamo sicuri, quindi dobbiamo avere le connessioni sicure, se uso TLS ma c'è un problema perché devo fare l'exchange, il setup di queste connessioni ogni volta che la creo, mi partono, fai conto, qualche decina di millisecondi solo perché ha una connessione e poi c'è il tempo in cui mando la richiesta tramite rete eccetera eccetera eccetera cosa vuoi? vuoi che non ci metta 10-20 millisecondi a rispondere? stiamo parlando di servizi velocità.A questo punto sommi tutto, se ne ho 5 in cascata, mi sono già bruciato a spanne.100 millisecondi solo di tempo di rete, non ho fatto niente.Ho bruciato 100 millisecondi.Mi dicono che io devo rispondere dentro 200 millisecondi e mi ho già bruciato 100? C'è qualcosa che non mi torna.Questo è il primo aspetto, il primo problema.Secondo problema, serverless.Bellissima idea.Serverless è una genialata, è fenomenale.Io ho cose che non girano, faccio scale to zero, quindi quando non girano io non pago niente.Bellino, è molto utile.Se ho delle cose che non girano molto utile.Piccolo problema appena cominciano a girare nell'implementazione principale di serverless che è AWS lambda bisogna fare nome e cognomi ok tu paghi la tua esecuzione dal momento che inizia al momento che finisce e esegue una sola richiesta alla volta.Se io faccio all'interno una chiamata a un database io sto pagando per il mio server che stia fermo.Questa cosa da un punto di vista di costi non scala.No JS è fatto per fare io, è fatto per far girare tante cose in parallelo e io ho delle risorse che sto pagando ma non sto usando.Quindi è uno spreco, perché se ho delle risorse che pago e non uso è uno spreco.Nella realtà quindi abbiamo da un lato i modelli attuali che entrambi non funzionano.Per vari motivi non funzionano.Quindi cosa siamo andati a fare? Abbiamo pensato, ma un attimo.Node.js è fantastico.Non era mai stato provato prima.Quindi io posso prendere un'applicazione, posso far girare e forse eseguire più applicazioni Node.js all'interno dello stesso processo.Usando il multitrading.Multi trading c'è dal 2018 quindi è robusto su uno JS ormai.Posso far partire un'applicazione separata dentro ogni thread.Bellino! Ok a questo punto una volta che ho i miei thread separati ok posso fare comunicazione tra di loro però posso anche evitare siccome sono tutti nello stesso processo posso evitare di andare sulla rete posso evitare di aprire delle socket, posso evitare di pagare del pegno al sistema operativo, ma posso rimanere e fare semplicemente della comunicazione fray thread.Ci sono gli atomics, c'è post message, possiamo fare delle cose molto carine.Da qui nasce una buona parte di quello che è Watt.L'altro aspetto è che la maggior parte di No JS è molto raw come runtime.Mancano tutta una serie di cose che le aziende danno per scontate.Come facciamo monitoring? Prometheus? Datadog? Cosa facciamo? Come lo configuriamo? Quali sono i dati che mi servono? Quali sono i dati che mi servono per fare scaling, autoscaling di queste cose? Come faccio a sapere che la mia applicazione sta bene? Ok? Supernoto? Ok? Se io scalo, fantastico problema, questo mi è successo infinite volte in consulenza.No JS se tu gli dai un giga di memoria tenta di usare un giga di memoria, sempre e comunque.La maggior parte delle applicazioni No JS in produzione su Kubernetes sono configurate che quando usa l'80% di memoria il Kubernetes la uccide e la fa ripartire, da cui la mentela principale del cliente è "ah, c'hai un memory leak?" ok, domanda numero 1, hai un memory leak? ok, che memory leak? e la seconda è "la mia applicazione è instabile e continua a crashare".L'hai ammazzita eh! Cioè, letteralmente sei lì e ti continui a infilzare col pugnale e ti fai del male da solo.Se gli dai un giga di memoria lui usa un giga di memoria.Per sapere se stai avendo o meno un leak devi guardare cosa c'è dentro quella memoria.Se tu non guardi quello che c'è dentro quella memoria non saprai mai se hai un leak o meno.Questo è un po l'aspetto.Molto simile l'aspetto per la cpu.Event loop utilization.La maggior parte dei sistemi scalano sulla cpu, sull'utilizzo di cpu.piccolo problema cpu è un proxy molto blando rispetto a quanta capacità residua ho nel mio sistema voglio usare l'event loop utilization.Cos'è l'event loop utilization? mi dice quanti cicli del mio event loop, quanta percentuale del mio event loop è stato utilizzato per quello specifico 3.funziona da dio e dà dei risultati molto più performanti perché posso sostanzialmente predire quanto il mio cip la mio sistema sarà bloccato e quindi posso scalare molto possibile aggiungere aggiungere servizi molto più velocemente quindi vat cosa fa prende e instrumentano gs e instrumenti i vari thread delle varie applicazioni per estrarre queste metriche queste metriche che poi oggettivamente cosa ne facciamo noi le metri usiamo nel nostro prodotto commerciale ma non siamo qui per parlare del prodotto commerciale per cui se siete interessati andate sul nostro sito e finita qui il pitch ok però ecco il concetto è standardizziamo anche quest'aspetto in ultimo standardizziamo anche la gestione dei log se non usate pino state sbagliando ok ma anche se non usate pino e state sbagliando noi vi copriamo lo stesso ok e riusciamo completamente a salvare a salvare i log nella maniera corretta e a e a direzionarli dove volete mandarli, che possano essere su Elastic piuttosto che su Loki, piuttosto che su Splunk.Ovunque li vogliate mandare, però dovete usare Pino veramente perché non se ne po' più.Gli Autopitch li fa appalate.No, no, io vi voglio bene, non usatelo.Io prima un tempo dicevo "no, non usate queste cose, poi chiamatemi e fate consulenza", ma ora non lo posso più dire.E quindi era una soluzione fenomenale al problema.Perché il numero di consulenze fatte nel fissare le promise è altissimo.Ho provato in tutti i modi a evitare certi problemi delle promise quando entravano dentro noi.Non ci siamo riusciti? Ciao, tutto ora per il 2024.La mia domanda è, da una prospettiva di DX, quindi di developer experience, cosa cambia per lo sviluppatore e cosa cambia nell'ottica di DevOps? - Io parlo di DevOps, tu parli dello sviluppatore.O niente, tutto e niente.- Tutto e niente.Allora, il punto è, noi abbiamo usato una regola, il principio d'oro di Watt è semplice.Supportiamo tutto quello che avete, ma ci assicuriamo che quello che state facendo male ve lo sistemiamo noi.punto questo è il principio che creava che diciamo alla base di watt quindi la questione è se tu decidi di usare watt Oggi con codice esistente quindi con la tua applicazione esistente cosa devi fare crea una folder ruota mettici un watt json mettici una folder web e copia il tuo vecchio progetto dentro web hai finito non c'è letteralmente nient'altro da fare a quel punto il tuo servizio servizio o macro servizio che sia, gira dentro VAT, i log li gestiamo, le strumentazioni ci pensiamo noi, monitoraggio dei servizi, auto restart dei servizi, scalamento, scaling così facciamo prima, scaling dei servizi all'interno dello stesso processo, noi li chiamiamo worker, quindi è una replica dello stesso servizio all'interno del worker, il che per la cronaca se state pensando al server side rendering si è pensato per quello e e vi diamo un aumento lineare al numero di servizi e delle prestazioni all'interno dello stesso processo e in tutto questo voi avete fatto cp src dst fine tutto qua VAT è pensato per non mettersi tra i piedi cioè noi vediamo tante cose belle cercando di non trovarci tra i piedi non interrompe in nessun modo il vostro flusso di lavoro, per assurdo potreste persino linkare a Watt una folder esterna se vi va, non vedo il motivo ma nessuno ve lo vieta, e tutto questo avendo cose in più ad esempio togliamo un sacco dei problemi per far comunicare servizi tra di loro, come diceva Matteo togli il networking quando è possibile, togli le porte di rete quando è possibile, per intenderci, se il vostro servizio è su HTTP sotto determinate condizioni molto facili da applicare, voi non dovete neanche più far partire una listen, ci pensiamo noi e facciamo in modo che tutto funzioni in maniera corretta.Vi facciamo merging degli schema OpenAPI e degli schema GraphQL, cosa che prima facciamo in tutto il discorso che abbiamo messo, però nativamente supportiamo la composizione di grafico era la composizione di open api che volete di più questa da parte del dx come developer experience noi vogliamo essere la cosa più facile a mettere senza quasi accorgersene fine tutto qua sulla parte dei box prego a te sulla parte dei box ok puoi prendere watt metterlo nel tuo docker container e funziona tutto ok però ti ritrovi ti ritrovi che puoi direzionare open telemetri con un cambio di configurazione, ti puoi direzionare i log con un cambio di configurazione, ti puoi gestire le metriche compromissius e sono tutte configurate out of the box in una maniera corretta, quindi ritrovi già tutti i valori settati giusti e questo è sostanzialmente.Abbiamo alcune cose nuove che arriveranno nelle prossime settimane che sono molto carine, bene, ma al momento.Quindi state sintonizzati perché vi lasceremo un po' di cose.Ci vediamo tra 4-5 mesi.Un secondo, scusatemi, time out taglia.Stiamo in diretta? Ciao, dopo la tagli questa, capito? Io, se la gente mi apre la porta, capito? Questo è di una scusa.E questo è il best case scenario con VAT, è deploiarlo su un container? Lui è deploiato su un container, ok? In server we believe.Noi sinceramente software in produzione eseguito che fa un minimo di traffic, eseguito modalità serverless secondo me è uno spreco di risorse eseguito su lambda è uno spreco di risorse di caratteri cubitali.Per assurdo è possibile però se vi vengono a scoprire ci provate.Però nel container paradossalmente a parte tutte le cose gratis che abbiamo tipo l'instrumentazione di open telemetry che ti viene gratis e questo mica da ridere al posto di stare là a battagliare a fare tutto abbiamo però se ho capito bene out of the box anche la possibilità di deployare più applicazioni nello stesso e nello stesso container fondamentalmente dentro sto facendo più thread.Quindi tu invece che deployare 10 microservizi da soli li puoi in ognuno nel suo container con non lo so una service mesh, kubernetes o quant'altro puoi deployarli tutti insieme ma soprattutto in development li hai che girano tutti insieme e quindi tu non devi più far partire quelle dieci porte non so quante volte avete fatto partire 10 sistemi separati per far gestire un un sistema di micro servizi e avete sostanzialmente una porta sbagliata e non funziona più niente bisognava diventare il Ciccilinco gli univa il Docker compose con 70.O con il Docker compose e infiniti servizi.Ecco tutte queste cose sono cose del passato.Come facciamo con VAT? Con VAT lo fai partire il tuo Application Server funziona tutto di suo.Ok gli dici qual è la cartella lui le carica tutti insieme.In quel caso quando scali tu scali tutto l'Application Server.quindi li puoi scalare, hai due modelli di scalabilità.Il primo modello è scalo in verticale, posso scalare in orizzontale più copie di questa cosa, ma posso anche dire per ognuno dei microservizi, per ognuno dei servizi che girano all'interno, quante copie voglio di quel servizio.Se io voglio averne cinque copie, posso avere cinque thread uguali e lui automaticamente fa round robin all'interno.Devo avere molti CPU disponibili nel mio pod.- Però le usi tutte, abbiamo fatto dei test e le usi tutte.Cioè il punto è che supportiamo lo scaling intra process o intra pod se vogliamo parlare in termini di Kubernetes e l'inter pod, quindi l'accezione classica di Kubernetes.Tenete conto che anche all'interno dello stesso processo avete le stesse garanzie che vi dà kubernetes ovvero dire diamo il limit loop utilization threshold, il memory threshold, max memory e un url da verificare per vedere se l'applicazione ancora da considerare sana.Se una qualunque di queste non è valida il singolo worker quindi il singolo thread viene buttato giù ma gli altri continuano a girare in round robin che significa che non c'è nessun downtime.Domanda magari un po naive, qual è il costo in termini di memoria, il costo computazionale dell'orchestrator che sta dentro VAT e fa tutta sta roba? Allora la zero non è vero, in termini di memoria di gratis, ok come dico sempre, nier zero.Allora due aspetti.Il primo punto è che non va valutato in questo modo, ma va valutato contro il costo di una connessione TCP, va valutato contro il costo di un processo esterno.Ora, un worker thread è leggermente più leggero di aprire un processo.Un worker thread occupa, appena partito, circa 30 mega di ram ok vuoto senza la vostra applicazione dentro quindi in realtà ci costa poco ok in termini di overhead di traffico ok tu devi compararlo con aprire una socket e cp fare tutto la danza di ccp fare tutta la danza di tls se stai parlando sulla rete eccetera eccetera eccetera eccetera capisci che il vantaggio è immediato usando il sistema di comunicazione tra processi all'interno del stesso processo rispetto al sistema a passare tramite la rete ecco quindi c'è il vantaggio è immediato in quel caso.abbiamo detto che in un ecosistema multipod l'ecosistema iniziale che hai dipinto all'inizio dell'episodio dove ho un container dove ho un NextJS nell'altro dove ho il backend node o l'API node che mi picchia sopra dati o orevere, quella comunicazione avviene attraverso la rete spostando tutto su Watt abbiamo detto che la comunicazione può avvenire in intra process cosa cambia per me come developer? prima domanda, seconda domanda è cosa succede sotto il cofano se eventualmente esiste una trasformazione? la seconda non lo vuoi sapere fidati facciamo magia nera.Vabbè dai non è così malaccio però ti perdi nella comunicazione tra worker e thread fondamentalmente.Ti dico solo per fartela breve che un progetto penso che ha scritto Matteo che è la base di questo sistema utilizza simultaneamente una rete a stelle e una rete punto punto per implementare questa storia.Devi pensare in questi termini.La comunicazione viene gestita in quella maniera.Paolo sono solo tipo 200 righe di codice cioè adesso non raccontare come se io abbia scritto un abominio da 10 ore.No, queste discorsiette le abbiamo già fatte.Allora per chi ci ascolta...345 per la precisione.Allora per chi ci ascolta a Dittor Vergata che ha studiato il professor Pettorossi negli anni 2000, qualcuno ci sarà, se vi ricordate il suo libro com'era è quello di cui parla Matteo.Dici "no ma so poche robe" però ogni riga ci sono l'equivalente di quattro libri di informazione.Ti dice "Ma Rosa, ho quattro pagine".Quello, cioè, Thread Dispatcher, che potete cercare su...11 Thread Interceptor.Ma tu ogni tanto l'ho rinominato quattro volte.No, l'ho rinominato quattro volte.Ecco, 11 Thread Interceptor, cioè, ho tre nomi diversi, ok.11 Thread Interceptor.Sono effettivamente cento righe di...350, adesso, dai.Con l'ultima aggiunta di Marco.Ah, sì, con Luke, sì.Però, sono estremamente dense.Quello è il cuore della comunicazione che si basa sulla messaggistica tra worker thread con particolare routing e soprattutto come dice il nome sul magnifico lavoro fatto da Matteo, da Robert, Naghi e da altri su undici sull'interceptor.Come vedete Watt non è niente di nascosto, tutta la luce del sole è disponibile, leggermente incomprensibile all'inizio ma assolutamente disponibile.Non è incomprensibile.Quindi utilizziamo No JS al meglio possibile e se non ci arriva lo modifichiamo per arrivare lì.Soprattutto l'ultima che hai detto.Quella pure non è indifferente.La domanda è quindi la comunicazione tra le due applicazioni avviene sempre sotto forma di comunicazione diretta ma sotto il cofano c'è Mago Merlino che trasforma quella comunicazione diretta è stata forma di una fetch.Tu utilizzi fetch? Si.Monkey patch a manetta.Niente, zero monkey patch.Non facciamo monkey patch.Io sono contro il monkey patch.Quindi anche io perché non ha mai portato nulla di buono.Siccome siamo entrambi ex rubisti sappiamo che cosa ci poteva con il monkey patch tipo sul rubio robe varie e la potevi molto meglio.Allora noi non facciamo monkey patch perché utilizziamo l'internal di node o l'internal di 11 in questo caso.Sono API pubbliche non sono internal, sono tutte API pubbliche.Ci sarebbe da parlare...ah no perché la vetriatura pubblico il dispatcher, ragione, ok allora giusto giusto giusto.E' pubblico, poi documentazione.Parliamone.Allora vi spiego.Fetch sul node si basa su 11, semplicemente.11 ha un concetto che si chiama global dispatcher, come potete ben immaginare è quello che viene utilizzato in automatico quando fate una qualunque richiesta con 11 o se siete sul node con fetch.Installando un interceptor su quel dispatcher possiamo metterci nel mezzo e trasferire richieste tra thread senza utilizzare la rete in nessun modo.Tutto qua.Chiaro, cioè...è tutto a loro.È chiaro il concetto a strato, l'implementazione un po' meno.Allora Matteo ha ragione di me.Però sono curioso e provo ad andarmela a vedere.Allora, Matteo ha ragione su questa cosa.Il concetto non è molto complicato ma è denso.quindi uno che è completamente fuori dal contesto, c'è un sacco di cose da mettere, da impilare per dire "che cavolo sto facendo?" poi nel momento in cui tu c'hai tutti i pezzettini, effettivamente non è troppo complesso, è solo estremamente denso di informazioni, tutto qui.- Sì, tra l'altro Matteo ha condiviso un link che poi mettiamo nelle note dell'episodio.La cosa che mi incuriosisce a manetta è come la trasformazione dei payload o di tutte le informazioni aggiuntive di una comunicazione HTTP viene poi trasformata per essere trasferita sotto forma di comunicazione intra processo tra thread.Sono stringhe.Sono buffer, sono stringhe.Sono buffer, è binario.Ad oggi facciamo in un modulo ma lo cambieremo perché quello attuale può essere più performante e quello nuovo sarà più performante.Però ancora non ho finito di scriverlo il modulo nuovo.Quando ho scritto il modulo nuovo, quando è finito, poi Paolo farà la review e poi mi tira un po' di uova.Capito? Di nuovo a steme dovute alla densità dell'informazione.Ma lo sai, glielo ho raccontato.però funziona alla perfezione però allora ti do un piccolo aneddoto l'ultima volta che abbiamo parlato di una tecnica simile l'ultimo codemotion un mesetto fa di quello che ti stiamo parlando adesso sul thread dispatcher l'audience era lì per tagliarsi le vene per la vostrusità che gli abbiamo vomitato addosso di colpo quindi essendo un audience non not specifico, che stanno a parla.A proposito, appello pubblico, ve prego, se sapete che il talk è tecnico e non siete denod, non ve ne ripenite l'assenti, vi fate solo del male.Ma no, invece imparano, non è vero.Io sono assolutamente d'accordo.Andate a vedere i talk difficili, così imparate.Aspetta, non difficili, non è quel problema, è il fuoricontesto.- Se tu non ti sfidi mai, non provi a imparare cose nuove, non supererai mai il tuo livello.Quando talvolta andavo a vedere i talk su QCon o altre conferenze di questo tipo, i talk più interessanti per me erano quelli degli altri Runtime, per vedere cosa stavo facendo."Ma tu c'hai il background, immagino che lui non ha il background, ma ha i thread di spazi e il giorno dopo si butta da un ponte e dice "Vabbè, posso così".Vabbè, stiamo divagando fortemente, lasciamo perdere.Per tutti voi che siete usciti da un bootcamp, non siete in tanti, studiate.Se n'è tanta da studiare, quindi studiate.Zeppata.No, per la realtà.però a questo punto mi servite nel piatto d'argento una domanda/provocazione a cui risponderà Paolo così no perché noi ne abbiamo parlato in lungo e largo del fatto che oggi non abbiamo più javascript developer o node developer ma abbiamo framework specific developer che è un po' come freno coda alla fine.Fondamentalmente quanto tool come VAT, tool come il framework di turno, astrae tanto di questa complessità da rendere le persone veramente ignare di tutto succede sotto e quanto responsabilità è di framework facili da usare che nascondono tanta complessità.Allora quanto mi vuoi politically correct? Non ti voglio politically correct.Allora si riassume sempre in un punto, aspetta, spezziamolo in due la questione.Riguardo i tool, dipende molto dal tool e tornando da dove siamo partiti dopo insourcerobbevarie, dipende anche dallo scopo del tool, perché un tool che è veramente pensoso, quindi non ha nessun intento di acchiapparti in qualche modo, probabilmente ti toglie solamente quello che veramente è inutile, totalmente totalmente inutile.La butto lì se uso vede una volta, non è che ogni volta mi ricordo al costruttore di pino perché a un certo punto diventa totalmente inutile la stessa identica configurazione.E il fatto che il tool lo faccia per me non toglie nulla dal mio effort di sviluppo perché mi devo concentrare sulla business logic, sull'architettura e quant'altro.Quindi quello è un discorso che dipende dal tool, cosa ti vuole far fare, cosa non ti vuole far fare e quale problema vuole risolverti.Soprattutto partiamo dal presupposto che tutti noi possiamo risolvere i problemi risolti dai tool ed è per questo che esce un front end ogni 5 minuti, però il problema è quanto tempo abbiamo perché tutti quanti sottovalutano il fattore tempo è fondamentale su tutto.Buono, noi tutti e tre siamo genitori di bimbe piccole e sappiamo che fondamentalmente il tempo è la più grossa risorsa che abbiamo, a prescindere dai soldi praticamente.Per quanto riguarda l'altro sviluppatore, quanto ti vuoi affidare ai tool? Ti puoi affidare ai tool tanto quanto tu è sicuro della tua posizione di lavoro, ma sappi che se ti affidi 15 anni a un tool e vieni cilicenziato sei fottuto, te ne vai sotto un ponte.Punto.perché nel frattempo tu sai usare una cosa oppure una parte di una cosa non ti sei più aggiornato non hai provato sfide nuove non hai fatto niente di niente se poco poco ti cambia la comfort zone la tua comfort zone sparisce sei totalmente inutile nel frattempo hai perso 15 anni di vita e ci sono ventenne che ti fanno il culo in cinque minuti punto e valutazione posto rischio se tu sai che stai lì per sempre e nessuno lo sa quindi non esiste affida del tool ma poi il punto è Alla fine, alla sera, ti devi guardare allo specchio Se tu ogni giorno fai un lavoro noioso, perché a un certo punto il tuo lavoro è sempre lo stesso, come dite voi, crudino della chiesa Quoto Githubar totalmente, a un certo punto ti romperai le palle e ti vuoi suicidare la serenata Oggi non so perché parlo solo di punti, c'è gente che si ghetta ma rimane quell'idea D'accordo? Eh però è così però così, cioè va l'anno di fondo con jump, mentre la gente si va a buttare sotto all'ernesimo crude, mangia tutto che palle, io dico sempre a mia moglie, pure quando andrò in pensione farò la stessa cosa, voglio dire, se mai andrò in pensione, perché mi diverto a farlo, mi romperrò le palle dopo un po'.Tutto qua.Sì, sì, no, la mia domanda era legata al fatto dell'onboarding, no? Matteo l'ha introdotto dice venite ascoltate talk che sono anche ripidi in termini di learning curve a me è capitato al Fosdam di entrare in stanza e sentire talk e uscire dalla stanza e dire non ho capito un cazzo di niente di quello che stavano dicendo giusto hai fatto bene invece quando si parla di sistemi operativi o si parla di cose molto molto lontane però intanto tu hai uno stimolo, magari senti una parola o qualcosa che approfondisce e ti si apre un mondo, a me è successo un paio di volte.Però mi chiedo, sai, nell'avere delle astrazioni, layer di astrazioni sopra, poi si perde di vista elementi fondamentali.Faccio un esempio, la prima cosa che ho notato quando ho iniziato a studiare Rust era che se non hai capito come cazzo funziona la memoria che cos'è l'IP e che cos'è lo stack tu non lo usi punto e ma mi sembra anche normale punto cioè non è che forse lo usi e poi non sai se la RAVE va là e la stringa va da un'altra parte e ma sei ma giochista se utilizzi un sistema a basso livello perché la gente si pensa che Rust è alto livello, ma in realtà è a basso livello e se tu lo usi come ci vuoi utilizzare, usi JavaScript e potremmo avere comunque una parede sì che la gente crede che JavaScript non abbia memory leak, ma lasciamo perdere, se no Matteo mi parte per tre ore Matteo, ma il punto è...Tenetemi, controllatemi.Lasciamo perdere, l'abbiamo già parlato a lungo, è ovvio che devi sapere quello che stai facendo, cioè è normale, ma come...altrimenti là mostri anche l'incoscienza del fare questo lavoro.Cioè secondo me è quello.Poi è chiaro che Matteo su questo ha totalmente ragione, tu non puoi andare in una conferenza in cui non ti porti nulla a casa.Anzi in realtà ne parlavo stranamente stamattina con mio cogli in auto.Il punto è, se tu vieni a una conferenza, a parte vivere la giornata di festa, la giornata in mezzo alla conferenza, o meglio di festa, siamo tutti socialmente a accordo, quindi di di grosso modo festa, in un bel ambiente in cui ti puoi sfogare e parlare della tua passione, ma non ti porti nulla di nuovo a casa, è equivalente a che ti sia andata a fare una serata al pub praticamente.Però il pub te costa 5 euro, una conferenza te costa 2,50 il biglietto, quindi è un attimino economicamente sconveniente.No? non so, forse un po' troppo civico, non lo so, però alla fine è quello.Sì, io credo di non avere altro da aggiungere a quello che hai detto, era abbastanza transcianco siccome...Un po' crudale, lo sappiamo.No, no, sono d'accordo con te, la mia preoccupazione continua è che, confrontandomi spesso con con con con Junior e Mid e che veramente la creazione e l'uso di questi tool spesso non è affiancata a una una un'altrettanta formazione, no, del dire che cazzo sta succedendo sotto il cofano.L'esempio l'esempio dell'event loop, maestro, quante persone che usano, adesso il trigger Matteo ed è pronto a parlare per altre...Sì, sì, vai, sono pronto, carico.Guarda, io l'ho detto a James l'altro giorno.James Nel ha fatto un magnifico talk al NodeConf EU e io alla fine ho detto "Già, James, mi hai messo in imbarazzo, perché io che sono Node TSE, non ho idea di come cavolo funzioni l'event loop, almeno non al dettaglio che tu hai fatto vedere nel talk".Poi magari, chiaramente, non so dove andarmela a studiare, quando mi serve, però fino a ora non mi è mai servito, probabilmente ci sono tre persone al mondo che lo sanno sì probabilmente una in questa goal, l'altra ci ha fatto il talk, la terza sarà Joy no no, ce ne sono di più, probabilmente Ben Northausen ok ma come vedete sono conferenti quando abbiamo scritto la guida sull'event loop che cosa che mi diverto a chiedere a 100% delle persone che dicono di essere esperti di uno JS è la mia tipica domanda.Cosa che avevo preparato per il colloquio con te prima di entrare nella zona di lavoro? E' lì, io lo dico a tutti e lo dico più volte pubblicamente, capito? Giusto la chiedo sempre, giusto? Se tu dici che sei esperto di OGS io ti chiedo di giustificare questa cosa.Normalmente le persone cascano miseramente quindi io mai quelli che mentono non mi piacciono.questo è un po' il discorso quindi se vi fa l'intervista Matteo la risposta è sei esperto in OGS si conosco l'event loop no la risposta è l'uomo senza sbagliare così non si può sbilanciare si che poi conosce profondamente l'event loop come dicevamo è una roba un po' non neanche complessa domanda Quanto poca divulgazione è stata fatta sull'event loop? Quali sono le difficoltà di veicolare questo tipo di concetti? Ah bellissima la domanda, ti do la risposta.La maggior parte delle cose sono state fatte da trainer, formatori, educatori, divulgatori, senza studiare, senza andare a vedere come funzionavano veramente le cose.Sono state fatte nel 2015 e non più aggiornate.Per cui tu capisci che il software cambia e se tu non aggiorni i tuoi corsi e continui a insegnare la stessa cosa, tu rimani completamente fregato.Infatti questo è anche un altro problema.Quando tu hai le risorse online, ci vorrebbe per chi è fan del professor Barbero, che ogni tanto nelle sue lezioni dice "Bisogna verificare le fonti di racchette e questo chi l'ha detto?" come il discorso sulle fake news.Se la gente digerisce il primo tutorial che trova a caso su Medium, Ashnod, quel che ti pare, e ci ha dato a 2015, che nell'informatica è un'altra area geologica, oppure anche recente, ma tu non trovi una seconda fonte che ti dica la stessa cosa...- No, no, ma la trovi.Il problema è che la trovi, Paolo.- Sì, perché non copia e sono tutti copie in colla certo.Il livello di disinformazione su Node.js ha raggiunto dei livelli assoluti tant'è che anche persone che dovrebbero essere estremamente competenti, autori di moduli usati dal mondo su npm, pensano che il tutto sia il contrario di tutto e gli agini volano.su cose banali.Quanto la documentazione di node ha responsabilità qui? domanda, provocazione eh? io sto solo rompendo i coglioni in questo episodio.No, non ho detto di documentare, allora sai qual è il problema? perché se la vedi dal punto di vista dell'usabilità come la vedrebbe noi UI designer non è che sia proprio il massimo della consultabilità.Da quel punto di vista possiamo fare decisamente di meglio.Come esaustività c'è scritto tutto però.Cioè noi nelle piarde in onde se non c'è documentazione non passano.Da un punto di vista di reference è perfetta.Da un punto di vista di guida per imparare Node.js è molto mancante.Questo nasce un po' dal problema dei volontari.Chi è che contribuisce un corso o una guida per imparare No JS gratuitamente quando lo può prendere e vendere? Ogni riferimento a persone infatti è puramente casuale, ma comunque voglio dire, cioè effettivamente la gente ci mangia.Ma non è la vita, capito? Non è...- Cioè ne mancano le guide, la consultabilità dell'API reference è discutibile.- In realtà, ritornando proprio sulla documentazione, c'era un po' di tempo fa, sono capitato su un framework per la stesura di documentazione, probabilmente voi lo conoscete già, si chiama di Ataxis ed è stato fatto dentro Canonical ed è un, lezzi, una guida, no? Che spiega grosso modo come deve essere la documentazione.Io ne ho parlato a lungo qua nell'episodio.Io non so se vedete il mio schermo.Sì, se nessuno...e questo è molto figo perché fa capire come dovrebbe essere strutturata la documentazione analizzando su due assi la parte diciamo relativa all'azione e all'apprendere fondamentalmente gli elementi per la stesura della documentazione completa sono da una parte la reference che fa informazione le auto guides che guidano l'utente verso un goal specifico, che possono essere i famosi autou che troviamo su qualunque tipo di framework commerciale, la parte di tutorial e la parte di explanation.Soprattutto questa parte secondo me è fondamentale.Se le auto guides e i tutorial possono essere delegati al medium di turno, al blog di turno, secondo me la parte di explanation e di reference deve essere quella curata in modo più più più più maniacale ed è un casino da fare - si voglio - ed è oggettivamente un casino perché specie se stiamo parlando di un tool o un framework o un qualunque cosa che è guidato da una comunità con un gruppo di volontari che ci dedica il proprio tempo libero.Cioè questa cosa è da una parte è marketing e un gruppo di volontari questa parte non la cura però nel contempo è anche divulgazione.- Chi paga per fare tutto questo? - La domanda è sempre quella, chi paga? - Anche quando pagano, io ce lo racconto sempre, c'è due cose in questo, quando io la sviluppo FAT per platformati quindi mi paga il signor Collina e il signor Romaraska in particolare, il problema è che potrei scrivere tutto FAT ma se devo scrivere due ricredi con documentazione torno di nuovo al suddetto ponte di qualche minuto fa, cioè non ho voglia di scrivere la documentazione.- Paolo, vai a scrivere la documentazione.- Eh, lo so.Ma te dice, "Matteo, scrivi due cose, scrivi sia ISNOTE che scrivi documentazione".Sono due commenti che vedo più spesso su Slack, quindi immagina.D'altro canto, nel mio caso specifico, questa cosa la feci davvero all'università.Feci un progetto di reti di calcolatori, dissi ai miei colleghi, "Vi scrivo tutto il codiceio se non tocco una riga di documentazione".stavo a quei livelli e come invece ne stanno altri allora tu le pia reference la scrivi, il tutorial lo scrivi ma quando si tratta di scrivere un'explanation quindi un deep dive a basso livello di alcuni internal che sono fondamentali per utilizzare il tool correttamente ti vuoi sparare poi magari per carità c'è chat e gpt che ti toglie la parte noi usata le scatole ci scrivi due frasi e le espandi, di grosso modo va bene, però devi puntuare tra le legge e così via.Sì, il discorso è che spesso l'explanation è esattamente quello che porta revenue in un progetto open source o supporto.L'explanation...Cioè l'esperto che viene, ti fa il workshop in azienda e ti spiega nel dettaglio come funziona quella roba tu lo paghi soldi sonanti ok? Lo paghi bene? Dovresti.In teoria però il workshop ha più valore dell'explanation perché poi viene un feedback diretto per esempio in questo caso cioè se tu lo cerchi per supporto commerciale o piuttosto affidarmi una guida direi a chiamare la persona e direi guarda ti pago il viaggio da me.In modo tale che se ho dubbi specifici per il mio caso, tu mi fai un workshop specifico per il mio caso che è estremamente difficile e vado a coincidere con un tutorial o con un explanation.Perché poi ognuno ha proprio la propria decisione, lo sappiamo.30 anni di consulenza in tre, sappiamo le esigenze dei clienti sono molto diverse.Alla fine.Guardavo l'orologio, siamo già a un'ora e dieci e dobbiamo avvicinarci alla chiusura.Prima di chiudere abbiamo...dobbiamo insomma dedicare un momento a ringraziare chi supporta il podcast, se l'applicazione non fallisce e allora salutiamo e ringraziamo i donatori.questo questa settimana dobbiamo ringraziare un donatore che è giuseppe piopaprusso che ci lascia anche un messaggio scusate per non averlo fatto fatto prima grazie per l'impegno, la passione e la simpatia che mettete in ogni episodio.Un abbraccio Giuseppe.Grazie a te Giuseppe per averci offerto le tre birre che virtualmente consumiamo in questo episodio.A questo punto è arrivato il momento tipico e topico di GeekBuddy, il momento in cui noi condividiamo con voi un libro, un sito, qualunque cosa abbia catturato la nostra attenzione e pensiamo valga la pena essere condiviso nella nostra community.Quindi è arrivato il momento del Paese dei Balocchi.Riconducono il Paese dei Balocchi.Ah, il Paese dei Balocchi.Allora qua la domanda è chi vuole iniziare? Si vede che siamo impreparati? Manca la preparazione.Ce l'ho uno io, uno al volo.Un sito di cui devo ritrovare il link, però visto che buona parte di noi stiamo su Mac su Linux, ve prego levatevi da Windows, ve prego, ve prego, ve prego.Paolo, lo sai che è il tuo incubo, rimarrai il tuo incubo.Perciò ci provo, no, vabbè, non ha resi...rimarrai il tuo incubo.Dovrai continuare a dare supporto.Porca miseria, è il santo pezzetto del mio tempo, voi non avete idea.Vabbè, parte crudeltà su poveri panda molisani indifesi, allora, il link che vi vorrei condividere io è una repo chiamata Modern Unix.Ora, che cos'è? Sicuramente tutti voi avete famigliarità con il concetto dell'era e poi chiamate OSOM qualcosa OSOM Vim, OSOM Ruby, OSOM Rust, OSOM quel che vi pare C'è questa Modern Unix, che cosa fa? Siccome a tutti noi ci piace la CLI Vi dà alternative moderne per i tool Unix classici Perché voglio dire, se stiamo negli anni 2024, magari è il caso di non utilizzare più, che ne so, GREP che è stato fatto negli anni '70 Quindi c'è GRIP GREP E così via Modern Unix, dopo lascio Mauro il link così ve lo mette in descrizione e divertitevi E adesso Matteo, tocca a te! Io non ce l'ho, cioè, io non ce l'ho Ripetimi la consegna così mi viene in mente qualcosa Dammi altri 5 minuti di pensiero Si è mutato Mauro si sto parlando mutato, un libro, un tool, un film, un vino, qualunque cosa ti vada da condividere con noi.Allora che cosa posso condividervi? Io vi condivido una cosa secondo è molto bella.Non so quanti di voi abbiano apprezzato le qualità di scrittore di uno dei più grandi sviluppatori italiani.Ho avuto la fortuna di fare la pre-lettura, da leggere in anteprima.Io non posso che consigliare a tutti di leggere "WAP" di Salvatore Sanfilippo, a.k.a.Antirath, che ha scritto questo libro sull'AI, secondo me è bellissimo, è proprio uno dei pochi libri che secondo me è fattuale.Normalmente i futurologi si inventano le cose.Il futuro che purtroppo Salvatore descrive, distopico, secondo me è molto concreto nelle cose che succederanno, in particolare questo futuro fantascientifico da un punto di vista di tecnologia disponibile, ma d'altro canto di catastrofe ecologica, se vogliamo.e questo libro secondo me racconta un po' l'evoluzione dell'AI e quello che si porrà per avere e che si porrà le domande che ci porreremo come specie, come abitanti del pianeta Terra nei prossimi anni.Ecco, secondo me è molto filosofico, è un libro molto filosofico, molto bello, ok? e che raccomando a tutti di leggere, ok? Perché appunto l'ha scritto prima che l'AI facesse il boom, ecco, quindi voi capite quanto ci vede lungo.e io ribadisco che secondo me è una delle cose più belle che potete leggere oggi.Quindi io ve lo consiglio e spero che voi lo andiate tutti a leggere.Tra l'altro è stato più di una volta nominato nel nostro episodio e abbiamo fatto un episodio specifico proprio sul libro un po' di tempo fa, quindi super.Io ho un balocco del quale non ricordo il titolo, fatemelo trovare perché è un libro che sto leggendo ma il titolo non lo ricordo.Insomma non sta nel mio corso.Vi dico, sì sì, Humble Bundle, è stato pagato il libro, non ti preoccupare.Ok, ok, l'ho trovato.Il titolo è "Continuous API Management" ed è un bellissimo libro che guarda alle API in ambito enterprise parlando di come vengono gestite le API in un enterprise.altro bel topic magari ci si può fare un'altra puntata la governance sulle API credo che sia uno dei tasti dolenti di quasi tutte le enterprise no? e questo libro è veramente carino quindi ve lo metto nelle note dell'episodio è continuous API management di Orilli è uscito in un humble bundle dove c'è un sacco di libri sulla software architecture qualche mese fa quindi potete procurarlo Bien, bien, bien, siamo arrivati alla fine dell'episodio intanto io voglio ringraziare Matteo e Paolo per essere venuti a trovarci grazie, grazie davvero.Onestamente siccome siete tutti e due esperti in materia, se vi va una di queste settimane quando sarete un po' meno pressati dalle scadenze dei rilasci visto che avete un rilascio grosso la prossima settimana, avete detto no, tra un paio di giorni, quando sarete un pochino più rilassati se vi va di venire possiamo parlare davvero di API governance e io so che ne avete tanto da dire.Io sono cattivo, mi puoi avere quasi quando vuoi, basta che chiedete.Capito? Io ogni tanto vengo se volete a raccontare delle delle opinioni cattive.Capito? Poi mi dai degli spunti in realtà, perché poi mi viene in mente che devo fare dei talk, devo spiegare delle cose.Quindi devi essere cattivo o devi fare dei talk? Devo essere cattivo, devo fare dei talk in cui spiego delle cose che la maggior parte della gente non si è, dei problemi che non sapeva nemmeno di avere.Allora, se pubblico caro, se voi pensate che Matteo sia cattivo, pensateci dove che fa tutti i giorni.Questo è il te cover.Sto scherzando, sto scherzando ovviamente, mi dovresti licenziare.Però, però...Dopo ci vediamo, dopo ci vediamo.Facciamo guano guano.Guarda, io credo che proprio il top della cattiveria Matteo, almeno l'ho vissuta io quando assegnava delle issues o delle stories perché erano aliene ricordo ancora Matteo un problema con lo spinner di...di cosa? di...ah! Dio! - Adesso sono curioso - Del benchmark in tutto Mi viene bombardier - Autocannon - Autocannon - Autocannon - C'era sulla punta della liga, c'era questo spinner fatto con ora che attaccava event listener a cazzo e non si capiva dove cavolo attaccasse questi event listener non si è capito dove li attaccasse - Ma poi ma, almeno Altecrea creava la e-show, a me se ne è scinciata con "C'ho una cosa divertente per te" - E già là Paolo trema sulla sedia - E se lo faccio, allora si direi come dire, una sfida tra il Halloween e i Holiday - Divertiamoci un poco - Grazie, grazie davvero ragazzi per essere venuti Faccio vedere una cosa, prima che andate via, vi faccio vedere un anteprima di quello che sto facendo in questo momento.Posso scollivere lo schermo? Sì, vai.Io vi faccio vedere cosa ho fatto durante questa presentazione, durante questo episodio.Il livello di disagio è elevato.aspettate un secondo, devo fare così, ok, dove è? Non sta andando, capito? Io ve lo devo, ve lo volevo far vedere ma sto fallendo.Nel frattempo piccolo lancio commerciale, se volete c'è la nostra maglietta online, quindi andate nello shop e potete acquistare la maglietta del video terminalista, metal meccanico.Oh, la maglietta del video terminalista - Giallo, giallo la scuola.- Bellissimo.Ok, guardate adesso io cosa sto facendo.Notate cosa c'è qui in questo schermo.- Aspetta, il Mauro non lo sta facendo vedere, io non vedo nulla.- Aspetta, non sta andando.- Ma mi sa di Mauro dove metterlo in...eccolo qua.- Guardatelo tutti, guardatelo tutti.- Cosa cavolo.- Runtime Service Exit.- Guardate qui, è Windows, ok? Io ho la mia VM Windows e sto litigando, quindi capite quello che stiamo facendo io e Paolo in questo momento.e parliamo che Windows è il problema, vedete che cresce e non capisco il motivo.Non usate Windows di prego, non lo so più.Questo è il problema.Io ve l'ho solo voluto far vedere, capito, in modo da rendervi partecipe del disagio.Guarda, la metto così.Se non ci fosse stato Windows, BAT sarebbe uscito due mesi fa.True story.quanto mi abbia rallentato windows per lo sviluppo voi non potete avere idea perché comunque windows è comunque supportato completamente funziona tutto completamente e masochisticamente aggiungo fantastico detto questo io vi do appuntamento alla prossima settimana ciao ciao siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo ma il Gitbar è davanti a una birra, tutto ci sembra un po' meno grave.[Musica]
