*musica* E' colui che inizia tardissimo perché sta bevendo un bicchiere d'acqua.Comunque, bene e benvenuti.Nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Sì, sì, sì, avete sentito bene.Stavo bevendo un bicchiere d'acqua perché, ahimè, ho fatto promessa che fino a Natale mi...*tossisce* in qualche modo mi contengo con l'utilizzo dell'alcol.Ma dopo Natale vedremo.Detto questo, cosa che sicuramente vi interesserà un sacco in realtà anche no, il mio compito prima di iniziare il nostro episodio è quello di raccontarvi rapidamente i nostri contatti.Info, che ho la gitbar.it e tbrenrepo sono i modi canonici per contattarci.Abbiamo anche un nuovo vecchio sito web, dico nuovo vecchio in realtà perché il design Non è cambiato granché, ma è praticamente cambiato tutto, nel senso che l'abbiamo riscritto in astro grazie anche al contributo di alcuni di voi.Grazie, grazie davvero per averci aiutato.Sito che finalmente mostra anche i vecchi episodi.Quindi se vi siete persi qualche episodio, mi raccomando, riprendetelo, perché ne vale la pena.troverete delle chicche che erano un po' nascoste negli ultimi tempi.Detto questo è ricordato anche che abbiamo un fantastico gruppo Telegram e quindi se non l'avete fatto iscrivetevi perché non potete perdervi il gruppo Telegram, la parte più bella della community io direi a questo punto che possiamo iniziare e posso così presentarvi il nostro ospite.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.C'è un'azienda italiana in realtà che collabora con tantissime aziende che utilizziamo tutti i giorni e che fa una cosa super interessante ovvero gestisce e genera music data stiamo parlando di una delle aziende italiane più di spessore parliamo di music match io quella x la mangio sempre abbiate pazienza e andiamo con noi a vedere un po' sotto il cofano di quello che fanno Flavio Lanternini, ciao Flavio come va? Ciao Mauro, tutto bene? Tu sei front-end developer, no? Io sì Dimmi come lo devo pronunciare senza che la lingua mi si attorcigli dentro la bocca Allora, è stato difficile anche a me all'inizio, però è "Mewzix Match" Con la "x" "Mewzix Match", ok Esatto Penso a "Mewzix" ma più accentuato alla fine Sì sembra quando parlano i miei bravissimi colleghi che mettono le "sciessessess" dappertutto.Super figo, intanto grazie di esserci venuto a trovare.Sono super felice, tra l'altro noi ci siamo incrociati a Code Emotion.Sì è vero è stato è stato un caso, proprio grazie a un mio ex collega anzi.Possiamo anche citarlo e ringraziarlo.Si esatto possiamo salutarlo Davide grazie mille è stata una bella esperienza Grazie Davide anche perché grazie proprio a Davide adesso tortureremo Flavio per sapere un po' in realtà cosa fate e che stack tecnologico è come approcciate a alcuni dei vostri prodotti perché la curiosità di guardare sotto il cofano di un'azienda che collabora con nomi importanti come quelli che potete vedere nel loro sito, si parla di Shazam, Google, Instagram, Tidal, Spotify, insomma chi più ne ha più ne metta, non so se li potevo dire ma sono pubblici.Sì sì sì sì.Amazon, Apple Music, Bing, Vavo, Tidal, ho detto, insomma sono tanti ed è un'azienda italiana e la cosa mi ha un po' stupito in realtà, non sapevo foste italiani.Ma Flavio, per chi non è avvezzo al vostro business insomma, cosa fate? Allora, noi come hai detto produciamo data, music data, quindi siamo una data company e grazie maggiormente alla nostra community in realtà agglomeriamo, collettiamo, perdonami l'inglesizzazione della parola, principalmente testi di canzoni, informazioni sulle canzoni, tutto quello che più o meno riguarda le canzoni, testi, sincronizzazione soprattutto riguardo...penso che molti conoscano Spotify, molte delle canzoni di testi che vedete su Spotify sono sincronizzati, anche quelli li sincronizziamo, prendiamo dati proprio sulla musica, questo è il nostro main business.Voglio farti una domanda perché è la prima curiosità che mi viene tu ai hai parlato di una cosa che a me sta molto a cuore, il concetto di community e di contributi dalla community, ma oggi nel 2020, quasi 2023, nella trascrizione di una canzone e nella sincronia quanto c'è di community e quanto c'è invece di AI? Allora i numeri precisi sfortunatamente non te li so dire però il contributo della community ancora è la maggior parte soprattutto perché la musica a differenza magari del parlato di un podcast o comunque di un video youtube ha molto rumore quindi c'è la musica le parole vengono dette a differenza della lingua le parole vengono dette magari cantando in modi differenti quindi estrarre tutti quei metadata con l'intelligenza artificiale è complesso però in breve per rispondere alla tua domanda è ancora molto molto molto viene dalla community.Interessante, è difficile far convivere metadata e dati che vengono dalla community da dati che vengono estratti in modo del tutto tecnologico? No, perché comunque noi su molti dei nostri contenuti poi abbiamo un layer di quality assurance, quindi abbiamo proprio dei curators, li chiamiamo, interni che si occupano effettivamente di assicurarsi che la qualità sia dei metadati in generale che sia corretta, che sia appropriata.A livello di prodotto, quindi voi siete una data company, e quando si parla di data company insomma mi viene da immaginare un grande data lake, è una società che insomma offre l'accesso a queste informazioni, no? Sto sbagliando? No, offriamo l'accesso a queste informazioni, abbiamo delle API pubbliche per esempio, che possono, c'è un piano gratis, un piano a pagamento che quindi possono essere richiamate un po' da chiunque, ma principalmente in realtà come distribuiamo i dati avviene quello è d'accordo direttamente con il partner, quindi il metodo, il media effettivamente è diverso per ogni partner.Chiaro.E il prodotto quindi sono queste API o ci sono un'altra serie di prodotti? I prodotti sono diversi, in realtà abbiamo le nostre applicazioni, quindi quelle dove effettivamente la community interagisce, che sono su Android e iOS, e questo è uno dei nostri prodotti.Altri prodotti che sono stati rilasciati relativamente ad recente sono volti a un pubblico di professionisti, quindi la cura dei propri metadati o dei metadati di comunque di una serie di artisti che si gestiscono, oppure prodotti relativi al publishing, quindi noi non ci occupiamo soltanto effettivamente di dati ma anche un po' delle interazioni che ci sono in tutto il mondo della musica, quindi publishing, mondo del publishing, mondo dei professionisti e di recente abbiamo anche in realtà rilasciato un prodotto che forse un po' ti interessa che è il Music Smash Podcast, nuovissimo.Giusto 15 minuti fa ha riempito il questionario per avere l'accesso.bene bene.Vediamo, io sono molto opinionato da questo punto di vista nel senso che non adoro tanto le piattaforme che stanno entrando nel modo del podcasting ma perché sono un vecchio nostalgico.Molti mi definiscono, definiscono il mio approccio al podcasting come un approccio un po' stalmaniano e quindi anch'io quando si parla di podcast mi lascio crescere la barba bianca.No però sono curioso di vedere insomma come ci si pone.Per cui ci sono diversi prodotti tecnologici e se ne parliamo di stack tecnologico quali sono le tecnologie che utilizzate? Riuscirò a non dire tecnologico un'altra volta.Quali sono i linguaggi, i tool che utilizzate per realizzare questi prodotti? I tool, i linguaggi sono...questo poi dipende dalle macro-area.Nel nostro team, quello di front-end, il nostro stack è prevalentemente JavaScript, TypeScript anzi, e nello specifico React, React Native.E questo in realtà lo portiamo anche in JavaScript con i nostri back-end for frontend che sono i node.js e invece il back-end, il grande back-end è principalmente scritto in php però anche quello si sta un po' evolvendo in varie direzioni.Quando parli di back-end parli del monolitozzo.Sì parlo del monolitozzo però ecco so che comunque stanno facendo tanti lavori anche sul monolite quindi credo che non rimarrà un monolite per per tanto però lì c'è tanto PHP per esempio.Sì ma non c'è azienda medio grande che non abbia un pezzo di monolite PHP ancora da qualche parte cioè il monolite PHP immagino sia qualcosa tipo symphony.Allora, so davvero poco a riguardo in realtà, forse il monolite non è neanche scritto in un framework.Comunque parliamo di codice che probabilmente ci portiamo dietro al 2010, quando l'azienda si è formata, quindi puoi immaginare effettivamente più di dieci anni di codebase che si accumula come potrebbe essere.Però no sai ha senso questa cosa, io ci riflettevo proprio l'altro giorno e ne parlai anche a suo tempo nella puntata dove facevamo spiegare a Calvino il refactoring, cioè ci sono delle parti di codice che anche se insomma stanno su monolite, funzionano bene, non danno problemi, sono mantenibili più o meno, cioè alla alla fine tutta questa smania di fare refactoring quando sono mantenibili e funzionano bene, vabbè parliamone.Certo è che proprio in macchina mentre tornavo ho letto il gruppo Telegram un articolo condiviso da ammazza quanto scrivete non riesco a tornare indietro non lo trovo adesso scusatemi, ma leggevo un articolo insomma che sul fatto che Elon Musk lascerà solo il 20% dei microservizi, quello di Twitter, e quello insomma boh, farà un monolite, si farà fare un monolite dagli amici suoi di Tesla, cosa farà boh, vabbè.Non lo so, non vorrei essere nei loro panni.Cazzate a parte, torniamo a parlare di cose interessanti.Quindi avete una serie di front-end, come mi dicevi, scritte in React Native.Sai perché proprio React Native e non soluzioni tipo Flutter o Kotlin? Questa penso sia una decisione che è stata presa ben prima che arrivassi io in azienda, posso immaginare il perché comunque.L'attuale sito web musicsmatch.com era scritto in React su CoffeeScript e probabilmente per avere uno stack più simile possibile fra la vecchia codebase e una nuova codebase hanno deciso di utilizzare React.In più React da qualche hanno è il framework più conosciuto a livello front-end, probabilmente qualcuno mi odierà per questa affermazione.Non sul più conosciuto, potrebbero avere qualcosa da ridire su framework barra libreria, però fra di a te lo sai come siamo noi, siamo picchi su cose completamente inutili e sulle cose importanti poi diciamo non ci formalizziamo.No, è interessante perché quello che dici tu è credo uno dei motori che continua ad alimentare React Native, cioè il fatto di avere un'unica codebase o comunque facciamo un passo indietro, un team che ha fatto upskill su un certo set di librerie e di linguaggi per cui alla fine se utilizzi gli stessi linguaggi tu hai diversi team di giolli fondamentalmente.E di lì mi parte la domanda, prima tu mi hai detto che avete anche utilizzate anche javascript nei vostri back-end for front-end giusto? sì per cui alla fine come siete organizzati avete un team di back-end un team di front-end o siete full stack e quindi tutti fanno tutto? allora questo questo è proprio un argomento caldo in realtà.Al momento siamo organizzati principalmente, cioè l'effort principale è sul front end, mentre abbiamo un team che è un po' più full stack di quello di cui faccio parte, in cui c'è un po' di contribuzione, si mischia un po', c'è un po' di contaminazione back end front end e l'idea sarebbe quella un giorno di cercare di formare proprio delle figure un po' più full stack comunque permettere anche al resto del team front-end di poter interagire agilmente sul back-end perché effettivamente come dicevi la tecnologia è la stessa quindi è soltanto sono soltanto risorse in più che possono portare più idee più innovazione più anche un flusso di release e di feature maggiore.A livello di frontender, interagendo col back-end, ci sono stati degli elementi che insomma hanno fatto smadonnare, sono stati trovati particolarmente complessi per un frontender? Allora sì, sfortunatamente il nostro back-end per frontend è un monolite, un monolite comunque che ha i suoi bei sette anni, scritto in un javascript che voleva essere molto...che voleva guardare un po' al futuro ma che sfortunatamente non ci è riuscito, quindi sì la comprensione...- C'è un po' di express - Allora c'è un po' di express, però il fatto è che express è proprio la punta dell'iceberg, lo vedi nell'index e poi non lo vedi più.Quindi c'è tutta un'architettura, quindi probabilmente il comprendere quell'architettura è la cosa un po' più difficile, non è tanto il codice in sé, però per esempio si fa tanto uso del global, quindi spesso non ti rendi bene conto con cosa stai interagendo, quindi c'è tanto studio e quando mi sono approcciato a questa codebase per la prima volta ho dovuto studiare proprio i processi con il debugger che cosa stava succedendo.Sai che è una cosa che sto trovando spesso nelle codebase anche di alcuni clienti che seguono, cioè il fatto che di per sé il framework che si utilizza è è abbastanza minimale.Io mi capita di vedere Codebase con Fastify, no? E Fastify io lo chiamo il framework invisibile perché fondamentalmente non c'è un framework.Sono quattro handle, due plug-in, cioè è veramente invisibile a livello di impatto per uno che nella sua vita ha scritto codice symphony che insomma ha la sua struttura definita, tira via la linea guida per dare un riferimento a chi è nel mondo JavaScript, una specie di nest JS super strutturato.Però poi alla fine vedo che moltissimi costruiscono dei livelli da strazione ed è capitato anche a me talmente tanti livelli da strazione che poi la complessità è data da questi livelli da strazione che si poggiano uno sopra l'altro perché noi vogliamo fare il codice ordinato, perché noi vogliamo fare il codice pulito, perché noi vogliamo mettere il domain driven design dove magari non ha senso farlo perché sono 4 handler che servono 4 end point quindi alla fine si crea questo carico cognitivo altissimo non riutilizzabile perché il carico cognitivo che c'è sul framework io imparo express, io imparo fastify, io imparo symphony ma lo gioco su tutti i siti che utilizzano quel framework ma questo livello di complessità che invece ci viene dato da queste astrazioni fatte dal team di sviluppo poi rischia di rallentare perché non è un asset che tu compri cioè la knowledge di queste astrazioni devi o crearla sul campo o crearla sul campo perché tu non vai nel mercato e dire no io voglio uno sviluppatore bello skillato su questa mia architettura.No no è verissimo, cioè è un'arma, la trovo anche io ormai, è un'arma a doppio taglio, nonostante anche io vengo dal mondo l'arabel invece e quindi symphony e l'arabel perlopronto abbastanza simili.Occhio perché anche là fai un po' di schifo.Lo so benissimo, però anche il teasing che è divertente.Esatto, stai triggerando bellissimo.Poi quando quando un po' mi sono avvicinato invece a librerie o framework un po' più minimali, anche controllando il mondo PHP come Slim per esempio, e mi sono trovato meglio, ti danno un po' più di libertà, però effettivamente su, come dicevi te, magari vai implementare dei design pattern che effettivamente non ti servono assolutamente, e magari lì per lì non è un problema, mentre stai facendo l'MVP, mentre stai lavorando in pochi nel progetto ma scala tutto quel design pattern, scala quel processo di pensiero a 2-3 anni con altri cinque sviluppatori e è difficile mantenerlo in modo da non darsi tutti a interazzarfa sui piedi.Deve essere veramente strutturato bene e soprattutto ci deve essere chiara la visione la visione nel lungo periodo.In alternativa, ogni giorno che passa sono sempre più parti leggero e poi se devi evolvere, evolvi, ma parti leggero.Io per esempio da poco stavo lavorando su un sistema di booking.Io sono un po' fissato col functional domain driven design, io e il mio caro amico dr.Blaster, e ho fatto insomma sto pezzettino di sistema di booking cercando di aderire il più possibile a questo approccio, cioè per aderire il più possibile a questo approccio intendo dire mi sono prima scritto le firme in typescript, mi sono fatto tutte le funzioni con meno side effect possibile mettendo i side effect all'angolo alla fine si funzionava bene alla fine si anche leggibili le firme perché in realtà le dinamiche di dominio erano chiarissime però poi alla fine se io devo il resto l'applicazione era un crude e poi alla fine se noi facciamo la tara dei nostri back end quello che facciamo nel 90% dei casi è leggi il database scrivi nel database un po' come metti la cera e togli la cera esattamente quello che si fa.Prima lava tutte le macchine poi le lucidi con la cera.Ma perché - Che devo lavare le macchine? - No, no, no.Ricorda patto.Nessuna domanda.- Sì, ma credevo che...- Avanti.Devi dare la cera con la mano destra.E la devi togliere con la sinistra.Dai la cera, togli la cera.Il respiro lo prendi con il naso e lo emetti dalla bocca.Dai la cera, togli la cera.Non dimenticare il respiro, è molto importante.Dai la cera, togli la cera.A quel punto, se per esempio non hai bisogno di fare delle API GraphQL, perché estrarre la funzione dall'Handler? Per esempio, questo è un esempio.Io mi sto facendo queste domande perché sarà che avvicinandomi ai 40 anni voglio essere più pragmatico e avere meno side project nel cassetto quindi probabilmente un po' mi viene da quello.Per cui dicevo alla fine per un frontender approcciare a questa logica di back-end spesso spaventa giusto? Devi essere un po' portato a avere anche quel tipo di mentalità secondo me, di poter avvicinarti anche al back-end, questa ovviamente è mia opinione.C'è chi preferisce lavorare, come dice il mio collega, in realtà sul front, del front-end, quindi sulla parte più vicina all'utente, e c'è chi magari ha una mentalità, e qui piace un po' smanettare di più sull'architettura, sulle dinamiche un po' più sul back del front end e quindi magari queste personalità sono un po' più portate ad avvicinarsi anche poi al back end.Concordo con te anche perché poi se noi ci ragioniamo un attimo, alla fine mi viene da fare questo esempio che mi ha fatto Alessio e mi ha fatto riflettere, mi ha detto "ma alla fine chi ragiona nel front del front-end?" quindi che non passa a lavorare nel buff, dice "ma cacchio il front end oggi è una cosa particolarmente articolata, in realtà ha talvolta più complessità del back end e se noi a me viene da pensare Redux come pattern, mettici anche le saga.Cioè la complessità che vedi là, o anche Redux Trunk che è Trunk, la complessità che vedi là è secondo me molto più alta di buona parte dei back-end anche a livelli architetturali, non solo, cioè non sei più uno spostapixel.E a questo punto mi chiedo se è proprio una questione di stato mentale cioè io con tutto quello che non ha un feedback immediato con la UI non ci voglio lavorare o cioè perché alla fine il linguaggio è lo stesso? Sì, questa effettivamente è una bella questione.Probabilmente anche magari essere vicini a quelle logiche di business un po' più delicate Quindi più ti avvicini al back-end più database, dati dell'utente, dati sensibili, hai possibilità magari di cancellare, di fare dei danni e forse quello può un po' trattenere.Però sì, è verissimo quello che dici, il front-end sta diventando molto più complesso, è diventato molto più complesso perché effettivamente siamo passati da static a delle vere web app, quindi delle applicazioni che funzionano anche 100% direttamente sul browser e per farle funzionare hai bisogno di complessità.Interfacciarsi alle app per interagire col microfono, con l'audio, con il sistema di storage, insomma, non sono più delle strutture di markup HTML e tre righe di CSS e oggi anche il CSS come il nostro amico Davide ci insegna ha la sua complessità.E quindi dal tuo punto di vista come si può traghettare, come si può accompagnare il frontender puro verso un ruolo un po' più full stack? Sicuramente aiutandolo il più possibile, quindi avere un back-end che permetta un onboarding agile, cioè facile proprio.Quindi sicuramente aiutandolo, quindi pairing, spiegazioni della codebase che spesso possono essere, in alcuni casi possono essere molto più grandi di quelli dei front-end con side-effect che non ci si aspetta però comunque io rimango dell'idea che deve essere approcciabile proprio il codice quindi non ci deve essere troppa astrazione magari non troppi design pattern che magari sono molto specifici per quell'applicazione, altrimenti devi per forza spiegarli farli imparare anche allo sviluppatore e documentazione, cioè è tutta knowledge alla fine e sicuramente devono essere persone che se la sentono, quindi che gli piace effettivamente magari mettere mano del codice backend.Vero, vero.Torniamo per un attimo al nostro front end.Tu mi hai detto che parte del vostro front end è fatto in React Web, ho fatto due apc enormi, due virgolette enormi quando ho detto web, e un'altra parte è fatta con React Native.Esistono dei punti di intersezione, librerie condivise, se sì come le gestite? Allora fortunatamente la maggior parte della nostra codebase grazie a una fantastica libreria chiamata React Native Web è condivisa quindi noi abbiamo la fortuna effettivamente di avere una singola codebase per tutti i nostri progetti che condividono logiche sia per le applicazioni attive sia per le applicazioni web.Quindi grazie a questo noi riusciamo effettivamente a ridurre di molto il carico che abbiamo addosso però effettivamente ci sono un po' di accorgimenti che dobbiamo fare per forza di cose.Librerie, immagina delle web API che non esistono sul nativo o viceversa, quindi spesso ci ritroviamo a fare delle soluzioni ad hoc per nativo oppure no, però per il momento è la minoranza.Hai parlato di React Native Web.Io, lo posso dire in tutta sincerità, tempo fa stavo sviluppando un'applicazione React, avevo il terrore fottuto di utilizzare React Native Web per fare praticamente l'applicazione mobile first e poi farne la versione web, che mi sono bloccato e ne ho fatto due fondamentalmente.Mi sono condiviso le logiche di business e avevo due applicazioni una in React e una in React Native.Ho sbagliato nel senso la mia domanda è quali sono stati i pain point di sviluppare un'applicazione React Native ed esportarla, buildarla web e quali invece sono stati veramente vantaggi che dite ok è stata la scelta vincente Allora intanto ti rispondo alla prima domanda, se hai sbagliato.Secondo me no, questo perché alla lunga probabilmente è la scelta migliore sia per la codebase che sia per le applicazioni.Separare un po' ti permette di fare più agilmente delle ottimizzazioni su una piattaforma sull'altra senza doverti preoccupare dell'altra piattaforma.Per esempio, Web Items e Accessibility su Web che sono un po' più complicati se parti da un approach mobile first.Quindi, in un progetto personale comunque un progetto un po' più ristretto, secondo me, anzi, è la scelta migliore.Da nostro punto di vista invece i pain point sono proprio tutti quei meccanismi in cui devi fare, devi distinguere quindi accessibility, la semantica sul web, tutte le differenze magari che ci sono fra React Native e ReactJS che ovviamente avendoci una libreria di mezzo magari non ti rendi conto immediatamente, mentre sicuramente la velocità di sviluppo è il vantaggio più grande, il fatto di avere una sola codebase e avere tutto lì, navigazione, componenti, eccetera.però pensandoci anche così su due piedi sicuramente se tu avessi una design library per esempio fatta bene, quindi che gestisce bene i propri componenti web e i propri componenti nativi.In quel caso le tue applicazioni, potresti dire che sono React Native o React Web, sono applicazioni costruite con la tua Design Library, poi tutta la logica di business...Guardi, entriamo nel dettaglio, che è una cosa che sono super curioso.Cioè, fammi un esempio pratico.Allora noi per esempio abbiamo una design library, la chiamiamo Ritmo per rimanere in tema musicale e la nostra library è cross platform, quindi per la maggior parte è ancora React Native Web.Siamo in corso proprio di cercare di separare un po' per avere una parte più semantica sul web e una parte più ottimizzata su native.Però noi costruiamo effettivamente la nostra applicazione utilizzando questa design library, quindi c'è di effettivo React poi sul codice che scriviamo tutto il giorno c'è il poco, cioè c'è le view, in realtà penso quasi esclusivamente le view.Ma per cui voi cosa avete? Avete questa library cui componenti poi al loro interno outputano cosa? Degli eeve o delle...non mi ricordo come si chiamano in React Native.Ah devi usare le Views.A quel punto come funziona la component library? Dentro il componente disegnato bellino si basa su View, quindi su un componente base di React Native o si basa su un div per web e esiste un modo per selettare, per decidere "ok sono su web, uso il div, sono su react native, uso il view?" Allora questo dipende molto dal componente.Ti faccio per esempio un esempio sul bottone, che è già il bottone di per sé sul web è un po' discusso, è un bottone, è un anchor, e noi facciamo questa distinzione per web di creare degli anchor oppure creare dei button quindi abbiamo della logica proprio custom dentro in base a quali sono proprio la configurazione di questo componente poi all'interno andrà a renderizzare, quindi a istituire un anchor o un un bottone, mentre sulla parte nativa utilizziamo direttamente button di React Native quindi quello che viene renderizzato a nativo con direttamente un componente nativo altri invece dove non possiamo al momento ancora trovare un web component che lo sostituisca utilizziamo le view che poi vengono convertite in div ok ok ma la selezione all'interno del componente immagina che sia il bottone ok la selezione all'interno del componente che ti dice ok sto girando su react native questo deve essere un system button oppure sto girando su web e deve essere un un button un button un link La fai a livello componente dello UI kit o lo fai attraverso una prop che passi? No, lo facciamo a livello di UI kit, quindi ogni componente sa come si deve comportare in un contesto nativo oppure web questo lo facciamo tramite differenza per esempio React Native Web ti dà la possibilità di avere un suffisso iFile.web quindi per esempio button.web.ts e quello è un tipo di selezione quindi nel caso in cui i componenti proprio hanno bisogno di funzionare in modo completamente differente rispetto da React Native a React Web invece in caso vogliamo riutilizzare del codice o magari sono poche modifiche da fare, pochi comportamenti da gestire, utilizziamo una utility di React che si chiama Platform, semplicemente quella poi a runtime, mobile time, ci va a dire qual è il sistema operativo, qual è la piattaforma che stiamo utilizzando.Quindi possiamo discriminare sul sistema operativo tramite il codice proprio.Chiaro e a livelli invece di, essendo React Native oggettivamente multiplatform almeno per ciò che riguarda Android o iOS, avete sbattuto la testa su incompatibilità? Ci sono un po' di incompatibilità, non direi niente di assurdo, ogni tanto ti ritrovi la differenza di funzionamento fra React Native e React Web cioè per esempio l'errore che succede più spesso è che su React Web puoi avere un text, cioè un componente di testo che può avere una stringa null all'interno mentre su React Native no e crasha proprio l'applicazione, fa un throw e non ho idea del perché, non l'ho mai investigato però è così e spesso te lo rendi conto soltanto quando effettivamente fai dei test su un nativo, è difficile da trovare, da cacciare perché quando succede sono dati che arrivano dall'API, quindi questi sono i piccoli problemi.Poi come dicevo anche su delle API, per esempio URL, la classe url è completamente riemplementata su React Native e manca di tante utility, quindi spesso provi della roba sul web, funziona, vai a testarla sull'applicazione, sul simulatore e non vai, devi capire il perché.Però nulla di troppo complicato da questo punto di vista.E tra Android e iOS invece? Tra Android e iOS sono più le differenze effettivamente che ci sono magari su React Native, quelle documentate, quindi magari un componente ha delle limitazioni su iOS, ha delle limitazioni su Android, però avendoci una design library di solito poi magari abbiamo degli switch case che mettono delle prop in base a se Android o iOS magari si comportano in un modo, a volte i padding o i margin funzionano in modo leggermente differente fra uno sistema operativo e l'altro quindi devi fare degli accorgimenti.Quindi alla fine quel tipo di differenza la gestita a livello di UI library esponendo poi delle API al netto di quel problema giusto? Sì sì sì.Ok, noi ci prendiamo un secondo per un momento classico del nostro podcast.*musica* è il momento di ringraziare i donatori, chi ci supporta e fa sì che ogni giovedì o Giovenica il nostro podcast possa raggiungere le vostre orecchie.Questa settimana abbiamo ben tre donatori da ringraziare.Dopo un paio di settimane senza nessuno finalmente abbiamo delle persone che ci prendono sulle loro spalle e fanno sì che Gitbar possa continuare a essere prodotto anche perché è gratis ma non senza costi.Dobbiamo ringraziare quindi Filippo Frater che ci ha invitato tre birre scrivendo questo messaggio "ormai un anno che vi seguo e mi date sempre degli spunti super oltre a farmi compagnia nel tragito casa lavoro quando mi recu in ufficio ci sono moltissime puntate che ha adorato ma quella sulla felicità per ora è la mia preferita" Abbiamo anche Andrea Peracchi che ci ha donato due birre e ci ha scritto "Vi ascolto da tempo e ho finalmente deciso di unirmi al gruppo Telegram e di darvi il mio supporto per il vostro ottimo lavoro.Anche se non sono uno sviluppatore ma un sistemista di un tool software, il podcast contiene contributi preziosi per tutti.Grazie!" Per finire la carrellata dei donatori di questa settimana abbiamo Livio Francesconi che ci ha donato una birra Quindi solleviamo il calice e brindiamo alla salute di Filippo, Andrea e Livio Cin cin Prima di continuare con l'episodio però vi devo ricordare e vi devo chiedere una cosa cosa.Allora, se Gitbar vi è utile vi chiedo di aprire l'applicazione Apple Podcast se avete iOS, di stellinare il nostro podcast e di lasciare una recensione.Questo perché? Perché in realtà siccome siamo veramente in tanti, tantissimi, mi piacerebbe vedere Gitbar che scala nuovamente le classifiche in modo da riconquistarci un posto di tutto rispetto nella chart tecnologia.Detto questo ritorniamo al nostro discussione con Flavio e gli voglio chiedere un'altra cosa in realtà.voi gestite più prodotti e più piattaforme e mi dicevi che sia prodotti che piattaforme alla fine condividono dei pezzi di codice per cui nella mia testa l'omino mezzozopo che c'è mi ripete ormai da da qualche minuto non so se vi ricordate la scimmietta sulla testa di Homer Simpson che suona i piatti Ok, nella mia testa c'è una scimmietta che dice monoripo monoripo monoripo monoripo e lo fa lo sta facendo già un quarto d'ora quindi la mia domanda è Clavio monoripo o non monoripo? La tua scimmietta ha ragione noi siamo una monoripo che alvoi ha più di una decina, quasi due decine penso di progetti al suo interno, usiamo yarn e Augmented con Learner, e anche se per esempio sul nostro backend for frontend stiamo sperimentando con NX, ancora in fase di sperimentazione però, utilizziamo quindi Yarn con Learner e sì, è tutto condiviso, abbiamo dei pacchetti che chiamiamo prodotti o applicazioni, pacchetti che sono più di core, quindi librerie a basso livello che sono condivise praticamente ad ogni prodotto, e quelle che sono gli shared che vengono condivisi da più prodotti.E adesso la domanda cattivissima.Vai.Pain points, perché tutti i benefici dei monoripo ormai li conosciamo, li hai appena detti senza non dirlo, però voglio chiederti pain points di questa roba? Ce ne sono, quello in cui abbiamo usato la faccia più frequentemente è quello delle release, e anche del versioning in sé, essendo più prodotti che hanno dei cicli di vita, che sono gestiti in modo completamente differente l'uno dall'altro, questo è un argomento organizzativo almeno, e spesso ci pestiamo i piedi a vicenda.Questo è tutto comunque in fase di miglioramento, si pensa in realtà, pensiamo che per fine anno riusciamo un po' a sistemare questi pain point, però questo è un forte problema perché è difficile comunque garantire che il codice, quando mandiamo in produzione, non sia stato alterato da un altro progetto, perché adesso la nostra organizzazione poi è sulla monoripo che è scalata tantissimo negli ultimi due anni, quindi immaginati due prodotti a diventare sei, sette prodotti al momento, sia interni che esterni, che devono condividere con un'architettura che sta a penza da due anni fa, per quando c'erano due quindi stiamo un po' rivisitando come strutturiamo la monorepo, come gestiamo la release, probabilmente riusciremo a sistemare questi prodotti utilizzando delle strategie di branching differenti, però sì, questo è sicuramente il pain point più evidente, l'altro è quello invece proprio del versioning, che per esempio, facendo l'esempio di Ritmo, Ritmo è un risiede sulla monorepo, la nostra design library, e viene aggiornata un po' da tutti, quindi c'è il design team che analizza le modifiche richieste e genera ticket per la modifica della design library, però arrivano da varie parti dell'azienda.Spesso è difficile far organizzare per aggiornare un prodotto quando c'è un break in change, quindi immagina io cambio l'API del bottone, tutti i prodotti si devono aggiornare.Non avendo un ciclo di release comunque adatto alla mole di prodotti che abbiamo, ci troviamo allungare un pochettino i tempi perché dobbiamo effettivamente stare dietro all'aggiornamento su ogni prodotto quindi questi sono i due grandi pain point però sicuramente con un'organizzazione migliore riusciamo a risolverli o forse magari anche con NX, chi lo sa, da vedere.Guarda questo problema lo riscontro comunque spessissimo in aziende che scalano per cui è una cosa fisiologica nell'adozione di monolipo, però credo che molto ne venga da come viene gestita l'ownership, nella mia esperienza questo ho capito, cioè le situazioni dove c'era meno dolore, ragà nel nostro lavoro un po' di dolore c'è sempre, però le situazioni dove c'era meno dolore erano situazioni dove l'ownership era condivisa ma c'era perché il vero problema di quando si lavora in monolipo è quella che io chiamo il lancio delle feature, cioè io prendo faccio una roba la butto là tu mi fai la code review mi mi dici che va bene e boh l'ho vomitata là in quell'angolo e poi ognuno se la arrangi una buona test coverage aiuta ma in ambito mobile immagino che si in two hand va bene tutto quello che ti pare ma qualcosa sfugge sempre.Se invece l'ownership di chi fa la modifica nella UIKit per esempio, stiamo ragionando per esempio, è anche quella di tenere aggiornati tutti i prodotti e fare in modo che buildino esattamente come devono buildare e fa parte proprio dell'ownership, fa parte del ticket a quel punto tutto diventa più controllabile anche in termini di code review.Sì è vero è quello che in realtà facciamo adesso cioè o facciamo in questo modo o facciamo un po' di micro versioning chiamiamolo così quindi magari per un periodo c'è button e button next come componenti e piano piano si migra verso ButtonNext e poi si rifattura via Button, rinominando tutto, quindi dipende un po' dalla mole anche del lavoro perché effettivamente magari la nostra non è la monolip più grande che esiste assolutamente però effettivamente assicurarsi che tutti i prodotti funzionino poi è un lavoro a sé praticamente potrebbe essere un task a sé e quindi l'idea è un po' quella di avere l'ownership della design library però comunque dare la libertà ai singoli prodotti di poter aggiornare i componenti o meglio la design library, la versione della design library quando hanno le risorse per poterlo fare.Ti volevo fare una domanda, invece con gli shared tools come fate? Ti faccio l'esempio il web pack della situazione, ogni progetto ha la sua versione specifica o utilizzate una versione condivisa? Utilizziamo una versione condivisa, non è forzata soltanto a livello organizzativo, quindi quando vengono creati nuovi pacchetti ci si assicura semplicemente che sia sempre la stessa versione.In quel caso NX potrebbe essere figo per quanto riguarda la parte di boilerplating e di generators.Sì infatti è quello che stiamo guardando un po' e proprio anche la generazione di codice è fantastica, qualcosa che al momento non abbiamo neanche noi, anche se rimaniamo con Yarn in futuro, con Learn, probabilmente dovremo mettere in piano un sistema di generazione di codici, soprattutto adesso che stiamo iniziando a scalare tanto.tra l'altro ne approfitto per ricordarvi che nell'episodio 133 abbiamo parlato proprio di NX con Yuri quindi se vi va andatelo a recuperare.Per quanto riguarda invece tu hai parlato di design UI kit.Quindi io mi immagino anche un team di design che su Figma, su quello che insomma fai layout, di un design kit che poi deve supportare una serie di prodotti quindi magari anche una complessità maggiore.Come si costruisce o almeno come costruite voi la comunicazione tra designer, stories e developers? Allora questa è un po' è un po' differente per ogni team quindi ci sono delle lieve differenze fra ogni team, però generalmente abbiamo sempre un mockup che arriva dal team di design, viene validato dal prodotto e una volta validato effettivamente arriva a noi sotto forma di user stories, quindi è abbastanza lineare, quindi idea, prodotto generano generano dei mockup e vengono un po rifiniti con dei processi interni e una volta che sono pronti inizia effettivamente lo sviluppo e questo e spesso e vanno effettivamente una design library si pensa se a questo nuovo componente deve finire nella design library oppure è semplicemente un pro un componente per questo prodotto e quindi la c'è un po la discriminante se metterlo sul lato di design library oppure se lasciarlo a sé stante.Questa decisione è in capito in capo al P.O.o al tech team o ha una accordata tra tech team e design? No, non è accordata quindi c'è comunicazione, c'è molta comunicazione per fortuna con il team di design quindi spesso parliamo anche per allineare i design perché ovviamente persone differenti producono dei design leggermente differenti, spesso parliamo anche per unificare i design su vari prodotti in modo da poter effettivamente unire questi componenti dentro la design library e si unichiamo.C'è tanti tanti meeting e cerchiamo di raggiungere un common ground.Super super interessante.Io guardavo l'orologio e siamo a un'ora.Io devo dirvi la verità, stamattina mi sono svegliato molto presto, sono in piedi dalle 5 e quindi Flavio mi vede sbattigliare ma non perché è noioso, ma perché non ce la faccio a farcela, però volevo chiederti una cosa prima di passare al momento il Paese dei Balocchi.Volevo chiederti quali sono state le tue esperienze in merito a due elementi, ne abbiamo già parlato in privato però mi piacerebbe che ne condividessi la tua posizione su questo con tutta la nostra community.Ritorniamo per un attimo a web e a native.Ci sono due elementi che spesso sono controversi, una è l'accessibilità e l'altra è la semantica.ci hai sbattuto, avete sbattuto il muso su questi topic, queste problematiche, se sì cosa vi portate a casa, nel senso in termini di esperienza acquisita? Sì ci abbiamo sbattuto e ci stiamo ancora sbattendo comunque per raggiungere dei livelli di accessibilità intanto accettabili, Sfortunatamente non tanto React Web, ma React Native per web, non è il tool di base più accessibile del mondo, più semantico del mondo, quindi è stato difficile inizialmente capire che cosa dovevamo, le azioni che dovevamo fare e da lì effettivamente che è arrivata la necessità di dover splitare un po' di più i componenti e renderli, fargli fare semplicemente delle cose da web quando sono su web e cose un po' più native quando sono su React Native.Hai degli esempi pratici? Sì, proprio l'esempio più pratico è propriamente quello che ci abbiamo messo di più a realizzare una maniera fatta bene, passami il termine, è la Select, l'infamous Select, che prima che ci mettessimo mano era una serie di div che funzionavano soltanto col mouse e abbiamo dovuto metterci mano per avere un meno l'accessibilità sul keyboard e là abbiamo potuto effettivamente studiare tutti i vari standard di accessibilità che ci sono, capire come si doveva funzionare su un web accessibile e comunque trasformare un po' più simile a effettivamente essere una select HTML, un web component.Perché non è una select nativa quella? No, non è una select nativa perché per esempio non è...le select native riusciamo a farle soltanto se non c'è la search, per esempio o magari se non hanno troppa customizzazione nei drop down però nel momento in cui metti la search e magari c'è la check box dentro e hai un po' di customizzazione è un po' più difficile renderle semantiche e quindi abbiamo dovuto creare appunto dei...abbiamo dovuto replicare quello che farebbe il browser su una select normale utili sopra un componente principalmente React Native Mamma, quindi ne siete...questo per quanto riguarda l'accessibilità e invece per quanto riguarda la parte semantica che comunque è strettamente legata poi al concetto di accessibilità cioè i calci in culo con la sequenza degli header tag, se è un discorso, che il calci in culo che ti dà l'accessibility validator con la sequenza dei tag H o dei tag non semantici, comunque è un problema di accessibilità.E in quel caso come l'avete risolto? Ancora non l'abbiamo risolto del tutto, quindi è un work in progress, e comunque l'accessibilità alla semantica è un argomento dell'ultimo anno nella nostra design library perché abbiamo aumentato le risorse, si è formato questo nuovo team di platform e quindi effettivamente abbiamo potuto metterci tempo e risorse nello scrivere dei componenti più accessibili, più semantici.E quindi piano piano, pezzo per pezzo, andiamo lì e cerchiamo di capire qual è la...come dovrebbe funzionare correttamente questo componente sul web, sia a livello di accessibilità sia a livello di semantica, e cerchiamo di trovare un trade-off fra riscriverlo completamente, riscriverlo in parte, in modo che funzioni bene sia su web che su nativo.Chiaro.Chiarissimo.Anche là è tutto un mondo da esplorare, e soprattutto ricordiamolo davanti a tutti l'accessibilità è una roba fondamentale anzi lancio un SOS siccome il repo del sito di Gitbar è aperto a tutti se ci fosse qualche volenteroso che vuole buttarci un occhio e vedere migliorare un pochino l'accessibilità del nostro sito internet accessibilità e anche performance che ieri guardavo Lighthouse e per poco mi metteva a piangere accessibilità e il repo lo trovate nelle note dell'episodio Flavio è arrivato il momento tipico e topico del nostro podcast il momento chiamato "Paese dei ballocchi" che già conosci il momento in cui sia i nostri guest che i nostri host condividono con noi qualcosa che abbia catturato la loro attenzione un libro un video un articolo un post un giocattolo non lo so qualunque cosa quindi la mia domanda subito dopo la sigla è hai qualcosa da condividere con noi e conduco nel paese dei balocchi.Ah, il paese dei balocchi! Allora Flavio, cosa ci porti in dote qua su Geekbar? Allora, vi porto in dote il libro che probabilmente per me mi ha un po' sbloccato come programmatore e appunto parlando di Symfony, PHP e Design Pattern Il libro è "Advanced Web Application Architecture" di Mathias Notbach e parla di design driven design ed è stra chiaro, semplicemente mi ha aiutato un po' a uscire da quelle dinamiche molto legate al framework che avevo prima e un po' capire come strutturare un'applicazione a grande scala e poi Nobak spiega benissimo ed è stra interessante da leggere, quindi è una lettura che io consiglio tantissimo, penso da medium in su, secondo me aiuta tanto.Concordo, cambia completamente il modo di vedere le applicazioni.Io non ho letto il libro di Mnoback, ho letto l'infame bellissimo dal mio punto di vista, il famoso libro rosso del DVD.Ci sono tipo mille pagine di robe, però è un viaggio, è veramente molto bello.Anche io ho un balocco, In realtà oggi, facciamo un po' il momento casa Brain Repo, oggi mi è scoppiata la gomma della macchina, ero molto nervoso e quindi per rilassarmi io tendo sempre a non ascoltare niente che riguardi lo sviluppo software ma colpisca altri argomenti.Per cui il mio balocco è un canale YouTube, si chiama Intel, ed è un canale YouTube dove potete vedere delle registrazioni, delle live di D&D e di giochi di ruolo è abbastanza rilassante in realtà, aiuta parecchio, quindi se siete un po' sotto stress ha senso portare la testa su un altro mondo tra gnomi e elfi ranger e uscire fuori dalle robe di tutti i giorni E non potevo non sbagliare sigla, giusto Flavio? Dai! Oggi è una di quelle giornate da dimenticare.Per fortuna c'è stata la chiacchierata con te che un po' mi ha ripigliato, se no veramente oggi era una di quelle giornate da cancellare dal calendario.Dicevi che cosa spieghi? L'unedì.Sì ma credo che sia uno dei più brutti lunedì della maia.Detto così, poco c'entra.In realtà, insomma, io sono stato super felice di averti avuto qua davanti ai nostri microfoni, super felice di aver raccontato anche in parte la vostra realtà italiana di cui penso che come Italia bisogna essere abbastanza fieri e finalmente felice di avervi avuto qua su Gitbar visto che ho mandato qualche mail, non so se l'avete ricevuta ma mi ha fatto super piacere avervi qua Anche per me è stato un vero piacere Mauro, è stato davvero interessante condividere questa esperienza con te.Io ringrazio nuovamente Flavio, grazie per essere venuto.Vi ricordo rapidamente due cosine velocissime, prima che parta la sigla.Allora, se volete contribuire a migliorare il nostro sito Gitbar, nelle note dell'episodio trovate Il link al nostro repository, c'è qualche issue, nei prossimi giorni ce ne saranno delle altre quindi se volete migliorare il sito o se non vi piace il sito avete il modo per Fare degli improvement.Vi ricordo rapidamente i nostri contatti info@gitbar.it Brain Repo e il nostro gruppo Telegram.Soprattutto mi raccomando se avete un telefono Apple, iTunes, andate, lasciate una recensione nel nostro podcast, lasciateci le stelline cadenti in modo che possiamo non cadere ma conquistare le prime posizioni della classifica tech.Perché o raga siamo una bella community insomma Ci prendiamo lo spazio che ci ci ci ci deve Sto dimenticando qualcos'altro no quindi ringrazio nuovamente Flavio per esserci venuto a trovare e non mi resta che insieme a Flavio augurarvi appuntamento alla prossima settimana GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.*musica* *voce in sottofondo* Piantala! Maledizione! Che stronzi questi programmatori! Telefona a quelli di Metri.A Cambridge.
