Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Bene, benvenuti in un nuovo episodio di Gitbar.Quest'estatta è, mamma mia, un'estate così affollata, non la vedevo da tempo.affollate le spiagge, è affollata la Sardegna nonostante adesso sia scoppiato il caso Corona e ci siamo praticamente barricati in casa e andiamo in spiaggia ormai alle 7 di sera ed è affollato anche Gitbar, infatti quest'estate Gitbar il podcast è ricchissimo di ospiti e anche oggi ne abbiamo uno ma prima di svelarvelo il mio compito forse anche un po' logorroico è quello di ricordarvi i nostri contatti.Potete scrivermi a info@gitbar.it o a @brainrepo mi raccomando per qualunque cosa, maledizioni o richieste di informazioni io sono a vostra disposizione fatto questo memorandum molto rapido, prima di scoppiare dal caldo, introduco l'ospite di oggi abbiamo Maxim Sinek, ho detto bene? Benissimo, perfetto, ciao! È la prima volta che non sbaglio accenti e parole, questo è fantastico.Chi è Maxim? È il CTO di Nucleod, è il principal architect di Evology ed è anche il lead maintainer di Hospital Run.Non vi svelo tanto di questi progetti, di queste aziende, perché sarà lui a raccontarsi.Allora, la prima domanda che ti faccio, Maxim, è come sei entrato nel tunnel? Quindi come sei diventato sviluppatore? Eh, questa è un'ottima domanda.Innanzitutto grazie di avermi invitato, mi piacerà fare questa chierata con te.Diciamo che è sempre stata una mia passione, come tanti di noi credo, da quando eravamo piccoli, ci stiamo cimentando e ci cimentiamo con questi attrezzi meravigliosi che sono i computer, pian piano approfondendo sempre di più gli argomenti, alla fine mi sono avvicinato alla programmazione e ne ho fatto il mio lavoro da almeno dieci anni a questa parte diciamo che si lo faccio tutti i giorni lo faccio per passione lo faccio anche per per mestiere quindi così è una storia come tante immagino Fantastico insomma tu più o meno il percorso di tutti c'è chi ha iniziato a giocare con i videogame poi voleva diventare sviluppatore di videogame e mai nessuno che avesse perseguito l'obiettivo fino alla fine siamo finiti tutti a sviluppare qualcos'altro.No, in realtà c'è Marco che ho intervistato in una delle prime puntate del podcast e lui in realtà è diventato sviluppatore di videogame e poi c'è insomma lo sviluppatore che prende il suo spazio, impara dei nuovi linguaggi e inserisce una serie di elementi in una cassetta degli attrezzi che è la cassetta degli attrezzi professionali che ci portiamo ogni giorno.Nella tua cassetta degli attrezzi da sviluppatore cosa c'è dentro? Beh direi che se qualcuno mi dovesse chiedere cos'è, diciamo, la tecnologia e runtime che preferisci in assoluto è assolutamente Node.js che ormai uso da otto anni e che è stato per me fulgurante, un amore a prima vista.All'epoca programmavo, probabilmente come di nuovo tanti di noi, PHP e Python principalmente, e poi pian piano quando quando diciamo è esploso con versioni ancora 0.8 e le successive per me è stato veramente spolverante.Da allora ne ho fatto il mio principale ambiente di sviluppo di runtime e praticamente per fortuna riesco sia nel lavoro che nel tempo libero a usarlo come come ambiente principale quindi sono molto contento e molto felice.Certo ti faccio una domanda spesso anzi quasi sempre mi arrivano dei dei messaggi privati su twitter o delle email che chiedono "Mauro mi raccomando quando intervisti gli ospiti ricordati di chiedere l'editor o le idee che utilizzano" perché lo sai noi siamo maledettamente feticisti e ai gingilli ci teniamo particolarmente per cui...uso WS Code come tanti di noi di nuovo in realtà preferisco editor più leggeri e WS Code già sta diventando un po' troppo pesante per come concepisco io l'ambiente di sviluppo, prima di usare WS Code usavo Sublime Text.Però devo dire che la Microsoft e la comunità open source sta facendo veramente un lavoro a grezzo, che era la mente se visto prima, almeno io non ricordo, ed è molto potente e aiuta sia chi ha le prime armi sia chi ha bisogno di gestire repository molto grossi.Quindi per me oggi è una scelta unica, nel senso devi per forza usarla.sì e se dovessi dirti Vim? guarda ottima domanda quando ero giovane avevo tanto tanto tempo libero quindi non dovevo lavorare non dovevo per sostentarmi usavo Vim però si parla di 15 anni fa e quindi diciamo non l'ho poi mai portato nella mia carriera professionale era più quel periodo quando sei oggi 33 anni quindi 15 anni fa ero adolescente più o meno ed era in quel periodo in cui appunto avevo tempo e lo usavo.Non riesco purtroppo a essere produttivo oggi con Vim, quindi non lo uso.Guarda non potrei condividere meglio questa posizione io lo usavo nel periodo universitario poi l'ho accantonato.Ho provato da due mesi a questa parte a rispolverarlo.Seguondo me sto preparando dei corsi ho detto vabbè lo rispolvero riprovo visto che comunque mia moglie lo usa tutti i giorni quindi dico dai insomma e mi prendi in giro tra l'altro mi prendi in giro perché uso via scodde lo sai no la famosa guerra degli hater un po' come la guerra degli spazi o delle tabulazioni per l'indentazione.E quindi ho provato ma caspita, voi che mi trovate ancora nella parte bassa della curva d'apprendimento, quindi sto ancora sperando di superare quel dosso e diventare particolarmente più ma non ci riesco.E' più forte di me.Ti capisco veramente guarda non proprio non riesco.Ripeto non è che non mi trovi, le cose riesco a farle ma sono troppo lento e devo pensare troppo a come parle.Quindi no preferisco preferisco usare uno strumento come WS Code.Ahimè.No è assolutamente un ottimo strumento.Tieni presente che anche io penso che ho vissuto da sviluppatore anche PHP.Io ho vissuto il passaggio tra PHP Storm a WS Code e quindi all'inizio ho sofferto un po' il passaggio perché PHPStorm è un IDE super completo, super integrato, super tutto è anche molto figo devo dire però ragazzi l'avvio di VSCode prendi trascina il file SBOOM e hai un editor in stile Sublime Text ma molto più potente di Sublime Text molto più potente anche molto più facile da configurare, molto più rapida la configurazione è davvero una sorpresa Prima ho detto che sei CTO di Nucleod.Di cosa vi occupate? Nucleod è una startup nata ormai tre anni fa da un'idea di un gruppo di amici, perché alla fine lo siamo, che voleva cambiare un po' il mondo, come tante storie, voleva cambiare il mondo della realtà virtuale applicata alla medicina.Quindi Nucleod si occupa principalmente di sviluppare e tuttora ci stiamo lavorando un prodotto per gli HoloLens di Microsoft, quindi Mixed Reality.Il prodotto principale si chiama Chiron, è ancora in forma di prototipo, ma lo stiamo già usando con successo qua nell'ospedale vicino a Bravito, che è Udine, include Nezia Giulia, nel reparto di neurochirurgia.Può essere visto come un supporto al neurochirurgo per migliorare la neuronavigazione durante le operazioni al cervello, fondamentalmente, quindi rimozione di tumori e simili.La sfida è molto grossa perché siamo veramente piccoli, come è giusto che sia, essendo una start-up, ma ci sono player molto grossi affermati da decenni che hanno già tecnologie interne e quindi diciamo è difficile emergere.In realtà lo facciamo anche in questo caso più che altro per passione, nel senso che siamo tutti informatici, uno di noi è anche un medico, neurochirurgo, guarda caso, e quindi possiamo applicare quello che conosciamo e quello che insomma sappiamo e vogliamo ulteriormente approfondire in un ambito che è complesso e che potenzialmente potrebbe risolvere grossi problemi e dare una grossa mano alla medicina in genere, perché poi noi lo stiamo applicando alla neurochirurgia perché è l'ambito che ci serve per testarlo.Se funziona in neurochirurgia durante le operazioni al cervello può essere applicato a n altri ambiti intraoperatori, appunto per la necessità della precisione assoluta, qualcuno direbbe submillimetrica, ma non è proprio così, per appunto del device stesso.Fondamentalmente è questo, e poi tutti gli MS è connessi per riuscire a portare in sala operatoria con successo questa app alla fine per gli HoloLens, perché di app si tratta, che comunque comunica con il mondo esterno, quindi neuronavigatori, dei sensori in città operatoria eccetera quindi fondamentalmente è una società è una piccola startup che serve semplicemente per sviluppare questo unico progetto e che esiste perché ci permette di parlare con un altro tono con gli interlocutori di prima quindi con le grosse aziende con gli ospedali diciamo che se fossimo solo noi cinque amici la faccenda non funzionerebbe proprio benissimo.Si concordo anche perché la credibilità in queste fasi e soprattutto in quegli ambiti dove in realtà il biglietto da visita assume un valore importante.Ti faccio una domanda ma questa è una mia curiosità che esula un po' dall'ambito e dal contesto tecnologico ed entra un po' nel mondo delle start up dove ti confido che non sono un grandissimo conoscitore.Ma qual è il vantaggio che può avere una start up rispetto a un grande player in quel tipo di ambiti che sono molto verticali molto specifici? Questa è un'ottima domanda in realtà perché prima di cominciare a fare questo anche io me lo chiedevo e quindi non è che lo vedevo come una soluzione comunque difficile no perché sei piccolo ci sono pesci grossi e quindi magari è difficile anche farsi notare in realtà lavorando ci abbiamo scoperto che è anche un vantaggio perché spesso capita perché appunto, come dicevo prima, queste grandi aziende, Metronic, Eatomed e altre, in realtà internamente stiamo pensando da anni di sviluppare o stiano già sviluppando soluzioni simili che si integrano ai loro sistemi.Quando però capita che c'è un nuovo player esterno, per quanto piccolo sia, che magari ha un qualcosa di diverso rispetto a quanto hanno pensato loro, spesso attira questi pesci più grandi e quindi sono interessati da un lato a capire fin dove sei arrivato e cosa sei riuscito a sviluppare, dall'altro come poterti portare verso di loro piuttosto che dal loro concorrente.Quindi banalmente ti offrono accesso ad API oppure a cose che comunque non potresti in alcun modo approcciare diversamente.Poi questo, come dicevo, in realtà è davvero particolare come startup.Non la chiamerei neanche startup, mi sento stretto, nel senso non è un'azienda che è nata in questo momento per accogliere dei fondi, dei investitori per potersi espandere e scalare.Non c'è niente da scalare al momento perché sono centinaia i centri al mondo che potrebbero permettersi una soluzione del genere e giustificarla, quindi giustificare l'investimento per usarla.È un progetto di ricerca e sviluppo che nel momento in cui riusciamo a dimostrare che è fattibile, può essere usato con assoluta precisione certezza e tutto il resto potrebbe diventare una startup in senso lato cioè un'azienda che a quel punto si potrebbe raccogliere fondi ed espandersi quindi il senso in questo caso è così.Una domanda questo tipo di mondo è caratterizzato da un certo livello anche di sensibilità di criticità no perché stai sviluppando delle app che vanno ad operare in situazioni critiche.Da CTO come ti poni e quali sono diciamo quelle che secondo te sono le migliori pratiche per affrontare queste situazioni e questi contesti? È davvero tosta, non te lo nascondo, perché comunque spesso le decisioni che prendiamo...facciamo una premessa, la premessa è che quanto stiamo che stiamo sviluppando non esiste e quindi non abbiamo un reference sul quale basarci.L'altra premessa da fare è che le uniche fonti che abbiamo per riuscire ad avere un minimo di background al quale puoi applicare del nostro sono tuttora in fase di… sono dei paper universitari, quindi di ricercatori che dimostrano un piccolo pezzettino di una big picture che stiamo cercando di comporre noi lavorandoci.La vera sfida è appunto questa.Grazie al fatto che siamo multidisciplinari, come dicevo prima, abbiamo uno dei soci che è un studente di neurochirurgia, nel senso che è uno specializzando, e dottore, ovviamente, medico.Gli altri sono praticamente informatici.Riusciamo comunque a compensare, in questo caso, le mie lacune.Un altro aspetto che ci è venuto incontro da questo punto di vista, sul fatto di essere sicuri che quello che stiamo facendo poi, da un lato è giusto, dall'altro non uccide nessuno e che funziona, sono le aziende che abbiamo incontrato sulla nostra strada, che ci sono aperte e ci hanno veramente aiutato a capire come fanno loro cose simili, quindi neuronavigazione, come fanno elaborazione di immagini in tempo reale o comunque quasi in tempo reale e comunque quali sono le procedure per poi certificare un device del genere, perché questo una volta che sarà sul mercato, se mai ci finirà, dovrà essere certificato come device medico usabile in sala operatoria, che è ancora più stringente rispetto a un qualsiasi altro dispositivo medico applicato diciamo alle persone comuni o comunque fuori dalla sala operatoria.Questo è un aspetto che stiamo rimandando volutamente perché abbiamo capito che basarsi magari su soluzioni già pronte di grosse aziende con le quali possiamo integrarci, usando quanto loro hanno già brevetato o comunque certificato, ci permette ogni volta di togliere magari un pezzettino dalla certificazione che ci serve.Quello a cui puntiamo è che questo pezzettino che tocca a noi certificare sia così piccolo che sia facile da dimostrare che funzioni.Per ora la faccenda è promettente, nel senso che ogni giorno, man mano che il tempo passa, riusciamo sempre di più a stringere questo cerchio, però arriverà il momento in cui probabilmente dovremo capire in realtà come essere sicuri di quello che stiamo dicendo.Al momento, principalmente appoggiandosi anche dentro la sala operatoria e l'altra strumentazione, possiamo essere sicuri che quello che facciamo è giusto.Inoltre, nei test che stiamo facendo, il nostro device non è l'unico usato, è solo un ausilio che non viene usato neanche dal chirurgo che sta operando in quel momento, ma dal suo vice.diciamo.Di solito sono in due o tre chirurghi che sono lì e quindi uno lo guida e l'altro effettivamente esegue.Oppure in una fase preoperatoria, quando il paziente è già preparato e già fissato al tavolo operatorio, il chirurgo che poi andrà a eseguire l'operazione effettivamente usa il device, usa gli Hololens e capisce da dove entrare, da dove bucare la testa per riuscire a raggiungere il tumor e comunque asportare quello che deve asportare.quindi per ora la faccenda è tranquilla.Ok quindi riesci ancora a dormire la notte non ti senti schiacciato dal peso delle responsabilità? No decisamente no.Altro ruolo che ho trovato un po' cercando nella rete e spulciando il tuo Linkedin è il ruolo da principal software architect di Evology.Di cosa vi Evology è un'altra azienda che può essere considerata una startup, nel senso che è nata 5 anni fa dalle ceneri di un'altra azienda che è stata scorporata.Evology si occupa di logistica per gli e-commerce.In realtà si occupa di logistica a 360 gradi, logistica moderna, innanzitutto cos'è? Sono quei processi che ti permettono, una volta ricevuto un ordine su diversi canali possibili, di evaderlo in minor tempo possibile, accontentando il tuo cliente e tracciando tutti i passaggi intermedi.Evology ha un suo prodotto SaaS in cloud, sviluppato ovviamente in Odd, in Fastify e MongoDB, che appunto si occupa di gestire il magazzino, quindi la warehouse, banalmente è un warehouse management system da un lato, dall'altro si occupa di ricevere gli ordini, quindi è un order management system, e come terza strada, terza cosa che fa è gestire i prodotti effettivamente, quindi può essere considerato un PIN, cioè un software che ti permette di gestire un catalogo e pubblicarlo su diversi diversi negozi online e offline, perché la parte finale e importante della logistica moderna è quella del retail.Spesso i nostri clienti hanno anche dei negozi nei quali vendono fisicamente a clienti che ci entrano e hanno bisogno di un software centralizzato che dalla sede centrale permetta di sapere in tempo reale in ogni negozio, in ogni magazzino, sia quant'è la quantità di merce e quale merce c'è.Quindi questo è l'ambito nel quale opera Evology.Interessante.Quindi insomma vita pienissima.Si.Si fa quel che si può.Ma riesci a trovare, vedevo, che riesci a trovare anche il tempo per contribuire al mondo dell'open source.e sono capitato su un progetto che ha focalizzato, ha catturato completamente la mia attenzione si tratta di Hospital Run, ci racconti di cosa si tratta? perché sicuramente potrai raccontarlo meglio di me, essendo il lead maintainer sì, sono il lead maintainer del progetto attualmente Che cos'è Hospital Run? Hospital Run è un progetto un po' da sognatori, che nasce da ormai nel 2014, quindi diversi anni fa, dalla mente di tre personaggi, in realtà sono ottimi programmatori, sono americani, che hanno avuto l'idea di sviluppare un software per gestire gli ospedali del terzo mondo.Detta così sembra una banalità, in realtà il software sviluppato è pensato sempre per ambienti di un mondo un po' diverso da quello del terzo mondo, quindi per noi occidentali che abbiamo risorse sia economiche che non, abbiamo connessioni sempre attive, abbiamo base di dati enormi.Hosti da RAN invece è pensato per tutti quegli ambienti dove tutti questi sono considerati lussi, quindi non c'è una connessione, non ci sono risorse né economiche né di altro tipo e soprattutto tutta la gestione del paziente non solo è fatta a mano tramite documenti scritti sulla carta ma spesso è anche per passaparola nel senso nel momento in cui cambia il medico dice a quello dopo guarda gli ha fatto questo e quindi cercano di arrangiarsi.Quindi il target di Hospital Run è fondamentalmente l'Africa e Afili.Come nasce il progetto? Nasce perché questi tre valdi personaggi sono andati in Africa proprio per toccare con mano quali sono le esigenze dei dottori che poi operano in quegli ambienti.L'hanno fatto grazie a Cure.org, che è una ONG americana che si occupa di fornire materiale e costruire ospedali generalmente in Africa.Dopo diversi mesi passati lì a capire le esigenze, ritornati in America, hanno costruito, o meglio, hanno incominciato a costruire la prima versione di Hospital Run, che appunto è un hospital management system in questo caso, oppure può essere anche usato come una cartella elettronica, quindi a mare.Il progetto è andato avanti per tanti anni, è stata la versione unica stata la versione 1 sulla quale lavoravano loro e altri della community era scritta in Ember, Express come server, CouchDB come database e poi vedremo perché CouchDB, che sembra una scelta un po' azzardata perché sicuramente non è il database più usato, però una caratteristica che lo rende assolutamente importante per un progetto del genere e fondamentale.È l'unica delle tecnologie usate che è difficile sostituire.Comunque dopo aver lavorato per un 5 anni su questa versione 1 scritta in Ember, purtroppo due anni fa il progetto subisce una battuta d'arresto dal punto di vista dello sviluppo perché due dei tre fondatori del progetto, cambiando lavoro, avevano meno tempo per lavorare su progetti open source e quindi non riuscirono più a contribuire maniera continuativa.Da lì la community si è un po' spenta, purtroppo Ember ha cominciato a perdere sempre più developer perché in quegli anni lì con Tatori C15 potrebbe essere ancora considerato una tecnologia assolutamente da usare.Oggi, dopo che è arrivato React ed Angular non è più così.Non ce n'è per nessuno.No, percopo no.E quindi diciamo nessuno l'ha poi portato avanti e i nuovi sviluppatori che avrebbero voluto contribuire non potevano perché non conoscevano Ember da un lato, dall'altro il codice che era stato scritto fino a quel momento era enorme e quindi era una codebase molto difficile da approcciare se uno non l'hai scritta tu, due anche se non l'hai scritta conosci molto bene Ember.Come poi arriva nelle mie mani questo progetto è un'altra storia divertente perché l'anno scorso, era metà luglio dell'anno scorso circa, stavo cercando di capire sul sito di OpenJS Foundation quali sono progetti meritevoli, meritevoli non dal punto di vista di particolari meriti, ma semplicemente di bisogno di sviluppatori ai quali potessi contribuire, perché l'open source è una cosa che ho sempre fatto, mi è sempre piaciuta e l'anno scorso finalmente mi sono imposto, perché ogni anno mi impongo qualcosa, L'anno scorso era l'anno in cui ho deciso che dovevo contribuire di più e tornare quanto più potevo all'open source, che mi aveva dato tanto nell'arco della mia carriera professionale e non.Andando sul sito di OpenJS Foundation e scorrendo tra i vari progetti che sono incubati dentro all'OpenJS Foundation, quindi Hosted Run effettivamente è un progetto protetto dalla OpenJS Foundation.e poi se vuoi magari possiamo approfondire cosa vuol dire per un progetto essere incubato Sì, lo vediamo alla fine.Ok, quindi appunto ho trovato Hospital Run, cliccando sul sito c'era un bel disclaimer grande, grandissimo, impossibile da non vedere, in cui uno dei soci iniziali, dei mantenitori iniziali, Joel, chiedeva aiuto e cercava nuovi lead maintainer per portare avanti un progetto in cui lui credeva molto.Infatti il blog pospo è quasi strappalacrime in cui ripercore tutta la storia che l'ha portato a pensare, a sviluppare, a ospitare e a costruire una community ed era dispiaciuto perché lo vedeva, stava vedendo che stava appunto spegnendosi la community e morendo il progetto.Assolutamente dopo aver detto questa cosa qua non ho potuto non contattarlo e dopo una chat durata un po' di giorni, in cui abbiamo capito di più l'uno dell'altro e quali idea ha il progetto, ha capito che io potevo essere quella figura perché le mie idee erano molto simili alle sue e le motivazioni che io avevo erano praticamente identiche a quelle che ha avuto lui 5-6 anni prima.Abbiamo deciso di fare questo passaggio di consegne e quindi sono diventato effettivamente io, nel 1° di agosto dell'anno scorso, il di Hospital Run.Quindi a questo punto ti sei catturato sul groppone un'altra grande responsabilità.Si detta così è vero, non ci avevo pensato fino ad oggi, momento di riflessione.E quindi la mia domanda che ripeto oggi sto cercando di rimandare il più possibile la discussione tecnologica ma tanto ci arriviamo sulle architetture e sulle tecnologie però questa domanda viene di conseguenza e come organizzi la tua giornata tra lavoro su nucleo, lavoro a Evology, contribuzioni su Hospital Run.Come riesci a avere un equilibrio e magari anche una vita privata? Allora spesso si sente dire l'importante è sapessi organizzare.Però è una banalità, ma in realtà è proprio così.Dipende da come vivi le cose.Cominciamo da quella cosa alla quale dedico il minor tempo, proprio fisicamente il minor tempo, quindi meno minuti spesi sopra, che è il progetto Chiron di Nucleod.Perché? Perché essendo appunto un progetto di ricerca sviluppo, molto del lavoro che devo fare passa dal leggere paper, quelli di prima, o comunque fare delle prove dirette su quanto ho letto poco prima.Principalmente il tempo dedicato a Nucleod è quello della lettura, quindi può essere o mattina prima di mettermi a lavorare oppure la sera prima di andare a dormire o nei weekend.Lo tratto come se fosse un momento di relax, perché di fatto lo è.Quindi leggendo e apprendendo cose nuove, comunque ci lavoro sopra.Per quanto riguarda l'open source in genere, quindi sia Hospital Run, più recentemente anche Fastify, quello è proprio il momento con il quale comincia la giornata.Quindi se la mia giornata comincia lavorativa, comincia alle nove, nove e mezza, l'oretta prima oppure un'oretta e mezza prima è quella spesa a controllare gli iscritti aperti, vedere come sono le pull request, capire quali sono le cose da sviluppare nel prossimo futuro, quali sono gli eventuali issue da aprire, coordinare un minimo degli altri dei maintainer con i quali mi confronto praticamente quotidianamente, per poi cominciare la giornata lavorativa, quindi lavorare effettivamente su Evology, che è poi il mio lavoro.Per quanto riguarda invece la sera, è la stessa cosa al contrario.Quindi se la mia giornata finisce per le 18, 18.30, l'ora successiva è sempre spesa sull'open source.Quindi pull request, chiusura, è la stessa organizzazione fondamentalmente della macchina.Capita che ci siano anche, soprattutto per Fastify, dei momenti nei quali sto attivamente lavorando però scopro un bug o uno dei plugin di Fastify, in cui in quel momento intervengo direttamente sul codice, apro la pull request e quindi diventa il mio lavoro di quel momento.Stesso discorso per quanto riguarda i weekend.Personalmente cerco di non lavorare nei weekend neanche sull'open source perché il rischio burnout è sempre molto vicino.In passato mi è capitato, soprattutto nei primi momenti in cui ho preso ospita Run per essere il lead maintainer, avendo dovuto riattivare la community, a un certo punto sono arrivati a avere molte contribuzioni di persone che avevano bisogno di guida, nel senso proprio di capire come poter contribuire e come poter essere utile al progetto.Questo è un altro grande problema del progetto Pinsource, che anche se riesco a trovare tante persone volenterose che spendono il loro tempo per fare qualcosa di meraviglioso o bello, devono essere indirizzate, se no si rischia che il tempo di tutti venga speso in maniera sbagliata.Quindi, in un primo momento, dovevo per forza anche "lavorare" nei weekends o hospital run ed è stato davvero pesante.Quindi, dopo un periodo così, ho capito che è meglio cercare di contenersi ed è meglio cercare di, appunto, come dicevo prima, organizzarsi, avere magari uno schedule più rigido, ma che ti garantisca le giuste ore da dedicare a qualsiasi cosa.Alle varie attività, certo.Promesso.Per ora questo tipo di domande le sospendiamo e passiamo invece ai giocattoli.Una domanda che in realtà sto tenendo a freno già da un po', appunto con il fatto di chiederti qual è lo stack tecnologico che sta sotto Hospital Run, e il perché della scelta di queste componenti tecnologiche.Allora, come accennavo al volo prima, Hospital Run in questo momento usa uno spec completamente diverso rispetto, o meglio, parzialmente diverso, anzi non parzialmente diverso rispetto alla vecchia versione.Stiamo lavorando sulla versione 2 di Hospital Run ed è una breaking change nel senso che la codebase è praticamente stata interamente accantonata della versione 1 e sono state prese solo le scelte di design offerate dal vecchio team e le logiche dell'applicativo stesso.Perché? Perché abbiamo scelto di usare Reap.Come dicevo prima, continuare su Ember era molto complesso l'anno scorso, anche perché purtroppo, essendo stato fermo più di due anni il progetto, aveva versioni vecchie di dipendenze, versioni vecchie di Ember che erano proprio non più da un lato compilabili e dall'altro avviabili.Quindi abbiamo dovuto operare una scelta che in un primo momento ha creato anche abbastanza problemi, perché diversi maintainer di Amber sono venuti sul nostro Slack a chiedere come mai, a insistere che non venga abbandonato Amber, però col seno di poi mi sento di dire che è una scelta che abbiamo preso coscientemente che sta pagando.Di qua abbiamo, perché non l'ho presa da solo, l'abbiamo preso sia con i vecchi maintainer sia con il nuovo team che poi si è andato a formare nei primi mesi, quindi ci siamo seduti diverse volte a un tavolo virtuale e abbiamo capito che forse per il progetto era meglio lasciar perdere Ember.Quindi una delle tecnologie usate è Rehab.L'altra tecnologia usata che è poi quella che permette di fare quello che rende diverso da tutto il resto presto, ospita run, cioè di farlo funzionare anche offline, è PAUSEDB e CAUSEDB.Cos'è PAUSEDB? PAUSEDB è un database scritto in javascript che gira all'interno del browser e si appoggia alle API native del browser, indexDB quindi, per fornire un'interfaccia salvataggio locale di dati.Il grosso punto a suo favore è che out of the box permette di sincronizzarsi più o meno in automatico con un server CouchDB remoto, quindi nel momento in cui la connessione nel device che ha avviato l'interfaccia è presente, ogni cosa che viene è fatta viene salvata immediatamente in automatico in un server CouchDB remoto.Nel momento in cui la connessione cade e quindi si offline, l'utilizzatore può continuare a usare l'applicativo come se niente fosse successo.Tutte le modifiche che fa verranno salvate in locale e nel momento in cui torna online verrà sincronizzato col CouchDB remoto.Questo, come dicevo prima, è è assolutamente una killer feature che non possiamo togliere, non possiamo dimenticare, perché i nostri utilizzatori nel terzo mondo non hanno il lusso di avere una connessione sempre presente e se ce l'hanno può succedere che non sia sufficientemente veloce o stabile.Uno degli esempi che abbiamo avuto è una clinica su quattro ruote, nel senso che è un fuoristrada che gira nei vilaggi della Kenya, mi pare, e lui, perché alla fine è solo, è un medico da solo che gira i villaggi, ha la connessione soltanto nel momento in cui rientra la sera nella sua sede e quindi tutto il lavoro di una giornata viene scaricato, è come se fosse un backup remoto automatico nel momento in cui si ricollega.L'ultima tecnologia grossa che usiamo è Fastify per la parte server.La parte server al momento è accennata, nel senso che è quella che ha bisogno di più sviluppo, che però è lento perché fondamentalmente sono l'unico che può lavorarci.Il problema è che devo lavorare anche sul resto e coordinare il progetto e quindi il tempo da dedicare alla parte server è davvero poco.Purtroppo mi sono accorto che è più facile attirare sviluppatori front-end React che sviluppatori back-end.credo perché essendo un progetto che non è diretto ai developer quindi non è una liberia non è un framework ma come utilizzatore è un utilizzatore finale cioè l'utente viene vista un po' meno cioè l'approccio è diverso e quindi ci sono meno contributor occasionali o persone che passano per dare una mano sì persone che magari lo usano lo integran e contribuiscono quelle mancano esattamente.Quelle mancano completamente e secondo me è la cosa difficile di progetti come questo però conto che pian piano riusciremo in qualche modo a formare una base di contributors che permetta comunque un continuo sviluppo.Ti volevo fare una domanda sul passaggio tra Ember e React.A livello operativo di mera produttività nella scrittura piuttosto che anche capacità nel fare interfacce non lo so più o meno performanti più o meno interattive più o meno belle.Quali sono le caratteristiche che hai visto, insomma il plus che portava React rispetto a Ember? Allora personalmente ho usato Ember davvero poco e l'ho usato tanti anni fa in questo caso specifico nel progetto ospita Run, la vecchia versione che ancora dovrebbe girare da qualche parte come demo, l'abbiamo lasciata volutamente, aveva il problema che tutta l'interfaccia era a cerva e quindi anche l'interazione con l'utente, l'esperienza utente ne risentiva.Non credo, anzi sono quasi certo, che non fosse dovuto a Ember in sé, che comunque è un ottimo framework e ha introdotto diverse cose che poi anche oggi come concetti sono rimasti.Il problema vero, come dicevo di Amber, è la user experience che è completamente diversa rispetto a quanto siano abituati i sviluppatori più giovani e moderni, chiamiamoli così, o comunque quelli che sono usciti recentemente o dall'università o dai vari bootcamp che hanno approcciato il web già con React presente.Quindi per loro, diciamo, è il riferimento per fare un certo tipo di interfaccia.Mi sono accorto che durante il cambio, appunto come abbiamo fatto il cambio MREACT, c'è stato un boom di nuove persone che hanno cominciato a aprire issue, hanno cominciato proprio a costruire una community intorno che, ripeto, nel front end di questo momento è grande, anche perché partecipiamo anche a un progetto che si chiama MLA, mi pare, o MLJ.Comunque è un progetto dell'università americana che manda studenti universitari a contribuire a progetti open source che secondo loro sono validi.In questo momento ne abbiamo 8 o 9 che proprio costantemente come tirocini o fanno questo.Ed è stato scelto proprio in quanto una tecnologia che loro stanno studiando, hanno approfondita lezione e hanno bisogno di usare.Quindi non credo che ci sia una differenza sostanziale, però le tecnologie dovrebbe essere stata usata nello stesso modo e non è così per il vecchio progetto.Ok, altra domanda, anche questa giusto una curiosità.Perché React rispetto a soluzioni alternative come Angular piuttosto che Vue.js o Svelte? Allora, all'epoca, cioè un anno fa, Svelte non era così famoso, nel senso si sapeva cosa era, ma non era una tecnologia magari per il futuro, era vista così, più per il futuro.Poi effettivamente adesso sta venendo sempre di più usata.Per quanto riguarda la scelta sul perché è caduta su Rehab rispetto invece a Vue, che era già maturo all'epoca e oggi è ancora più maturo, era dettata dal fatto del numero di sviluppatori possibili che potessero contribuire.Quindi è stata fatta proprio...ci siamo, come dicevo prima, di fronte a questo tavolo virtuale abbiamo deciso che è React per la community che c'è già.Quindi molte delle cose che avremmo dovuto spiegare scegliendo un altro framework non le abbiamo dovute spiegare perché chiunque volentieroso di contribuire sapeva già che mondo fosse e quindi non c'era bisogno di preconcetti o comunque di cose da sapere prima di poter contribuire.Certo, ti volevo anche chiedere un'altra cosina, questa volta in merito alla scelta del data storage quindi di CouchDB e PouchDB.Questa è una cosa che ti chiedo anche dettato un po' dalla mia ignoranza perché non ho mai approfondito quindi ammetto veramente la mia ignoranza in materia.PouchDB gira in locale come detto prima utilizzando sotto il cofano index DB ma il dubbio che mi viene è questo la sincronizzazione con CouchDB funziona mi viene difficile anche spiegarla uno a uno cioè il mio client si sincronizza tal il quale con il data storage centrale oppure ci sono dei sistemi di ACL di diritti per non andare a sovrascrivere per andare a scrivere solo in certi in certe porti non lo so non so se sono riuscito a spiegarmi perché è un po confusa la domanda nella mia testa.Allora è confusa ma in realtà non sei l'unico quindi non è la prima volta che mi viene rivolta questa domanda e io stesso all'inizio ho avuto problemi con CouchDB.Da cosa derivano i problemi? Perché è sì un database ma è anche e soprattutto un server che espone delle API JSON più o meno RESTful, quindi in realtà tutto il funzionamento e tutta la sincronizzazione si basa sul fatto che lui può ricevere degli oggetti JSON mandati in post, anzi in put, su certe rotte esposte e può a sua volta inviare a un altro server CouchDB o PouchDB le stesse informazioni, quindi funziona a chiamate HTTP.La particolarità è proprio questa, è uno dei pochi, forse l'unico, non saprei, database che non usa un protocollo suo per comunicare tra le varie repliche, ma usa l'HTTP, quindi sono delle chiamate HTTP normalissime.Come avviene la sincronizzazione? La sincronizzazione non è uno a uno, non c'è nulla di particolare in realtà.Tante istanze di CouchDB possono essere collegate tra di loro e formano un cluster di CouchDB.PouchDB, agli occhi del CouchDB, è un altro CouchDB, perché? Perché implementa il protocollo di comunicazione del CouchDB.Quindi tra di loro loro si vedono semplicemente come istanze remote di CouchDB.Il meccanismo di securitizzazione funziona perché se tu modifichi in locale un documento e una versione diversa dato a CouchDB, viene fatta una chiamata di aggiornamento, quindi BVIA, quindi chi dei due si aggiorna prima notifica l'altro che c'è stato un aggiornamento.L'istanza che riceve fa un diff internamente tramite un algoritmo ben spiegato sul sito di CouchDB per capire se quello che sta arrivando, quindi il dato, l'oggetto che sta arrivando, è effettivamente più nuovo o più vecchio rispetto a quanto già salvato.Se non riesce a capirlo e non riesce ad aggiornare i campi, pone in caso, entrambi nello stesso istante abbiamo modificato il campo name con due valori diversi, a quel punto quel documento finisce in conflitto e ci sono diversi scenari possibili, quello che è auspicabile che venga proposto all'utente che in quel momento sta usando il sistema, quale delle due versioni è quella giusta.L'altra particolarità che fa funzionare il tutto è che è un contatto based-upend only, quindi lui non rinfiazza i documenti, ma il documento finale è una...è diciamo una...una vn versione ennesima del documento finale.Esatto, che però è dedotta da tutte quelle precedenti e c'è un meccanismo di compatazione ovviamente una sorta di event sourcing esatto è una sorta di event sourcing ancora più distribuito e comunque un po' con meno constraint quindi un po' più stupido però è proprio questa la sua potenza infatti ci riusciti a avere un'implementazione praticamente perfetta anche nel browser perché PowsDB ripeto implementa il protocollo di CowsDB ha quasi tutte le funzionalità di CowsDB in locale Come funziona l'ACL, chiamiamola così, o comunque il sistema di permessi? È integrato dentro al CouchDB, quindi c'è una collection di users che contiene gli utenti, i quali hanno proprio delle credenziali, quindi username e password, che sono salvate in un database e nel quale oggetto utente puoi salvare cosa può fare all'interno della piattaforma.Il tutto funziona, per una cosa molto brutta e molto poco intuitiva a chi non è abituato, tramite delle funzioni MapReduce, quindi in realtà il database in sé, quindi non l'istanza del server, ma proprio il database finale, non è come su Mongo che ogni collection rappresenta un'entità diversa e quindi magari possiamo avere i blog post e i commenti.In CouchDB tutto finisce nello stesso Calderone, che semplicemente si chiamerà blog.Ed è a livello applicativo che lo sviluppatore decide cos'è un blog post e cos'è un blog comment tramite delle funzioni di MapReduce, che a loro volta producono delle liste che permettono di essere...che poi sono lo strumento tramite il quale querare il database.Quindi secondo me la difficoltà nell'usare ChaosDB è perché è completamente diverso da tutti gli altri database che conosco, è il suo maggior...il suo più grande punto di forza, che è la sincronizzazione, praticamente, real-time su infinite repliche, è anche il suo maggior problema per gli sviluppatori, perché è difficile domare.- Immagino.E a questo punto mi viene da chiedere se...Hospital Run, praticamente...correggimi se sbaglio perché non sono andato a spulciare i documenti architetturali per cui buona parte dell'attività sta nella parte front end, nel lato front end che ha l'interazione con paoCDB giusto? sì e qual è allora il ruolo invece della parte back end che poi avete implementato con fastify e ci farai un po' da cicerone no? in questo mondo.Però qual è il ruolo della parte proprio back end? Essendo alla fine un sistema che permette di amministrare gli ospedali o comunque delle piccole medie cliniche, c'è tutto un discorso molto importante riguardante la comunicazione del software, quindi di Hospital Run, con gli altri software che si occupano di gestione di cartelle elettroniche oppure di documenti per la sanità.Tutto questo enorme capitolo si chiama HL7, è uno standard internazionale al quale più o meno aderiscono tutti i vendor che fanno il software per gli ospedali o comunque per la sanità e che è una lingua franca che permette di querare in qualsiasi sistema che lo imprimenta e avere delle informazioni in una forma standard, in un file JSON banalmente, dove i campi però appunto sono molto ben definiti all'interno dei documenti pubblicati ogni anno e quindi quanti più player cercano comunque di adeguarsi.La parte server serve proprio a questo, quindi da un lato l'istanza server di Hospital Run, come diciamo prima è un server Fastify, che non fa altro che fare da proxy per il CouchDB, quindi tutte le richieste che arrivano su un certo endpoint /db, Fastify le prende e le in strada verso CAUSDB, che poi sono quelle per far funzionare il front end di Hospital Run.L'altra parte che fa Fastify è quella di esporre tutte le risorse servate dentro al CAUSDB nelle API HL7, FHIR, che è l'ultima versione di questo standard.Quindi Sicuramente l'utente finale che usa l'interfaccia non se ne preoccupa e potrebbe funzionare anche senza, infatti in questo momento funziona senza Fastify e senza il server, ma nel momento in cui si va in produzione diventa assolutamente fondamentale perché permette di fare queste operazioni.Inoltre, è nostra intenzione sviluppare un sistema di autenticazione anche esterno, quindi Active Directory o altri provider esterni o auto, quello che è, che permettano di generare un token di autenticazione all'interno dell'utente di CouchDB che ha fatto la richiesta in modo tale da avere un single sign on.Anche per questa parte qua Fastify è assolutamente fondamentale e non possiamo fare a meno di una parte server.domanda fastify è un framework che sto vedendo sempre acquistare sempre più scena no all'interno del mondo dei server back end su node qual è il motivo che vi ha spinto a utilizzare questo questo framework e quali sono i vantaggi che questo framework da rispetto alternative come può possono essere insomma l'express della situazione? Allora nel caso di ospita run diciamo che la scelta è stata dettata da me che sono un grande grande fan di fastify perché sono un grande fan di fastify perché risolve a meno per me risolve in maniera ingreggia un grande problema che è quello del poter scrivere dei server, quindi il codice che poi gira sul server, in maniera "backup" cioè staccata e avviabile in modo indipendente.Generalmente lavoro nel mondo dei microservizi, quindi quando sviluppo qualcosa in realtà non ho più monoliti da tanti anni e quindi mi serviva uno strumento che mi potesse permettere di cominciare con un monolite strutturato in un certo modo e quando il il domain di una specifica parte dell'applicativo diventava […] il diventare un microservizio, staccarlo e farlo girare da solo.Questo in Fastify è molto facile grazie al sistema di plug-in.Quindi Fastify ha un sistema di plug-in veramente unico nel suo genere che permette di scrivere codice riusabile è organizzato in maniera ottimale per un mondo distribuito, chiamiamolo così.Tant'è che recentemente addirittura...L'altro sistema di plugin che se non mi sbaglio si chiama Avvio, quindi un nome italianissimo, no? Sì, perché l'ha scritto Matteo Collina e spesso i suoi pacchetti hanno nomi italiani, undici e tanti altri, sì.Avvio è esattamente il sistema che poi permette l'avvio di Fastify ed è quello che carica i vari plugin e capisce come avviarli.la particolarità di Fastify di avvio è che fa tutto in maniera assincrona, che è un'altra cosa che non si era vista prima.Quindi tutti i plugin vengono caricati in modo assincrono e possono essere eseguite operazioni assincrone durante l'avviamento del server, ma l'istanza finale di Fastify, quindi il server principale, verrà avviato solo nel momento in cui tutti i plugin sono stati effettivamente caricati e quindi tutti i controlli possono essere fatti prima che l'avvio sia avvenuto.E sei sicuro che una volta che l'istanza del server si è avviata il tutto è funzionante e funzionale.Guardavo anche dei benchmark e fastify si comporta più che egregiamente rispetto ad altri framework, è una cosa che ha catturato l'attenzione.Sì anche il nome tra l'altro è stato scelto proprio per indicare questa cosa qua però si è accorto che poi le persone o comunque i sviluppatori lo vedevano come la principale caratteristica del framework.In realtà è una delle cioè sicuramente Assolutamente il core team ha come priorità quella di mantenere la velocità attuale, quindi lasciarlo posizionato dove è, tra i più veloci se non il più veloce, ma la developer experience in realtà è quella che la fa da padrona.Quindi anche durante le modifiche o comunque durante le PR o comunque durante il lascio di nuove versioni viene sempre preso in esame se quanto fatto incide in maniera negativa sulla developer experience.una delle cose che ho visto in giro con guardando anche delle piccole prove fastify l'ho provato diciamo che dovrò tenere un corso a breve e gli esercizi la parte back end l'ho provata su fastify.Una delle cose che ho notato spesso utilizzata è il JSON schema nelle rotte.Intanto cosa sono i JSON Schemas e soprattutto quali sono i vantaggi che questa tecnologia di validazione e serializzazione ha, i vantaggi che porta appunto nella validazione e nella serializzazione delle richieste? Allora innanzitutto hai fatto bene a introdurre l'argomento perché è un'altra di quelle cose molto importanti secondo me che lo distinguono rispetto al competitor per per quanto anche altri, come ad esempio HappyJS, facciano qualcosa di simile.La particolarità di Fastify, di nuovo, è che è integrato a Out of the Box, cioè uno sviluppatore non deve fare nulla, anzi, è usato internamente da Fastify per renderlo così veloce.Cosa sono i JSON Schema? Sono un insieme di...innanzitutto è un JSON, quindi un file JSON, quindi deve essere un file JSON valido, che descrive lo shape di un oggetto JSON.Perché è importante? Perché ti permette di descrivere campo per campo del suddetto oggetto qual è il tipo e quali sono i constraints dello stesso.Quindi ad esempio un campo può essere stringa, deve rispettare un certo pattern di regular expression, non deve essere più lungo di così, eccetera eccetera.Come viene usato il JSON schema da Fastify? Ogni rotta in Fastify può, opzionalmente ma è candamente consigliato, avere anche agganciato un JSON schema che descriva il payload in arrivo, quindi banalmente il body nel caso di richiesta JSON, oppure anche i parametri passati come query string e anche altre cose, ma non approfondiamo perché dopo diventa troppo complesso.Comunque, permette di agganciarci a ogni rotta un JSON schema che descriva il payload.Inoltre, sempre agganciando la rotta, si può anche impostare quanto la rotta tornerà.Quindi, qual è lo shape dell'oggetto che verrà ritornato dalla rotta.Questo è internamente usato da Fastify, tramite un pacchetto sviluppato dal team che è FastJSON Schema, o JSON Fast Schema, non mi ricordo mai come si chiama, che appunto sapendo già in anticipo come è fatto il payload, è molto più veloce a fare la serializzazione in JSON della risposta rispetto al JSON stringify classico.Per quanto riguarda il payload in entrata, il JSON Schema serve per fare proprio la parte di variazione, quindi viene usato da un lato nella risposta per la serializzazione, per farla molto veloce e giusta.D'altro canto, durante la richiesta iniziale viene usato per validare quanto sta arrivando nel payload.Se qualcosa non torna viene proprio trovato un errore di tipo validation error con spiegati quali sono i campi che non corrispondono rispetto alla descrizione fatta tramite JSON schema.E questo è un vantaggio averlo out of the box no? Assolutamente un vantaggio ed è perché ci siamo accorti che tanti sviluppatori magari prima non lo facevano ma vedendo la documentazione di Fastify da un lato ed essendo così facile farlo lo usano perché poi...Io ricordo che validavo tutto a mano con Express nel primo periodo che lo usavo.O cercavo soluzioni...Esatto più che altro bravo, cercare soluzioni che qua non devono essere trovate nel senso che c'è nella guida ufficiale di Fastify un capitolo enorme sulla validazione e serializzazione.Ti faccio un'altra domanda, questa è una curiosità.Che differenze vedi poi da una persona che lo usa tutti i giorni? Una soluzione che utilizza nel backend Fastify e una soluzione che utilizza un Apollo server con GraphQL? Allora, proprio recentemente mi è capitato di dover implementare delle API GraphQL.Generalmente lavoro in RESTful, sia nel progetto open source, perché alla fine CouchDB, come vedevamo prima, è REST, sia nel lavoro perché è tutto lo stack di evaluajebrad.us sul REST.Recentemente proprio mi sono approcciato alla questione GraphQL e in realtà, sempre il buon Matteo Collina, ha scritto un plugin per Fastify che si chiama Fastify-GQL, che implementa in Fastify un server di fatto GraphQL.Rispetto a una soluzione come Apollo non saprei dirti perché non l'ho mai usata in maniera approfondita, a parte quattro test fatti dal loro sito.Però posso sicuramente dirti che l'implementazione del plugin in Fastify è davvero ottima perché risolva i problemi anche come quello di n+1, quindi query, quando hai il query anidata, e sono out of the box gestite grazie ai constraints impostati, perché anche quello, quindi ogni plugin ufficiale di Fastify viene scritto con un'ottica di attenzione alle performance e a non lasciare agli utenti la possibilità di sbagliare.Quindi c'è un occhio di riguardo, come sono prima la developer experience che passa anche da questo.La qualità diciamo dei plugin è generalmente molto alta.Ci sono anche dei plugin della community che comunque vengono più o meno validati da alcuni membri del team.Sì questo è quanto.Quindi non saprei risponderti rispetto a una follow server.Ok però adesso facciamo la domanda più simpatica.Diciamo che te l'ho già anticipata in pretrasmissione però volevo volevo chiedertelo di persone e condividerlo con la nostra community di github.In hospital run ho visto che hai optato o avete optato per un setup monoripo.La mia domanda è quali sono stati i vantaggi e quali sono stati i dolori pain points di questo approccio? Sono proprio gioie e dolori, se dovessi riassumere velocemente cosa vuol dire avere una monorepo è questo.Nel nostro caso tra l'altro una monorepo un po' diversa rispetto a quella di Babel ad esempio, che è un altro progetto grande che è stufato in monorepo, perché la nostra è sia monorepo dal punto di vista dei pacchetti che vengono pubblicati su su package diversi su npm sia sono dei sub modules git diversi, quindi abbiamo diverse repository git che vengono aggregate da una terza repository che è poi la vera monorepo.Perché monorepo? Perché il progetto era già strutturato in due parti, che è frontend e backend, anzi frontend e server si chiamava all'epoca, e quindi abbiamo voluto lasciare questi due progetti senza crearne uno nuovo su GitHub, quindi lasciare proprio le due repo esistenti.Inoltre, il fatto di strutturare la monorepo ci ha permesso di creare una terza repository, quindi non contenti delle prime due, ne abbiamo creato pure una terza, che è quella dei components, che sono i componenti poi usati, i componenti React poi effettivamente usati dentro all'interfaccia frontend, e abbiamo deciso di metterli in una monorepo.La monorepo ci permette di gestire di maniera agevole, più o meno agevole in realtà, la pubblicazione dei componenti da un lato, dall'altro dello sviluppo locale.Quindi se stai lavorando sui componenti, c'hai una cartella che è lì vicina e localmente viene importata quella, nel momento in cui fai il bundle e lo pubblichi, noi usiamo docker quindi docker image, possiamo affidarci a quanto pubblicato in remoto.Quindi diciamo che sulla carta la gestione a monoripo è sicuramente la soluzione migliore nel momento in cui hai diverse parti che condividono alcune cose, quindi la stessa codebase fondamentalmente usata in posti diversi, perché poi una quarta repo che abbiamo sempre a seguito è quella della shared library tra frontend e backend, nella quale sono finiti tutti gli schemi, che dicevamo per la validazione o comunque tutta l'interfaccia è TypeScript, perché un'altra cosa da dire è che è scritto in TypeScript.Quindi avere una monoripo ci permette una gestione veramente agevole.Quali sono i punti, diciamo, dolorosi? Innanzitutto questo approccio è poco conosciuto all'interno della community di sviluppatori, o almeno quelli che sono venuti in contatto con Hospital Run.Ci siamo accorti che molte domande, molti lì su aperti in realtà sono dovuti al fatto che poi lo strumento non è ben chiaro come debba essere usato.Ci capita in realtà, il lì su aperto in maniera più frequente è quello in cui si sono rotte delle dipendenze e non compila più.Perché non compila più e si sono rotte le dipendenze? Perché è molto difficile ad oggi essere sicuri di quale struttura effettivamente durante un'installazione avranno alla fine i vari node modules.Piccola premessa, per amministrare la monoripo usiamo Yarn Workspaces.All'epoca l'alternativa era TNPM Workspaces, sono i due player che potevamo scegliere.Perché non potevamo usare Learna, che di solito è il più usato? Perché all'epoca e soprattutto tuttora Learna non supporta i submodules di Git.Quindi per Learna, non esistendo questo concetto, non è capace di fare le cose che noi servivano.Iarn, Workspaces e PNPM lo riuscivano già a fare e riescono a farlo tuttora.Abbiamo votato per Iarn perché gestiva in maniera migliore una cosa che si chiama il no hoist.Cosa succede di solito nelle monorepo? Che quante più cose cercano, quante più dipendenze devono essere spostate top level, in modo tale che appunto anche esse siano condivise.a livello di monorepo si ha un unico node modules e poi per come funziona il commonjs di node, quindi con i vari require, in realtà tutto è a posto perché essendo parent vengono pescati da là.Ci sono dei casi nei quali questo non è vero, ad esempio TypeScript, tutta la toolchain di TypeScript, se non è installata nella cartella locale vicino al tsc config, vicino al package json del package della monorepo può dare problemi.Quindi lo stesso TSC, VSCode, ma anche anche il TSLint che usavamo all'epoca, oggi è SLint.Cioè tutta questa toolchain di sviluppo non è ottimizzata quando viene fatto l'hoist dei pacchi al top level.Siamo riusciti a farlo funzionare lo stesso perché appunto Yarn ci permetteva di usare specifici pacchetti, di setarli come no-hoist e quindi vengono installati nella cartella giusta del pacchetto giusto, nella norma giusta.Però tuttora, quindi a un anno di distanza, più di un anno di distanza, capita ciclicamente che io debba passare a ripulire nuove indipendenze introdotte che prima funzionavano e non funzionavano più, oppure ex-novo, semplicemente sono state aggiunte e non funzionano.Quindi questo è sicuramente un problema e personalmente sto tuttora cercando e stiamo cercando come più di me una soluzione e ad oggi non la trovo.Se non fossero stati dei Git submodules e se fosse stato tutto un'unica monorepo Git, monorepo proprio dei pacchi, sarebbe stato più facile a meno da quello che abbiamo potuto osservare perché l'herna è più intelligente a gestire queste cose però nel nostro caso appunto l'herna non era usabile ho molte speranze nell'npm workspace che è una feature che dovrebbe uscire con npm 7 non ho ancora avuto modo di guardarla ma veramente spero che abbiamo risolto siamo riusciti a risolvere il problema.Quali sono i vantaggi che ti ha portato bene la gestione e l'introduzione dei submodels? proprio nella gestione anche della stessa community e dei vari contributor che permette a un contributor che si occupa solo di frontend di clonarsi il locale, di forcarsi e clonarsi il locale soltanto la repo del frontend e quindi senza neanche avere tutte le altre lui può sviluppare e preoccuparsi solo del suo articello e questo è una cosa molto molto importante abbiamo visto perché appunto molti sviluppatori RARP che ci sono non sono affatto a vezzi né di toolchain di sviluppo complesse né della parte back-end né di tutta quella serie di operazioni che facciamo sulla CECD e che vengono fatte in maniera trasparente quindi permette allo sviluppatore di occuparsi solo di ciò che lo riguarda insomma.Insomma diciamo che vista da fuori può sembrare un lavoro quello del main maintainer semplice in realtà è un bel casino.è un bel casino che come dico sempre ha bisogno di una mano quindi per chi volesse contribuire a questo progetto cosa vogliamo dire ai volenterosi che Beh innanzitutto che si facciano un giro sul sito che è ospitarun.io che secondo me descrive i principi che sono alla base quindi non non tecnici ma proprio filosofici che sono alla base del software che secondo me in questo caso sono importanti e in secondo luogo che i contributor non bastano mai e che anche una riga scritta oppure una modifica alla documentazione che sembra inutile invece è molto preziosa.Sono più contento se devo fare la review di 200 pull request ogni mattina piuttosto che non vederne neanche una perché è importante ripeto anche un piccolo passo cioè il processo di sviluppo di progetti così grossi open source è fatto di piccoli passi quindi anche il più piccolo passo in realtà è un grandissimo passo verso la meta che nel nostro caso il rilascio della versione 2.Se in ascolto ci sono dei volentierosi che si occupano di server scritti in ODE e magari sanno cos'è Fastify, o anche se non lo sanno perché possono imparare la strada facendo, sicuramente sono i benvenuti.Fantastico.Prima hai detto che Hospital Run è un progetto incubato da OpenJS.Pensavi che me lo possessi dimenticato.[Risate] Cosa significa per un progetto andare sotto il cappello di OpenJS? OpenJS innanzitutto è una foundation che è il risultato della fusione, la JS Foundation e la Node.js Foundation che l'anno scorso sono fuse e hanno formato la OpenJS Foundation quindi è il cappello sotto il quale sono raccolti sia il front end che il back end banalmente del mondo JavaScript JavaScript.Dietro ci sono dei membri molto grossi che permettono le attività della foundation che sono Google, IBM, Microsoft e altri che adesso non ricordo e la OpenJS Foundation tra le iniziative che ha, le altre sono certificazioni o comunque riunioni dei membri, ha anche quella di aiutare dei progetti che per la foundation stessa sono strategici per l'evoluzione da un lato di java scritto e per l'altro della community che ci gravita intorno.Ci sono diversi tier che adesso non ricordo ma sono visibili assolutamente sul sito della OpenJS Foundation che è openjsapp.org.Ci sono diversi stage quindi di incubazione o comunque di aiuto, loro li chiamano hosted projects in inglese e in base al tier nel quale il progetto entra ha diversi benefit, ad esempio ospita run in questo momento dentro al at large projects che sono quelli considerati importanti e strategici per la per la foundation stessa e che hanno già un sacco di utilizzatori comunque hanno un impatto positivo non solo sulla community ma anche fuori della community.Per far capire a te, agli ascoltatori, allo stesso livello ci sono Ace Lint, Libuv, Express stesso, MomentJS eccetera.Quindi sono progetti comunque che tutti noi riconosciamo come importantissimi per l'ecosistema.La particolarità di Hospital Run è che è l'unico progetto che non fa parte della toolchain, non è rivolta agli sviluppatori.Per la stessa foundation è un progetto molto importante al quale tengono.Infatti nel momento del passaggio delle consegne l'anno scorso ho parlato con gli amministratori della foundation stessa, i quali mi hanno chiesto se vogliamo portare fuori o no il progetto, premettendo che per loro è molto importante, che continua esserci perché è unico nel suo genere.Ovviamente per me è giusto che sia OpenJS e adesso spiego anche il perché.In realtà la foundation garantisce che anche se dovesse succedere qualcosa a me, che sono l'in-maintainer in questo momento, io non potessi più occuparmi del progetto o tutti gli altri in-maintainer non potessero più starci dietro, garantisce che il progetto sopravviva, perché ad esempio il nome, il logo, il sito, quindi l'ospita RAM.io, nel caso di donazioni, la cassetta dove vorrebbero messe sono tutte gestite dalla fondazione stessa, che fornisce anche esperti legali o sviluppatori per aiutare i progetti a crescere ancora di più.Ad esempio, quando abbiamo scelto la licenza MIT per tutto il progetto lo abbiamo fatto anche consultando il legale dell'OpenJS Foundation, che in realtà è quello della Linux Foundation perché l'OpenJS è sotto il cappello Linux, che ci ha consigliato di usare questo e ci ha detto come fare in modo tale che il progetto possa rimanere di tutti, perché un'altra cosa importante da dire è che il progetto non è del lead maintainer, non è mio, non è di nessuno, è della community e deve essere così, dei contributors e di tutti quanti noi.Quindi l'attività che fa la OpenJS Foundation secondo me è di fondamentale importanza.Tra l'altro da quando si sono uniti hanno anche aperto a nuovi progetti, quindi in qualsiasi progetto abbastanza grosso può fare richiesta di entrare sotto questo cappello.Recentemente anche a stesso Fastify ne ha fatto richiesta ed effettivamente in questo momento è nell'incubation projects, quindi uno stage di incubazione, insieme a NVM che un altro l'ultima l'ultima edition che è stato fatto alla fondazione.Diciamo che non si tratta solo di un bollino per dire siamo importanti ma in realtà ha proprio un ruolo da garante nella vita del progetto.Anzi, proprio per rafforzare questo concetto tutti i progetti che ne fanno parte devono avere nelle proprie ripositori su github un documento, un markdown nel quale si specifica proprio tutto il processo che potrebbe essere fatto nel caso in cui debba cambiare il lead maintainer o nel caso in cui ci siano problemi all'interno della community.Quindi una sorta di statuto che tutti i lead maintainer devono firmare a cui devono sottostare.Quindi diciamo il tutto è globale e condiviso non ci sono cose nascoste e soprattutto in ogni momento è chiaro cosa si sta facendo se non lo fosse appunto chiunque può andare a rivolgersi ad OpenJS dire controllate un momento cosa sta succedendo con il progetto che c'è qualcosa che non va fantastico ho scoperto una cosa nuova perché in realtà conoscevo OpenJS ma non ho mai approfondito i processi...Anche io non li conoscevo prima di entrare in questo mondo e secondo me anche quello potrebbe essere visto come un problema di comunicazione perché comunque è un'altra di quelle entità create per la community e pochi pochi sanno che in realtà esiste o cosa fa.Qual è il suo ruolo? Sì.Maxi io cosa ti devo dire non posso far altro che ringraziarti, ci hai accompagnato a esplorare un mondo che è un mondo bellissimo non solo per la varietà tecnica dello stack che utilizzate ma anche per il grandissimo valore etico del progetto che ripeto dal mio punto di vista anche anche sul livello personale è uno dei parametri che personalmente mi cattura più l'attenzione quindi io ti ringrazio a nome mio e a nome della community di Gitbar per lo sforzo che stai facendo tu e tutti i contributor del progetto ti ringrazio anche per essere venuto a farci visita sapi che Gitbar è anche un po a casa tua quindi quando c'è qualcosa da raccontarci scrivimi e mi fa immensamente piacere farmi un'altra chiacchierata con te.Grazie tante, sicuramente non mancherò e secondo me la divulgazione che fai è importante perché la comunità italiana ne ha bisogno quindi approvo assolutamente quanto fai e mi fa veramente molto molto piacere raccontarti il mio piccolo cosa faccio quotidianamente quindi grazie ancora.Bene abbiamo ascoltato Maxim Sinek questa volta spero di non aver storpiato nome e cognome noi ci diamo appuntamento la prossima settimana sempre qua su BipBap non ci muoviamo però come sempre prima di lasciarvi alle vostre faccende vi devo ricordare i contatti anche perché i contatti sono un elemento importantissimo che mi permette di chiacchierare con voi quindi potete iscrivermi a @brainrapper su Twitter o a info@gitbar.it se l'episodio vi è piaciuto mi raccomando aggiungete Gitbar nel client di podcast che preferite se proprio poi vi è piaciuto tantissimo beh lasciate una recensione su iTunes Store o sull'applicazione podcast di Apple questo ci aiuterà ad arrivare a più persone possibile detto questo io vi do appuntamento alla prossima settimana ringraziando nuovamente Maxim noi ci sentiamo giovedì prossimo e nulla alla prossima GitBar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web di metodologie e degli strumenti mancabili nella cassetta dei attrezzi di full stack dev
