Siamo noi che nonostante il deploy fallito, la CI rossa, il business incazzato, ci troviamo al Gitbar e davanti a una birra tutto ci sembra un po' meno grave.Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Siamo già a gennaio, in realtà gli ultimi episodi in qualche modo, anzi l'ultimo episodio programmato risaliva prima di Natale, abbiamo parlato di CQRSS, quindi probabilmente avrete sentito dei salti temporali, si parlava di una settimana prima, ma non era così.Insomma, se vi siete sentiti un po' straniti da quell'episodio non preoccupatevi perché è stato registrato circa tre mesi fa e l'abbiamo riproposto la settimana scorsa.La settimana scorsa, oggi perché stiamo registrando giovedì scorso.Vi ho confuso abbastanza.Ok.Interstellar era più facile.Detto questo io presento...Scusa Matti? Interstellar era meno complicato di così.Sì sì ma sono io che non sono in grado di spiegarlo ma non preoccupatevi non è successo niente.Mattia l'abbiamo già annunciato, si è annunciato.Ciao Matti, con noi c'è anche Carmine.Ciao ragazzi buonasera benvenuti sul podcast più bello dell'internet.Aiuto questo che anche tu di solito era Mattia che entrava in fase ASMR invece oggi ha una bella voce spingente.Oggi che io posso parlare come una persona devi parlare tu con la voce sexy.Cioè poi se volete io posso comunque fare la voce sexy lo stesso sapete che non problema.Allora il paese dei balocchi lo facciamo tutto così.Aiuto no io direi di no però vanno alle ciance.Il mio balocco è un spray che puoi spruzzare e poi puoi spolverare con un pennellino.Puoi pulirci sia la tastiera che...tipo così e lo lasciamo.Ok detto questo io direi che possiamo ricordarci rapidamente i nostri contati info@gitbar.it @brainrepo su twitter e sto dimenticando qualcosa no no niente perché il nostro gruppo telegram è il gruppo telegram più più più più bello del mondo e potete trovarlo digitando @gitbar nel vostro client di telegram preferito e siamo aspetta che ce l'ho qui ora live così anche con il numero possiamo dare quella dimensione temporale questo momento siamo 1526 persone quindi venite si parla di cose assolutamente non noiose e non ripetitive mi raccomando Gitbar e non Gitbar Italia.Detto questo io vi ricordo rapidamente anche il nostro canale YouTube che è nuovo siamo ancora pochini ma stiamo crescendo e quindi se non l'avete ancora fatto cliccate sulla campanella e iscrivetevi cliccate sul campanaccio per rimanere rimanere aggiornati ma bando alle ciance oggi abbiamo un ospite sono posso dire anche di cliccare sugli ad di youtube in modo da pagarmi lo stipendio ognuno tira l'acqua alla sua carretta e va bene cliccheremo sugli ad di youtube non so se li mette gli ads su github Spero di no, non so...Cioè...Cioè spero di sì per te, spero di no per gli ascoltatori di Ghinsa...Non ho capito un cazzo, vabbè...Facciamo così, che tagliamo questo pezzo che ci stiamo un po' intrippando...Detto questo io direi di presentare l'ospite di oggi.Abbiamo con noi un amico, un collega ma anche un grande professionista...Staff Engineer a NearForm.Abbiamo con noi Matteo Pietrodazzi.Dazzi.Ciao Matteo, come stai? Ciao Mauro, ciao Mattia, ciao.Grazie mille per l'invito, sto molto bene e devo dire che fa un certo effetto passare da ascoltatore ad ospite.Fa molto piacere personalmente.Il piacere è tutto nostro come si suol dire e non è una cosa detta così per dire ma perché oggi ti sfrutteremo al massimo.Io direi prima di iniziare alla chiacchierata con te di fare un piccolo giro e provare insomma a mettere a fuoco il topic di oggi.Quindi inizierei così ciao sono Mauro e non faccio front-end da circa due anni e spiccioli.Ciao sono Mattia e ho scritto del CSS nelle vacanze di Natale ma non facevo del front-end da credo 5 anni.Ciao sono Carmine e copio e incollo le stesse classi di Tailwind ogni giorno.Io invece sono Matteo e non tocco un micro front-end da due ore.Micro front-end ok hai già anticipato l'argomento di oggi.Passato di moda tipo il micro front-end, siamo ritornati al monolite.No, non diciamole queste cose.Allora Matteo prima domanda in realtà.Si è parlato tanto qualche anno fa di Microfrontend.Io ricordo iniziai, bellissimo, iniziai ad approcciare al Microfrontend, questo questo lo devo dire sottovoce, per preparare un corso.Io ho tenuto un corso su Microfrontend circa più di tre anni e mezzo fa, quasi quattro, quando Microfrontend in action, forse, il primo libro su Microfrontend non era ancora uscito.E la cosa divertente è che feci questo corso partendo dalle server-side includes.Poi mi ricordo che c'era una libreria chiamata Luigi o qualcosa del genere.Mi ricordo che c'era qualcosa che veniva da Zalando all'epoca, Zalando aveva sviluppato qualcosa di interessante e poi c'era un framework, se framework si può chiamare, un tool perché a questo punto veramente io non so più come definirli, che era Single SPA.Quindi la mia domanda è cosa è cambiato da tre anni a questa parte a oggi nel mondo dei micro front end? Ma guarda ti dico personalmente magari ridurlo sui tre anni ti posso dire che è un po' riduttivo.Tieni conto che allora io cominciai a lavorare nel 2016 e già come prima esperienza lavorativa ho avuto la fortuna/sfortuna, dipende da che punto poi lo guardi, di lavorare primo progetto, primo lavoro direttamente con Miko Frontend, quando ancora non si chiamavano Miko frontend.Lavoravo per una banca italiana, se ci ascolta il responsabile, ciao Marco, dove appunto venivano messo a disposizione un prodotto che si chiamava...non so se posso dirlo...sì sì, non abbiamo...Allora, che si chiamava BackBase, che ti dava la possibilità di configurare le tue pagine e e montare dentro ciascuna di esse quelle che prendevano il nome di widget.Quindi tu avevi la pagina tappezzata di queste widget e già quelle erano definite i tempi Microfrontend, perché erano proprio delle porzioni piccole piccole, ai tempi scritti addirittura con AngularJS.Le cose sono cambiate, sì, assolutamente, giusto per tornare alla tua domanda.Questo perché? Perché anche gli approcci un po' sono sono cambiati.Tu prima appunto citavi Taylor di Zalando che ormai è stato praticamente deprecato, è archiviato su github, non lo utilizzano.Anche quello personalmente non ho mai avuto modo di provarlo, ma so che ai tempi appunto era molto in voga e lo stesso che hai citato anche tu, il single spa che agli inizi era l'approccio più semplice perché gli sviluppatori erano concentrati, o meglio, erano abituati alla scrittura di single page application e quello che single spa faceva era "ah ok, tu stai cercando di montare il tuo entry point in React.Aspetta, io ti metto a disposizione tre funzioni, mount, unmount, la terza non me la ricordo, sono un errore fresco.Comunque, preso quello, io poi riesco a montarti dove ti serve, con questo lifecycle abbastanza ridotto, la tua single page application e rendertela così un unico frontend.Nel single spa comunque poi, che comunque è ancora mantenuto, forse non più come un tempo, ma ancora mantenuto, poi è nata un'altra libreria on top di Single Spa che si chiama Kuyankun, che cercava un attimo di offrire qualche funzionalità in più.Questi appunto erano, diciamo, gli approcci, chiamanole così, iniziali, quando un po' l'argomento è esploso.Da lì c'è stato poi una una sorta di, non vorrei dire roadmap perché non c'è niente di pianificato, ma c'è stata comunque un'evoluzione per cercare di definire quali sono gli approcci e anche cercare un attimo di definire quelle che sono le metodologie, mettiamola così, moderne.Volevo farti una domanda proprio sul concetto di Micro Front End, no? E se secondo te c'è stata un'evoluzione? Io ricordo qua avemmo più di una volta Luca Mezzalira che appunto parlava del topic.Se ricordo bene all'epoca lui era in da zone e in da zone avevano comunque dei tool abbastanza custom, se ricordo bene, per gestire appunto i micro front end.Però voglio chiedermi una cosa.Io ricordo che uno degli elementi che portò Luca con appunto la sua prospettiva più da architect, quindi più architetturale, era il fatto di avere tanti team verticali, orizzontali scusami, quindi che ne so, un team multidisciplinari dove c'era il designer, dove c'era il backender, il frontender per cui il dominio affettato a pezzi e questo affettamento andava a toccare anche la parte frontend che poi andava in qualche modo orchestrata ed era un modo per proiettare l'organizzazione nel software che si sta facendo un po' per rispettare la famosa legge di Conway che dice che ogni software in qualche modo rappresenta la struttura dell'organizzazione.Allora mi chiedo oggi, sono passati diversi anni ma oggi la problematica che i micro front end vogliono risolvere è ancora la stessa se purghiamo il tutto dalle mode e dai fronzoli che sono? Allora personalmente mi sentirei di dire sì, tieni conto che nel momento in cui tu devi dare una definizione al concetto di micro front end, partiamo dal presupposto dicendo che il micro front end di per sé essendo uno standard de non hanno proprio una definizione specifica.Ogni persona che li ha approcciati e ci ha lavorato ha cercato di dare la propria definizione.Cioè abbiamo ad esempio Michael Geers che ha fatto l'owner del sito microfrontend.org, che dice che è un concetto che estende ciò che già sappiamo dei microservizi al mondo del front-end.C'è un articolo molto interessante sul blog di Martin Fowler, di Cam Jackson, che dice che i micro front-end sono uno stile architetturale che permette appunto di rilasciare piccole applicazioni front-end in maniera del tutto indipendente e di essere di conseguenza composte in un insieme, chiamalo così, più grande.Quello che stavi definendo tu prima, ossia l'affettare pezzi dell'applicativo secondo diversi approcci, è un qualcosa che appunto Luca Mezzalira, che già citavi, ha documentato molto bene in un articolo che si chiama "Microfrontend decision framework", liberamente consultabile su Medium, liberamente tra virgolette, poi dipende un attimo dal paywall di Medium, però molto carino perché ti spiega un attimo quelli che possono essere gli approcci per dire "ah ok, io ho il mio pezzettino, nel momento in cui voglio arrivare alla vista finale, come posso fare, cosa posso fare".per quanto riguarda lato utente ci possono essere delle suddivisioni, prendono il nome di "vertical split" e "horizontal split".Sono un po' autoesplicatori, però vertical split vuol dire che presa ad esempio una pagina, ciò che l'utente vede, quella è un solo micro front-end, quindi l'intera visualizzazione di quella pagina è un micro front end.L'horizontal split, invece, vuol dire ho più micro front end all'interno della stessa pagina.Qual è il più semplice? Qual è il più difficile? Da quello che si sta andando a implementare, dal problema di business che si vuole andare a risolvere.Personalmente non penso ce ne sia uno più difficile, uno più semplice.Diciamo che però condivido appieno il fatto che ci sia la possibilità per ciascun team di curare, passami questo termine, il proprio giardino in una maniera del tutto efficiente, senza stare a guardare poi tutto ciò che c'è intorno.O meglio, fammi correggere un attimo questa cosa, devi guardare ciò che ci sta intorno, ma al posto di avere una visione a 360 gradi di tutto l'applicativo, lo devi avere al più su quelle interfacce che sono state concordate, il che ti riduce di molto sia, a mio avviso, processi come l'onboarding, perché ti focalizzi su una determinata cosa, quella è e quella rimane; e in secondo luogo hai anche la possibilità di spaccare meno roba nel momento in cui magari ci possono essere certe modifiche su codice non tuo.- Chiedo a Carmine...- Volevo inserirmi, sì, perché tantissime delle cose che hai detto mi ci ritrovo anche nel contesto da cui arrivo io, che è diverso.Se gli ascoltatori affezionati se ne ricordano, io e Mauro abbiamo fatto una puntata parlando di microservizi in cui abbiamo detto fondamentalmente le stesse cose, nel senso che i microservizi appunto ti aiutano a mettere in pratica a quella che è la legge di Conway, per cui di fatto vai a deployare il tuo organigramma in produzione e quindi ti consentono di spacchettare la tua applicazione da un monolite ai team che la compongono e a spacchettare il lavoro rispetto alle persone che hai, ti facilitano l'onboarding per questa cosa e così così.Volevo capire con te se sto dicendo una cazzata o no, se in effetti il concetto è fondamentalmente lo stesso, cioè di spacchettare una cosa più grossa in in micromoduli serve per queste cose qui, più per le persone che per questioni tecniche fondamentalmente.Ma allora su questo non ti do del tutto ragione, nel senso che anche per questioni tecniche personalmente ha dei vantaggi nel senso è vero che magari durante le fasi iniziali cercare di rivedere la propria struttura per incapsulare bene le cose e definire magari una superficie comune tramite delle interfacce eccetera eccetera può sembrare complesso ma a lungo andare anche tecnicamente parlando ti porta dei benefici nello stesso modo che in cui lo fanno i microservizi, perché? Pensa ad esempio anche solo al testing, ok? Io non devo stare a testare un applicativo con magari 250 componenti, 300 moduli eccetera eccetera io mi testo la mia piccola porzione e la pipeline al posto di metterci magari 40 minuti ce ne mette 4 solo per quel pezzo lì ho un problema ho una regressione non devo fare rollback di un intero applicativo devo fare rollback di un singolo pezzo, quindi anche indipendenza nel deploy.E sono tutte queste cose che, a mio avviso, in un mondo come quello odierno, dove gli applicativi volente o non volente diventano sempre più complessi, avere delle tecnologie che ci portano comunque a ragionare in termini molto più semplici aiuta, aiuta un sacco.Poi è vero che magari questi problemi che ti ho detto, tipo test e quant'altro, possono risultare dei problemi meno noti o stanno cercando di diventare meno invasivi nel momento in cui, ad esempio, cerchi di introdurre le nuove toolchain che stanno uscendo fuori, basate su Rust, che abbattono di molto questi tempi.Però, è vero, a volte non fanno tutto miracoli.Perdonami Matteo, io vabbè lo ripeto sono un po' lontano dal frontend, però mi chiedo il fatto del testing, il fatto di avere delle interfacce ben definite, quindi di componenti più disaccopiati possibile o moduli più disaccopiati possibili, non è comunque una cosa che tu puoi fare anche con un approccio un pelino più monolitico se vogliamo utilizzare questo termine nel senso, la butto dal punto di vista pratico.Io mi faccio i miei bei componenti, me li mostro e li rendo funzionali dentro uno storybook della situazione e me li testo in modo isolato, che ne so la pagina A me la testo in modo isolato in un contesto, uno scope definito senza portarmi dietro quello che è tutta l'impalcatura del micro front-end che poi mi piacerebbe vedere con te, quindi tutto quello che è lo scheletro che fa funzionare questa questa grande macchina.In quel caso io avrei lo stesso benefit, nel senso di avere dei componenti disaccoppiati, avere dei testing time magari ridotti perché sto testando solo porzioni del codice senza portarmi appresso un costo che poi quantificheremo ma che comunque dovremmo avere per quanto minimo.Assolutamente, allora tieni conto che secondo me nel momento in cui tu entri a un livello di dettaglio del singolo componente, magari è effettivamente qualcosa che puoi perdere.secondo me dovresti un attimo allargare la tua la tua visione e a pensarla come applicativo intero, cioè ipotizzo se io da una pagina che ne so carrello devo andare a una pagina checkout so che ipotizzo c'è un qualcosa molto spesso all'interno dei micro front end, cioè un orchestratore chiamiamolo così, che gestisce quest'API per comunicare magari tra le varie pagine o comunicare tra i vari micro front-end, in generale, che dici "ok, la mia superficie di contatto in quel caso è più piccola perché c'è qualcuno di esterno che la sta gestendo, quindi io posso sostituire quella parte esterna come voglio senza andare poi ad intaccare tutto ciò che ci sta tutto ciò che ci sta dietro.Se già invece mi dici "no, perché io mi sto portando dentro tutto anche l'altro pezzo di applicativo che ad esempio ti fa il check out", li possono essere problemi, perché nel momento in cui non funziona qualcosa a te potresti intaccare quell'altro.Se quell'altro non funziona potrebbe intaccare te.Quindi sono tutti scenari che questo genere di approccio tende un po' ad evitare.Voglio fare un po' l'avvocato del diavolo.Per retta dunque, ne ho fatte anch'io con "single spa" bellissimo, o "spa", non so come si dovrebbe pronunciare, è più bello.Ma a questo punto se ritorniamo all'esempio diciamo dell'e-commerce con la sua pagina, cioè con la sua pagina, con le sue sezioni per la consultazione dei prodotti e la parte che fa checkout, beh a questo punto non posso avere due singole application diverse che sono comunque servite, che hanno sostanzialmente come dipendenza alla stessa libreria common o perché tanto poi si finisce comunque a farla questa cosa e ho montato due appiazzi diversi, magari mi posso mantenere l'autenticazione perché ho un identity server uguale o lo stesso cookie o lo stesso token o comunque fare in modo che l'esperienza sia abbastanza seamless, e posso dare ognuna di queste app a un singolo team, un singolo repo, una singola pipeline.Allora, a questo punto, il vantaggio del Micro Frontend rispetto a questa cosa qual è? Secondo te? Allora, tieni conto che, tecnicamente parlando, nel momento in cui tu mi dici ad esempio che hai un'esperienza con con single spa, tu quello che fai effettivamente è tirare su due single page application, cioè quindi di conseguenza in quel caso non hai molta differenza.Secondo me l'approccio che, ad esempio tu stavi descrivendo, è effettivamente un micro front-end, non è fatto sfruttando le librerie di cui di cui abbiamo parlato fino ad oggi, sfruttando un approccio sempre verticale, come ti dicevo prima, quindi una pagina, una singola single page application, orchestrato però in maniera differente.Il fatto è questo, no? "Ah, se devo fare i front-end, devo usare client-side, giusto per tenerla semplice; devo usare per forza single spa; devo usare per forza..." - introduco un altro argomento che magari discutiamo dopo - "module federation".Uno li fa poi come meglio crede.Ad esempio io stesso ho fatto un orchestratore Microfrontend che esula completamente da Single SPA, ma le modalità con cui poi tu puoi interagire tra varie pagine eccetera eccetera è il medesimo.Quindi hai la tua single page application, al posto di montarla con il life cycle di Single spa mi son detto usiamo qualcosa di web standard come eweb component e la single page application viene montata su un custom element.Esatto, ma alla fine io volevo arrivare proprio a questa cosa qui, quindi diciamo possiamo dire che quando parliamo di micro frontend parliamo di una metodologia che è comunque diciamo agnostica sia del framework web come stai facendo la pagina, insomma, quindi che possessa, diciamo, tutta la parte di framework UI, ok? Possiamo definirla così, ma agnostica anche dai vari tool che ci sono a disposizione.Quindi agnostica da SBA, bla bla bla, da Luigi o altre cose, insomma.Quindi nel senso, è una metodologia che può essere utilizzata con varie cose.Ma in realtà volevo arrivare proprio a questo punto qui perché è questo è questa diciamo la cosa che a me piace di questo approccio, che almeno se dovessi fare una riflessione così così personale è raro vedere ultimamente ma in generale nel mondo del front end qualche cosa che funzioni e che sia così davvero distaccata da un tool di riferimento.Cioè nel senso non è che io sto a fa' quella cosa nuova e fancy che però si fa solo con Next o si fa solo con Svelte o si fa solo con Astro, si va solo con qualunque altra cosa che sia uscita oggi.Quindi nel senso questa parte della metodologia del microfrontend è la stessa cosa che apprezzo anche della parte dei micro servizi, ovvio il fatto che sia prevista fin da subito nella metodologia l'interoperabilità tra strumenti diversi che magari funzionano anche in una maniera diversa e a questo punto voglio fare una domanda per tutti.Secondo voi, per quanto riguarda il front-end, sto vedendo da qualche mese, ma in realtà anche da un annetto, se ci facciamo caso, Remix, Astro, lo stesso Next, ok? Si stanno tutti trasformando, o stanno tutti proprio nascendo, come diciamo, come quello che era visto l'antichristo fino a 48 mesi fa, a 36 mesi fa, ovvero di ritornare comunque a fare un'applicazione che sia monolitica.Cioè, nel senso, se andiamo su Medium a tre anni fa, si è detto non fare un'applicazione monolitica, fai l'API con il frontend, la single page application, con lo stesso blog magari c'è scritto.E visto com'è bello questo approccio innovativo che fa Next, che ti fa mettersi la parte di API che è di frontend insieme, è una cosa che si può fare anche con l'Aravel da 15 anni.Quindi, da questo punto di vista, secondo te, a questo punto, possiamo arrivare anche a definire magari micro front-end e micro servizio insieme? Probabilmente sto dicendo una grande castroneria, ma immaginiamo queste applicazioni Next che hanno sia la parte front-end sia la parte back-end.quindi magari che si occupano solo di una specifica parte del nostro dominio, che vengono servite con una metodologia che comunque rientra in quella del micro front-end.Quindi di che cosa stiamo parlando? E ancora quello micro front-end sono micro monoliti, sono...Di che cosa stiamo parlando? Perché questa è una cosa che ho visto chiedere spesso anche su Red, sì, ok, la voglio fare il micro front-end, se nella mia applicazione Next mi metto la rotta che mi fa la query sul database io di solito rispondo con un account con quello principale e gli link or else e poi non scrivo più niente.Però tu che cosa risponderesti? Diciamo che questo è un attimo un campo minato nel senso che tool come Next.js ad oggi, faccio una dichiarazione forte, non fanno niente per rendere la vita più semplice a chi ad esempio vuole sviluppare micro frontend.Allora, e questo c'è da dirlo.Tieni che io ad oggi sono contributor per quanto riguarda il progetto Module Federation, ok? e ti giuro non passa giorno in cui non mi arrivano tonnellate di email di gente che prova a utilizzare il plugin di Next.js per Module Federation e questo puntualmente non funziona.Ma non è che non funziona perché chi lo sta mantenendo è un caprone, ma banalmente perché la difficoltà di questi framework, che adesso magari qualcuno chiama meta framework eccetera eccetera, è talmente, alta e certe cose sono talmente complesse da generalizzare che si fa veramente fatica, tant'è che l'owner di per sé della Module Federation, il buon Zachary Jackson, ha speso mesi e mesi per rendere compatibile la Module Federation con Next 13.Passato un mese e mezzo, se ha visto arrivare Next14 con la nuova struttura cartelle eccetera eccetera ha preso il lavoro, buttato via, e c'è gente che continua a pingare, a chiedere "è possibile, non è possibile?" eccetera eccetera.Ripeto, per darti un attimo di contesto su quello che è questo amore e odio tra Next.js e chi, come me, vorrebbe un po' di libertà, mi verrebbe da dire che nel momento in cui c'è la possibilità di avere codice diviso, gestibile da un singolo team e che poi viene preso e assemblato a run time, io lo definirai Microfrontend.Secondo me la sottile differenza sta lì, ossia dove tu poi aggreghi le varie pagine.Tornando un attimo all'articolo che stavo citando prima di Luca Mezzalira sul micro front-end decision framework, lì fa un ottimo esempio su come può avvenire la composizione per essere considerato un front-end, quindi client-side all'interno di un browser, edge-side, citando gli edge-side include di Cloudflare e compagnia, oppure server-side.È una cosa che l'aggregazione delle pagine e quant'altro avviene a build time, personalmente difficilmente lo definirei microphone-tend, perché non c'è quella diciamo capacità di hot-swap.Quindi alla fine è un'applicazione web normale che risponde ad una rotta con una pagina, nel senso si si ritorna alla fine a quella cosa di insomma, piuttosto che avere quella capacità di dare al cliente la possibilità di prendere una cosa invece che un'altra.Io adoro proiettare sempre i concetti nuovi che arrivano e che mi si propongono davanti su dei side project che non vedranno mai la luce e a questo punto come ben sapete tutti ormai da anni.A questo punto mi chiedo più di una volta io ho provato a tirar dentro il micro front end, parlo di anni fa, dei miei side project senza senso perché io sono da solo mi sto facendo un micro front end forse sono un idiota, forse insomma la dh hawaii in quel caso avrebbe un pelino più senso, lo so l'ho detto, però mi chiedo oggi se tu dovessi mettere una barriera d'ingresso all'utilizzo del micro front end quindi diciamo la barriera sotto la quale la butteresti su singola server, singola spa o o Twire o quelle cose là, quindi semplificata al massimo.La barriera, diciamo, che posizioneresti? Dove la posizioneresti? Per quale tipo di applicazioni minimo? La posizionerei su applicazioni che hanno un dominio ben definito, o meglio, hanno, devono gestire magari, multipli domini, chiamiamoli così, principali o secondari che che essi siano, e il confine tra questi domini è proprio ben definito.Cioè, tornando all'esempio di Dazon, che magari citavi prima.Va bene, è un'applicazione della Madonna, business e quant'altro, però ha un dominio ben definito.Il primario è "permettiti di vedere gli eventi sportivi" e uno, se vogliamo, secondario è il pagamento.Se le prendi circolarmente, già anche solo queste due cose sono applicazioni che potrebbero avere una certa difficoltà e, secondo me, beneficiano della suddivisione in in Microfrontend.Ovvio è che se devi fare giusto una piccola dashboard in cui mostri quattro dati, ti direi forse non ne vale la pena, così come, a mio avviso, potrebbe non valerne la pena per progetti, diciamo, che seguono un paio di persone che magari sono sempre le stesse.Cioè vi è incomodo, a mio avviso, nei problemi, diciamo, enterprise con appunto domini ben definiti, team che magari possono essere geolocalizzati in nazioni differenti, che possono avere conoscenze diverse, capacità diverse, eccetera eccetera.Lì secondo me sì che hanno una grande efficacia.Io mi è appena partito un thread nel cervello e non riesco a fermarlo, tipo sto bruciando, ho bisogno di pasta termica tra la testa e le cuffie, nel senso che stavo pensando, proprio mentre parlavi di dominio o chiamiamolo bounded context, quindi di contesto ben circoscritto, mi è venuta in mente l'applicazione Furvie che stiamo scrivendo, tra l'altro "Ciao Flavio, grazie per il tuo effort sulla parte rast senza dita non saprei come fare e là per esempio quello che abbiamo provato a fare nella parte front end è cercare di disaccoppiare il più possibile gli stati lo stato ok dividendolo in più stati e cercando di creare dei bounded context no quindi contesti abbastanza isolati con dei componenti che raccolgono parti isolate dell'applicazione orchestrati da un unico router ok che però ti sposta e allora tu questo lo definiresti micro front-end perché cioè se ci penso rispetta molte delle cose che hai detto per cui se non è micro front-end perché non lo è Lo so, domanda dai cazzo! Abbi pazienza Matteo! Perché non lo è? Penso che dipenda un po' da chi lo scrive, nel senso nessuno viene lì con una pistola alla tempia nel dire "no cavolo se non lo fai a Amico Frontend allora non ne va la pena" eccetera eccetera.L'approccio è...o meglio, come farlo è a descrizione.Ti sono stati più o meno descritti, lì a un certo punto state è capire se quel trade-off ne vale la pena.Per come me l'hai raccontata, in queste quattro righe potrebbe valerne la pena, ma siamo sempre lì.sei solo tu che stai facendo una roba del genere? Matteo, quello che io mi chiedo è, se io disaccopio lo stato, ok? E poi c'ho dei container, che in qualche modo contengono quella porzione di applicazione che poi è una porzione di sottodominio, ok? Ed è bella isolata.queste porzioni di dominio interagiscono tra di loro attraverso degli eventi? Allora questo è un micro front end anche se non uso un classico orchestratore o non lo è? A mio avviso non lo è, non lo è perché tu nel momento in cui cambi una cosa all'interno di questo dominio devi stare a rideployare tutti gli altri.Poi, una volta che prendi, stacchi i domini, questo ad esempio il module federation ti permette di farlo così, veramente in una maniera molto molto banale.Nel momento in cui hai l'indipendenza, il controllo sul build and deploy del singolo dominio, in quel caso lo puoi considerare Microfront End.Quindi possiamo dire che uno degli elementi importanti del micro front end è che ogni elemento, ogni entità, ogni micro front end ha il suo ciclo di vita separato da altri.Assolutamente, assolutamente.Stessa cosa così come capita anche sui microservizi.Uno ha la necessità di rilasciare per una nuova funzionalità, se le interfacce di comunicazione concordate non vengono rotte può rilasciarlo in maniera e lo stesso identico approccio vale per i micro front end.Prima stavi parlando di eventi, possono essere eventi custom event, può essere un subject di RxJS, possono essere delle callback, possono essere le window, però giusto per dire la superficie poi su cui negoziare un punto di incontro può essere vasta, anche lì sta a te.Vorrei neanche definire lo stand-up, comunque la metodologia non ti impone neanche questo.Ti dà magari delle linee guida su comunicazione, sul fatto che due cose debbano comunicare, su come poterlo fare, ma poi l'approccio predefinito lo scegli tu sostanzialmente.Ecco, altra domanda, poi chiedo ai miei amici Carmine e Mattia se se ne hanno loro, scusate ma io ho un sacco di punti interrogativi in testa che sta scaldando, si sta scaldando.Sai abbiamo parlato di microservizi, con il mio compare Mattia, tempo fa come lo ricordavo abbiamo fatto una puntata sui microservizi e uno degli elementi importanti della puntata era i problemi, i costi dei microservizi.Tra l'altro, per esempio, parliamo del problema dello stato nei microservizi, lo stato condiviso nei microservizi, o il problema della comunicazione tra i microservizi.Ecco, coi microservizi Mattia Sentirana dentro la testa "saccabattere, sacca pattern sacca pattern sacca pattern sacca pattern.Con i microservizi esistono dei pattern ormai assodati che sono diventati letteratura che sono in qualche modo la via no? Il modo con cui con cui con cui ci muoviamo.Qual è lo stato intanto quali sono i problemi e le complessità dell'utilizzo dei microservizi qual è lo stato dei pattern o delle best practice nell'adozione dei micro front end? Allora ti direi che per quanto riguarda un punto di vista puramente di costi non ha diciamo lo stesso impatto per quanto riguarda i microservizi per un semplice motivo.Se tu hai ad esempio un monolite, ipotizziamolo fatto in node, il momento in cui tu hai un monolite e lo tiri su praticamente paghi il costo, ad esempio ipotizziamo sempre di girare su kubernetes e piattaforme simili, paghi per quanto riguarda l'immagine docker un unico costo che è l'immagine di node di base più l'immagine del tuo applicativo, singola istanza di node che viene eseguita.Nel momento in cui tu invece approcci a un microservizi, hai un costo di base che deve essere moltiplicato per n, dove n è il numero di microservizi, perché hai n volte la stessa immagine di base replicata per ciascuno dei microservizi, on top poi ci metti il tuo codice.Stessa cosa nel processo node, di base viene lanciato n volte una per singolo microservizio e on top poi ci paghi il costo dell'esecuzione del processo di node.Sui front-end, ad esempio, nel momento in cui tu decidi di comporli client-side, questo costo volendo non ce l'hai, perché banalmente sono file statici che vengono presi, messi su S3, quindi di per sé tu non vai a pagare un costo computazionale.Se vuoi invece di S3 utilizzare Nginx puoi farlo uguale, puoi usare un'unica istanza, volendo, che raggruppa tutti i tuoi file statici.Quindi non vai ad avere un costo "eccessivo" di costo aggiuntivo di esecuzione, storage delle immagini docker e quant'altro.Questo di sicuro è un punto a favore.Per quanto riguarda i pattern che vengono molto spesso adottati, ci può essere ad esempio l'utilizzo di un application shell.Un application shell non è nient'altro che, chiamiamolo così, il primo micro frontend che viene caricato e il suo compito è quello di caricare tutti gli altri in base a n condizioni, chiamiamolo in generale contesto in cui l'utente si trova, come può essere ad esempio la route corrente, il fatto se l'utente è autenticato o meno, se ha l'accesso a queste cose qui, ecc ecc ecc...e esporre le API che diciamo ci dicevamo prima per avere questa interfaccia di contatto, quindi puoi esporre ad esempio l'API per lo storage di informazioni che devono passare da pagina A a pagina B, tiene in pancia le informazioni dell'utente e cose così.Ti ho ucciso? No, no, no, non mi hai ucciso, semplicemente ero in muto, come come tutti i boomer che si rispettano.No hai assolutamente risposta per esempio l'application shell era uno di quei pattern che mi venivano in mente.In realtà sui microservizi c'è un gozziliardo in letteratura sui pattern, sulle best practice.Un po' meno ne trovo proprio sui micro frontend, però credo che sia anche una questione di giovinezza dell'approccio, che puoi far ridere dire di giovinezza dell'approccio perché ne parlavamo con Mattia e con Carmine, cioè per me i micro frontend sono anche le server side di Apache o dei web server alinomati.Io vorrei fare polemica su questa cosa perché non sono per niente d'accordo sul fatto che sia una questione di giovinezza.Io sento parlare di micro front-end da quando facevo il front-end io, che era veramente cinque anni abbondanti fa.Adesso faccio il vecchio rompipalle, ma secondo me il fatto che ci sia meno letteratura e meno best practices e meno pattern e meno...se vuoi, vecchi barbogi che ti spiegano come devi fare le cose è una questione nativa proprio del contesto del front-end, in cui la gente è cowboy e fa fondamentalmente il cazzo che gli pare, perché tanto settimana prossima c'è un altro front end, un altro framework di moda e non c'è intenzionalmente la standardizzazione.Non c'è standardizzazione il modo migliore di fare le cose perché è una cosa giovane, secondo me è una cosa che ci piace raccontarci ma non è vero.Non c'è standardizzazione perché non si vuole che ci sia.Sì sì sì ma alla fine c'è l'application shell è quello che è un portlet container di LiveRay o quello che fa NERCIA.js quando carica le cose per un esempio più moderno o quello che puoi fare con tutte quelle soluzioni Enterprise con la simile iFrame che chiama un altro robot Java che ti mostra la roba.Quindi nel senso alla fine è un pattern che c'è sempre stato però probabilmente ora stiamo vedendo l'evoluzione più mainstream.Cioè probabilmente se stessimo parlando di questa di questa cosa qui che è fatta comunque in questo modo che è anche più accessibile a tutti, ma non abbiamo mai fatto una puntata su come è bello LifeRate.Cioè almeno io non sarei stato presente.Io sarei stato presente con un'ascia a questa puntata, insultare chiunque sostenga che l'I3 sia bello.- Sai cosa? Io penso che, concordo comunque con quello che dice Mattia, e penso che il problema sia un attimo dovuto dalla quantità, dalla grande quantità di approcci con cui tu puoi, ad esempio, prima parlavamo scusami della, delle modalità di comunicazione all'interno di micro servizi, più che dire "va bene, magari si agcappano" eccetera eccetera, ma, astraendoci un attimo, mi viene da dire che la comunicazione avviene attraverso la rete.L'informazione che prende esce, che poi si utilizza HTTP, gRPC, che sia rete locale, sia rete internet, etc.comunque la comunicazione viene attraverso la rete.Comunicazione sempre limitiamoci per il momento al client side, per quanto riguarda i micro front end conto quattro modi diversi perché può, anzi se non di più, perché puoi salvare le informazioni nel session storage, vi prego non fatelo, potete salvare le informazioni nella window, vi prego non fatelo, potete utilizzare i custom event, ok va bene, potete utilizzare i subject di RxJS se volete fare magari qualcosa di reattivo, ok va bene, e sono quattro esempi per fare approcci, quindi client side.Se poi cominciamo a scalare dicendo "amaci la composizione su ledge", "amaci la composizione server side eccetera eccetera eccetera esplodi il numero delle possibili combinazioni.Quindi il fatto che secondo me non ci siano degli standard, qualcuno ci può essere, tipo quelli che ti citavo prima, è dovuto più che altro perché magari ci sono tante persone che fanno micro frontend, ma ciascuna con un proprio approccio e quindi questo porta magari le persone a vedere lo stesso problema però con prospettive diverse e di conseguenza il punto di incontro magari è più è più difficile da trovare.Adesso abbiamo parlato solo di pattern, ma magari è anche corretto parlare di antipattern.Il primo antipattern che mi viene in mente, ad esempio, è, nonostante l'approccio lo permetta, sfruttare tecnologie diverse per fare diversi micro front-end, quindi c'è chi lo fa in React, chi lo fa in Angular, chi lo fa in Vue, chi lo fa in Svelte.Quello ad esempio è considerato un antipattern perché soprattutto nel momento in cui arrivi client-side vuol dire che ti devi caricare quattro differenti librerie per comporre la tua UI.E poi voglio vedere il povero team che fa lo UI kit.Che cazzo deve fare? Deve fare web component così lo supporto ovunque, però anche lì è sempre qualcosa di un po' complesso e al posto di semplificare l'onboarding.Questa cosa ti rende anche più difficile spostare le persone da un team all'altro e da un microfone da un altro.Ti crea problemi di hiring perché cosa chiedi alla gente quando fai i colloqui? Se usi 18 frame per azione.Se qualcuno che faccia bottoni.Eh sì.Vabbè ok però come lo vuoi questo bottone? Cioè insomma nel senso sì no assolutamente con un concordo 100% applicazione di codice per risolvere problemi comuni esatto quindi anche qui micro frontend lo facciamo questo package common.Posso abbracciarti stavo per chiedere la stessa cosa sei la mia persona preferita della settimana.Utils, common, components, "design" c'è quelli che lo chiamano tipo @mycompanydesign dove alla fine ci finisce tutto.No, serio, è una domanda seria.Il grande classico è la classe che formatta le date, che condividi tra tutti i microservizi e/o micro frontend di turno e poi comunque hanno centomila metodi diversi per formattare le date e ognuno ha il suo, ma sono tutti condivisi.Esatto, esatto.E sei fortunato se hai condiviso? Ci sono situazioni dove ogni team esporta il suo package per formattare le dati in modo che sia condiviso ma ognuno c'ha il suo.Assolutamente, perché tanto NPM costa poco, quindi si possono fare.No, In realtà ecco perché se uno pensa a quello che stiamo dicendo prima, magari spesso noi intendiamo, quando facciamo questo package commode, dal punto di vista di summa UI, proprio di mettere quelle cose comuni.Non lo so, allora a questo punto non andrò a mettere dentro la navbar perché non mi serve, perché la navbar sta nell'application shell.A questo punto andrò a mettere dentro il bottone effettivamente del mio design system, la classe performance formattare le date, ma allora a questo punto tutta quella logica che è comune ad esempio tutta la parte di autenticazione, no? Ok, quindi banalmente immaginiamo che ho un flusso estremamente semplice con "out", ok? Quindi ho il mio token che c'è il classico, il set timeout che mi riferisce il token, il cookie, faccio la chiamata eccetera eccetera.Tutto questo, quindi tutta quella logica che è a comune tra le applicazioni, va nell'application shell, quindi l'application shell assume anche un ruolo di coordinatore di queste funzioni che sono comunque a core.Alla fine se io sono logato, se io ho il cookie, qualunque richiesta parte da quella pagina web se lo becca comunque, oppure ogni micro front-end si occupa anche magari di questo? Sto parlando così.Allora, su questo ti posso dire, come al solito, non c'è una solita risposta e la letteratura ci dice "fai un po' quel che vuoi".Personalmente io lo stesso problema sul cliente in cui sono attualmente e quello che abbiamo fatto è Application Shell va a definire l'HTTP client, va a definire tutte le logiche per autenticazione, refresh token, interceptor vari eccetera eccetera e mette a disposizione l'http client a tutti gli altri micro frontend.Te la faccio in maniera più semplificata perché nel mio caso lo scenario è module federation ok? ho configurato module federation per dire axios deve essere iniettato in un singleton, quindi di conseguenza tutti i micro front end hanno accesso alla stessa istanza di Axios.Nell'application shell quello che faccio è gestire l'autenticazione, configurare Axios con l'interceptor nel momento in cui ricevo un 403 e gestire il refresh token, configurare l'istanza iniziale con il bearer token eccetera eccetera eccetera l'hai introdotto tu l'argomento no? "module federation" allora proviamo visto che siamo già un'ora di puntata, per me sono passati dieci minuti, hai da fare stasera Matteo? ma guarda finché non viene mia moglie a reclamare la camera direi che non ho problemi Ok puoi dire di addobbare il divano allora perché stai con noi ancora un po'...E' probabile che si sia già addormentato.Scherzo, naturalmente scherzo, mi faccio ironia.No, tra l'altro so che Carmine e Mattia possono stare quindi possiamo andare un po' lunghi, no scherzo.Facciamo una domanda...Module Federation in quale modo, intanto cosa è, magari ci fai un overview generale, poi in qualche modo gioca un ruolo determinante nel mondo di Micro Front End? Allora partiamo dalla definizione, come definizione Module Federation non è nient'altro che una metodologia per distribuire software a run time e dà a disposizione anche qualcosina di molto comodo come aggiungere fallback se qualcosa non dovesse andare a buon fine eccetera eccetera lavora su sia client sia server.All'interno dei micro front-end è uno dei possibili approcci che possono essere utilizzati per la loro implementazione.Perché? Ipotizziamo ad esempio ipotizziamo React, al posto di dire "ok importami questo componente dalla mia cartella locale" ok io gli posso dire "importami questo componente da un'entità che viene chiamata Remote" quindi un qualcosa che è un'entità che sta appunto in remoto da qualche parte, sulla quale però io posso contare nel momento in cui mi serve prelevare del codice.Attenzione non sto dicendo componente, io sto dicendo codice, quindi ciò può valere per componenti, react, funzioni, diciamo la qualunque.Quindi quello che prima si diceva, ad esempio la libreria common, può capitare, ci può essere.Anche qui dipende un attimo come te la giochi.Potresti farla versionata come pacchetto npm e ogni micro frontend poi alla sua, magari in questo modo avendo ognuno la propria versione, riduci la possibilità di avere dei problemi in caso di breaking change, oppure se ti interessa una strategia più del tipo "voglio che questa libreria sia subito disponibile nel momento in cui la rilascio, sia subito disponibile a tutti quanti senza che nessuno debba mettersi ad aggiornare le cose a mano", bene, il module federation è un esempio di come questa cosa possa essere fatta.Attenzione comunque non è la panacea a tutti i mali, ti dà un'enorme mano per quanto riguarda importare codice che sta a remoto, ma già capendo da questa definizione capisci che introduce anche dei problemi, ad esempio nel momento in cui tu sviluppi in TypeScript, tu dici importami il modulo x da questo remoto, ma questo remoto essendo remoto non ti mette a disposizione un tipo.Come si risolve? Per questo tipo di problema ho scritto un plugin che sostanzialmente si attacca al lifecycle del bundler, fa sostanzialmente due lavori.Nel remote compila tutti i tipi e gli crea un piccolo zip.Nel host, ossia chi richiede il codice in remoto, scarica questo zip, lo scompatta in una cartella e configurando nella maniera più corretta il tsconfig, gli si può dire "ah, per questi moduli qua che io ti sto definendo come "pippo" nel remoto "pippo" prenditi i tipi da questa cartellina qui così in fase di build non hai nessun tipo di problema.Lo stesso si riflette comunque anche sui test perché se mi dici io sto importando un qualcosa da remoto, si ma Jest non è che ti va a prendere il codice da remoto e la soluzione è più o meno comunque la stessa.Bravissimo, ho due domande.Premetto che la module Federation Webpack l'ho vista veramente di sfuggita.Come funziona per lo sviluppo locale? Nel senso tu ora mi stai dicendo, ok, in fase di build, quando immagino una macchina che fa questo processo automatico, idealmente, che effettivamente ha l'accesso a internet e quindi scarica questo pacchetto da remoto.Cosa diciamo, come farebbe per una qualsiasi dipendenza? Per lo sviluppatore che sta sviluppando sulla sua macchina, come funziona? Cioè nel senso, deve sempre andare a star prendendo questo remoto su internet o ci sono anche modi in cui deve veramente dire ok, c'è tutto quanto clonato, va in una sorta di npm link ma con la module Federation.Mi sto spiegando malissimo però spero che...>> GIOVANNI Sì, assolutamente.C'è la similitudine è corretta, però è esattamente il modo corretto di procedere, nel senso che nel momento in cui io ti dico "remoto" capisci che già questa definizione è astratta, perché lascia la possibilità di dire "ah ok, ma il mio remoto sparo google.it o è localhost 3001? È un remoto? È da qualche parte in rete? Dove poi questi file vengono sostanzialmente messi a me non interessa.L'importante è che se io contatto remoto/entrypoint l'importante è che lì riesca a trovare la definizione corretta di un endpoint module federation che riesce poi a risolvere i componenti nella giusta maniera.In uno sviluppo locale, se ho questi due micro front-end in federation, avrò magari due processi di code watching e di hot reload, magari, ok? Magari se sei in un punto salvo mi rimane comunque esposto il modulo aggiornato.Così come faremo con NPM.E invece l'altra domanda che mi sta un pochino più a cuore è come funziona la cache invalidation? Nel senso io ricordo molte volte, ma ti parlo di due anni fa, stavo facendo una progressive web app per il cliente.Insomma ci si dovette un po' inventare questo sistema di specchie leve con il service worker eccetera eccetera per far caricare la nuova versione.Quando questa era disponibile era la versione refresh a page, una roba aberrante, però Stackover flow disse che si faceva così e io mi sono fidato.Ma come funziona invece per la module federation? Perché magari, cioè, come viene risolto questo problema? Perché nel senso a me stava venendo in mente, ok, l'endpoint di module federation è sempre lo stesso, però serve magari dei chunk diversi ogni volta o dei file diversi ogni volta.Oppure viene sempre servito lo stesso file ma con un e-tag diverso, ma qual è la strategia per far sì che quella cosa venga cacciata, se viene cacciata nel modo giusto? Allora, essendo comunque una risorsa statica viene ovviamente cacciata.Le tecniche, chiamiamole così di refreshing possono essere diverse mi vorrebbe mi verrebbe da dire? Cioè tieni conto che a Modify Federation di per sé espone anche delle utility che ti permettono e sostanzialmente a runtime di andare a specificare ad esempio "lost" e il nome del remote entry per dire "ok io me la voglio giocare tutto per tutto in lato codice" perché sennò di default la procedura standard è quella di definire l'host e il remote entry nel plugin in fase di build e questo poi prende parte eccetera eccetera.Banalmente quello che a te poi a un certo punto interessa è dire "guarda ho una nuova versione del mio file di remote entry" se tu nell'andare a comporre a runtime l'url in cui andare a trovare questo remote entry a un certo punto ci appendi un query parameter come può essere come ad esempio con la versione ipotizzo questo poi automaticamente invalida la cache e si riscarica tutti i chunk che gli servono da capo.E tu direi dove metto queste versioni? Può essere un file json statico o stato insieme all'application shell, però appunto queste di solito sono cose che l'application shell fa.quindi diciamo alla fine possiamo dire che l'application shell effettente è il coordinator dell'intera serie di appliazione quindi diciamo...tant'è che di solito viene chiamata anche micro front-end orchestrator...ok ok quindi diciamo non è una cosa che si fa, è solito che un micro front-end che sta in un'application shell ha una dipendenza da un altro micro front-end, cioè immagino che sia una cosa...si può fare volendo, si può fare.Questo, almeno nel gergo "module federation", nel momento in cui importi qualcosa da un altro amico frontend e lo esporti qualcos'altro, prende il nome di "bi-directional host".Ok.Voglio fare un guardavolo orario, siamo a 1 ore 15, ti chiedo Matteo, per favore chiedi scusa la tua signora poverina che veramente ci odierà quindi scusati da parte nostra però voglio farti un'altra domanda in questo ultimo periodo voi per colpa di zio guglielmo che oltre a fare i componenti che fanno quelli e sequelle sta un po mettendo in fermento il mondo del front end triggerando molto opinio però si parla tanto di server side components e quindi la mia domanda è intanto cosa sono una piccola introduzione per chi non le conoscesse però soprattutto che gioco possono giocare in un'ottica di micro front end in questo caso? Allora qua tocchi un attimo un topic un po' un po' dolente diciamo.Voglio le bold opinion! Allora mettiamola così di per sé.Tra l'altro è tutta la puntata che penso "Figa oh va che bravo che ogni volta che gli facciamo una domanda fastidiosa lui è molto bravo perché risponde sempre con "dipende" poi dice "eh in questo caso si fa così, in quest'altra cosa così" adesso invece sento odore di bold opinion e di "no, non dipende per un cazzo".Allora, mettiamola così.Il concetto di per sé, tenendo conto che non è ancora del tutto sfruttabile da Reactplane, fa sì che di conseguenza approcciare ai micro front-end sfruttando React Server Component sia complicato perché ti devi affidare a strumenti come Next che, come ci siamo detti precedentemente, non aiutano lo sviluppatore nello sfruttare micro front-end e quant'altro.Quindi da questo punto di vista diciamo che c'è ancora molta server da fare e mi verrebbe a questo punto a me da fare a voi è, ne avevamo veramente bisogno le React Server Component? Per fare una premessa, so che comunque poi la community di React.Appena fai una piccola critica, Madonna, arrivano con i forconi.Ma tenendo conto dei problemi che ha React ad oggi, tipo...tipo che è un chiodo nel back-end, cazzo! Lo state management che mette a disposizione è inefficiente e tra un po' è sconsigliato dalla qualunque.Non c'è una build in formato esm disponibile, quindi questo significa che tecniche molto carine come può essere il tree shaking sono difficili da attuare, quindi hai di conseguenza il bundle che è un po bloated di roba che magari ti può servire non ti può servire eccetera eccetera eccetera.Cose così, no? Cioè, ne avevamo così tanto la necessità di questi React Server Components, non c'era la possibilità di fissare quello che a mio avviso è un po' chiamamolo così, debito tecnico che si porta ormai dietro da diversi anni? Allora, rispondo io per rispondere per primo, tanto Faiud anni fa mi ha già scartato meta perché non sapeva che fa l'hacker rank, probabilmente invece scarta il rank la prossima volta che riproverò, quindi lo posso senza nessun problema.E' peggio con loro.No, a parte gli scherzi, cioè a parte gli scherzi, mi hanno veramente scattato due anni e mezzo fa perché è una pippa.Comunque, credo che i server component di React siano l'ennesima cosa che ovviamente è uscita open, perché il progetto è open e si è voluto contribuire, ma nasce da un'esigenza specifica che aveva meta e che ora tante persone vogliono ficcare a forza in tutto quanto l'ecosistema per risolvere problemi che il 99% delle persone non ha.Perché poi alla fine si tratta di prendere un caso d'uso estremamente di nicchia su una scala estremamente enorme e tentare di portare quella, quell'approccio che richiede un certo tipo di know-how, un certo tipo di, di, di infrastruttura anche proprio a livello di, di team.Siavano persone estremamente esperte su quella, su quella cosa ed è una tecnologia molto nuova, cioè l'esperto è quello che ha fatto il commit e che la usano loro, ok? Nel senso quindi secondo me è semplicemente vuole portare a forza qualche cosa che è una novità, dirompente nel grandissimo panorama bellissimo React, viva Meta, però effettivamente risolve delle problematiche che il 99% delle persone non ha, quindi credo che in questo momento sia molto anche il trend.Come, allo stesso modo, penso che la trasformazione di Next.js in quello che è de facto un framework monolitico sia anche l'ennesimo tentativo di inseguire un trend che fa su Edge.io e porta necessariamente a snaturare le cose.Infatti...marketing driven development...sì, ma alla fine è quello, cioè qual è la necessità del server components di React per l'applicazione web medium anche per quella grande? Cioè con tutta la complessità che ci sta dietro? boh, non lo so, non riesco veramente a spiegare.Io personalmente su questo pensiero non sono del tutto d'accordo, nel senso che secondo me anche il solo tentativo di voler far arrivare sul browser dell'utente una quantità minore di JavaScript, quindi intasare meno la rete, rendere di conseguenza il dispositivo dall'utente più veloce, efficiente, una migliore fruizione, eccetera eccetera, è comunque un tentativo nobile.Il problema secondo me è il modo in cui è stato pensato.Cioè secondo me c'è stata veramente la fretta di dire "ah, sta prendendo piede robe tipo "Laila sta prendendo piede, ciò questo ritorno al server per fare certe cose, ok allora dobbiamo farlo anche noi".E poi l'output è a volte discutibile, questo "use server", "use client", che poi due si intrecciano sì, ma ti complica un po' le cose perché se devi fare un componente server con magari qualcosa che ha l'interattività client, allora li devi dividere...cioè a mio avviso se fai certe cose ok, nobile lo scopo, ma dovrebbero effettivamente avere una developer experience che non sia una pena.Su questo punto di vista, secondo me, chi ha fatto un ottimo lavoro, ma veramente un ottimo lavoro, sono i ragazzi di QUIC.Stavo per dire la stessa cosa! Tra l'altro se ci segue, ciao Giorgio! Loro hanno fatto veramente un ottimo lavoro, perché dici, ok, c'è quel dollaro, cosa fa quel dollaro? Tu ci vrappi dentro la qualunque e lui in fase di build ti riesce già a scomporre tutto quanto.Tu, sviluppatore, devi pensare "ah no, ma questo aspetta che forse lo devo mettere l'esicci, devo fare la suspense in maniera che poi avvenga lo split".No! Dollaro! Stop! User experience fantastica e dici "tanto di cappello, tanto di cappello".Io personalmente, la prima volta che ho sentito React Server Compile, che sarà natale di due anni fa, un anno e mezzo fa, mi ricordo che era tipo inizio gennaio.Sì, che poi tra l'altro le informazioni erano super limitate, non c'eravamo capito un cazzo fino a 4-5 mesi dopo.Sì, era un po' come se fossi Antani, appena ha visto quel video lì.Però ha detto "cavolo, speriamo che dopo magari la batosta del look che sembrava inizialmente buttata un po' lì, sperando che si siano ripresi.E no, alla fine no.Personalmente mi dispiace perché, siamo sinceri, il reale cappello da frontendista è ciò che porta attualmente il cibo alla mia tavola.Ed è veramente un peccato vedere queste scelte opinabili? Questa così come "ah ok se devi fare un applicativo React vai di Next.js" No, no.Se me lo voglio deployare su un Edge che dico io che non sia Vercell perché devo fare una fatica immensa? No? C'è nel senso...sono un po' i miei pensieri così, perché ad oggi...Io sono assolutamente d'accordo, il storm è anche uno sforzo di comunicazione che si vuole per forza spingere in quella direzione.Cioè nel senso, c'è tante persone che sono convinte che al giorno d'oggi per fare un personale react ci vuole per forza un extra, quando invece puoi farlo con byte e viene una single page normalissimo usata l'ultima volta tre mesi fa.Puoi utilizzare niente, cioè SBuild, c'hai un'applicazione, c'hai un bundle JavaScript, basta, sei fatto alla single page application, non ti serve nemmeno byte, lo fai con SBuild a man, lo fai come fai.Lo stesso Create React App che è come PHP che si dice che sono anni che non son cura più di nessuno, lo stesso Create React App con tutto il fatto che non è manutenuto più come la prima si può utilizzare.Insomma è pure uno uno sforzo di comunicazione proprio che sta andando sta andando secondo me in una direzione assoluta.Visto che hai nominato VIT, scusami Mauro, ci tengo a dire che come piccola chicca da provare R-SPAC...Tra l'altro Matteo aggiungo che tu a brevissimo in azienda farai un talk su R-SPAC, giusto? Domani.Perfetto e poi riverrai da noi per parlarci appunto di Ernest Pacco, ti anticipo che ti riromperò le scattole.Credo però, visto che siamo un'ora e mezza, voglio fare una battuta, fare un giro per avere le vostre opinioni e poi avvicendarci verso la chiusura.Abbiamo visto che in realtà quello che spesso è necessario è un po' di pragmatismo, cioè capire quando ha senso utilizzare i micro front-end o quando è sufficiente disaccopiare le componenti della nostra app il più possibile, quando ha senso andare di monolita o quando ha senso andare di micro servizio o micro front-end, quando ha senso utilizzare Next.js, a questo punto io ci metto punto di domanda perché nel mio zainetto dell'esperienza ho robe tipo un Next.js utilizzato con Redux e Redux Saga con uno stato che si sincronizzava tra backend, tra server side e client side e le lacrime di sangue, lo ricordo ancora bene, le lacrime di sangue per far funzionare tutta sta merda, quando in realtà sarebbe bastato veramente semplificare e ridurre al minimo questa cosa.Allora un po' triggerato dal mio amico Carmine dalle conversazioni che abbiamo spesso in privato mi chiedo quanto in realtà ad oggi importante il movimento di gente come l'Aravel che spinge InertiaJS o la posizione di un DHH che dice "oh raga noi dobbiamo rilasciare un'applicazione" ma che cazzo parliamo di server side component? Se stiamo riportando la roba nei server stiamo mischiando le cose facendo un grande minestrone a questo punto va a fanculo generiamo l'HTML con Pug oppure semplifichiamoci la parte front end utilizzando HTMLX che è un altro trend no e cerchiamo di ridurre da questo punto la complessità e utilizzare questo livello di complessità solo quando serve.Io lo so che Matteo oggi lavora in un contesto perché un po' ho capito il progetto e il cliente sul quale è, ragiona in un contesto dove questo tipo di strumenti è necessario.Però per l'applicazione media che non ha un impatto di quelle dimensioni, che è molto più contenuto, talvolta anche il solo React è overkill.Quindi mi chiedo Secondo te e secondo voi, è una domanda che giro anche a Mattia e a Carmine, quanto ad oggi nel front end che vediamo c'è l'over-ingenializzazione? E secondo voi cosa bisognerebbe fare per razionalizzare un po' questo sforzo? Iniziamo da Matteo.Allora, c'è over-ingenializzazione? Sì.Tant'è che per me, già visto che l'hai nominato prima, anche solo Redux, non vera e ingeniorizzazione della Madonna, che molto spesso potrebbe non servire però a Redux, ma sì, usiamolo.Su cosa invece potremmo focalizzarci per capire quando stiamo come ve l'ho ingenierizzando, direi cercare di capire prima il problema rispetto a dire "ah vabbè facciamolo con React" o "ah vabbè facciamolo con Svelte".Quindi qual è il tuo problema? Devi tirar fuori qualcosa di statico? Devi tirar fuori qualcosa di dinamico ma con poca interazione con l'utente? Qualcosa che invece ha molta interazione e ti serve qualcosa di molto veloce? Una volta che ti fai comunque tutte le tue analisi su quella che è poi il problema che devi andare a risolvere, scegli la tecnologia adatta per farlo e mai fare il contrario.Prima tecnologia, poi vediamo se posso utilizzarla per risolvere il mio problema.Molto spesso ti schianti contro un muro.Io l'opinione più bold parlo per ultimo, Carmine dici la tua.bene ce l'ho anche io bella bold.Secondo me il 99.9 per cento...allora a meno che la tecnologia prima di decidere cosa devi fare ce l'hai quando fai il capitolato del bando pubblico e quello è tutta quanta un'altra storia.Ok perfetto, perché c'hai i tre ingegneri dell'ente che hanno detto "Oh, ma lo sai, come si fa? Magari c'è quello un po' più vecchio e dice "No, lo facciamo con Java server page e quindi tu ce lo devi fa' per forza, c'è quello magari un po' più giovane e dice "Facciamolo con Cha-CPT".Ok? Cioè, quindi nel senso, quella è tutta quanta un'altra storia.tolto questo caso limite, secondo me la differenza sta nella quantità di...cioè la differenza sta nell'urgenza e nella qualità del deliverable, o meglio, se io so che devo rilasciare qualcosa, se io so che devo fare qualcosa che deve veramente funzionare, qui dico una cosa estremamente bold.Io rifletto bene, come dicevi tu, sul problema che io voglio risolvere.Se ho tempo di fare le astroputtanate, ok, per fare il crude, probabilmente me lo posso permettere, o comunque accetto il fatto che mi terrò delle conseguenze.Del 99.9% a casi, secondo me, va benissimo vite o va insomma, l'ho sentito pronunciare in mille mila modi diversi, con una single page application.Ma anche strumenti come Inertia, JS, a me piacciono moltissimo, che si avvicinano molto a quello che noi stiamo dicendo di micro front-end e di component switching.Posso decidere se farlo in React, se farlo in Sveltec, eccetera eccetera.Per me nel 90% dei casi l'applicazione monolitica server-side rendered probabilmente va bene a tutti.Se ho la necessità stretta di fare server-side rendering, usare il framework UI che più mi aggrada e possa essere React, che possa essere Vue, che possa essere Svelte, che possa essere qualunque cosa.Per arrivare al punto in cui io devo dire "ho bisogno di fare un'applicazione ibrida con Next.js" significa che devo veramente avere la incontrovertibile prova che quella cosa effettivamente mi serva.Se io sono ad una scala per cui mi serve Next, per cui mi serve il microfono, per cui mi serve qualunque cosa, ok significa che mi assumo quella responsabilità lì.Quello che io vedo nel 99% dei casi è la cosa opposta, ovvero io prendo la tecnologia che più o meno va e la faccio.Ed è una cosa che faccio spessissimo io.Io ho tre CD che sono fatti con Gatsby che non avvio più, li ho rifatti con Jekyll.Cioè quindi anche io stesso sono stato il primo che si è lasciato ingannare questa cosa.Qui ho preso delle scelte anche sul back-end, in passato, per questo.Io ho fatto della roba con scala, con play framework, che mi vorrei tagliare una gamba per aver fatto cose del genere.Perché? Perché me ne ho fatti il corso su Cursera di Ascala, l'oridodeo, e mi sono detto "ah, però scala".Ok, lo ho fatto.E me ne sono comunque pentito.Quindi secondo me se hai tempo di fare tutte ste astro puttanate significa che te lo puoi sempre permettere.Se hai bisogno di fare un deliverable serio, scegli la tecnologia con estrema razionalità.E questa cosa va su qualunque cosa.Da quello che fa il server con Go, con Node, con PHP, con Java, con Bash e si fa il routing a mano con le regexp, a quello che fa totalmente l'opposto e mette next anche per fare il form di contatti.Se ti puoi permettere una cosa del genere, si fa che il tuo deliverable è null, cioè si fa che non c'è valore nel tuo deliverable, se puoi veramente permetterti di fare una una cosa del genere e Rails al giorno d'oggi è la scelta più sensata per una apprezzazione MWC monolitica.Prego Mattia, poi arriva l'assegno da DHH.DHH, chiaro, che salutiamo sempre con molto affetto.Salutiamo sempre, lo avremo alla prossima puntata.In realtà, mi sembra che siamo tutti abbastanza allineati sul fatto che esiste nel nostro mestiere in generale, non tanto nel front end o nel back end o in una nicchia, un problema di over-ingenializzazione, cioè di sparare alle formiche con un cannone.Ed è una cosa che abbiamo fatto tutti e che vedo in mille contesti diversi.una cosa che non hai citato tu ma che sicuramente hai visto succedere è che in questo momento qualunque cosa tu abbia se non la riscrivi in RAST sei un fallito.Detto che siamo tutti d'accordo su questa cosa io vorrei fare il passo successivo e chiedermi e chiedervi anche a questo punto perché succede questa cosa.Un po' io la spiegazione che mi do è che la maggior parte di noi fa questo mestiere perché ci piace e perché ci dà soddisfazione giocare con dei giochi nuovi fondamentalmente.Un po' è bandwagon effect appunto quello che se tutti attorno a te stanno riscrivendo le cose in rust ti senti un po' spinto a doverlo fare anche tu.Un po' è quello che diceva Matteo prima che hai detto giustamente anche tu che forse ci manca un po' il focus su qual è effettivamente il problema da risolvere, perché se hai chiaramente quello in mente ed è quella la tua priorità assoluta, forse scegliere lo strumento giusto ti viene più semplice.Invece, come dici tu, se hai il tempo di permetterti di usare uno strumento che magari non è quello perfetto, che è quello che ti piace o va di modo in quel momento, se sei in una situazione di privilegio il tuo deliverable non è così importante.Però allora mi chiedo come facciamo a non cadere vittima di tutti questi bias che evidentemente tutti abbiamo? Perché questa cosa ci siamo cascati tutti ma esiste anche poi il bias opposto a questo che è quello che ci ha portati ad avere node.Io so solo javascript nella vita ma voglio fare il back-end quindi prendo l'engine di Chrome e lo incastro in un back-end stupro i back-end per fare i back-end in javascript.Il problema opposto è dire "ok, io so un linguaggio e voglio farci tutto".Come ci salviamo da questi bias? Usando l'unico linguaggio veramente "general purpose", Java.Aspetta, dov'è il tastino per uscire? Allora, io ho un punto di vista leggermente diverso rispetto a Carmine, nel senso, secondo me il come salvarci è proprio il cercare di, non in produzione, ma cercare magari di farci, diciamo, dei "giocattoli" per capire le situazioni, i problemi su cui una determinata tecnologia si comporta bene, sulla quale mi dà dei vantaggi, e le situazioni in cui sostanzialmente qualcosa lo lo potrei evitare.Diciamo che la fortuna, chiamamola così, di dire, dico proprio sul lavoro, "ok proviamo questa cosa con un cliente, proviamo questa cosa e vediamo come va", personalmente non l'ho mai avuta.Nel senso, su di me i clienti sono sempre aspettati che mi portano un problema, ma si aspettano comunque una soluzione.Quindi il dire "ok, per risolvere questo problema uso questo" piuttosto che quello, quello e quell'altro, fa parte del bagaglio culturale che mi porto dietro.Quindi la risposta alla domanda "come posso fare a, diciamo, evitare questo genere di cose?" invece di andare contro un muro di mattoni, diciamola così, andare contro un muro di gomma, dove il muro di gomma è tuo e il risultato è un giocattolino che ti ha fatto capire "ok, mi piace, la posso usare oppure no, lo posso buttare".Sì, quella del P.O.C.e delle esperienze, degli spike è anche secondo me un approccio che ha senso infatti io è un po' di tempo che sto cercando di fare lo shift verso la parte da software architect no e secondo me è una cosa che un po' si ottiene in vecchiaia quando tu invecchi un po' il focus del concentrarti sul problema micro lo perdi, specie se sei uno come me che soffre di ADHD imperante quindi veramente il livello di concentrazione è minimo e quindi devi in qualche modo attingere al tuo bagaglio di esperienze.E allora secondo me la soluzione è in qualche modo cercare di trasformare o almeno fare un leggero shifting da un approccio tecnico a verticali, quindi che ne so io lavoro in javascript, ho la mia bella verticale di javascript, poi mi appassiono a Rust e mi tiro una bella verticale in Rust, che è un po' quello che succede spesso perché siamo tentati di cadere nei rabbit hole, e quindi quando vediamo Rust diciamo "oh no cazzo, l'ownership devo capirla", poi tutto il problema della programmazione asincrona me la devo studiare, ci devo riuscire, no? Perché questo è quello che succede.In realtà dovremmo in qualche modo cercare di sviluppare un po' di più quello che si chiama, perdonate il mio inglese, "technical breadth", no? Quindi cercare di ampliare lo spettro più che scendere giù in verticali, che è un po' l'approccio che il software architect c'ha che poi è quello che approccia i problemi con una visione un pochino più listica, un pochino più ampia.A questo ci aggiungerei il concetto di anche nei side project, anche nei nostri POC, anche nei nostri approcci, anche quando facciamo degli spike, fermarci un un attimo a ragionare sulle abilities, dash abilities, quindi sulle caratteristiche non funzionali che quello che stiamo facendo deve avere.Questo ci aiuta a comprendere meglio il problema anche quando facciamo sperimentazione e ci aiuta in qualche modo a escludere tutti i giocatori che possono essere fighi con una prospettiva a verticali ma che in realtà sono figli a prescindere, ma nel contesto del problema che vogliamo risolvere sono steli.E questo secondo me può essere la soluzione.Naturalmente la ricetta giusta non c'è perché il nostro mondo è molto variegato, noi siamo dei bambini che adorano giocare con i propri giocattoli, quindi sai, anche invecchiaia mi verrebbe da dire.Se ti vedi nuovo giocattolo ci vuoi passare del tempo.Se vuoi poi in un certo senso è uno dei motivi per cui poi diventiamo bravi a fare questo lavoro perché probabilmente senza quella spinta a voler giocare con dei giochi non diventi bravo.Non fai quegli spike in cui poi impari delle cose nuove.Però non dobbiamo dimenticarci che dobbiamo risolvere problemi.Ma infatti il mio discorso di prima era più una critica quando non c'è questa fase qui.Cioè nel senso quando io prima dicevo "devi scegliere quello che va bene" significa che hai provato le varie scelte prima e le sai discernere.La mia critica era alla scelta con i paraocchi di qualche cosa perché è l'ultima cosa.Io ricordo che qualche anno fa andava tantissimo MongoDB, MongoDB per qualunque cosa.Anche per farci le relazioni.Ah sì, anche per farci le relazioni.Andava una bomba, MongoDB, mettevo MongoDB, mettevo MongoDB e alla fine questo MongoDB andava bene una volta su di noi.Insomma, era quella la mia critica.Assolutamente.al lavoro abbiamo una roba facciamo esperimenti ogni giorno insomma per scegliere quindi sì sì assolutamente sì però carmine vuoi mettere andare a una conferenza e dire che cazzo tutti che parlano di nuove tecnologie rasta e tu vai dici no cazzo java 8 fa il suo e funziona Adesso allora ne droppo una gigante.Lo sappiamo tutti che c'è un grosso scollamento tra chi va alle conferenze e parla e chi lavorano.Enorme.E con questo io direi che possiamo andare al paese dei balocchi.Io sono uno di quelli che va alle conferenze.Io faccio entrambe ovviamente perché sono un paraculo.Ma tu sei ambassador, cosa vuoi? Io vado alle conferenze quest'anno, io vado al Fosdame e faccio proprio il bohemian della conferenza.Perfetto, bellissimo.Ma tu dell'edizione 2022? No, no, quest'anno non riesco.Peccato.Comunque per tutti quelli che ci stanno ascoltando, Gitbar sarà presente.No, no, non riesco.Peccato.Comunque, per tutti quelli che ci stanno ascoltando, Gitbar sarà presente al FOSDEM con una delegazione che sarà fatta solamente da me, Mauro e Alessio, sicuro, a quanto capi, anche perché Alessio sta con me.Quindi sì, ci staremo.Ma siamo tutti nello stesso hotel.Esatto.esatto, mi stavate facendo venire voglia però è il mio compleanno e lo viene a festeggiare a Bruxelles, male! dai festeggiamo il tuo compleanno all'Hackerspace si ti metti a suonare drum and bass all'Hackerspace dai! vi ricordo che per chi dovesse venire ci vediamo al Fosdem e anche quest'anno cercheremo di registrare una puntata pirata.Io spero che Carmine e Alessio portino con loro lo spadino per scassinare un'aula come abbiamo fatto l'anno scorso, perché è il modo migliore per farlo.Ci saranno delle sorprese quando saremo là, adesso non possiamo anticiparvele, però detto questo, insomma, io direi che passiamo al momento il Paese dei Balocchi.e conduco nel Paese dei Balocchi.Ah, il Paese dei Balocchi! Visto che siamo a un'ora e 46 e abbiamo altri 15 minuti di episodio davanti, quindi credo che suoneremo le due ore in questo giro.Il Paese dei Balocchi è il momento nel quale i nostri guest e i nostri host condividono con noi un libro, un film, un podcast, un giocattolo, qualunque cosa abbia catturato la loro attenzione e reputino utile, importante, in qualche modo bello, condividere con la nostra community.E allora la mia domanda è iniziare dal nostro ospite.Matteo hai qualcosa da condividere con noi? Assolutamente, allora quest'oggi visto che abbiamo parlato un po' di nuove e vecchie tecnologie e cambiamenti quando farli e non farli, vi vorrei consigliare un TEDx Talk tenuto da TedxMilano, tolk in italiano nonostante il titolo sia in inglese, "The Unbearable Desire to Change", ossia "Il desiderio insopportabile di cambiare" tenuto dal buon Giacomo Poretti, il comico.È un talk molto profondo, a mio avviso, che tocca un attimo appunto questa necessità continua di cambiare, che ha preso ormai sopravvento all'interno della nostra società.Personalmente è un talk che mi ha aiutato in un periodo lavorativo molto difficile, quando volevo lasciare un vecchio lavoro che ormai mi aveva portato al burnout per andare verso nuove avventure e mi sento a punto di consigliarlo a tutti voi qualora non l'abbiate mai visto.Visto ed è bellissimo, l'ho trovato nelle note dell'episodio.Mattia? Allora io siccome non venivo da un po' ovviamente faccio un po' l'anarchico, ho due balocchi.Uno tra l'altro l'avevo scelto, entrambi li ho scelti prima dell'inizio della puntata, ma capita veramente a fagiolo perché è un libro di tra l'altro di un mio collega, perché è un tizio che lavora a Google, quindi tecnicamente è un mio collega, si chiama George Fairbanks, e il libro si chiama "Just Enough Software Architecture" e parla esattamente di quant'è la quantità giusta di design up front da fare, perché non sia troppo o perché poi non ti trovi nella merda, fondamentalmente.Quindi spiega modelli che puoi usare per descrivere un sistema che stai progettando, in modo che il sottotitolo sia "Risk-driven architecture" o "Risk-driven model".e quindi ti dice "ok analizzi quali sono i rischi che puoi che puoi ittare".Insomma è molto bello, è molto bello e tra l'altro appunto parla anche di over engineering e under engineering, over design, under design, over thinking, under thinking, quindi capita a fagiolo secondo me, con molte cose che abbiamo detto.Quindi o sono molto fortunato o è effettivamente un tema interessante.L'altro balocco invece è una cosa molto più ludica ma super interessante, come il nostro pubblico sa.Io ho un figlio che ha compiuto sette anni da poco e sono caduto vittima finalmente, dopo un po' che mi stavano addosso, delle sponsored che probabilmente tutti i genitori un po' nerdo tra di noi hanno visto di questo affare che si chiama "Touring Tumble", che è praticamente una specie di pacinco, sai, con il gioco giapponese con le palline che cadono, in cui devi mettere dei pezzi che di fatto rappresentano né più né meno che delle porte logiche.Ci sono una serie di puzzle da fare per cui, per esempio, ti spiega come si fa a contare in aritmetica binaria usando le porte logiche e quindi poi ti insegna a costruire i latch, ti insegna a costruire registri e tutte queste cose qua e di fatto impari fondamentalmente come funziona all'interno un computer.Mio figlio ha fatto le challenge più semplici e si è divertito perché si gaza a vedere le palline.Adesso che siamo arrivati a quelle un po' più complicate, in cui devi fare tipo la sottrazione tra numeri binari usando dei cosi che si spostano a destra e a sinistra, quando gli cade sopra una pallina io mi diverto come un asino e adesso c'è...Quando lui va a dormire io ci gioco da solo perché è veramente una figata.Assolutamente lo recupero e lo metto tipo in cantina pronto per quando l'hamburger cresce così insomma c'è già il regalino.Vado io? Eh sì.Ok allora io ho due balocchi in realtà nella chat dei baristi c'era anche uno che era quello di principe ma per diciamo per dignità non lo porto come balocco, ma ne ho due che sono comunque belli.Il primo è sostanzialmente la guida ufficiale su come fare il packaging degli RPM.Per chi non sapesse di cosa stiamo parlando un pacchetto RPM è sostanzialmente un pacchetto che contiene un programma che viene solitamente usato nelle distribuzioni redat-based o pezzose.Ve lo sto linkando come balocco perché è una cosa che mi sono trovato a fare di recente, insomma era quella parte del processo di sviluppo del software che non mi era mai interessata, che comunque non ci avevo mai messo mano.È una cosa estremamente magica, cioè nella link della descrizione troverete, credo che debba essere la reference, non c'è scritto credo il 60% delle macro, è una cosa assolutamente magica, ma vi dà un insight molto molto interessante su come vengono installate effettivamente le cose che installate nel vostro sistema operativo e può essere secondo me uno di quei pezzi di conoscenza utile anche se non fate questo come insomma lavoro, perché spesso tutta questa roba, questo alore, insomma, di magia.Diciamo, il container docker è quella cosa un po' più mainstream che tutti quanti stanno a leggere, un docker file è un RPM spec, effettivamente è un po' più, come un po' più complesso.Invece, l'altro balocchio libro che ho dovuto leggere proprio per fare, adesso lo so, qui ho dovuto fare l'appetizzazione di Erlang ed è un libro sulla programmazione in Erlang che dovrebbe essere di Armstrong, se non erro.Sì, ecco lì, sì, ok.L'astronauta.Esatto, esatto.L'astronauta è un piccolo passo per l'uomo, un grande passo per l'umanità.Infatti, poi, ha scritto il libro che parla proprio della luna.Vi consiglio di comprarlo cartaceo, cioè vi do sempre lo stesso consiglio ogni volta perché l'ebook in formato kindle, almeno specialmente con gli snippet di codice, non rende assolutamente.Quindi compratelo di carta.Non è la cosa più sostenibile, ma almeno per me è la cosa più significativa.Cioè, mi piace proprio vederlo in libreria.Scusa, io prendo parola per dare il rant delle 11-2 minuti.Io mi son rotto le palle dei libri, i book per sviluppatori formatati col culo.Non si legge niente, non funziona un cavolo e tra l'altro imballano il cobo non so perché.Io adesso mi sfogo, mi incazzo, mi sta uscendo la mena.Pastiglie, le pastiglie, vi prego.No, perché in realtà io ho un flow.Il mio flow è quello che negli ebook tendo a sottolineare le cose e a condividerle.Io me le trovo nel il mio ZC, non il mio tool di notte da salvare perché è sempre qualcosa di utile andare a riprendere in mano questi appunti generati automaticamente.Per cui gli ebook dovrebbero essere per me la via, il modo migliore per leggere i libri.Peccato che non ce ne sia uno formato.Non ne è uno, cazzo! Allora a questo punto non lo so cosa fare.Credetemi, è venuta voglia di farmi il mio ebook reader, vi giuro, vi giuro.Sono arrivato a questo punto scusate, scusate lo suovo.Ma hai perfettamente ragione.Ma dai cazzo stiamo facendo i device con l'intelligenza artificiale a forma di coniglio porca puttana e non riusciamo a fare un ebook reader in grazia di dio con un formato in grazia di dio.E soprattutto chiedo anche la grande pletora di persone che scrive "ebook techie" che ci seguono, il codice, se potete, non lo mettete con le cazzo di immagini, perché non si capisce una minchia ancora di più.Se vedo un altro screenshot del codice nel mio ebook, io me lo riprodurrei e lo spacco a terra.Cioè io non so...- Che tra l'altro è l'unica cosa che potresti voler copiare e incollare, no, sta in un'indicazione.tu lo devi vedere così.Allora, questo è lo che adesso faccio il rant.Il mio professore di di algoritmi ci dava le dispense così, che non c'eva un cazzo di senso già fa sto sto implementazione dello stacking, c'eva un cazzo di senso, copiava e incollava da Geek for Geeks, quindi lo poteva andare a prendere lì, però però ti doveva mettere quella cosa di difficoltà e quindi faceva copia e faceva lo screenshot e lo metteva nella dispensa.La dispensa in pdf formatata benissimo, un lavoro della della della madonna ma il codice non si copiava.Scusa scusa Matteo ti sei dovuto subire i nostri rami.Adesso il mio saturimetro è un scese la pressione calata quindi posso parlarvi dei miei balocchi.Allora io ho un libro, un libro molto carino devo dire, non so se ve l'ho già già già portato però lo riporto, che poi è il libro dalla quale ho preso il concetto del "technical breadth" del triangolo della software architecture che vi ho mezzo accennato prima nel modo peggiore in cui avrei potuto farlo.Il titolo è "Fundamentals of Software Architecture, an Engineering Approach ed è un libro molto bello.Anch'io ho un secondo balocco che è la fotocamera.Vi svelo un segreto.Nelle puntate precedenti avete visto una scritta del gatto apparire perché la mia fotocamera si surriscaldava e perché vedevate semplicemente la mia faccia gigante in stile mostro.Ecco, solo oggi ho scoperto che in realtà c'avevo lo SteadyShot, quindi la stabilizzazione software che zoomava in modo eccessivo e che consumava, faceva surriscaldare la fotocamera.Oggi, insomma, è durata tutto l'episodio e sono quasi due ore, quindi mi sento di suggerirvela.La nuova Sony ZV-E10 funziona da Dio, bellissima, e quindi ve la insomma ve la suggerisco.Prima di lasciarci però è arrivato il momento di ringraziare chi ci sostiene.Gitbar è gratuito ma non senza costi, molti di voi ci stanno stanno facendo sì che insomma possiamo sostenere parte dei costi di questo episodio.Quindi io devo assolutamente ringraziarvi.Questa settimana abbiamo un sacco di donatori e quindi sono super super felice di ringraziare Livio Francesconi che ci invita a tre birre.Ahimè il suo messaggio è croppato perché che PayPal lo taglia, per Olivio mandacelo intero via email e sarò super felice di leggerlo.Poi oggi tra l'altro, una cosa che mi ha scioccato, due donazioni praticamente nello stesso momento, quindi mi son chiesto magari fare il ringraziamento dei donatori con un'altra prospettiva di camera come ho fatto nella nuova puntata funziona di più.Scherzi a parte devo ringraziare Francesco Napoletano che ci ha invitato ben quattro birre.No.Che è un mio caro amico peraltro.Otto birre, non quattro, otto birre.E Marco Damiani che ci invita a tre birre e io vi ringrazio tutti con un abbraccio gigante perché grazie al vostro sostegno, diciamo riusciamo a pagare lo sciroppo per la tosse, parzialmente, no riusciamo a pagare parzialmente gli abbonamenti che insomma sono quelli che fanno sì che noi poi possiamo venire da voi ogni settimana a raccontarvi delle cose con dei super ospiti come l'ospite di oggi.Mauro ha la tosse quindi donate perché abbiamo bisogno di Mauro con una voce nelle migliori condizioni possibili.Se volete delle altre puntate comprate della birra balsamica per il povero Mauro che come potete sentire sta in condizioni precarie.In realtà le condizioni precarie ci sono tutte però insomma davvero ha ragione ha ragione Mattia in qualche modo se vi fa piacere sostenerci ecco sapete come fare nel sito c'è un'area supportaci e poi ci tengo a ricordarlo Gitbar funziona può funzionare anche con le nuove modalità di supporto chiamate anche value for value nel mondo dei podcaster che cos'è il value for value.Noi una volta a settimana produciamo un episodio quindi ci impegniamo, accendiamo i microfoni, contattiamo gli ospiti, talvolta rompiamo anche le palle agli ospiti per venire, è vero Matteo? In cambio come riconoscenza di insomma di quello che facciamo esistono dei modi anche tecnologici per supportarci al di là del classico PayPal che sono il value for value, ovvero lo streaming di Satoshi con le applicazioni di Podcasting 2.0 è possibile collegare il proprio wallet Lightning per donare un Satoshi che è tipo una frazione di centesimo ogni minuto d'ascolto.Questo oltre a supportarci ci dà il feedback del fatto che ascoltate l'episodio, in più c'è anche la possibilità di fare dei boost che sono diciamo dei messaggi che viaggiano appunto attraverso la donazione Lightning, tutto questo supportato, l'ho detto malissimo, vabbè vi metterò i riferimenti sulla tecnologia perché è comunque una tecnologia molto interessante, infatti presto romperò le scatole a Franco Solerio proprio per parlare queste nuove tecnologie, di come sono implementate.Detto questo io mi sono perso, ho aperto 70.000 parentesi, ma a questo punto voglio ringraziare Matteo che è venuto a trovarci, grazie, grazie di cuore.Grazie a voi.Io dico sempre, Gitbar è un po' come il dopolavoro postale degli anni 70, quel circolo arci che sta sotto casa tua e che in un modo o nell'altro ci sei finito dentro, vuoi perché la birra costa poco e magari ci sono le bottiglie da 66 e tre bicchieri con un paio di bottiglie ci fai tutta la sera e questi circoli di solito quando entri la prima volta ti fanno la tessera perché se viene la finanza poi comunque la tessera ce la devi avere ecco da oggi ritieniti Tesserato Gitbar questo vuol dire che quando hai qualcosa di interessante e io so già che hai qualcosa di interessante da condividere con noi, contattami c'è sempre una birra fresca da bere in compagnia anche di nostri host che ringrazio Mattia e Carmine che hanno fatto delle domande super interessanti e come sempre insomma versano la birra con la giusta quantità di schiuma esattamente come va versata.Detto questo io ringrazio nuovamente Mattia, ringrazio Carmine e ringrazio Matteo.Vi ricordo che potete contattarci @brainrepo su twitter, su via via email a info@gitbar.it oppure...basta, oppure niente, finito così.Cazzo mi sta messo il muto.Oppure il gruppo Telegram, il gruppo Telegram più bello d'Italia e gitbar nei vostri client Telegram preferiti.Eh no, gitbarità senza te.Ah, la tosse di sconchio! No vabbè, la mia tosse era funzionale.La tosse è...ma in realtà noi, perché stiamo facendo la tosse ora, lo possiamo svelare a chi si ascolta.Perché è per indicare che...Perché abbiamo scoraggiato.Esatto, è per indicare che questa puntata non è stata generata con chat.cpt.E' verissimo.E questo è verissimo.È quella cosa che...Il giorno che ChatGPT impara a tossire noi siamo tutti senza lavoro.Siamo tutti quanti...Io sto aspettando il giorno in cui ChatGPT impara a fare un sacco di cose, che però non dico.Ma quando ChatGPT mi impara a fare certe cose, beh, se si svuota la vita.Non ti chiediamo cosa.E nel non chiederti cosa io ricordo rapidamente che abbiamo anche un canale YouTube, è un canale YouTube molto giovane abbiamo bisogno del vostro supporto se non l'avete ancora fatto cercate Gitbar su YouTube oltre ad ascoltare gli episodi potete vedere i nostri bei faccioni e se non l'avete ancora fatto iscrivetevi al canale e cliccate sul campanaccio che il modo per ricevere le notifiche dei nuovi episodi anche in video.Detto questo è a due ore e sei minuti di episodio io vi do appuntamento alla prossima settimana un abbraccio ciao ciao ciao ciao ciao siamo noi che nonostante il deploy fallito la sei rossa il business incazzato ci troviamo al github e davanti a una birra tutto ci sembra un po meno grave [Musica]
