Benvenuti su GITBAR, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Benvenuti in questo nuovo episodio di GITBAR.Ormai siamo prossimi a Ferragosto, in realtà Ferragosto è qua, è domani, eppure noi registriamo tra l'altro ho intercettato un ospite che si è reso disponibile in questa data così particolare e così calda prima di presentarvelo però lo sapete ormai la routine è quella vi ricordo rapidamente i contati potete iscrivermi a info@gitbar.it via email oppure a @brainrepo su twitter nomi di lungo ancora nomi di lungo di più sui contati perché ormai li conoscete bene quindi vado subito a presentarvi l'ospite però questa volta voglio farli in un modo un po particolare immaginate uno sviluppatore italiano un architetto anzi per meglio dire italiano in viaggio verso tokyo con l'obiettivo e il compito di spiegare a immagino un amministratore delegato o comunque persone di un certo livello, come far scalare dei team fino a portare appunto questi team a diverse centinaia di persone.Questo sviluppatore, quest'architetto è Luca Mezzalira che abbiamo oggi con noi, super guest.Ciao Luca! Ciao, piacere, grazie per avermi invitato.Come va? So che sei a Londra, fa caldo? è stata una settimana torrida la scorsa ma devo dire che da oggi finalmente è ritornato il classico, le classiche nuvole londinesi con un po' di pioggia e si è rinfrescato quindi passeremo un ferragosto, benché non esiste ferragosto in Inghilterra, estremamente fresco.Ah fantastico almeno tu stai al fresco qua penso ci siano 45 gradi all'ombra.Allora ti faccio subito una domanda a bruciappelo, anzi facciamo una cosa, spengo la webcam perché so che tanto tra un po' impazzisce la rete, quindi abbi pazienza.Chi è Luca Mezzalira, detto da Luca Mezzalira? Luca Mezzalira è un appassionato di informatica in tutte le sue sfaccettature, amante del software, grandissimo amante delle sue architetture software e dei pattern, totalmente non convenzionale e sempre alla ricerca di migliorarsi vivendo nel concetto di continuità.ottimo tu oggi ti occupi hai un ruolo importante in una grossa società parliamo di un ruolo come vp of architecture in da zone il mio inglese è orribile quindi abbi pietà di me anche tu come sanno i miei ascoltatori.Anche il mio non è un archivio, ma ce la caviamo.Sei google developer expert, sei community manager nella community appunto London Java, script speaker internazionale e autore per O'Reilly.Insomma hai qualcosa altro che fai? Dove trovi il tempo? Le tue giornate sono di 40 ore, come funziona? No, ho imparato a ottimizzare i tempi durante la giornata in una secondo me in un buon modo.A Londra quando quando vai a lavorare di solito a meno che non sei veramente ricco e di solito i giocatori non sono immediatamente quando arrivano a Londra ricchi, neanche dopo però diciamo che in generale è difficile esserlo.Di solito prendi un affitto fuori Londra e questo significa che il tuo tempo per andare a lavoro va dai quando sei fortunato i 30-35 minuti a quando sei un po' meno fortunato l'ora l'ora e mezza.Io di solito ho un'ora più o meno dipende dai vari cambi che devo fare di commuting quindi un'ora per andare a lavoro un'ora per tornare a casa e quelle sono due ore al giorno che spendo facendo attività che può può essere lettura di libri, scrivere codice, disegnare architetture, ascoltare podcast, quindi cerco di ampliare.La parte della community è stata un po' una passione che ho anche quando ero in Italia, che ero parte dello staff di ActionScript.it e quando sono arrivato a Londra ho trovato un sacco di community interessanti, ma mancava una di JavaScript di riferimento.C'era quella di React e di Angular, ma cinque anni fa non c'era una di JavaScript che fosse più generica, che desse l'opportunità a tutti.Ridendo e scherzando, è diventata, come mi dice Google, la community più grossa d'Europa.Aspetta.Google Developer Expert mi è stato chiesto direttamente da Google per l'effort fatto nella community e nei vari speakerage che fatto in giro per il mondo quindi lì è stato proprio un dipendente di google che mi ha approcciato e mi ha fatto la proposta detto proviamo ci vediamo come va anche perché il processo è composto da interviste quindi non è giusto ti danno automaticamente vedevo che comunque un processo abbastanza articolato per l'ottenimento di cos'è una certificazione un riconoscimento saprene anche esatto un riconoscimento e ti voglio fare un'altra domanda oggi ricopri un ruolo abbastanza anzi molto importante dentro da zone che ormai è diventata una realtà affermata anche nel territorio nazionale italiano non che in che parte coprite l'europa credo tutta giusto no adesso stiamo su nove regioni siamo Brasile, Austria, Svizzera, Canada, Germania, Giappone e Italia.E verso la fine di quest'anno saremo su oltre 200 nazioni.Wow, quindi salto in avanti importante, bello.Senti il peso della responsabilità? Beh sì, tutti i giorni, perché soprattutto quando abbiamo lanciato in Italia e in Giappone, sono stati due punti chiave per la mia esperienza da zone.Nel Giappone perché era la prima nazione che abbiamo lanciato e quindi un po' il fatto di dire bene abbiamo lavorato 14 mesi veramente duro perché abbiamo fatto un sacco di lavoro per arrivare in tempo per l'inizio della stagione e abbiamo rilasciato, è andato tutto bene.Poi in Italia più che altro perché sai un po' perché la mia nazione di origine, un po' perché comunque, se dobbiamo dirla tutta, siamo stati i primi a portare il concetto di live streaming su internet, toccando probabilmente la seconda cosa dopo la pizza più importante per gli italiani.Soprattutto contando anche il contesto delle infrastrutture italiane, che è sempre un problema.Diciamo che non è stata una passeggiata al parco, come dicono qua.Esatto.raccontaci un attimo come sei arrivato ad Azone e poi come hai raggiunto il ruolo che oggi ricopre all'interno della società? Allora io lavoravo per un'azienda che si chiama Massive Interactive che è stata acquisita da Delta 3 che è un'azienda tra l'altro italiana e erano specializzati nella creazione di piattaforme OTT per varie aziende.Quando sono entrato ho lavorato su un progetto per per Deutsch Telekom e un altro per Channel 5, che è un canale qui in Inghilterra.Subito dopo mi hanno affidato il primo progetto, che è stato Dozone, che non si chiamava Dozone, era per l'azienda padre di Dozone che si chiamava Perform, o si chiamava Perform perché ora è stata venduta.E sostanzialmente ho fatto un anno come consulente esterno, avevo il mio team e noi eravamo l'azienda lo sviluppo dei 14 primi device che sarebbero stati disponibili al launch di The Zone, con 14 diverse piattaforme, quindi mobile, web, le TV, console e set of box.E poi eravamo quelli che aggregavano in un layer su AWS le varie altre aziende che lavoravano con The Zone.Quello è stato il mio primo ruolo come architetto per quella parte lì.Durante il percorso è stato un percorso molto interessante, siamo riusciti a rilasciare e nel frattempo i ragazzi di The Zone mi dicevano "guarda, noi stiamo pensando di internalizzare la parte tech, cosa ne pensi?" E lì non ci ho pensato molto e ho detto "sì, certo, immediatamente".anche perché diciamo che il concetto a quei cinque anni fa, Netflix chiaramente era ben sloganato e aveva già tolto di mezzo la problematica di dire "facciamo streaming online" e sappiamo che avevano dei numeri importanti.Per me il fatto di farlo con lo sport, che è una cosa che ognuno ha nel DNA, era veramente un no-brainer, perché il fatto che puoi dare sport a amanti dello sport a un prezzo accessibile anziché le complessità che altre broadcaster possono portare.Per me era veramente stra-eccitante.E poi il fatto che comunque ero tra i primi a entrare nel team tech come front-end architect ho detto "bellissimo, tra l'altro avrò anche la possibilità di un po' disegnare la direzione tecnica dell'azienda per quel che riguarda il front end, non mi aspettavo di arrivare a essere il GPO.Eppure, eccoci qua, sei arrivato e sei diventato una figura di spicco anche nella divulgazione, portando in giro per il mondo il pattern dei micro front end.Dal punto di vista di Luca Mezzalira, cosa sono i micro front-end? I micro front-end secondo me sono una soluzione per scalare le architetture front-end che fino a 3-4 anni fa non erano tenute così in considerazione.Una cosa che ho sempre notato, essendo amante di architettura, essendo amante anche del front-end, chiaramente perché il mio background è come programmatore front-end, la cosa che notavo è che c'erano un sacco di discipline e di studi e di pattern riguardanti il mondo del back-end, però spesso ci dimenticavamo che il front-end gioca un ruolo fondamentale nello sviluppo di qualsiasi applicazione.spesso vengono utilizzate nella maniera complessa come utilizzate negli ultimi dieci anni, però diciamo che già ai tempi di The Flash, che per me era il mio mantra a suo tempo, quando è stato introdotto il primo linguaggio OOP all'interno di ActionScript, lì c'è stato ExoScript 3 esatto.Lì c'è stato un push della community di backends, soprattutto di Javisti e Cshark, che hanno iniziato a instradare gli sviluppatori, quelli che erano veramente sviluppatori e non i designer che usavano GoTo and Play per gestire tutti i siti, e implementato una serie di pattern e di architetture che erano veramente importanti per quel tempo e lì siamo cresciuti parecchio sotto l'aspetto tecnico perché secondo me quella è stata un po' la rivoluzione che mi ha fatto amare moltissimo la parte architetturale.Guarda ricordo benissimo quell'epoca perché per tanti anni ho sviluppato interfacce su flex, l'ormai defunto flex in in action script 3 e ricordo che paragonandolo poi a quello che in realtà nello stesso periodo si poteva fare utilizzando javascript e i framework che giravano quel periodo era tutta un'altra storia.Io ricordo che le interfacce che facevamo per ERP e CRM erano completamente diverse ed erano fuori da ogni tipo di paragone con quelle che invece non erano sviluppate utilizzando quella tecnologia.Devo dire che la fine è stata un po' tragica.Sì, sono d'accordo con te, è stata un po' una botta, però diciamo è la legge di Darwin, o ti adatti o muori.Ti dico, per me Flash è stato probabilmente uno dei più grandi amori che ho avuto per vari motivi, ma principalmente perché effettivamente la duttilità di quella tecnologia, se sapevi utilizzarla, era pazzesca.Io portai ad avere un'applicazione Flex con Air 1.5 che non era neanche ottimizzato per mobile su un prodotto di ricerca e sviluppo di Ducati dove abbiamo messo questa tecnologia all'interno di una motocicletta, un motorino a quel tempo, e stiamo parlando di undici anni fa, dove girava con...faceva sostanzialmente...abbiamo cambiato la dashboard meccanica con una digitale e recuperavamo i dati dal motore in meno di 14.000 secondi, perché era uno standard industriale.E lì sostanzialmente dovevamo far vedere la velocità, la marcia e tutto quello che c'era dietro.E avevamo aggiunto una parte importante che era basata su internet dove potevi fare voice over e ptra moto e moto quindi potete chiamare gratis tramite internet e vedete le mappe e potevi settare i tuoi percorsi o avevi una webcam una frontale un retro dove potevi andare a vedere mentre guidavi diciamo che cosa succedeva davanti o dietro di te.Si vero si potevano fare delle cose magnifiche per l'epoca perché io faccio il parallelismo mi viene in mente che lo stesso periodo l'alternativa era prototype e jquery quindi anche la qualità del codice che andavi a scrivere ha molto più alta.I primi pattern ricordo di averli visti in action script.Sì, credo che il mondo javascript stia pagando un po' lo scotto che adesso stanno secondo me, tutti gli sviluppatori stanno imparando molto di più però vedo a molte interviste che ho fatto anche qualche anno fa quando facevo assunzioni dentro The Zone e quando vai sul mondo pattern, quando vai sul mondo architetturale c'è soprattutto per risultati di JavaScript c'è un po' di gap rispetto a quello che si faceva negli ultimi anni di JavaScript, di ActionScript.Vero, concordo a pieno.Quindi hai introdotto un po' per ritornare sul discorso dei micro front-end hai un po' introdotto di cosa si tratta ma secondo te quali sono le esigenze che spingono verso l'utilizzo di questo di questo pattern? Secondo me i micro front-end non sono una soluzione che va bene per qualsiasi software Sono totalmente convinto che single page application, server side rendering sono ancora, o anche il Jamstack, che ultimamente ha preso un grosso piede, sono ottime architetture che vanno prese totalmente in seria considerazione e sono probabilmente per la maggior parte i progetti più che valide e non serve assolutamente usare i microphone tens.Però c'è una nicchia di mercato dove hai la situazione come ci siamo ritrovati noi in The Zone, che hai centinaia di persone a lavorare sulla stessa piattaforma e se non riesci a modularizzare creando un'architettura che renda indipendenti i tuoi team, che non significa creare dei silos dove ognuno fa quello che vuole, ma significa creare una decentralizzazione dei team può essere un problema.Purtroppo una single page application o una solid rendering può rischiare di non dare questa libertà.Ora, faccio molti parallelismi nel mondo architetturale con la parte organizzativa, perché ci sono studi che vanno a partire dagli anni '70 che appunto cercano di trovare una correlazione tra questi due mondi che ad oggi è stata provata e io sono un grosso sostenitore.Un'architettura non può essere disegnata senza tener conto della struttura aziendale o delle possibili evoluzioni di una struttura aziendale se effettivamente c'è una trasformazione all'interno dell'azienda.Queste cose vanno di pari passo e non possiamo diciamo distaccarle, quindi dobbiamo tenerne conto e come architetti dobbiamo essere diciamo dobbiamo capire le esigenze non solo sotto l'aspetto tecnico ma anche sotto l'aspetto della comunicazione tra team, di come i team sono formati, dell'esperienza dei team e via dicendo quindi diciamo che i Microfront End vanno non solo a sopravvivere a un problema tecnico ma anche a un problema di organizzazione vero vero mi viene da immaginare una metafora, correggimi se se secondo te è sbaglio l'idea che la parte tecnica riguardante appunto il pattern dei micro front end può essere vista un po' come gli ingredienti di una ricetta però il processo quindi la ricetta vera e propria nasce nel momento in cui tu organizzi tutte le risorse per poi poter fare quel piatto.Quindi mi piace proprio immaginarlo così.Cosa ne dici? Ci sta come metafora? Sì, mi trovo d'accordo.Diciamo che secondo me una cosa interessante che credo sia abbastanza in linea sul mondo, sulla comunità di JavaScript, è che fino ad oggi la maggior parte delle volte noi prendevamo delle librerie o dei framework come Angular, come React, Redux e via dicendo, li mettiamo insieme, ma l'architettura per sé non era disegnata da noi, ma era, diciamo, data dal mantenitore della libreria, dal mantenitore del framework, o dal team dietro al framework.Oggi per Mecofrontend ritorniamo a parlare di architettura nel mero senso della parola, dove prima facevamo scelte di design, oggi facciamo scelte architetturali, Io lo trovo estremamente stimolante mentalmente, perché partire da qualcosa che non esisteva e cercare di dargli un contorno e dargli dei pattern che possono essere utilizzati per creare architetture è una sfida che non mi sarei aspettato di trovare nel mio cammino, ma soprattutto di trovare a questi livelli.lo sto facendo con interesse e grande passione.Sto cercando di mettere tutta la professionalità che posso avere per riuscire a dare un path da seguire, un percorso da seguire per chi si approccia al mondo microfrontense ed è anche per quello che sto spendendo molto tempo nel parlarne, perché più ne parlo, più riesco a crearmi dei modelli mentali che possono essere riutilizzati in altre occasioni.facendo molte consulenze nel mio tempo libero con aziende da tutto il mondo spiegando il perché di certe scelte, vedo applicate questi pattern all'interno di altre aziende, vedo che funzionano, quindi questo mi dà diciamo una buona...Ti ho perso l'ultima parte.Una buona? Una buona? Eh, non mi ricordo.Vabbè, d'estate è un po' così, abbi pazienza Luca.So che tu avrai una connessione fantastica qua.Lasciamo stare.Rimpiango la mia connessione francese.ho capito perfettamente la posizione.Ti faccio una domanda.Tu prima hai parlato tanto di creazioni di team che affrontano delle porzioni della business logic insomma dei front end.E' uno degli elementi principali dei micro front end lo slicing verticale.Nell'approccio verso lo slicing verticale entra in gioco un concetto che spesso si studia nel mondo back-end che è quello del DDD, del domain driven design.Come si sposano le due cose dal tuo punto di vista e come si organizzano i team dalla tua esperienza? No, questa è una bellissima domanda.Allora, domain driven design è una disciplina che ho ancora tanta strada da fare per poter utilizzarla al 100%.Comunque, la parte che io ho trovato utilizzabile nel mondo front-end, che spesso non ho visto parlarne ad altre persone, è la parte di come identificare un dominio di business.Perché questo? Perché il domenio del design parte dal fatto di dire ok, noi dobbiamo creare un'applicazione che è sostanzialmente un dominio.Pensiamo per esempio a Netflix.Il loro scopo è creare una piattaforma dove chiunque possa vedere su qualsiasi piattaforma che ha a disposizione, in qualsiasi momento della giornata, il film o la serie TV preferita.Questo è un po' il core di quello, di Netflix.Quindi che cosa fai? Per fare una cosa del genere, sì, tutto bellissimo, ma hai delle parti che devono essere fatte, quindi tu devi registrarti al servizio, devi pagare una sottoscrizione al servizio, se c'hai qualche problema devi avere la possibilità di contattare il customer support e via dicendo.Cioè queste sono tutte cose che però non definiscono la proposition di Netflix e queste vengono anche chiamate in Domain Driven Design come generic domain.Quindi sono delle cose che devi avere nella tua piattaforma, ma che non necessariamente caratterizzano la tua piattaforma.L'integrazione di PayPal, di Netflix, è identica a quella che abbiamo in Windows One ed è identica a quella che c'è in Amazon Prime.Quindi la realtà è che dividiti da degli strumenti per identificare i domini e dargli un peso all'interno della tua azienda.Questo peso, che è sostanzialmente diviso in tre, in core domain, che sono effettivamente il problema che stai cercando di risolvere, quindi nel caso di Netflix, sarebbe la possibilità di avere il catalogo, avere la distribuzione di device, avere il video streaming.Hai dei support in domain, che sono dei domini di business che sono addizionali al core, quindi se per assurdo un dominio di business che non è core, dovesse, quindi se un supporto in domain dovesse mancare, puoi creare dei pattern attorno a quello in maniera tale che non vada a ledere il core path dell'utente.E poi hai dei domini generici che sono altrettanto importanti ma non caratterizzano il business, che siano appunto il metodo di pagamento, la sottoscrizione, vi dicevo.Questi chiaramente dopo dipende da azienda a azienda, possono, evolvono chiaramente durante la vita aziendale, perché all'inizio quello che può essere un generic domain può diventare un core domain nell'evoluzione aziendale.Nel caso di Netflix prendo il concetto di sottoscrizioni.Per esempio all'inizio Netflix utilizzava un'azienda di terze parti per gestire le sottoscrizioni, chiaramente pagava per utente registrato, a una certa soglia hanno capito che quella doveva essere, perché lavorano a una scala pazzesca, hanno dovuto crearsi il loro team e il loro tool interno, che ha estremamente senso perché l'evoluzione aziendale fa evolvere anche i domini di business e questo deve essere, secondo me, riflesso anche all'interno dell'architettura e dell'organizzazione aziendale.In generale, credo che DDD non sia stato applicato nel mondo frontend, un po' per mancanza di practitioner.Io credo, secondo me, nel identificare come possiamo trovare un dominio nel caso di Microfrontend, riguardo come fare uno slice.Tu l'hai chiamato verticale, io di solito nelle mie esplicazioni dico sempre può essere verticale o tropizontale, dipende dal tipo di architettura che vogliamo mettere in piedi.Però il fatto di identificare un domain da già l'idea di come suddividere, di come dividere scusa, il concetto tra component e Microfrontend.Che spesso una delle domande che viene spesso fatta è "ma alla fine un microphone tablet component.La realtà no, non lo sono.Il component è il punto di vista di un tecnico che va a risolvere un problema che può essere di duplicazione o può essere di riutilizzo, un altro è vedere l'applicazione dal punto di vista del business e quando vai a scindere queste due cose e le vai effettivamente a capire all'interno, vedi subito che il punto di vista cambia completamente.Verissimo, tra l'altro era una domanda che avevo preparato per dopo, quindi hai fatto centro la divisione la divisione del team e quindi anche del del dominio in sottodomini no? crea o comunque rischia di spingere verso silos di informazione tra l'altro se a questo ci aggiungiamo un concetto che è che tu promuovi a spadatrata che è lo share nothing, ho visto diversi talk dove ne parli, spesso si rischia di cadere in questa trappola, quali sono secondo te le armi che abbiamo per difenderci da questa condizione? - Ce ne sono moltissime, ho praticamente un capitolo sul mio libro dove ne parlo perché sono convinti.Allora diciamo bisogna prendere secondo me la parte di sviluppo software nella sua totalità, non possiamo pensare solo alla parte coding.Però per assurdo, se pensiamo al fatto di abbiamo dei team che lavorano indipendentemente e fanno un deployment che è indipendente l'uno dall'altro, è vero si possono creare i silos, ma ci sono delle metodologie che ci permettono di risolvere questi problemi.Un esempio, faccio una serie di esempi che appunto secondo me sono validi in una situazione del genere.Ci sono delle...abbiamo creato, per esempio, in The Zone una serie di meeting che aiutano a socializzare tra team.Quindi abbiamo la community of practice, che sostanzialmente prende tutti i front-end developer e li mette in una stanza ogni 15 giorni a parlare per un'ora di un problema che hanno risolto o di una cosa che hanno fatto nel loro tempo libero.Ma comunque va a creare il bounding tra i team.Abbiamo le Town Hall, che invece sono degli eventi che vanno fatti per ogni Dev Center, dove abbiamo, non so, un centinaio di persone, dove c'è un'ora e mezza, due ore di presentazione erafrica su cose che sono state fatte all'interno del Dipartimento, back-end, front-end, quello che può essere.Abbiamo le RFC, so, request for comments, che sono utilizzate per quando vogliamo evolvere l'architettura vogliamo introdurre un nuovo tool, vogliamo cambiare una metodologia nella nostra CI/CD e quello è un altro modo per poter creare knowledge all'interno dei team perché sono fatte in Git e quindi tutti hanno accesso a Git e possono andare a leggerle.Abbiamo le Architecture Decision Record dove andiamo a catturare con i principal engineer il perché facciamo uno snapshot di com'è la situazione aziendale in quel momento là e il perché prendiamo una direzione rispetto a un'altra.Tra l'altro hai fatto un tweet oggi su questo, Sì, perché c'è stata una discussione abbastanza accesa in una community che seguo di CTO dove la gente chiedeva "ma perché utilizzare le ADR?" e io sono un grosso sostenitore, le utilizziamo spesso in The Zone e secondo me sono fantastiche in combinazione con le RFC perché vanno a coprire i due aspetti principali nello sviluppo software e soprattutto creano knowledge perché infatti con le diar, per esempio, hanno una, l'architecture decision record, hanno un pro fantastico che è il fatto di sei mesi dopo, tre mesi dopo, che qualcuno vuole capire perché si è stato fatta una decisione, è lì, disponibile, uno la può leggere, capisce le varie opzioni che avevamo a quel tempo e capisce perché abbiamo preso una decisione, che non significa rimarrà quella per sempre, significa che quello snapshot aveva un certo tipo di connotazione, spieghiamo la connessione e per me è importantissimo questa parte.Sì anche perché ti dà le informazioni se è il caso di cestinarla quella decisione o di tenerla perché se perdi il contesto e le esigenze a quel punto sai che la devi cestinare e non sei costretta a tenerla dire "eh ma si fa così" o "abbiamo sempre fatto così" non esiste in quel caso.Secondo me quello è uno dei problemi che spesso si hanno ma questo è fuori dal mondo del biotech, secondo me queste sono sono practices che si possono utilizzare in qualsiasi mondo.Però diciamo che queste, quando hai un'architettura distribuita, front-end, back-end, il fatto di utilizzare queste tecniche aiutano molto a creare la colla, il collante tra tutti i team.L'altra cosa è che abbiamo i nostri principal engineer che sono tra front-end e back-end, che sono quelli che diciamo sono poi i guardiani di quello che sta succedendo tra i team, quindi stanno con quali problemi hanno, fanno, riportano agli architetti che quali sono le sfide che si trovano giorno dopo giorno e poi cerchiamo di trovare un modo per risolvere i problemi che vediamo ogni giorno.Ci possono essere anche cambi architetturali o cose che non sono state pensate all'inizio perché appunto c'è c'è stata un'evoluzione del business, un'evoluzione delle richieste.Ti faccio una domanda sempre in merito ai team.Quando ho fatto un po' di ricerca, studiavo l'argomento, in realtà sono in attesa della pubblicazione del tuo libro, per cui cerco un po' di materiale in giro, e ho notato che quando si parla di micro front end, si parla di team, spesso ritorna il concetto di team cross funzionale, quindi dove all'interno del team noi troviamo dalla parte di front-end, quindi dai front-ender ai back-ender ai data analyst, insomma figure eterogenee che servono per la realizzazione di quel pezzettino specifico del user journey, insomma quel sottodominio come l'hai definito tu in diverse presentazioni secondo te Il ragionamento dei team cross funzionali è un requisito, quindi l'adozione di team cross funzionali è un requisito nel momento in cui si lavora con il pattern micro front end o si può fare a meno di questo approccio? Guarda, io ho lavorato per un po' di anni in team cross funzionali e io credo che siano fantastici perché ti danno veramente tanto e riesci veramente a sviluppare delle cose che potrebbero essere un po' più complesse nel mondo, dove di components team, come vengono chiamati, quelli che sono specializzati in fronte a Becken.Però ci sono delle situazioni dove non credo siano sempre applicabili e ti faccio l'esempio pratico di quello che stiamo facendo di The Zone.Noi abbiamo dei team che sono cross-functional, perché riescono effettivamente a gestirsi una pipeline end-to-end, quindi riescono a farsi back-end e front-end insieme.Però la maggior parte dei team non lo sono, e c'è una spiegazione logica dietro questo.Se tu pensi che, appunto, abbiamo una cross-platform application che ha una trentina, 30-35 device che dobbiamo supportare, significa che se noi facciamo cross-functional, dobbiamo avere dei team che sono molto più grandi dei mitici due pizza team che diceva Bezos di Amazon.E l'altra cosa è non possiamo avere che ne so decidiamo.Abbiamo solo il front end quindi web developer che sono con i back end developer e fanno una feature end to end perché se questo accade significa che noi dichiariamo che il web è first class citizen all'interno di The Zone e invece non è vero perché noi vogliamo che avete centinaia di device.Esatto quindi non possiamo non possiamo permettere una cosa del genere.Quindi la soluzione di utilizzare team, components team, in questo caso, ci è venuta comoda.È chiaro che ci sono dei trade off.Quindi nel momento in cui tu dici "fai una cosa del genere", come facciamo a comunicare con i team, sapendo che magari un team che sta sviluppando delle API che sono, che ne so, in uno del Dev Center, deve comunicare con un altro Dev Center, che è in un'altra parte d'Europa.E lì, appunto, una cosa che enfatizzo molto nei miei workshop è il concetto di API first.Quindi il concetto che si utilizzano per lo sviluppo dell'API, soprattutto nel mondo Microsoft, in generale della definizione dell'API, e poi avere il consumer e il producer che lavorano verso questo contratto, uno per consumarlo, l'altro per produrlo, ed è la stessa cosa che facciamo sul mondo microcontent e col mondo back-end.Quindi si lavora molto sotto questo aspetto e soprattutto, secondo me, si danno, stiamo cercando di dare un'enfasi anche alla tipologia di device che abbiamo, perché per Assurdo e Endosone la maggior parte dei nostri utenti continua a guardare lo sport da TV o console.Quindi capisci che è un po' l'opposto di normali applicazioni dove hai una grossa quantità di persone che utilizzano mobile e poi web.Per noi la maggior parte dei nostri utenti utilizzano TV.e quindi già cambia la dinamica e il feedback loop delle tv e lo sviluppo su tv è molto più lento rispetto a web e mobile e anche con parecchi limiti anche tecnici immagino, no? esatto e visto che abbiamo introdotto la parte tecnica, mettiamo le mani sulla ferraglia quindi ci farai da guida, da caronte in questo percorso, piccola parte di chiacchierata tecnica sui micro front end leggendo o quando si approccia ai micro front end si capisce che in realtà esistono diversi modi per implementare questo pattern lo si può fare a runtime, lo si può fare per esempio utilizzando anche solo i link io divido la mia applicazione sotto applicazioni ci metto un reverse proxy davanti e in strada una parte da una parte o all'altra seconda del momento nella user story.Esistono davvero tanti tanti modi.Quali sono secondo te i casi d'uso migliore per ogni metodo tecnico per implementarli? Non ti dico di citarli tutti però almeno quelli più importanti.Sì assolutamente.Allora diciamo che io per il microphone 10 ho creato un quello che chiamo il Microphone Tend Decisions Framework, che secondo me è un po' il pilastro per poter disegnare un'applicazione Microphone Tend.Lo chiamo un po' i pilastri per il semplice fatto che seguendo questi quattro punti chiave, che fra breve è Nucleo, riusciamo a dare ed riusciamo a filtrare il quantitativo di informazioni che dobbiamo andare a prendere.La prima scelta è è quella di capire se vogliamo uno split, come lo chiamo io, verticale o orizzontale.Quindi voglio avere molteplici microphone 10 nella stessa pagina o un microphone 10 che alla fine viene rappresentato da una pagina HTML o una single page application.E questa è la prima scelta.Di solito io ho visto che l'utilizzo di una single page application, comunque di uno split verticale viene utilizzato dove abbiamo delle applicazioni che sono un po' più complesse e hanno una difficile connotazione di creare degli incapsulamenti importanti all'interno della view.Ti faccio un esempio pratico.Nell'Horizontal Split per esempio New Relic lo utilizza bene e ha però delle dashboard che sono ben incapsulabili.Nel caso nostro di The Zone, ma come se possiamo un'interfaccia di Netflix, il fatto è che probabilmente The Zone è anche un po' diverso.Nel caso di The Zone, dove hai il video player dietro all'insieme del catalogo e c'è una fluidità all'interno dell'interfaccia dove il catalogo può andare sopra video player oppure può scomparire, tutta una serie di cose così, creare un'interazione del genere spezzando lo sviluppo può diventare effettivamente problematico perché puoi ritrovarti con delle situazioni dove un team ha cambiato, che ne so, un'animazione o ha cambiato un modo in cui di interagire e chi va a comporre la pagina alla fine non lo sa e non può conoscere tutti gli edge case della situazione e quindi si può ritrovare in situazioni che a runtime l'applicazione si spacca.E questa è una cosa che io ho cercato di evitare dando più semplicità nell'utilizzo.L'altra cosa è che se pensiamo ai due modi, quando decidi di fare con un vertical split, sei molto più vicino al non normale sviluppo di una single page application o di una pagina HTML, se vogliamo.Quindi questo ti dà una serie di certezze che non devi reinventarti la ruota ogni perché infatti quando andiamo sull'Horizontal Split c'è un certo tipo di investimento che bisogna fare.Come fai a garantire che la tua interfaccia non si spacchi davanti all'utente, non si spacchi a runtime? Come fai a garantire una certa omogeneità della UI e non avere conflitti di dipendenza, non avere conflitti di CSS e via dicendo? Ci sono una serie di domande quando ci si imbarca nel mondo dell'horizontal split, quindi della parte di avere molti multiplici ma che affrontano la stessa pagina, che devono essere risolte non solo sotto l'aspetto tecnico ma anche sotto l'aspetto organizzazionale, perché devi anche decidere, ok ho quattro team che fanno quattro parti diverse dell'interfaccia, chi è il team responsabile per mettere tutto insieme e per essere sicuro che altri team non abbiano, diciamo, creato un'interfaccia faccia che ho creato un microphone tend che può spaccarsi a qualsiasi momento.Ci sono una serie di...non dico che sia impossibile ma devono essere ben pensate e c'è sicuramente un processo di studio che è più alto rispetto all'utilizzare il Vertica Split.Questa è la prima decisione secondo me.- Specie se non utilizzi un approccio alla Spotify dove usi gli iFrame e quindi parte della complessità lei ridotta ma solo in alcuni casi d'uso puoi permetterti quel tipo di divisione no? Assolutamente, tant'è che Spotify dato che lo citi è andata via dall'utilizzo dell'iFrame sul web ma lo utilizza ancora sulla desktop application.Ah ok, io mi ero fermato all'utilizzo in entrambe le piattaforme quindi mi stai dando un'informazione in più.Si, l'hanno fatto ma c'è un motivo, lo spiegano anche nel loro blog tecnico, il fatto di utilizzarlo su web portava ad scaricare troppo codice, ma se tu ci pensi nella parte desktop application l'idea è molto valida per il semplice fatto che non devono scaricare nulla dal network, è tutto disponibile nel pacchetto all'interno del tuo hard drive, quindi lì ha estremamente senso utilizzare un concetto di iFrame perché ti toglie un sacco di problematiche e anche se hai 100k in più va va bene lo stesso perché tanto alla fine viene caricato non da network.Sì anche perché comunque un'applicazione così ibrida di per sé pesa un'enormità visto che comunque si deve portare Chromium appresso.Ti volevo chiedere un'altra informazione importante.come ci si comporta invece? Perchè da quello che ho percepito, buona parte dell'approccio a Micro Front End utilizza una composizione a runtime.E la mia domanda è, con l'ASEO come si fa? Questa è un'ottima domanda.Allora, composizione runtime o meno, partiamo dal punto di vista SEO.Abbiamo un po' di opzioni con il microphone 10.La prima chiaramente è fare una composizione runtime con un server-side rendering.Ci sono già dei framework che lo fanno basato sul microphone 10.Quindi questo è totalmente possibile.non mi ricordo male, Puzzle.js è il primo che mi viene in mente e Hologram che è...scusa, Holochron, che è uno degli ultimi che è uscito, che è stato utilizzato da American Express, se non erro lo fa lo stesso.Questo è stato creato da dei consulenti che lavorano per American Express, interessante, Puzzle.js è fatto apposta per SEO, quindi per SEO.C'è un'altra tecnica che abbiamo utilizzato noi, in the zone, che viene chiamato dynamic rendering ed è un'opzione che è stata messa a disposizione da Google nel 2018, a maggio, e sostanzialmente quello che fa è, nel momento in cui riconosci che lo user agent è di un crawler, vai a servire una pagina ottimizzata per il crawler.Viene utilizzata la tecnica anche da Spotify, ed è molto interessante perché sostanzialmente vai a creare un markup che è ottimizzato per il crawler, L'unica cosa che fai è sostanzialmente nel momento in cui identifichi e dipende come hai strutturato la tua infrastruttura, può essere un application server che riceve la richiesta, nel nostro caso è una lambda di Edge che lo fa, perché utilizziamo Amazon, e quindi quando riconosciamo che c'è un user agent, che è un crawler, andiamo a servirgli le pagine del catalogo che sono statiche, non hanno nulla a che vedere, le rigeneriamo ogni 12 ore, e rigeneriamo tutto il catalogo ogni 12 ore.La cosa bella è che puoi aumentare le informazioni, quelle che sono nascoste, che magari aumenti il DOM element con interazioni dell'utente, in quel caso lì puoi rendere totalmente visibili, è un markup completamente diverso e viene utilizzato solo dai crawler, le persone normali utilizzano l'esperienza che siamo abituati ad avere.Molto interessante, è da approfondire, ho preso qualche nota perché mi hai sicuramente incuriosito.Volevo ritornare un attimo al concetto di duplicazione/condivisione.Quando si sviluppano delle applicazioni e le si vuole fare come dio comanda, spesso si utilizzano dei design system.Design system che sono spesso delle linee guida per la definizione estetica degli elementi della nostra applicazione.Se poi entriamo nel mondo dell'atomic design, ne parleremo poi in una delle prossime puntate, parlare di atomi, di molecole e via dicendo.Tu sei un ferreo sostenitore dello share nothing, ma con il design system, quindi quell'elemento che ti permette di dare una coerenza all'interno dell'applicazione, far percepire al tuo utente un'unica applicazione.Come ti poni? Come suggerisci di porsi nel contesto appunto dello share nothing? Allora diciamo che lo share nothing è un principio che deve stare, secondo me, l'ho enfatizzato molto perché spesso, soprattutto nel mondo frontend, abbiamo la tendenza di fare astrazioni in maniera molto rapida senza effettivamente pensarci troppo due volte o all'impatto che può avere.Ora io non voglio passare per la persona che dice duplicare il codice bello.Però ci sono una serie di scuole di pensiero che dobbiamo analizzare.La prima è, per esempio, partiamo da una che ho scoperto di recente, nelle ultime settimane, è stata molto interessante, il concetto di "dry", quindi "don't repeat yourself".Gli autori del libro, che è uscito da poco, di nuovo la ventesima edizione di Pragmatic Programmer, hanno chiesto in un'intervista, in un podcast, ma qual è stato il concetto, secondo voi, non hanno capito bene e loro hanno fatto l'appunto sul dry perché loro appunto il dry dicono guarda tutti hanno capito che il don't repeat yourself era basato sul codice in realtà noi intendiamo la business logic e lì fa la differenza del mondo perché inizia a essere già molte persone molti sviluppatori conosciuto hanno appunto questa la strazione facile e la strarre è secondo me è totalmente complessità che sta iniettando alla fine esatto è complessità che stai iniettando e spesso, troppo spesso purtroppo, ho visto situazioni nella mia carriera dove si facciamo una strazione dei componenti, li utilizzeremo centinaia di volte, alla fine vengono utilizzati due o tre volte e lì mi domando, abbiamo realmente una necessità? Perché se è codice che è like for like, quindi lo stesso, si capisco, ma la maggior parte delle volte c'è sempre quella piccola differenza in un specifico caso, quella piccola differenza in un altro caso e poi ho avuto purtroppo un'esperienza non molto positiva con un team che faceva core development di alcuni game engine e lì quando era un team piccolo e dovevano e davano la parte core degli engine per 80 persone, quando c'era una differenza chiaramente il loro backlog era infinito, ci mettevano mesi prima di cambiare le cose, perciò la gente cosa faceva? Creava un bel wrapper intorno a questo codice e iniziava a cambiare tramite composition o tramite inheritance e tramite mille altre tecniche, dipendeva dal linguaggio che stavamo utilizzando ed è stato un brutto risveglio perché dopo sei mesi che appunto loro andavano avanti a cambiare il codice dietro le quinte, alla fine non potevi più utilizzare il framework aggiornato quindi il core team era diventato totalmente inutile.Per quanto riguarda appunto la complessità e l'astrazione mi sento di suggerire un bellissimo video fatto da un amico Francesco Sciutti con Salvatore Sanfilippo dove parlano proprio del concetto di astrazione.Salvatore Sanfilippo porta le sue esperienze all'interno proprio dello sviluppo di Redis e suggerisco a tutti di ascoltarlo perché è molto molto interessante.Ci sono proprio dei passaggi che spiegano quando, secondo lui naturalmente, ha senso andare a creare una strazione e quando no.Naturalmente il contesto di sviluppo di Redis è molto particolare e soprattutto con dei constraint un pochino diversi rispetto a quelli che possiamo avere dal mondo frontend però devo dire comunque illuminante e si lega si sposa bene con quello che ha appena detto Luca.Si ti dico per il design system su Micro frontend è totalmente fattibile io ti dico non sono noi per esempio allora design system è composto di solito da design tokens e da components nel caso quando arrivi alla fine noi siamo partiti del design token quindi abbiamo dato i token ai vari team e loro utilizzano per avere consistenza i design token e fanno un'implementazione loro dei component e diciamo che lo sviluppo di DAZN non c'è troppo riutilizzabile tra domini sì possiamo avere dei pulsanti possiamo avere delle modali ma tutto qui non abbiamo così tanto da modificare, perché se dopo tu vai effettivamente nel dettaglio vedi che l'header è diverso se sei autenticato, se non sei autenticato e quando sei autenticato sei in un'altra sezione, cambiano le voci, cambiano le modalità di espressione e di come vengono gestite le cose, quindi anche lì il fatto che le abbiamo duplicate ha avuto senso perché alla fine vengono cambiate realmente una volta all'anno, quindi il cambiare una volta all'anno un header è probabilmente un lavoro da un'ora di uno sviluppatore a farla grande.Quindi farlo moltiplicato per 5-7 microfontane che abbiamo non è un grosso...scusate il mio cane.Tranquillo, sì non è un grosso effort.Io devo dirti che leggendo così nella rete, sono andato a documentarmi ho trovato qualcuno, se me lo chiedete non vi so dire chi ha scritto questo blog post, che diceva una cosa molto interessante all'interno di una società, mi viene da ricordare che fosse una hyperscaler ma non mi ricordo quale, si diceva che alcune parti che sono duplicate e condivise tra più team, spesso se non esiste una business logic stringente all'interno queste parti diventano codice open source quindi comunque mantenibile mantenuto da una certa community e condiviso quindi loro dicevano tutto quello che noi tendiamo a condividere diventa poi libreria esterna open source che ha la sua vita la sua strada e continua così.Come vedi questo tipo d'approccio? No ma assolutamente sono concorda, nel senso io credo che la cosa che ho cercato di enfatizzare pesantemente è il concetto appunto di ottimizzare quando o astrarle quando effettivamente c'è la necessità di astrarle.Troppo spesso ho visto astrazioni che non hanno avuto nessun senso nel lungo termine di un progetto perché diciamocelo fuori dai denti, fare un'astrazione è una figata atomica da sviluppatore, Però dopo bisogna pensare che quando sei un sviluppatore su un'azienda che ne so 10 persone un conto la strazione su un'azienda di 400 è completamente differente perché quel codice come fai l'onboarding dopo.No è onboarding ma anche il mantenimento perché dopo l'evoluzione molto più rapida non chiaramente c'è una diciamo un fuoco molto diverso rispetto avere 10 persone.Quindi per dirti, in DAZN abbiamo delle parti condivise, ma sono minime.Abbiamo due componenti che abbiamo deciso di farle, ma per ovvi motivi.Una è la parte di pagamenti, perché ci serve in due parti.Nel MyCraftFrontend dove facciamo la sottoscrizione, nel MyCraftFrontend dove gestisci il tuo account.E quella parte lì l'abbiamo decisa, volevamo farla condivisa, per il semplice fatto che non puoi avere un SDK per la carta di credito o di PayPal che è diverso per microphone 10.Non avrebbe senso, sarebbe un suicidio.E quella c'è stata veramente una forte richiesta di condividerla che secondo me ha avuto estremamente senso.E l'altra è il video player, perché la complessità del video player è ampia.Abbiamo un team di una decina di persone che ci lavora dietro su tutte le piattaforme e ci lavorano tutti i santi giorni da almeno un anno e mezzo.quindi quello ti fa capire che la complessità di questo componente, duplicarlo non avrebbe alcun senso.Quindi ci sono delle situazioni dove io reputo estremamente indicato avere della strazione, ma ci sono tante altre, appunto ho fatto l'esempio del ladder prima, che può esserci come no e abbiamo visto che nel lungo termine il fatto che sia stato duplicato è stato meno che un problema nel nostro caso.Poi è chiaro, quando parliamo di design system, possiamo arrivare a livello di componenti, noi abbiamo fatto un'analisi a riguardo di questo, volevamo utilizzare il web component ma non l'abbiamo potuto per il discorso che su tv anche quei polyfill non sono supportati.Adesso stiamo ragionando su come farlo con React, perché la maggior parte della nostra interfaccia è fatta con React, e se domani ci sarà un nuovo UI framework risvilupperemo il design system con un altro framework, però abbiamo messo una regola importante che è creare dei componenti che noi chiamiamo stupidi se vuoi, delle estrazioni del business logic ma avere dei componenti che sono duttili e che possono essere riutilizzati e composti insieme per creare un'interfaccia più complessa.Questa è una cosa che è molto molto interessante perché comunque gli stai alleggerendo tutta la parte di knowledge che ti permette di essere riutilizzabile.Ti faccio una domanda.Quando si parla di micro front end spesso si parla, comunque quando vai a cercare su internet, vai a documentarti, spesso si parla di web.Ma come vedi, e chi meglio di te può aiutarci a capire questo, come vedi il futuro dei micro front end invece in situazioni dove non si parla di web per esempio lo sviluppo mobile ha senso e se sì come? Si questa è una cosa che non ho ancora se parliamo di mobile browser si questa è una cosa che noi facciamo già se parliamo di mobile application si si parlo di iOS quindi Swift piuttosto che Java.Allora tecnicamente è possibile perché c'è la possibilità di fare un lazy loading dei pacchetti dei codici sia su Android sia su iOS.Qual è però il problema? E iOS addirittura anche con altre linguaggi.Per esempio se non è cambiato da cinque anni fa, anche con Lua puoi caricare codice runtime che utilizzavamo per fare dei giochi nell'azienda presente in cui lavoravo e quindi sviluppavamo in lua e caricavamo a runtime senza farla sottomissione tramite store.Però è possibile farlo, c'è solo una una grossa challenge, una grossa sfida che è quella del se tu pensi su web devi essere connesso a internet quindi di default tu hai un'architettura che richiede una connessione internet che ti permetta di scaricare qualcosa su mobile non necessariamente.Quindi la logica secondo me lì è fattibile farla, assolutamente, però devi essere, devi dare, devi partire dal concetto che il pacchetto che viene scaricato può essere che viene scaricato la prima volta e aperto offline.Quindi devi dargli un'esperienza utente che possa quantomeno dare delle indicazioni su devi essere connesso in rete o devi dare una user experience che sia decente.Altrimenti lì si invalida un po' il concetto di tutto.però lo vedo che sia fattibile.Noi per dirti, attualmente su mobile non lo stiamo facendo, ma su TV lo facciamo.E' interessantissimo il fatto che anche su device su cui le performance non sono così, diciamo, magnifiche, siamo riusciti a migliorare quelle dell'applicazione precedente solo perché carichiamo molto meno codice e carichiamo solo il codice che necessita l'utente per fare una specificazione e quello ha dato una spazzata di innovazione anche su device che sono magari del 2010 o 2011 che non te lo aspetti diciamo.Capito, adesso faccio una buttata sul tavolo, puoi mandarmi a quel paese, però è una cosa simpatica, un dubbio simpatico che mi è venuto l'altro giorno.Questo da già da diverso tempo devo dire, si parla molto di un approccio monorepo.Come vedi l'approccio monorepo col pattern micro front end? Oh questa è bella come domanda, me l'hanno fatta spesso.Allora all'inizio non riuscivo molto a capire perché vedete dei problemi su questa cosa qua, poi ho iniziato un po' a spenderci più tempo.Forse adesso capisco perché vedete dei problemi.Secondo me, allora, è totalmente fattibile utilizzare monoripo con Macfrontends, però bisogna capire su cosa stiamo ottimizzando e ti spiego perché.Allora, se utilizziamo una monoripo, partiamo dal presupposto che utilizziamo sempre le stesse, diciamo, utilizziamo sempre e cerchiamo utilizzare sempre le librerie che sono le più nuove e quindi c'è in generale su tutta la monoripo utilizziamo un update un costante update delle librerie e del codice che condiviso in questo caso quindi se in un in un'applicazione microphone tendo vogliamo utilizzare monoripo significa che a iniziamo a dire va bene ci sono delle astrazioni o se iniziamo a condividere del codice che può essere dopo fatto l'update tra tutte le piattaforme b può essere anche un discorso di dobbiamo vogliamo dobbiamo avere un investimento sulla qualità del codice molto alta, perché infatti il monoripo è una delle cose consigliate per il mantenimento del codice, perché se sai che la ripo si spacca nel momento che inizia la CI, sai anche che devi mantenere il codice, devi essere sempre in uno stato che può essere utilizzato.L'altra cosa interessante è a livello organizzativo, perché sulle monoripo tu quando hai una nuova persona che entra nel team, loro possono vedere pattern che sono stati utilizzati da altri team senza dover cercare la repository perché tutto il codice è lì.Però c'è anche delle delle delle sfide che sono per esempio quando la monoripo diventa molto grossa, dopo infatti i grandi del nostro settore come Google, Facebook o Twitter hanno creato le loro soluzioni per gestire monoripo perché sì, c'è sicuramente una qualità del codice tutto, però a una certa si arriva a gestire dei volumi che sono estremamente importanti.Quindi monoripo e anche tool non riescono a supportare certe volte tutta la complessità che possono avere nelle monoripo.Quindi sì, monoripo sì, va benissimo per Microfront End, però occhio che quando si lavora su aziende appunto di un certo tipo se non viene mantenuto e non c'è un investimento all'interno della parte di sia ICD e di come mantenere le monoripo possono diventare un problema.Ok, sì perché in realtà sentito dire così sembra quasi un approccio confligente, una sorta di contraddizione.Luca, io non so come ringraziarti a nome mio e a nome degli ascoltatori di Gatebar.Hai un po' illuminato la via sul mondo dei micro frontend dove non esiste grande letteratura in merito, giusto? No, attualmente c'è un libro che è un ebook sui micro frontend, un libro che è stato fatto da Michael Geers che attualmente è molto bello.Però non è stato pubblicato quel libro ancora.Sì, è stato pubblicato, c'è la MIP sicuramente, credo che in queste settimane stiano andando in produzione la parte cartacea.Sì, perché esatto perché l'ho acquistato online però la parte cartacea in realtà non era ancora disponibile.la spediranno credo a settembre/ottobre.Poi c'è il tuo! Sì c'è il mio che sto ancora lavorandoci, sono arrivato più della metà e l'unica cosa appunto è che ho troppa cose in testa e non troppo tempo per lavorare su tutto perché di solito faccio la nota ai weekend quindi sì sto facendo il mio meglio e non ho messo la stessa enfasi che ho fatto sul primo dove ho deliberato in otto mesi e questo me lo sto prendendo più comoda perché l'argomento è importante, lo sento molto mio e voglio dare tutte le informazioni che sono del caso e se devo espandere anche di più il tempo per farlo, lo farò adesso.Per ora dovremo essere in pubblicazione per aprile dell'anno prossimo, quindi cercheremo di mantenere quella data, voglio dargli lo spazio che merita perché c'è veramente tanto da parlare e tanto da scoprire, perché ogni mese infatti sto tenendo tutta la parte tecnica verso la fine del libro in modo tale che ho le ultime informazioni.Per esempio il module Federation è stato menzionato marginalmente da Michael e invece io voglio metterci un bel pezzo all'interno di Module Federation.Sì, devo dirti che ho quasi finito il libro di Gears, spero si pronunci così, e però per i più curiosi, a cui lo dico davanti a te, è possibile iniziare a leggere delle prime parti del libro di Luca registrandosi nella area learning del sito di O'Reilly.tra l'altro non la conoscevo, mi sono fatto l'iscrizione e ci ho trovato parecchio materiale utile.Quindi fatelo e poi acquistate il libro una volta uscito.Per quanto riguarda invece conferenze, questa epoca post-covid ha bloccato un po' tutto, giusto? Ma sai cosa? Sì e no, nel senso sì, non viaggio più come prima, però devo dire che fatto un botto di meetup, podcast e conferenze online, infatti adesso da qui a fine anno quattro conferenze e un workshop che devo fare tutto online, quindi la possibilità di se siete interessati a Microfront End di seguirmi, anche ad orari europei che sono idonei.Ok, il workshop è accessibile? Si può Se mi seguite su Twitter o su LinkedIn sicuramente ne avete visto parlarne, comunque è sul sito di Appium, che è un'azienda di Barcellona, che mi ha chiesto di fare questo workshop e registrazione online e finora diciamo saranno tre ore e mezza di discussione sui microphone tents, su varie tematiche, non solo sull'aspetto tecnico ma anche sull'aspetto organizzativo e ci sarà un una succosa parte dove lo chiamo il "meatbuster" dei microphone tend dove vado a sfatare alcuni miti sui microphone tend che ho letto negli ultimi due anni online.Sarà molto interessante.Mettiamo tutti i link, ti chiedo la cortesia se puoi inviarli così li condividiamo nelle note dell'episodio in modo da darti dare tutti i riferimenti.Luca allora io non so come ringraziarti credimi ti ho rubato quest'oretta e sono stra felice di averti qua ai microfoni di di Gitbar in versione estiva quindi grazie a nome mio a nome di tutti gli ascoltatori e poi quando vuoi Bussa questa è un po' casa tua.Grazie mille per l'opportunità e spero che siano state informazioni utili e se avete qualsiasi informazione o curiosità che volete su Microfon10 io sono sempre disponibile online, rispondo a tutti, magari con tempi che non sono di 24 ore però rispondo a tutti e mi fa molto piacere sentire feedback sul materiale che produco e anche cose che magari mancano e se posso nel mio tempo libero lavorarci lo faccio volentieri.Sapi che ti ridomperemo le scatole e cercheremo di riportarti qua non appena pubblichi il libro, che voglio curiosare un po' anche, magari così ci racconti anche l'esperienza, visto che ormai sei diventato uno scrittore assiduo essendo il tuo secondo libro giusto? Sì esatto E così magari ci racconti anche l'esperienza della scrittura dei libri tecnici se ti fa piacere Volentieri Luca io ti ringrazio infinitamente e noi ci sentiamo la prossima settimana non vi...prima di salutarvi il mio compito come ben sapete è quello di ricordarvi i contatti potete scrivermi a info@gitbar.it oppure a @brainrepo tutte le note dell'episodio, tutte le informazioni insomma di cui abbiamo parlato in questo episodio con Luca le trovate nelle note mi raccomando se vi fa piacere iscrivetevi utilizzando il vostro client di podcast preferito.Detto questo noi ci sentiamo la prossima settimana ciao! GitBar, il circolo dei Fullstack Developer.Una volta a settimana ci troviamo davanti a due birre e con BrainRepo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e degli strumenti immancabili nella cassetta degli attrezzi dei Fullstack Dev.[Musica]
