Ecco lui 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 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, io ho la gitbar.it e Trend Repo 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ò è Music Match, con la X.

Music Match, ok.

Esatto.

Penso Music ma più accentuata alla fine.

Sì, sembra quando parlano i miei bravissimi colleghi che mettono le scessessess dappertutto.

Super figo, intanto grazie di esserci venuto a trovare.

Sono super felice, tra l'altro noi ci siamo incrociati a Code Motion.

Sì, è vero, è stato un caso, proprio grazie a un mio ex collega anzi.

Possiamo anche citarlo e ringraziarlo.

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é ha 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ì.

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, soprattutto quello che più o meno riguarda le canzoni, testi, sincronizzazioni soprattutto riguardo, penso che molti conoscano Spotify, molte delle canzoni di testi che vedevi 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 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 metadata 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, poi principalmente in realtà come distribuiamo i dati avviene quello è da accordi 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 adesso sono volti a un pubblico di professionisti, quindi la cura dei propri metadati o dei metadati 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.

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, quindi anche 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 tu 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 aree.

Nel nostro team, quello di front end, il nostro stack è prevalentemente JavaScript, TypeScript anzi, e nello specifico React, React Native.

Invece, questo in realtà lo portiamo anche in JavaScript con i nostri backend for front end, che sono i Node.js, e invece il backend, il grande backend è principalmente scritto in PHP, però anche quello si sta un po' evolvendo in varie direzioni.

Quando parli di backend 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 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 Symfony.

Allora, so davvero poco a riguardo in realtà, però 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 10 anni di codebase che si accumula come potrebbe essere.

Però, 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 stanno su monolite, funzionano bene, non danno problemi, sono mantenibili più o meno, cioè alla fine tutta questa smania di fare refactoring quando sono mantenibili e funzionano bene, boh, vabbè, parliamone.

Certo è che proprio in macchina mentre tornavo ho letto il gruppo Telegram un articolo condiviso da ammazza, quanto scrivete io, 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.

Carzate 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, però posso immaginare il perché comunque.

L'attuale sito web, immusicsmatch.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 anno è il framework probabilmente 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.

Lo sai come siamo noi, siamo picchi su cose completamente inutili e sulle cose importanti e poi non ci formalizziamo.

È 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 jolly fondamentalmente.

E di lì mi parte la domanda.

Prima tu mi hai detto che avete utilizzato 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 è proprio un argomento caldo in realtà.

Noi 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 e 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 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 sono soltanto risorse in più che possono portare più idee, più innovazione e anche un flusso di release e di feature maggiore.

A livello di front-ender, interagendo col back-end, ci sono stati degli elementi che insomma hanno fatto smadonnare sono stati trovati particolarmente complessi per un front-ender? Allora sì, sfortunatamente il nostro back-end front-end è 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, cioè lo vedi nell'index e poi non lo vedi più e 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 vis, 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, 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 ha la sua struttura definita, tira via la linea guida per dare un riferimento a chi è nel mondo JavaScript, una specie di nest, nest JS, super strutturato, però poi alla fine vedo che moltissimi costruiscono dei livelli di astrazione, ed è capitato anche a me, talmente tanti livelli di astrazione che poi la complessità è data da questi livelli di astrazione 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 quattro handler che servono quattro 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 Symfony, 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'Aravel invece e quindi Symfony e l'Aravel è pronto abbastanza simili.

Occhio perché anche là fa resti incazzare parecchi.

Lo so benissimo però, anche un po' il teasing che è divertente.

Esatto, stai triggerando bellissimo.

Poi quando un po' mi sono avvicinato invece a librerie o framework un po' più minimali anche contenendo 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 facendo, stai lavorando in pochi nel progetto ma scala tutto quel design pattern, scala quel processo di pensiero a due tre anni con altri cinque sviluppatori e è difficile mantenerlo in modo da non darsi tuttavia intera zappa sui piedi.

Deve essere veramente strutturato bene e soprattutto ci deve essere chiara la visione nel lungo periodo.

In alternativa io 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 dottor 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, poi mi sono fatto tutte le funzioni con meno side effect possibile mettendo i side effect all'angolo.

Alla fine sì funzionava bene, alla fine sì anche leggibili le firme perché in realtà le dinamiche di dominio erano chiarissime però poi alla fine se io devo il resto dell'applicazione era un crude.

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 l'acera e togli l'acera.

Esattamente quello che si fa.

Prima lava tutte le macchine poi le lucidi con l'acera.

Ma perché devo lavare le macchine? Ricorda patto, nessuna domanda.

Eh sì ma credevo che...

Avanti! Devi dare l'acera con la mano destra e la devi togliere con la sinistra.

Dai l'acera, togli l'acera.

Il respiro lo prendi con il naso e lo emetti dalla bocca.

Dai l'acera, togli l'acera.

Non dimenticare il respiro, è molto importante.

Dai l'acera, togli l'acera.

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à, di poter avvicinarti anche al back-end.

Questa è ovviamente mia opinione.

C'è chi preferisce lavorare sul front-end, sulla parte più vicina all'utente e c'è chi magari ha una mentalità in cui piace un po' smanettare di più sull'architettura, 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à a tal volta ha 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à, ho anche Redux Trunk, la complessità che vedi là è secondo me molto più alta di buona parte dei back-end anche a livelli architetturali, non sei più uno sposta pixel.

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 boh 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, non sono più delle strutture di markup HTML e tre righe di CSS, 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 front-ender puro verso un ruolo un po' più full stack? Sicuramente aiutandolo il più possibile, quindi dandogli, 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 e 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 back-end.

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 effettivamente 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 webitals 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ù di stretto 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, però pensandoci anche su due piedi sicuramente se tu avessi una design library per esempio fatta bene, quindi che gestisce bene i propri componenti web, i propri componenti nativi, in quel caso le tue applicazioni neanche si potresti dire che sono React Native o React Web, sono applicazioni costruite con la tua design library, poi tutta la logica di business.

Entriamo nel dettaglio, una cosa che sono super curioso, cioè fammi un esempio pratico.

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 sul native, però noi costruiamo effettivamente la nostra applicazione utilizzando questa design library, quindi c'è di effettivo React Native, poi sul codice che scriviamo tutto il giorno c'è il poco, cioè le view, in realtà penso quasi esclusivamente le view.

Ma per cui voi avete questa library, i cui componenti poi al loro interno outputano cosa? Degli eve o delle...

non mi ricordo come si chiamano in React Native.

Ah, di usare le view.

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' disgusto, è un bottone, è un anchor e noi facciamo per esempio 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, a istituire o un anchor o un bottone, mentre sulla parte nativa utilizziamo direttamente button di React Native e quindi quello 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 vengono convertite in div.

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 button o un anchor.

Un link classico scusami.

La fai a livello componente dello UI kit o lo fai attraverso che ne so 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 e semplicemente quella poi al run time, mobile time ci va a dire qual è il sistema operativo qual è la piattaforma che stiamo utilizzando quindi possiamo discriminare sul sistema operativo anche tramite il codice proprio.

E a livello 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 nulla all'interno mentre su React Native no e crasha proprio l'applicazione va a fa un throw e non ho idea del perché non 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 proprio la classe URL è completamente riemplementata su React Native e manca di tante utility quindi spesso ti trovi della roba sul web che 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ò avendo uscito 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 un sistema operativo e l'altro quindi devi fare degli accorgimenti.

Quindi alla fine quel tipo di differenza la gestite a livello di UI library esponendo poi delle API al netto di quel problema giusto? Sì sì.

Ok noi ci prendiamo un secondo per un momento classico del nostro podcast.

È il momento di ringraziare i donatori, chi ci supporta e fa sì che ogni giovedì ci ringraziamo.

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é Gitbar è 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.

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.

Ma detto questo ritorniamo alla nostra discussione con Flavio e gli voglio chiedere un'altra cosa in realtà.

Voi gestite più prodotti e più piattaforme.

Ok e mi dicevi che sia prodotti che piattaforme alla fine condividono dei pezzi di codice per cui nella mia testa l'omino mezzo zoppo che c'è mi ripete ormai da qualche minuto.

Non so se vi ricordate la scimmietta sulla testa di Homer Simpson che suona ai piatti.

Ok nella mia testa c'è una scimmietta che dice monoripo monoripo monoripo monoripo e lo sta facendo già da un quarto d'ora.

Quindi la mia domanda è Flavio monoripo o non monoripo.

La tua scimmietta ha ragione.

Noi siamo una monoripo che ha più di una decina quasi due decine penso di progetti al suo interno.

Usiamo Yarn e Augmented con Learn.

Anche se per esempio sul nostro backend for frontend stiamo sperimentando con NX ancora in fase di sperimentazione però utilizziamo quindi Yarn e Learn 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 effettivamente quello più in cui abbiamo usato la faccia più frequentemente è quello proprio delle release quindi essendo 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, 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 points 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 è stata pensata due anni fa per quando c'erano due prodotti quindi stiamo un po' rivisitando come strutturiamo la monorepo, come gestiamo la release, probabilmente riusciremo a un po' 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 è una risiede sulla monorepo la nostra design library e viene 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 e 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 e non avendo un ciclo di release comunque adatto alla mole di prodotti che abbiamo ci troviamo a 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 dei 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, 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 e la butto là tu mi fai la code review 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 to end va bene tutto quello che ti pare ma qualcosa sfugge sempre.

Se invece l'ownership di chi fa la modifica nella UI kit 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 e 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 Button Next e poi si refactora 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 e anche se rimaniamo con Yarn in futuro con LearnA probabilmente dovremo mettere in piazza un sistema di generazione di codice 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 insomma 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' differente per ogni team quindi ci sono delle lieve differenze fra ogni team però generalmente abbiamo sempre un mock up 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 dei mock up e vengono un po' rifiniti con dei processi interni e una volta che sono pronti inizia effettivamente lo sviluppo.

E questo spesso effettivamente una design library si pensa se questo nuovo componente deve finire nella design library oppure è semplicemente un componente per questo prodotto e quindi là c'è un po' la discriminante se metterlo sul lato di design library oppure se lasciarlo.

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 dire 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 ci 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 splittare un po' di più i componenti e renderli farli 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 è probabilmente quello che ci abbiamo messo di più a realizzare in 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 praticamente soltanto col mouse e abbiamo dovuto metterci mano per avere un meno l'accessibilità su keyboard e là abbiamo dovuto 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 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 là la search magari c'è le check box dentro, hai un po' di customizzazione è un po' più difficile renderle semantiche e quindi abbiamo dovuto creare appunto, abbiamo dovuto replicare quello che farebbe il browser su una Select normale utili sopra un componente principalmente React Native.

Questo per quanto riguarda l'accessibilità e invece per quanto riguarda la parte semantica che comunque è strettamente legata poi al concetto di accessibilità cioè il calcinculo con la sequenza degli header tag, se è un discorso, il calcinculo che ti dà l'accessibility validator con la sequenza dei tag H o dei tag non semantici comunque è un problema d'accessibilità e in quel caso come l'avete risolto? Ancora non l'abbiamo risolto del tutto quindi è un work in progress, comunque l'accessibilità sulla 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 o non lo so qualunque cosa, quindi la mia domanda subito dopo la sigla è hai qualcosa da condividere con noi? E conduco nel Paese dei Ballocchi! Ah, il Paese dei Ballocchi! Allora Flavio cosa ci porti in dote qua su Gitbar? 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 Knopbach e parla di design driven...

scusa...

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 a un po' capire come strutturare un'applicazione a grande scala e poi Knopbach spiega benissimo ed è stra interessante da leggere, quindi è una lettura che io consiglio tantissimo per 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 Knopbach, ho letto l'infame bellissimo dal mio punto di vista il famoso libro rosso del DDD, 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 InTale, 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 Elfiranger, uscire fuori dalle robe di tutti i giorni.

E non potevo non sbagliare sigla, giusto Flavio? Oggi è una di quelle giornate da dimenticare, per fortuna c'è stata la chiacchierata con te che mi ha ripigliato, sennò oggi era una di quelle giornate da cancellare dal calendario.

Dicevi qualcosa su Instagram? È lunedì.

Sì ma credo che siamo uno dei più brutti lunedì del mare.

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 averti 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, e vi ricordo rapidamente due cosine velocissime, prima che parta la sigla, 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 che i nostri contatti info.gitbar.it e il nostro gruppo Telegram, soprattutto mi raccomando se avete un telefono Apple, iTunes, andate, lasciate una recensione del nostro podcast, lasciateci le stelline cadenti, in modo che possiamo non cadere, ma conquistare le prime posizioni della classifica Tech, perché oh ragazzi siamo una bella community, insomma, ci prendiamo lo spazio che 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.

Ciao! Ciao! 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.

Ciao a tutti!.