[Musica] Bene e benvenuti su Gitbar.Nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Oggi sono solo, salvo aggiunte all'ultimo momento, non ho nessuno degli ammutinati che viene a farmi compagnia, però ho un ospite, un super ospite, dovete resistere ancora qualche secondo e ve lo svelo.indovinate un po' perché qualche secondo? qualche secondo perché in realtà vi devo ricordare i nostri contatti info@gitbar.it @brainrepo su twitter ma soprattutto anche se ma soprattutto non si dice il nostro gruppo telegram mi raccomando iscrivetevi siamo sempre di più tra l'altro visto che oggi abbiamo avuto qualche nuovo arrivo tra i quali è venuto a trovarci il nostro amico Luca Mezzalira, anche lui si è unito ai bevitori di Gitbar e nulla quindi se non vi siete ancora iscritti, perché io so che molti di voi non si sono ancora iscritti, mi raccomando fatelo fatelo, ci trovate direttamente nel vostro client, telegram preferito cercando semplicemente Gitbar però detto questo, ricordate i contatti, io direi che è arrivato il momento di iniziare 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.Bene bene bene oggi sono super felice di presentarvi il nostro ospite, direttore director della Dev Experience per Nx DevTools e anche un Google Developer Expert, un istruttore su egghead e fa un sacco di cose abbiamo con noi Yuri, ciao! Ciao, ciao! Come va? Bene, bene, grazie, sono contento di essere su questo podcast Fai un botto di cose, mamma, come fai? Sì, ultimamente c'è tanta roba, abbiamo tanta roba da pubblicare, tanto contenuto da creare c'è tanta richiesta, c'è anche nuova, tante nuove idee siccome la gente ci contatta, ce ne parla, specialmente oggi magari parliamo un po' anche di monorepo e questo crea un loop continuo di cose da produrre in senso di contenuti e di...tanto lavoro Ti voglio subito fare una domanda a bruciapelo, qual è il ruolo effettivo, proprio fattivo di direttore della Dev Experience.Sì, è molto simile al DevRel in teoria, al Developer Relations.Praticamente io quando ho iniziato da Nowall o mai già quasi tre anni fa, sono entrato come engineer, come software architect, ho fatto consulenza con clienti e dopo un po', siccome siamo diventati più famosi e più famosi, il tool abbiamo avuto bisogno di qualcuno che si occupa prevalentemente solo di interfacciarsi con i sviluppatori, che alla fine per noi sono i clienti, se vuoi.E perciò il mio ruolo al momento, a Now, è di organizzare tutta questa roba, di produrre contenuto anche e quando siamo, insomma, diventare più grandi, più grandi, magari aggiungeremo anche altri dev rel in futuro, altre persone anche per il marketing, così via.Perciò il mio ruolo come direttore in quel senso è un po' di supervisionare tutta questa cosa e di entrare in questi questi discorsi.Però sì, alla fine sono l'interfaccia al momento tra il nostro team di sviluppatori e il mondo esterno sviluppatori che utilizzano i nostri prodotti.E quanto in realtà nel tuo lavoro c'entra il marketing e soprattutto come fai a non venire rapito dal mondo super veloce e talvolta, lo dico, siamo soli, anche un po' finto del marketing.Sì, assolutamente.Sì, diciamo, quello dipende sempre dalla struttura dell'organizzazione anche.Io secondo me sono fortunato siccome io coordino anche il marketing.Abbiamo delle persone che si occupano solamente del marketing, c'è puro marketing non developer relations, però nel nostro caso diciamo il devrel è al di sopra se vuoi, è la cosa principale sulla quale stiamo operando, mentre in certe organizzazioni è viceversa, cioè nel marketing è in top e poi sotto c'è il developer relations e altre ripartizioni.Il problema è che developer relations è molto diverso dal marketing, cioè noi sviluppatori sappiamo tutti, non vogliamo non vogliamo che gli addi vengano buttati su di noi, qualcuno c'è che cerca di venderci qualcosa, quello è la cosa che odio come sviluppatore, e come sono sviluppatore anche io capisco questa cosa.Perciò è sempre un avanti e indietro tra se con chi parli è uno sviluppatore o se con chi parli è piuttosto la ditta o il manager all'interno della ditta.Perché appena che tu parli con il manager all'interno della ditta diventa più marketing o anche se crei il sito di entry, praticamente di iNX per esempio, lì ovviamente diventa più marketing, i messaggi sono molto più raffinati in questo senso, ma tutto il resto come se adesso parlo con te o parlo con un altro sviluppatore su conferenze, tutto quello è di front, non cerco di vendere qualcosa anche perché poi i nostri prodotti sono open Open Source.Insomma sì.Tra l'altro un ragionamento che facevo con un amico è che alla fine vendere prodotti open source suona già una contraddizione in termini, però è maledettamente più difficile che vendere prodotti a pagamento, perché devi essere veramente convincente da far percepire il valore ma non dire "allora perché è gratis? Allora perché è aperto se non hanno niente di così tanto valevole da mostrare?" Adesso sembra assurdo sentito da me e te che comunque ci viviamo nell'open source e talvolta mangiamo di open source, no? Però ci sono delle altre situazioni dove questa cosa è nascosta.In questo periodo amo ripetere questa cosa la sto ripetendo come mantra, c'è un bellissimo libro che tra l'altro ho qua accanto a me sulle developer relations che è questo ve lo metto nelle note dell'episodio è developer relations how to build and grow asus eful developer program che dice una cosa importantissima che gli sviluppatori non vogliono comprare un prodotto adottare un prodotto lo dicevamo la settimana scorsa con Francesco parlando di backstage di Spotify, ma vogliono cocreare con qualcuno.Esatto, vogliono essere coinvolti nel processo.Se io uso NX, NX non mi sta vendendo per quanto gratis un prodotto, Narwal non mi sta vendendo un prodotto, ma sta cocreando con me e a quel punto i ruoli si cambiano e l'importanza e la salubrità mi farebbe da dire così della relazione è molto migliore e questa cosa spesso vedo che confligge con la visione del marketing vecchio stampo, il marketing classico.Allora la mia domanda e come si costruisce da DevRel e chi si occupa di Developer Experience una comunicazione profittevole col marketing, una comunicazione costruttiva col marketing? Nel mio caso io sono capo del marketing perciò riesco a dirigere un po' la direzione.Da quello dicevo non sono fortunato.No, ma scherzi a parte.Nel senso, secondo me è sempre una specie di...cioè, non è una linea fissa, non è un taglio fisso tra uno e l'altro.Come dicevo prima, dipende molto di chi hai davanti.E questo rende anche molto più difficile, nel senso, come tu mandi il messaggio.Perché, per esempio, se io parlo adesso con te, o faccio un talk, una conferenza, o scrivo un tweet su Twitter, o creo un video su Twitter, o una roba così.Lì tutta la voce è molto molto diversa, ma con la stessa voce non posso parlare se una ditta mi chiama e mi dice "ci faresti una presentazione interna di Anix per esempio, di Monoreaper?" Lì devi poi trovare l'equilibrio tra "ok, vendo il prodotto, nel senso di faccio anche vedere un paio di slide come è veloce, come è potente, quanti download ne abbiamo", che magari uno sviluppatore sia interessato, sia no, cioè marginalmente, ma sì, beh, è interessante ovviamente che viene caricato non so quante milioni di volte, però io sono più interessato a quello che...come mi aiuta nel mio lavoro, in questo momento.Perciò è una linea molto...non è una linea proprio fissa, cioè va un po' avanti e indietro e devi aggiustarti un po' come con chi parli, che rende difficile il lavoro in certi momenti.Però, come detto, nel nostro caso noi siamo cresciuti partendo dal DevRel, nel senso siccome facciamo, siccome Nowall fa anche consulenza abbiamo il marketing per la consulenza che vende tanti aspetti, ovviamente come siamo esperti nel monorepo, come abbiamo anche conoscenze dettagliate in React, Velocity, quelle cose lì, ma la cosa sulla quale stiamo basando tantissimo è più il DevRel, cioè il devol, developer experience, tutte queste cose che si interfacciano direttamente con lo sviluppatore perché il punto è essendo un tool di sviluppo il cliente principale è lo sviluppatore c'è il 90% dei casi com'è che una ditta inizia a utilizzare Next per esempio c'è uno sviluppatore che dice ma guarda è una bella cosa l'ho provato anche dopo lavoro sul mio progettino piccolo mio personale, ho giocato un po', mi piace un sacco, voglio utilizzarlo tutto il giorno al lavoro.E così parte la storia, ma è questo il giro di prodotto, parla con un altro, si mettono insieme, fanno una demo interna e poi dopo solo arriva il marketing talk perché ti chiama il manager e ti dice "com'è questo, com'è il supporto, come possiamo, ci fate consulenza, non ci fate consulenza, potete aiutarci in quel senso.No? Perciò noi ci basiamo tantissimo su questo aspetto di developer relations perché tutto parte un po' da lì.Assolutamente sì.Ed è la leva poi che fa lo sviluppatore e l'architetto più che lo sviluppatore attraverso i legami con l'architetto.Poi c'è un passaparola nell'ambito tecnico che fa una certa pressione nell'ufficio acquisti, si fanno tutte le famose un piscato di assessment per capire se si può utilizzare o meno.Chi vive nell'ambito enterprise probabilmente queste cose le conosce.Hai parlato di consulenza, no? E di open source.Perché, Narval, sapi che io storpierò la parola della tua, il nome della tua azienda lungo tutto l'episodio perché non sono in grado di declinare bene i nomi, gli ascoltatori lo sanno, l'italianizzo praticamente tutto pur vivendo in inglese, ma Narval deve tenere un equilibrio tra consulenza e sviluppo di un prodotto open source.Come si tiene questo tipo di equilibrio dal tuo punto di vista ci sono delle difficoltà che vengono proprio dal bilanciare questi due pesi che se giustamente bilanciati diventano un amplificatore economico importante però la ricetta non è poi così semplice.No assolutamente non è sempre facile, ci siamo a un pro e un contra, una parte difficile è una parte che è molto pro nel senso di facilità Nel nostro caso è un po' emerso come la strategia della ditta funzione.Quando Jeff e Victor Lawson, ex Googler, facevano parte del team di Angola, poi hanno creato Nowhall come ditta di consulenza di Angola principalmente.Avevano sempre già l'idea di avere questo...Siccome hanno vissuto l'episodio di Monolith all'interno di Google, hanno visto il beneficio, perché lo vuoi utilizzare, però anche la complessità.e la complessità.Ero sempre in testa di creare quel tool anche per il mondo open source, al di fuori di Google, che funziona però bene e che è facile ad adottare.Perché Google ha, come tanti magari sanno, anche il Bazel, che è l'equivalente di quello che hanno internamente, più o meno.Il problema è che Bazel non è facile.Nel senso, sì, se hai una vita grande, hai un team dedicato di tecnici che ti mantiene solo quello, puoi utilizzarlo e tanti lo fanno anche, però l'idea loro era sempre di creare qualcosa di facile da utilizzare nell'open source e l'open source specifico perché tutti e due amano l'open source, cioè Angular è open source ma anche già prima loro lavoravano in ambiti dove utilizzavano fortemente l'open source perciò quello era sempre una componente core.Come partito per On Hour, siccome se vuoi creare un business devi guadagnare soldi, devi pagare i tuoi dipendenti Esatto, principalmente il consulting è quello che facevano, con quello partiva il business, non c'era nessun funding esterno o niente, ma la consulenza era il coso principale.Quello però che facciamo, che facciamo ancora fino ad oggi, è che la parte open source è il 20% del lavoro, più o meno.Noi diciamo sempre l'80-20, cioè 80% consulting, 20% lavoro perché poi varia, la media nell'anno varia perché magari per un mese non hai un cliente o sei offline, in senso allora lavori full time open source.Perciò questo è un po' l'equilibrio, alla fine probabilmente sarà più 70/30, una roba così.Però vuol dire che sì, tanti di noi fanno consulenza a un cliente utilizzando maggiormente o quasi sempre Annex, Annex per lo sviluppo praticamente, e le idee, le difficoltà che vediamo che magari ci rendono difficile il lavoro con questo cliente perché c'è qualche problema che Nix, Nex non supporta bene, che non so, no, viene portato poi di nuovo nel prodotto open source in questi 20%, 30% di tempo in una settimana.E così praticamente attualmente è, diciamo, quell'equilibrio che facciamo.Non è facile, come puoi immaginare.La parte pro è che durante la settimana lavori in quel progetto di consulenza, è sempre super interessante, tante volte si dà una mano di fare il setup di qualche cosa, poi però hai il lavoro open source, magari giovedì, venerdì o venerdì solo, dove praticamente puoi un po' liberarti e lavorare su NX o queste cose.E dall'altra parte una cosa però che è molto pro è anche il fatto di vedere i problemi che ci sono.Perché un problema è che quando tu sviluppi un dev tool, lo sviluppi per il sviluppatore.Il problema è se sviluppi solo un dev tool e non hai tantissime esperienze, non lo vedi applicato in modo giornaliero direttamente, diciamo su progetti grandi anche, è difficile vedere dove sono ancora i problemi, dove magari deve essere aggiustato qualcosa in questo senso nel prodotto open source.Perciò questo equilibrio è anche al vantaggio che riusciamo a portarci dentro anche l'esperienza di lavorare con queste edit e vedere dove è una funzione e dove non è.Io vengo da una società con l'approccio simile e quindi riconosco benissimo questa e tra l'altro ci tengo ad aggiungere una cosa, nel momento in cui tu tieni un prodotto di questo tipo, di questa portata, un dev tool e lo tieni in casa, tu diventi, adesso passatemi il termine, lo so che non si dovrebbe dire, ma il massimo esperto di quel dev tool.Questa cosa ti crea un mercato di quella consulenza sana, quella consulenza buona dove tu sei la chiapa fantasmi, o il consulente che arriva, capisce la situazione, genera valore e non si addormenta all'interno dell'ecosistema del cliente facendo il mero e sporco e bruttissimo body rental.Quindi queste sono le dinamiche che si vanno a generare.Infatti il nostro approccio ai consulenti si è anche cambiato negli anni, nel senso quando si partiva con Nowrold e anche quando io ho iniziato a lavorare con loro inizialmente, la parte di consulenza spesso era anche lo sviluppo di feature con Angola, con OREC, quello che era.Tu eri proprio una specie di body rental in quel senso, tu lavoravi e sviluppavi feature.Adesso, siccome Nex è diventato molto più famoso, molto più utilizzato, si cambia pian pianino anche il tipo di consulenza dove facciamo meno sviluppo di di feature, ma veniamo proprio a chiamati come esperti di "abbiamo un monorepo, questa è la situazione, sappiamo che voi siete gli esperti di monorepo, avete anche NX, venite, dateci una mano a metterlo su".Perciò diventa un lavoro molto più, anche challenging, nel senso tu entri in una ditta, vedi una situazione esistente, cerca di dargli una mano e di magari mettere NX o quello che è e trasformare praticamente il loro modo di lavorare verso la direzione monorepo proprio.Ma è proprio il lavoro che vorresti anche fare, perché è quello che ti motiva di più.Esatto, ovviamente sei esperto anche in altri ambiti, però questo è il focus dove vorresti arrivare alla fine.Sì, poi anche lo sviluppare feature lo puoi fare in stile body rental, oppure arrivare là perché c'hai due o tre figure che sai che deliverano, che fanno delivery e quindi entri in un team portando della forza di consulenza che genera veramente valore.Questo è il tipo di approccio che un'azienda sana di consulenza secondo me dovrebbe avere.Ma potremmo rimanere ore a parlare di questa cosa.Invece io voglio arrivare a parlare di Enex.Ti voglio fare una domanda un po' da gnubo.La mia domanda cosa fa NX? Ha tutti gli effetti in soldoni per un developer perché dovrebbe adottare NX nel suo contesto? Allora quando parliamo di NX normalmente dobbiamo anche mettere il discorso monorepo.Dico dobbiamo mettere non necessariamente e possiamo entrare anche un po' al merito di di questa cosa, però NX praticamente è conosciuto per funzionare bene nei monorepo ed è quello che lo fa bene.Poi ci sono diversi casi, nel senso NX, quello che vogliamo noi raggiungere con NX che abbiamo lavorato molto, specialmente in quest'anno, è che si adatta alla tua situazione, nel senso funziona bene nel caso quando tu magari hai già un monorepo, magari con PNPM Workspaces o NPM Workspaces perché adesso ormai i package manager hanno già una specie di monorepo built-in dove magari...infatti spesso vediamo tanti clienti che sono partiti con quello, che va benissimo, hanno lavorato magari anche un paio di anni con questo, adesso sono nel momento dove diventa troppo grande, hanno dei problemi, magari ha problemi di performance, di build, così via, e cercano di una soluzione.E perciò lì è una modalità dove potresti dire "Bene, prendo NX, e Linux cosa fa in questo momento è far sì che i tuoi build, i tuoi test su un ambito più largo di un monorepo funzionino perfumante.Magari dobbiamo dire cos'è un monorepo? A livello molto alto non è niente che invece di avere un progetto per repository hai più progetti in un unico repository.Normalmente sono progetti correlati che insomma hanno qualcosa da fare tra di loro, per esempio nella stessa business area della tua azienda.In senso che non sono solo progetti completamente distinti, dove non si parlano fatti loro, hanno qualche relazione fatti loro.E questo è il monoreepo, no? E quando tu ovviamente fai il built in singolo progetto in CI, a una certa velocità, quando tu invece crei un repository con 5, 10, 100 progetti, è un altro discorso adesso far rendere questo performante diciamo nel nostro sistema di continuous integration.E questo è cosa Enhex fa nella base.Cioè ha dei sistemi di parallelizzazione dove questi task, i build, i test vengono eseguiti in parallelo al massimo possibile.Ha dei sistemi dove riesce a capire guarda in questo pull request ne hai toccato solo quei tre progetti Perciò non è che vado a rifare il build di tutti i progetti, ma esegui i task su questi tre progetti, sempre per il target, il goal di ridurre la run time nel tuo sistema di continuous integration.E questo è la base di Enext, dove facilita queste cose con questi meccanismi.Poi c'è un altro lato che è più quello che chiamiamo noi l'integrated monorepo dove Enhex ti fornisce anche dei plugin.Nel senso che non sei l'esperto di monorepo, non sai come partire, ci sono dei plugin che ti facilitano la partenza, ti generano del codice, ti preconfigurano la tua React app, la tua Angular app, in tal modo che funziona al migliore all'interno di un monorepo.E queste sono un po' ad alto livello le cose che abbiamo fatte.Io ricordo che insomma il monolipo, almeno adesso la cosa si è semplificata parecchio, però quattro anni fa o giù di lì, tre quattro anni fa erano veramente un bagno di sangue nell'ecosistema javascript.Dalla tua prospettiva, cosa vedi che è cambiato e che il trend evolutivo dei monolipo in cosa è cambiato e come Enhex ha seguito questo cambiamento e si è adattato all'evoluzione insomma, per esempio io ricordo quando arrivarono i Yarn Workspaces, eravamo tutti "ohhh" che adesso npm-workspaces, pnpm, ecco come narval è riuscito a seguire questa evoluzione ancorando le sue feature on top di questi tool perché so che sono compatibili.Sì, sì, concordo.Nel senso che due o tre anni fa, come sappiamo, non c'erano Yarn Workspace o MPM Workspace e così via.Quello che si utilizzava è o sapevi di NX, che già in quei tempi sapeva crearti un monorepo preconfigurato, dove gestisci anche le dipendenze, i link fra i packages, o l'alternativa era Learner, che ha un altro monorepo management tool che ormai noi abbiamo preso anche il stewardship di quello lì, la gestione, perché è stato considerato obsolito in aprile quest'anno, mi sa.Però questo a parte, praticamente erano queste due opzioni.Il problema nel monorepo, tu vuoi proprio evitare il fatto di dover pubblicare i pacchetti su una registry e poi riutilizzare la registry.Puoi avere quel link locale dove tu hai un pacchetto e poi direttamente ai referenzi il punto di entrata di quel pacchetto lo utilizzi nella tua app.Questo è quello che vuoi avere.E come dicevi, i AMP Workspace non c'erano, i NPM Workspace non c'erano, non c'era un modo di fare questa cosa.E in Enhex noi avevamo sempre questi plugin, la soluzione, dove lo facevamo tramite tipo TypeScript.TypeScript ha una feature che si chiamano TypeScript Path Mappings, dove tu potevi dire, guarda, @now/blablabla o @myorganization/blablabla, punta su quel file di TypeScript, che era uno dei pacchetti, e questo ti permetteva di non dover utilizzare il sistema di Yarmworks per esempio, e non ne avevi bisogno.E potevi comunque usufruire di questo vantaggio di poter condividere i pacchetti in modo veloce in un monorepo senza dover pubblicarli su una registry.E questo tuttora, anche oggi, puoi utilizzarlo.Cioè, tantissime ditte grandi utilizzano questo sistema di plugin con le Next, e anche noi stessi siamo ancora convinti che questo, diciamo, a lungo termine ti da più garanzie, più manutenibilità del tuo monoreepo, che è una cosa molto importante, perché partire velocemente è molto facile, abbastanza facile, il problema è che in un anno, un anno e mezzo, due anni, sei ancora contento del tuo monoreepo, no? Questa è spesso la sensazione che vedo.Posso farti subito una domanda? Sì.Perché mi hai messo la pulce sull'orecchio e io adesso sono curioso.Avendo anche da una parte la consulenza, probabilmente ne avrete visto di ogni.La domanda è in cosa questo approccio al monolipo è più sostenibile nel lungo periodo rispetto a un NPM o un PNPM dal tuo punto di vista? Sì il discorso è piuttosto...cioè nel senso il sistema di plugin che NX ti dà in un monorepo che...il sistema di plugin con Next noi chiamiamo l'integrated monorepo.Integrated perché è preconfigurato, non devi te occuparti di configurare ogni low level setting del tuo setup, il build e tutto quanto.Ma c'hai questi plugin, che tra l'altro puoi crearti anche te, abbastanza facilmente, che wrappano i tool sottostanti.E il discorso è che con questi plugin, se noi abbiamo tipo, non so, il React plugin, il TypeScript plugin, in un plugin per Cypress, per Jest, per Linting.Siamo noi, in questo caso, o un community provider che ha creato un plugin Nix, che ha messo tutti quei pensieri, tutta questa pianificazione di come dovrebbero integrarsi in un monorepo.Perché un discorso è mi prendo la Next.js app, mi prendo una Create React app, li butto insieme in un sistema di cartelle, metto su npm o yarn pmpm workspaces solo per avere linking ma con quello si ho fatto un monorepo riesco anche a condividere pacchetti in modo locale, linking e tutto questo funziona però poi uno ha la TypeScript version 5, l'altro ha la TypeScript version più vecchia, l'altro ha React 17, l'altro React 18 e allora praticamente io devo occuparmi come sviluppatore di mettersi che tutti questi si interfacciano in modo, diciamo, fatto bene così che si connettano in modo bene.E questo, diciamo, è un problema che spesso vediamo che anche in aziende grandi, e c'ha i tanti sviluppatori, questo diventa un problema a un certo punto, dove "ah, vedi quel pacchetto che è quello che vorresti utilizzare, però non ha la type script version giusta, perciò ti dà a runtime qualche problema quando esegui il prodotto".e in più, praticamente quello che avevo messo su questi plugin inoltre, su una serie di altre feature, nel senso che abbiamo clienti che hanno diciamo 200, 300, 400 progetti all'interno di un monoreaper dove sono diversi team che lavorano in questo monoreaper e allora hai una certa struttura anche di pacchetti che sono riutilizzabili e non riutilizzabili e quello che avevamo messo, quello che avevamo visto per esempio noi che spesso diventava un problema è come controlli chi può utilizzare cosa, importare cosa nei loro progetti.Che non lo puoi, cioè sì, con delle regole in qualche modo riesci a dire "guarda, questa è la struttura delle cartelle, perciò solo all'interno di quella cartella puoi importare, non al di fuori di quella cartella".Cioè con regole di questo tipo che metti nella documentazione, blablabla.Sappiamo tutti come funziona con "scrivo nella documentazione cosa dovresti fare e cosa no".E poi anche con tipo Visual Studio Code o questi sistemi che abbiamo oggi, l'auto-import te lo mappa su un altro utility che però non è nel tuo pacchetto ma nell'altro pacchetto, non te ne accorgi neanche, no? E subito iniziano ad avere delle cross-dependencies strane che poi diventa veramente un casino, specialmente con queste grandezze, no? Lì per esempio con i plugin abbiamo dei sistemi su che con delle lintool tu puoi dire, questi progetti li dai come un label, dove dici questo è il tipo feature di questo tipo di progetto e poi puoi definire quale label può dipendere da quale altro label per dire.In modo molto semplice puoi definire una specie di regole che però vengono automaticamente eseguite in CI, per esempio.Sono tutte cose così, che i plugin ti permettono anche fare, ti permettono perciò agevolare monolipo grandi e fa sì che non diventa un casino e dopo un anno dici "splittiamo di nuovo, facciamo un po' il repo".Si, per ritornare alla domanda che avevi fatto, come vi adottate anche nuovi sistemi come gli Yarn Workspaces, che è un sistema valido tra l'altro, perché se tu hai già le conoscenze o hai già un monorepo, non vuoi magari direttamente migrare sul sistema di NX plugin, quello sarebbe troppo complicato.Se magari hai già un monorepo di 50 e più librerie con PMP e Yarn Workspaces, vorresti solo avere qualcosa che ti gestisce e ti esegue i task in modo efficace.Quello è l'unico che vuoi, però non vuoi magari il plugin che ti gestisce tutto il build e non so cosa.Per quello noi ci siamo anche siamo evoluti, abbiamo evoluto Enhex in quella direzione in tal modo di poter anche essere una soluzione in questi casi.Questo è stato l'obiettivo.Chiaro.Domanda giusto per stare nel monolipo.Secondo te, Qua prendo in prestito una frase detta scherzando da un mio amico che è una battuta, ma secondo me un po' ha senso.Usare la parola monoripo è come usare la parola monolita a head of time, nel senso che uno dei problemi dei monoripo, dei rischi del monoripo è l'accoppiamento.Un po' tu l'hai detto ci sono dei lintool che ti permettono di mettere delle regole, cose che magari con con npm workspaces io non ce l'ho.No, no, non ce l'hai.Sì, sì.Oltre all'inting esistono una serie di altri tool e soprattutto questa cosa si presta a un approccio un pochino più verticale rispetto a che orizzontale dove non ci sono solo gli sviluppatori ma magari c'è un'organizzazione un po' più articolata con una forma che fa un po' da piramide, anche se poco ci piace.No, no, è assolutamente valido.Per quello dico sempre, noi abbiamo sempre due goal in testa come Naola, anche come ex core team members.Cioè nel senso di, sì, darti la possibilità di facilmente avere un monorepo in un'istituzione dove ti trovi, però sempre puntando su quell'aspetto di manutenzione a lungo termine.perché come dici te, su un Yarn Workspace si parte velocemente, però se lì non sei attento, dopo un po' c'è un accoppiamento fra i vari parti che è fortissimo e quello che crei alla fine è un monolithe.Perché a un certo punto se non riesci più a muoverti, perché hai troppe referenze fra i vari pacchetti e vengono utilizzati anche se non dovevano e poi ovviamente dopo staccarli di nuovo è un gran lavoro.Per quello dico, i monolipo come noi li mettiamo, come noi facciamo il setup anche spesso nelle aziende, questo è un aspetto molto importante di farla su divisione, e se questa la pianifichi per bene e la fai per bene, metti in passo già delle regole automatizzate in CI e così via, allora praticamente riesci veramente ad avere dei benefici.Perché lì quello che spesso invece vediamo, anziché avere un monolite, vedi che la gente inizia a creare più applicativi ad un certo punto entrando in quella direzione, per esempio, spesso abbiamo uno che dice "noi abbiamo una creator act up" o anche una next-gen app, o in mondo angolo abbiamo una angola CLI app che è un'applicazione con varie cartelle e così suddividiamo i nostri feature e spesso noi diciamo anche che quando prendi a next non devi immediatamente pensare a un monorepo ma semplicemente prendi la struttura di un monorepo nel senso che taglia la tua app in pezzi più piccoli, prendendo tutte queste cartelle che rappresentano una feature area, una domain area o quello che è, e lo estrai in uno o più librerie, che saranno sempre specifiche di questo applicativo, nel senso che non sono pensate per essere riutilizzabili in altri aspetti, no, no, sono sempre le stesse librerie, poi il fatto di staccarli dall'applicativo già ti dà una modularità più alta perché te devi pensare, ok, qual è l'API pubblica di questa libreria, no? C'è qualche cosa che al di fuori può essere utilizzata o no? Cioè, ho solo queste tre metodi dove posso attaccarmi all'applicativo o questo è, no? Cioè, quello che vediamo noi spesso è che lo sviluppatore in quel momento inizia già a pensare diversamente anziché quando è solo una cartella all'interno di il CLI tool, quello che vuoi, il Create React App o Angolo CLI.E poi, avendo questa struttura, diventa più pulito, perché quando tu hai più team e devi allocarli in quell'app gigante, allora già è più facile, perché lì poi adesso c'è il team della product list del shopping app, non so, quelli lavorano su quelle sottocortelle, perché questa è tutta l'afficcia, la loro main area per le shopping list.per il product list.E così via, tu puoi staccarli in questa maniera.E poi ti arriva la mobile app e già hai una situazione pronta per poterli utilizzare in modo più facile delle cose.Perché li hai già praticamente modularizzati se vuoi fino a un certo punto, anche se all'inizio avevi solo un'app singola.Questa è interessante, mentre parlavi mi hai fatto venire in mente una domanda bastardella, quindi mandami a quel paese se non ti piace la domanda.No, perché quello che fa fondamentalmente NX è in qualche modo dare la possibilità di abbracciare una serie di buone pratiche tra le altre feature che poi andremo a vedere, perché ce ne sono di altre altrettanto interessanti secondo me, suggerire e proporre delle buone pratiche per l'utilizzo dei monorippo con degli strumenti che semplificano.Strumenti che in realtà da quello che ho visto sono adattati in contesti molto diversi.E allora la mia domanda è in qualità di responsabile dell'area DX e in qualche modo completamente immerso nel progetto NX, come fate a bilanciare il trade off di una feature quest? Ti faccio un esempio, ogni utente è un utente diverso, talvolta con esigenze differenti in un ecosistema, in un contesto diverso.Arriva una feature request ho percepiti un'esigenza come fate a trasformare quell'esigenza in feature senza che questa trasformazione generi un impatto negli strumenti che sono dotati anche da un ventaglio di altre aziende che quella esigenza non ce l'hanno? Come si trova il balance tra questi elementi? Allora, normalmente, tutti i feature request li distinguiamo in due cose, principalmente, nel senso che la parte che finisce in NX Core, che è quello che puoi utilizzare anche con Yarn Workspace, per esempio, è la parte centrale di NX, e normalmente quelle sono cose di performance, o di caching, o tutte queste cose di base, di come si vengono gestite, gestito il monoreapon, da parte della speed principalmente o se questa feature ha a che fare con qualche plugin che diventano attaccati on top di questo NX Core e lì poi si distingue, cioè noi abbiamo i plugins che sono abbastanza piccoli fra di loro nel senso che abbiamo un plugin verticale per solo la gestione dei Jest test plugin solo per i Cypress test, per React, per Angular, per React Native e così via perché sono molto canalizzate e questo ci permette di ridurre anche l'impatto che hanno.Non è un unico NX dove cambia qualche cosa e poi esplode su un altro plugin di angolo, cambiando quella parte del React, perché riutilizza una parte comune.Ci sono ovviamente, per quello abbiamo un massivo numero di end-to-end test che girano ogni volta che cambiamo qualche cosa, però normalmente si canalizza veramente su uno dei plugin e maggiormente sono delle cose come, non so, sarebbe ideale avere un altro code generator per generare i componenti React in una certa maniera.Sono cose molto specifiche di un certo plugin e per quello l'impatto è solo locale all'interno di questo plugin.Cosa da dire però ovviamente è che per esempio, non so, noi al momento utilizziamo React con Webpack.C'è gente che dice "beh, noi vogliamo avere Vite, vogliamo avere YesBuild" e tutti quei nuovi sistemi più veloci e così via.Di cerchiamo normalmente di sicuramente anche frenare un po' perché cerchiamo di valutare cosa viene utilizzato maggiormente al momento nelle aziende grandi che sono un grande target dell'utilizzo di Annex.In base a questo facciamo una priorizzazione su come andiamo avanti.Però stiamo sempre dando un'occhiata su questi nuovi tool, infatti, ultimamente abbiamo aggiunto adesso YesBuilt e andremo avanti in questa direzione di bilanciare quello che ci arriva dalla community, quello che vediamo lavorando con i nostri clienti a enterprise, anche grandi, e un po' fare il match lì in mezzo.Il grande vantaggio secondo me è che abbiamo, da quando abbiamo introdotto i community extensions, che vuol dire che non dobbiamo fare il tutto lavoro noi.Nel senso, per React con Vite, per esempio, o anche NX con Svelte, Vue.js, ci sono dei community plug-in che sono veramente buoni e fatti bene, che praticamente uno potrebbe utilizzare.Se uno dice bene "now all React plug-in non mi piace, non soddisfa quello che voglio utilizzare", mi riferisco a uno dei community plugin e parto da questo.è come un npm package alla fine che aggiungo al mio workspace quindi abbiamo detto che questi plugin ti permettono di fare delle cose e ne hai citato alcuni, per esempio Jest In realtà rispetto a npm, install, jest e react testing library se sto lavorando con react cosa ho in più nell'utilizzo di un plugin? In questo caso per esempio quello di jest ma può essere quello di cypress Si si può essere quello di cypress, anche di react o qualsiasi cosa Si alla fine è che ti toglie tutto il discorso della configurazione da te C'è il senso di configurare una React app, per esempio un Cypress, all'interno di un monorepo può essere diverso nel senso che vuoi integrarlo con quella versione che esiste già, vuoi far sì che magari utilizzino una configurazione comune così che non per ogni app devi riconfigurare.C'è cose di questo tipo, chi sviluppa i Plurin, o c'è la community o noi in questo caso, pensiamo a queste cose, lo testiamo, lo integriamo in varie modalità diverse di monorepo e facciamo sì che funzionino bene.Tra l'altro stiamo anche collaborando spesso o molto con il team di Cypress, team di Jest, team di Storybook, che li chiediamo, li cooperiamo con loro, anche se dopo hanno la vicenda nel loro repo e viceversa.E sono tutte queste cose che noi stiamo occupando con Question Plan, anche te non devi praticamente pensare a come configurare in modo giusto Jest nel tuo workspace, ma viene già fatto in automatico per te.Quello che fai te è semplicemente aggiustarlo, no? E quello ovviamente devi farlo e puoi farlo, nel senso, però lì non vai necessariamente a toccare il low level webpack, ma vai in un che si chiama Project JSON, dove hai una serie di opzioni dove dici voglio avere gli externales compilati all'interno del mio vendor file o no.cioè sono delle properties che puoi andare a configurare.Altro vantaggio, che non è da poco secondo me, sempre anche parlando della manutenzione, è l'upgrade automatico.Cioè in senso che i plug-in, quello che ho, ha un comando di migrate che praticamente da una versione all'altra mi fa la migrazione automatica di NX stesso, delle file di configurazione, di Webpack, di Cypress, completamente in automatico, cambia il tuo call sorgente, cambia il tuo IFI di configurazione e così ti porta da una versione all'altra.E questo specialmente anche di nuovo se tu hai un monorepo abbastanza grande, può essere estremamente utile perché, almeno io quando lavoravo con dei clienti, se tu devi dire, o anche in generale se tu lavori all'interno di un progetto, se nel sprint planning devi dire "ah, dobbiamo fare l'upgrade di Webpack da 4 a 5 per essere importante e poi normalmente dicono "ah sì ma cos'è che implica ma non funziona più l'applicativo" no funziona però è importante perché cioè il nuovo feature potremmo usufruire del modifiederation che arriva in webpack 5, lo facciamo nel Qtrack, sappiamo tutti come funziona "Take ticket in coda al backlog" esatto, esatto sì sì, esatto e con questo comando che è molto diciamo, è stato un po' preso dall'angola CLI che ce l'aveva già dall'inizio l'abbiamo trasformato abbiamo sviluppato un sistema di code migration all'interno di NX che ti permette di fare queste cose e lo utilizziamo anche, cioè noi abbiamo fatto migrations anche di workspace angolare grandi dove abbiamo migrato tutti gli applicativi da Angular 13 a 14, da Webpack 4 a Webpack 5, mentre 300 sviluppatori stavano sviluppando sul main branch in continuo.Cioè non puoi dire in queste grandezze "affermiamo tutto, uno si occupa adesso per tre settimane a fare la migrate o quello che serve, e poi migriamo tutto".E perciò abbiamo proprio sviluppato questi code migrations che puoi eseguire più volte.come alla fine come non so se conosci database migration scripts dove puoi fare un upgrade da una versione all'altra che ti fa poi gli altri table e gli altri script e così via solo che si chiama sulla codice base.Sì sì super super interessante e adesso un'altra domanda cattiva però che secondo fa capire l'inquadramento di Enhex.Lo sviluppo di questi DevTools in qualche modo genera astrazione.Tu hai detto ci allontaniamo per un attimo da quello che Git chiama plumbing, da low level, astraiamo i concetti in modo che possono essere rapidamente configurati perché non ho bisogno di fare tuning sul dettaglio ogni volta.E poi io ti ho fatto un'altra domanda prima in merito a quanto una feature impatta su un altro utente che non ne ha bisogno, perché venendo dal mondo business a me è capitato di over modellare dei software cercando di riprodurre la realtà, creando una complessità allucinante che non permetteva di funzionare anche alle feature base, è una cosa che capita spesso, ognuno di noi l'ha fatto un'esperienza di questo tipo e tu hai detto no, con la pluggabilità, quindi la possibilità di lavorare a plugin, io risolvo il problema, che è un po' la stessa cosa che mi ha detto Francesco la settimana scorsa mentre parlavamo di backstage il developer portal promosso da e creato e mantenuto da spotify.la mia domanda è affinché un software sia pluggabile deve necessariamente astrarre delle cose alla base di questa astrazione da quello che mi è sembrato di capire ci sono due concetti importanti in NX, i generator e gli executor, mi sbaglio? Sì, sono un po il core che permette questa estendibilità.Cosa fanno questi due elementi? Qual è il loro ruolo? Si loro sono praticamente la parte core di ogni plugin alla fine.Il plugin stesso non fa niente di...o cioè normalmente ogni plugin fa da esecuzione del codice, cioè che il wrapping di un npm script quello serve l'executor.Anziché eseguire un monorepo NPM workspace dove tu hai un NPM script che ti fa da, non so, tsc per typescript compiler e poi ti dà tutti gli argomenti e i parametri, c'hai un executor @now, allora il tuo @myorg/tsc che praticamente wrap questo processo.Sotto le quinte, alla fine il coach fa nient'altro che eseguire, cioè fare un spawn sync di un processo un link di un processo, qualche cosa, in node e esegue il TypeScript compiler.Ma prima di farlo, magari, sapendo che si trova all'interno di un monolibro, magari legge la TypeScript config file, la root per fare delle ottimizzazioni, roba di questo tipo, e poi esegue questo processo.L'altra parte del plugin sono i generator, e quelli fanno nient'altro che generare il codice.Cioè, in senso, per React può essere il setup di un nuovo applicativo, un setup di un nuovo libreria, o anche solo il setup di un piccolo componentino nel modo come tu vorresti averlo, per avere anche l'uniformità fra i vari development team, così che ogni libreria, ogni componente sia più o meno una forma simile.Questo è un po' lo scopo.Agevolare lo sviluppo, alla fine, se vuoi.L'intenzione dietro i quinte.Questo può essere semplice come "sì, già ho un nuovo componente" o anche "sì, già ho questo componente, ma voglio che questo sia un rooted component" e si integra in questo applicativo e lo puoi dare come parametro.Questo è l'app dove si dovrebbe agganciare e Next poi ha anche certi generatori, dipende come complessi sono fatti, che ti inserisce persino anche il rooted component direttamente nell'app così che si connette la storia.alla fine sono delle utility, dei generatore che aiutano lo sviluppo, lo sviluppatore questo, sì chiaro, naturalmente però, altra domanda cattiva, oggi ti sto torturando, non è mia colpa, è la mia colpa alla fine no, questi tool tendono ad allontanare un pochino lo sviluppatore dal basso livello che in un contesto enterprise non è sempre poi così male, no? Nel senso che c'è qualcuno che si prende le responsabilità, decide, crea una strazione, omologa la decisione e così si va.In contesti un po' più piccoli, dove c'è questo tipo di elasticità, la cosa si presta bene o ci sono degli attriti? sì e no direi perché il discorso è che questi plugin sono abbastanza cioè si ti astragono l'npm script per dire o il wepack low level cioè dove tu praticamente ti confili completamente il tuo wepack o rollup o quel che è però è un strato sottile direi sopra quel layer che vuol dire che potresti toglierlo o molto facilmente anche creare il tuo plugin locale per configurare in quel modo come vorresti te.E comunque di nuovo poi però hai questo vantaggio di averlo uniformato e regolato.E questo per esempio per parlare delle aziende più grandi dell'e-enterprise, spesso è proprio quello che vediamo.Cioè questi noi li facciamo magari anche il setup iniziale, gli diamo una mano e poi loro si customizzano NX proprio come lo vogliono loro.cioè in senso customizzano come vengono generati i libri, hanno proprio loro set di plug-in, spesso anche solo locali, che possono anche vivere all'interno del monorepo, non è necessario pubblicare per esempio plug-in su npm o qualche parte, ma li puoi tenere locali e poi avere una forma di automatizzazione del tuo monorepo.Parlando dei scenari, diciamo, elastici, piccoli, start-up, quei scenari lì, lì dipende molto, c'è chi che dice "ah, ma è molto utile per così, specialmente se in uno startup deve essere veloce, se voglio fare un shipping di nuove feature molto velocemente, così so già che mi serve un monolipo, creo direttamente il setup predefinito che mi da iNexe e parto in modo rapido, non devo pensare a tutti i dettagli del monolipo di quel setup lì, e poi dopo ritorno e magari me lo aggiusto, me lo configuro.Però nello stesso momento poi c'è anche chi dice "no, voglio avere lo setup completamente sotto controllo, voglio configurarmi tutto io, voglio creare il mio webpack, il mio rollup o quello che sto utilizzando e poi aggiungere Next solo per il caching e per il CI e quelle cose lì ed è proprio quello il motivo perché abbiamo introdotto quel secondo modello di utilizzare Next senza i plugin è assolutamente solo per questo appoggio lì e quindi la domanda mi viene poi spontanea e automatica pensiamo a React per un attimo, alla Create React App arrivi a un certo punto dove tu fai l'eject dell'applicazione esiste un qualcosa di simile per Enhex? perché noi abbiamo parlato di adozione, quindi abbracciarlo se io invece volessi eliminare quella sovrastruttura, quella struttura, quei livelli di astrazione, esiste un Eject che mi butta il webpack nudo e crudo, quelle tre righe di script direttamente nel package JSON e ciccia? Sto semplificando un po' troppo? Sì sì sì sì sì no per quando utilizzi i plugin non esiste perché sarebbe anche abbastanza complicato realizzare un eject perché non sono tutte le tre righe praticamente di web che dovrebbe fare l'eject.Per l'approccio package based dove tu praticamente solo utilizzi NX on top lì ovviamente sì perché lì non hai mai utilizzato uno dei plugin e lì praticamente cancelli l'NX nella root della npm e fine, sai, perché già utilizzi diciamo il monoreapon modo tutto tuo, tutto sotto controllo.Quello è proprio il motivo anche per il quale noi ci riferiamo a quel tipo di setup come full control a te, no? Te gestisci tutto, voglia anche che te devi preoccuparti però di tutte le cose, di tutti i link, come fai il setup dei link in locale, devi conoscere npm, per esempio in Workspace, però se lo fai, e spesso quando hai già una struttura esistente, è molto più semplice di partire.E quello che puoi fare in quel momento è partire con quello e poi aggiungi dopo solo un plugin per un unico applicativo all'interno di quel setup e parti da questo.Però no, per il plugin React, per esempio, di NX non c'è una funzionalità di Eject.Avevamo pensato a quella cosa, però non è così facile realizzarlo.Non è solo una cosa e poi non era super alta priorità a livello delle richieste.Chiarissimo.In realtà la domanda mi portava nel ragionamento a un altro punto.Noi abbiamo fortemente parlato di NX e monolipo in questo momento, però immaginiamo il caso d'uso POC, Proof of Concept o Pet Project della situazione, ognuno di noi ne ha 70 che probabilmente giacciono sul cassetto.Non abbiamo una struttura per cui potrebbe non essere utile, potrebbe esserlo, ma anche potrebbe non essere utile avere un approccio a monolipo, ok per questo, però allo stesso tempo potrebbe essere utile per esempio un code generator, un sistema di plug-in.A quel punto la mia domanda è quanto NX si presta a essere utilizzato al di là del concetto di monolipo.No assolutamente lo puoi, quello all'inizio avevo detto, normalmente dobbiamo introdurre il discorso monolipo se parliamo di NX, però non solo, cioè nel senso tu potresti utilizzare NX oggi anche come alternativa a Create React App, che non è proprio diciamo super up to date e così via, ma utilizzi solamente NX con un'unica cartella app dove metti la tua app, non dovresti neanche utilizzare le librerie, tutte quelle funzionalità ma utilizzi solo il code generator alla fine.Perciò lì non hai veramente un monorepo perché ne hai solo un unico applicativo all'interno di quel monorepo, che è una cartella praticamente con un'app e usufruisci solo dei generatori DNNX.Sì sì assolutamente puoi farlo sì.Io mi immagino l'agenzia di comunicazione che ha bisogno di di di shippare tante app React, o angular o VGS che siano, però vuole in qualche modo, siccome ne fa tante e ne fa a ritmo molto sostenuto, vuole in qualche modo darsi una linea, cioè i componenti devono essere fatti in questo modo, lo scaffolding dell'applicazione deve essere in questo modo, components, container e quant'altro, gli stili devono essere...cosa ne so.È un caso comune che vengo chiesto anche.Cioè è un caso molto comune dove, come dici te, devono produrre più app velocemente comunque avendo un simile look and feel alla fine, no? O anche magari solo avendolo parametrizzato in modo diverso che però...cioè parametrizzato nel senso che averne più shell, no? che sono già preconfigurati in certa maniera e che poi vengono deployati in modo diverso per tipologia di cliente, che spesso esiste.Però lì spesso ho proprio il caso di Monorepo, nel senso che questi si creano la loro libreria design system, dove hanno i componenti riutilizzabili, la loro libreria teams, quel che è, e poi hanno i vari applicativi all'interno di quel repo che sono preconfigurati per i vari casi d'uso che hanno, e li compongono semplicemente utilizzando questo design system si trova all'interno del monolipo.Lì ho veramente spesso il caso dove la gente va in quella direzione.E tra l'altro là, credetemi, il vantaggio è altissimo del monolipo.Un po' di progetti fa, lavoravo in un progetto che non usavo il monolipo ma gli servivano, nel senso che io avevo bisogno di fare c'era un bug nella UIKit dovevo fare la PR, attendere che il team responsabile della UIKit approvasse la PR, che buildasse il modulo, che lo shippasse su NPM per potermelo vedere.Oppure facevo in modo molto vichingo, molto vichingo come ha scritto Matteo Colinacqua qualche tempo fa, sostituito io facevo hot replace nel node modules.Ecco qua un caso d'uso per chi non utilizza i monorepo.Già solo la visibilità del codice perché spesso se tu lavori in repo cioè singoli polirepo non monorepo diciamo in aziende grandi, te sei responsabile del design per esempio, sviluppi componenti inutilizzabili del design system, non sai neanche dove viene utilizzato, perciò non hai neanche modo di dire "adesso provo velocemente se quel bottone effettivamente funziona in quell'app o se non dà problemi" e già il fatto di essendo in un monorepo, il code che sorge di niente ce l'hai sulla tua macchina, cioè nel senso tu puoi anche utilizzare sistemi di Visual Studio Code per fare "find all references" di quel componente e lo trovi o fai un vecchio search con una redgex o qualche cosa e lo trovi il componente.E siccome, e questo è un altro vantaggio dei plugin, siccome il setup è uniforme in quel momento, te sai anche come far partire quell'applicativo.Perché sarà lo stesso comando come utilizzi per la tua demo app del tuo design system.Perciò questi sono tutti vantaggi dove tu già puoi dare un'occhiata, vedi come viene utilizzato e puoi anche fare cose di breaking change, diventa molto più facile.Sì, ha dei vantaggi e svantaggi sicuramente.Hai detto una cosa molto bella in realtà, cioè hai visibilità su cosa stai usando e come lo stai usando, no? E qua si apre tutto il capitolo di discoverability.Come NX abbraccia questo argomento? nel senso di non far vedere o...per esempio una cosa che ho visto una feature interessante è tutto il lavoro che fa sul dependency graph sì questo è molto interessante sì sì esatto, cioè questo è il dependency graph alla fine alla base di DNx cioè viene calcolato in un thread a parte, dietro le quinte, però viene utilizzato per tutti i processi che fa.Quando fa partire, diciamo, cerca di parallelizzare più task, guarda dependency graph per capire cosa deve essere fatto prima e quale lavoro deve essere fatto dopo, perché ovviamente conoscendo tutte le dipendenze, conosce come utilizzarlo.Però dall'altra parte, quello che dici te, è la visualizzazione di quel dependency graph.Quella è la cosa, secondo me, molto forte.anche il poter, cioè poter farlo vedere in una finestra del browser dove tu, anche non conoscendo la situazione del monoreap, puoi aprirlo, puoi vedere come i pacchetti dipendono fra di loro, puoi andare anche nel dettaglio e dire, guarda, voglio vedere, clicco su un nodo, cioè anche interattivo, ultimamente abbiamo fatto interattivo, nel senso che puoi cliccare su un nodo e dire, parto da questo nodo, so che voglio arrivare a quell'altro nodo, fammi vedere tutte le vie come arrivo a questo nodo, fare questi due, no? E sono strumenti di debugging alla fine, di esplorazione del monoripo e anche dei debbani per capire ma perché c'è quella dipendenza che non dovrebbe essere.Sì, era molto utile.Guarda, questa cosa da molti è sottovalutata, per me ha un'importanza allucinante se attorno questa feature mettiamo il frame di… sai, molti dicono scriviamo il codice per rifattorializzarlo, ok? Quindi prepara il codice quando lo scrivi in modo che sia facile stenderlo, ok? C'è un'altra scuola di pensiero che si affianca a questa che dice tu prepara il tuo codice affinché sia facile eliminarlo.È una cosa ancora più intelligente per chi lavora sul refactoring, per chi scrive il codice, se vuole avere del codice veramente disaccoppiato deve ragionare in questo modo.Avere una visualizzazione del dependency graph in quel modo assume un'importanza allucinante in quell'ottica e spesso è una cosa che non ci fermiamo a ragionare per esempio io oggi ho perso tre ore per cercare di purgare una cacchio di libreria che era accoppiata in tutti i modi possibili e immaginabili al codice Cerca e rimuovi, cerca e sostituisci spesso, non si presta bene alla creazione di un modello mentale, qua potremmo rimanere ore a parlare di carico cognitivo e di quello che facciamo, quanto invece si presta bene avere un grafo, un chart, un grafico che lo mostra.Questa cosa mi gasa tantissimo, lo devo dire.No, è una feature, probabilmente la feature più amata dei nostri sviluppatori, anche perché è una delle poche feature visuali, no? Perché essendo un dev tool che il 99% lo utilizzi tramite la command line, è un po' diciamo fresco avere qualcosa di visuale anche.No, ma è molto potente anche perché questo che si vede, diciamo, nelle visualizzazioni del browser è anche solo una parte.Lo stiamo sviluppando continuamente anche se stiamo pensando già ad aggiungere feature più avanzati nel poter scriptare quel graph, perché tante volte quello che fai anche e quello che non viene visibilizzato talmente è che questo dependency graph ha anche l'informazione dei pacchetti npm che ogni di questi pacchetti utilizza.Perciò tu puoi anche a livello node script, ti puoi fare un piccolo script dove puoi direttamente tramite un API farti dare il dependency graph che è un oggetto alla fine JavaScript, con tutte queste informazioni, e poi ti crea il tuo loop, il tuo algoritmo, che lavora su questo.Perciò questo graph praticamente puoi utilizzare in mille modi diversi che possono essere utili per il tuo caso.Per esempio, io avevo un caso in un'azienda dove facevamo consulenza, che era...sa che angola, mi sa? E volevano ottimizzare la startup time dell'applicativo, che con lazy loading è uno dei modi che puoi farlo, no? ma esendo un applicativo gigante che tra l'altro io non conoscevo neanche andare lì a trovare tutti i possibili paths ai componenti che non sono lazy loaded e perché non sono lazy loaded è quasi impossibile.Però scrivendo per esempio un piccolo node script su un NX Monorepo che lo utilizzavano NX, riuscivo a dire "bene, trovami tutti i node finali" e da quelli parti e vai su finché arrivi a un'app seguendo semplicemente il path del dependency graph e se non è lazy load, cioè se tutto il path è direttamente incluso tramite un import nell'applicativo elencami praticamente queste librerie e il percorso come arriva da un nodo all'altro, cioè mi faceva proprio vedere il file, la riga nel file dove viene fatto l'import che non era lazy e che potevo poi andare a sostituire.E questo ci permette per dire prendere conoscenze di una codebase gigante magari, dove non sai come è strutturata utilizzando questo strumento puoi ragionarsi su.E questo è solo un caso di uso, c'è le possibilità che...veramente è una afficcia bella, sì, assolutamente.E di lì la consulenza ben fatta, nel senso che arrivi là e gli riduci...Certo, lo fai in qualche giorno, dove un altro magari ha gli mesi a fare un lavoro che non è piacevole.Esatto.Parliamo a proposito di velocità.Io prima di fare questa chiacchierata NX l'ho solo visto, non l'ho mai provato, ma mi ripropongo, ho un POC da far partire a breve e mi ripropongo di utilizzarlo.Però una cosa che ho letto spesso è che si parla di velocità a mille da cosa è data questa velocità nel buildare grandi monolipo? quali sono le feature che permettono di farlo in modo così velocemente? sì, allora lì si parla sempre di ridurre la build time o test time, alla fine l'esecuzione di un certo task, qualsiasi task sia, poi alla fine, a livello di un monolipo, cioè perché ovviamente il singolo build di un React Hub o Angular Hub dipende come lo fai il build cioè se utilizzi Webpack o se utilizzi ESBuild o quel che è l'ESBuild in quel caso ti dà la velocità di quel singolo build specifico il problema è ovviamente se tu ne hai anche un build veloce di un progetto appena che aggiungi i progetti nel suo repository, quando tu fai il build sul tuo build server quello aumenterà ovviamente, no? C'è un'addizione dove aggiungi progetti.Se vuoi, a un certo punto, ovviamente, c'è una time che ti va su, che magari ti dura anche un'ora a fare il build o il test run.I strumenti che praticamente...alla fine, in monopty, servono dei tool che applicano delle pratiche per ridurre questo e per tenerlo abbastanza costante, nel senso di non avere quell'aumento.E tecniche di...Prima il discorso di capire quale progetto è stato toccato, sempre utilizzando quello del Dependency Graph, cioè utilizzando una combinazione fra git, commit, uno riesce a vedere tutti i file di cui sono stati toccati e poi questi file next se li prende, se li mappa sui nodi che hanno il Dependency Graph e poi capisce, ok, è stato cambiato quel progetto di mezzo, quale altro progetto dipende da questo progetto e poi va ovviamente a rieseguire i task su quelli, che idealmente è un subset di tutto il monorepo.Se praticamente IceFigure è l'ultimo nodo nel tuo graph, ovviamente il build è molto più lungo perché deve ricomputare tutto quanto, ma idealmente è un subset.E già questo aiuta tanto.L'altro poi è il caching.Il fatto di non rieseguire il stesso calcolo quando non sono state cambiate i parametri cruciali, nel senso col sorgente, il comando che è stato eseguito, gli environment variables o qualcosa che magari aggiungi anche te, praticamente permette di fare un caching di una computazione.Cioè ogni volta che fai NX Build quel progetto, NX Test quel progetto, NX si sale il risultato su una cartella locale e poi se questo viene rieseguito, verifica se quel progetto esiste già, se esiste già il cache di questo progetto, semplicemente fa il ristorno.Che vuol dire, anzi, che se il test run è veloce di, insomma, mezzo secondo, dopo saranno tipo 8 millisecondi, è una roba molto molto più velocemente.E idealmente, ovviamente, replichi questo cache, poi lo distribuisci anche nella cloud, in tal modo che non è locale sul tuo computer, sulla tua macchina, ma è proprio distribuito anche, condiviso con altri co-workers o il tuo sistema di CI.Ed ecco che entra in gioco appunto quell'ottimizzazione, è sempre il ruolo del dependency graph che è presente.Mi senti ancora? Sì, mi senti? Io intanto guardavo l'orologio, potrei rimanere altre tre ore con te a chiamare, ma so che dobbiamo andare a riposare, che domani si lavora.Però prima di salutarti abbiamo due momenti, e il primo è quello di ringraziare chi ci supporta.E' arrivato il momento di ringraziare chi ci prende sulle spalle e fa sì che ogni settimana Gitbar possa raggiungere le vostre orecchie.Questa settimana abbiamo una donazione da FIAK RAID, spero si legga così anche se sono quasi sicuro che non si legge così, e vi voglio leggere il messaggio.Ho appena fatto una donazione per supportarvi e dire un grandissimo grazie per il podcast.Sono irlandese, ho vissuto in Italia per tre anni in un paese vicino a Ferrara, ho passato le lunghe giornate di lockdown in bici ascoltando il vostro podcast.Adesso, vedendo che la mia esperienza di vita italiana sta per finire, mi viene un po' di malinconia e volevo fare questo piccolo gesto per dire un grandissimo grazie nel cuore.Godetevi un bel Guinness al pub per me.Come si dicono in Irlanda "slainte".Io ringrazio FIAC perché grazie appunto a FIAC e a tutti i donatori noi possiamo veramente pagare le bollette e quindi alziamo la nostra Guinness per brindare.Cin cin.Eccoci qua Yuri.Abbiamo ringraziato FIAC ma adesso è arrivato il momento tipico e topico del nostro podcast.Il momento del Paese dei Balocchi.Momento in cui sia i i guest che gli host condividono un libro, un talk, un post, qualunque cosa valga davvero la pena essere shareato nella nostra community.Quindi adesso facciamo partire la sigletta e poi ti chiederò hai qualcosa da condividere.[Musica] Allora, Yuri, cosa ci porti da scoprire oggi? Ma stavo pensando e uno che mi è rimasto abbastanza è un libro che si chiama "A Non Orthodox Guide to Making Things Work with Making" che è scritto da Tony Fadel e lui è il co-creatore dell'iPhone, cioè per primo dell'iPod, poi dell'iPhone conseguentemente e lui parla un po' di tutta la storia, come è partito, come è fatto l'iPod, come poi è sviluppato l'iPhone e dopo mi sa che ha anche creato il Nest, il Google Nest che poi è stato comprato da Google.Quello che mi è rimasto è perché lui parla molto di product development, cioè nel senso cosa dovresti stare attento quando sviluppi un prodotto, guardi ai pain points del prodotto anziché magari solo le finezze ultime che poi aggiungi man mano e così via.E quello mi è rimasto molto, abbastanza bello.Bello, bello.Lo aggiungo alla mia libreria Amazon e sono sicuro che molti dei nostri ascoltatori lo faranno.Io ho un sito, in questo periodo sto dando un occhiato un po' agli algoritmi cercando di rinfrescare un po' di lezioni dell'università di tanti anni fa e ho trovato un tool carino che in realtà da un lato mostra il codice dall'altra genera un grafo che insomma fa vedere il comportamento dell'algoritmo.Il sito è algorithm-visualizer.org è carino per spenderci qualche minuto e dare un'occhiata e fare un po' di ripasso Yuri è stata una super chiacchierata sono davvero felice che sei venuto a trovarci Sì, grazie mille dell'invito, è stato piacevole.Tra l'altro so che tu non parli spessissimo in italiano, giusto? Esatto, è stato un esercizio per parlare un po' di più.Ultimamente con il lavoro per la vita americana parlo praticamente esclusivamente l'inglese, perciò è stata una buona occasione.Guarda, sappi che è un po' il mio stesso problema, Gitbar nasce per cercare di di parlare un po' d'italiano perché da italiano che lavora in inglese e vive in francese anche io ho quel problema e tra l'altro non sa parlare nessuna delle tre lingue l'italiano l'inglese e il francese.No io ti ringrazio davvero tanto e come dico sempre da oggi Gitbar è un po' anche casa tua per cui quando avete qualcosa in Arwal o su NX di nuovo che vuoi condividere con la nostra community c'è sempre una birra fresca per te.Cool, sì, bello sapersi.Io ti ringrazio di nuovo e prima di salutarvi vi ricordo rapidamente i nostri contatti info@gitbar.it www.telegram.it e @brainrepo su Twitter sono i modi classici per contattarci oppure c'è il nostro gruppo Telegram se non l'avete ancora fatto mi raccomando iscrivetevi detto questo io direi che a questo punto vi saluto alla prossima settimana ciao ciao [Musica] GitBar, il circolo dei full stack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo Word.di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.[Musica]
