Opala stiamo registrando stiamo bellissimo ciao a tutti bene e benvenuti su github nuova settimana e nuovo episodio qua sul nostro bar degli sviluppatori allora io mi sento un po' così un po' shakerato perché registrare github di mattina non è cosa usuale però ci sta siamo ancora più più energici più freschi quindi la puntata verrà veramente come uno tsunami anche perché non ve lo svelo ancora ma abbiamo qua con noi un amico, un amico.Prima di salutare l'amico che è venuto a trovarci ha berso una birra alle tipo le 10 del mattino che suona malissimo, diciamo un caffè ma è meglio.Saluto Leo e Luca che sono anche qua.Ciao Leo, ciao Luca, com'è? Ciao ciao buonasera buonasalve buon fluido a tutti bene bene appunto è mattina quindi non possiamo bere quindi ottimo.Ma cos'è sta storia che non si può bere di mattina? Un petaggio di qualche anno fa non lo so nemmeno io.Ciao a tutti io sono già la terza birra che sono le 10 di mattina.Vabbè tu vivi a nord sei a un passo dal Trentino la si fa si va di grappa Alto Adige, ma che le pivreranno bene Comunque, bando alle ciance, di cosa parliamo oggi? Oggi parliamo di un argomento che mi interessa tantissimo, mi interessa talmente tanto che in realtà qualche tempo fa ho fatto sul topic in generale un post anche sul mio blog, che non spoilerò andatevelo a vedere se vi interessa dove parliamo di una commistione tra code, no code, half code, framework, meta frame...insomma io non ci ho capito niente 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 [Musica] Per spiegarci un po' come ci si posiziona in questo mondo abbiamo, come dicevo, un amico, un ex collega, il grande Matteo Collina.Ciao Matteo! Ciao, ciao Mauro, ciao ragazzi.Come state? Tutto bene? Leonardo ti vedo tutti i giorni? se non stai bene mi preoccupo, le cose sono peggiorate dalla sera alla mattina però no tutto bene tutto bene la grandissima abbiamo visto che negli ultimi mesi hai fatto uno sprint con il nuovo progetto nonché la nuova azienda che hai lanciato ormai è più di qualche mese Abbiamo annunciato la platformatic incorporated a settembre, abbiamo rilasciato il nostro primo progetto open source, abbiamo iniziato a fare un po' di cose, un po' di public relations, un po' di developer relations eccetera eccetera e le cose stanno andando relativamente bene, perlomeno relativamente nei piani.Tutto molto bello, tutto molto bello.Diciamo che l'azienda è nata a metà giugno, più o meno tra giugno e luglio dell'anno scorso, abbiamo cominciato a lavorarci per tempo pieno e poi abbiamo annunciato adesso, abbiamo annunciato prima e facciamo una launch week tra due settimane.Quindi cioè nel senso che dovete annunciare roba nuova tra due settimane, che Leonardo è qui e non sta sviluppando, quindi insomma ci sono dei problemi.Oppure va così bene che è tutto fatto, non lo so.Come sempre, immaginate che Leonardo è un mio collega, quindi giochiamo un po' in casa con Gitbar.Sì, ma oggi sono solamente host, quindi te sei l'unico ospite.comunque io ti metterò sulla griglia tutto il tempo sappilo perché mi hai coinvolto in questa cosa ieri quindi tutto al volissimo capito? Sì, diciamo chiamata tipo alle dieci e mezza di sera preso in contropiede.Matteo volevo farti una domanda prima di iniziare a parlare di platformatik però.Tu hai fatto tantissimi anni come consulente nel mondo Node.js.Sì.Oggi ti ritrovi a sviluppare per quanto sia open source un prodotto e anche a costruirci un'azienda sopra.Cosa è cambiato? Svariate cose.La prima è...io ho fatto professional services per Probabilmente la maggior parte della mia carriera, circa dieci anni, ho fatto Professional Services e oggettivamente parlando un cambiamento ci stava.Ho stato otto anni e mezzo in Near Form e per vari motivi mi stava relativamente stretta e quindi un cambiamento ci stava.Questo è il primo aspetto, un aspetto in cui tanti si riconoscono.fa lo stesso lavoro tanto tempo.In cosa consisteva il mio lavoro? Il mio lavoro principalmente consisteva nel parlare con gente, con aziende, sviluppatori che usavano Node.js e date queste cose, prendere il loro feedback e aiutarli nel risolvere i loro problemi e nell'usare queste tecnologie al meglio, semplicemente migliorando la produttività del team, piuttosto che i tempi di sviluppo, la fidabilità e tutto quanto.Usare la tecnologia che avevano scelto al meglio.Cosa è successo? È successo che mi sono reso conto che alla fine della fiera io dicevo sempre la stessa cosa a tutti.E nessuno ascoltava tra l'altro.nessuno ascoltava, ma io le dicevo anche pubbliche, nel senso proprio nel 9 su 10 le cose le ho sempre dette, quelle che dicevo privatamente ai clienti sull'estesi, le ho sempre dette pubblicamente nei miei talk, qualcuno ascolta, ma tante aziende no, relativamente no, tanti No, principalmente perché vanno a leggere quello che è il tutorial di ExoExpress del 2012/2013/2015 o il corso su Udemy di quegli anni lì, che ha milioni di views.Ma è vecchio, è roba… non si fanno più le cose in quel modo lì per farle fatte bene.La tecnologia è spostata e quindi danno retta a queste tipologie di cose, seguono questo tipo di trend, sviluppano cose in maniera subottimale e alla fine della fiera si ritrovano con una bellissima matassa di spaghetti code che non è poi gestibile in produzione.E io poi mi trovo a dire sempre la stessa cosa a tutti, come si risolve questo problema? o come si evita questo problema di avere in prima battuta.Che cosa è successo? Parlando con un mio caro amico Luca Maraschi negli anni ci siamo resi conto che anche lui aveva più o meno lo stesso tipo di ragionamento, che stava vedendo le stesse cose e abbiamo detto che Riusciamo a prendere questo know-how che abbiamo di come si sviluppa software in JavaScript, server-side, fatto bene, e sviluppiamoci un prodotto sopra in modo che io non debba andare in giro a ripetere le stesse cose a tutte le aziende che hanno i soldi per pagarci, ma possiamo fornire questo tipo di know-how, di esperienza in maniera molto più affordable se vuoi, per quello che riguarda la maggior parte delle...per quello che riguarda...sostanzialmente per migliorare la qualità di vita degli sviluppatori, ecco, se vogliamo.Ed è un po' il mio filo conduttore.Io ho sempre fatto cose, sviluppato software open source eccetera per migliorare la qualità, per migliorare l'esperienza degli sviluppatori, migliorare come i sviluppatori fanno software.In un altro modo, rendere la loro vita meno miserabile.Io non so quanti di voi hanno scritto per lavoro degli xlst, ecco quello è veramente una brutta vita miserabile.Se tu uno ha scritto degli xlst direi che più o meno ha toccato il massimo possibile fondo della developer experience.Peggio di quello non c'è nulla.Forse il Cobol.Ma secondo me il Cobol è meglio.Ho una visione del mondo che secondo me il Cobol è meglio di quella roba lì.Sono abbastanza convinto che il Cobol sia meglio.Quella roba lì è veramente brutta.Il Cobweb è stabile perlomeno, l'editor di quella roba lì crashava ogni 3x2 per DeFi, cioè una roba atroce.Però il mio lavoro è sempre stato quello di sviluppare tecnologie che consentissero agli sviluppatori di avere una vita migliore.Questo che cosa ha portato a noi? ha portato prima di tutto a Fastify, quando mi sono accorto che c'era un problema nello sviluppo backend in Node.js e quindi ho cominciato a svilupparlo nel 2016 con Thomas.Fastforward adesso è un progetto established, mi davano del pazzo più o meno quando ho cominciato a fare quella roba lì ecco e invece ha funzionato ecco nel senso sono molto molto contento siamo arrivati a abbiamo passato la soglia del milione di download alla settimana e io sono molto contento ecco questo è da mangiare a tanta gente mai compreso tra la gente che ha visto questo è è open source gratis, usalo, funziona bene, capito? e soprattutto non ti esplode, non ha un po' di mine all'interno come può avere oggi la community express, ecco, quindi molto meglio.Detto questo, questa è la prima cosa.Cos'altro? non voglio entrare troppo nel discorso express, ecco tutto E mi vedete bene? Vedete un po' di scatto dal mio lato? Ma forse no? Noi ti vediamo perfettamente.Passaggio da Fastify poi a Platformatic? Ah! Il passaggio è stato abbastanza come dicevo lineare.Fastify è opinionated ma è molto comunque molto molto freeform.Nel senso che tu puoi usarlo per fare quasi qualunque cosa, strutturare le tue applicazioni come preferisci di più.Uno dei principi cardinali di Fastify è "If it can be a plugin, it should".E quindi tutte le cose vengono estratte in modo da renderlo il più possibile agnostico, se vogliamo, ad alcune scelte architetturali.O in altri termini mi rendo conto che le mie opinioni sono abbastanza strette su alcune cose Tanta gente vuole corda per impiccarsi e io normalmente sono il primo che dice "Tieni tutta la corda che vuoi".Non so che stai facendo una roba che non dovresti farla, forse lo sai anche tu, ma puoi avere, se vuoi, è una tua scelta.Io di certo non sono qui a fermarti.Anche perché non è detto che io sia sempre nel giusto, ecco, magari posso anche prendere delle grosse cantonate, per cui una scelta potrebbe essere, un'altra scelta architetturale di come usare Fastify potrebbe essere migliore.Ed è successo in alcuni casi con dei plug-in e delle cose che hanno portato poi ad avere l'API attuale di Fastify, ecco, per cui è stato un approccio molto utile negli anni.però mi sono reso conto che quello che la community chiedeva e mi continuava a chiedere ogni 3x2 era appunto di avere un po' più di linee guida, un pochino più di struttura come usiamo queste tecnologie per sviluppare un API, un backend solido? e quindi in una grossa fetta di platformatic parte da questo fornire un'ottima developer experience, un ottimo project setup se vogliamo pur essendo sostanzialmente production ready.Questo spesso e volentieri per tanti punti di vista non c'è oggi sul mercato o se c'è è molto opinionated, per quanto sia è opinionated ma non troppo c'è roba molto peggio dal mio punto di vista per esempio non so se avete seguito le evoluzioni, tanto per tirare una frecciatina, a framework e approcci concorrenti ad esempio se avete sentito quello che sta succedendo con i decoratori di TypeScript in TypeScript avete sentito che c'è questa sintassi che potete usare i decorator di TypeScript perfetto ben ritornati nel mondo Java degli anni A me i decoratori in general piacevano, quindi devo dirti la verità, a me non mi dispiace più di tanto.Cosa è successo però con TypeScript? Quello che è successo è che TypeScript ha reso popolare i decoratori, prima che venissero standardizzati da TC39, che è l'ente regolatore di JavaScript, quello che standardizza ECMAScript, che poi è il linguaggio che usiamo tutti i giorni.e cosa è successo? la specifica dei decoratori che è arrivata ora a stage 3 nel linguaggio è incompatibile con quello che TypeScript aveva fatto per cui tutto il software che è stato scritto usando i decoratori di TypeScript non sarà valido JavaScript nel medio e lungo periodo, che è uno dei principali problemi di lingua, uno dei principali punti cardine di TypeScript, tra virgolette, è che è sempre Java, cioè è un superset di JavaScript, ok? Però usare quello ti porta ad essere fuori dalla, se vogliamo di essere incompatibile con con JavaScript stesso e per cui è un problema significativamente importante per tutti questi framework che hanno usato questo tipo di approccio negli anni.Per darti un esempio di cose di questo tipo.Quindi cosa è successo con Platformatik? Tornando a Platformatik, io mi sono reso conto che mancava un sacco di...sostanzialmente mancava tutto un approccio di tipo più simile a quello che a rubin rails ok c'è il vantaggio di rubin rails è che io ti do i binari tu vai sui binari è un high speed train ti muovi a cannone dopo di che qual è il problema di rubin rails ovviamente è che tu sei sui binari però per arrivare a la tua destinazione a un certo punto devi scendere dal treno andare a piedi e questo è un po' il problema di Ruby on Rails e a molti dei framework fatti in quel modo.Quello che voglio ottenere con Platformatic è, al contrario, il successo di Node, se vogliamo, è l'antitesi di questo.Il successo di Node è "no no ma io non ti do il high speed train, io ti do la 4x4 e la 4x4 va dappertutto, va nell'autostrada, va sullo sterrato, va dappertutto, vai più piano che con l'high speed train, però non è detto che per dove devi arrivare magari riesci a fare una strada che ci metti molto meno, perché in realtà sei sul 4x4, Di là poi sei a piedi, quindi quando tu arrivi alla stazione sei arrivato.Poi sei a piedi, ti devi tirare la valigia, successivamente ti lo dai in spalle e camminare.Con la 4x4 vai dove vuoi.Il successo di Node deriva da essere una 4x4.Quello che vogliamo fare con Platformatic è unire questi due approcci.In che modo? in che modo? Non so se avete sentito i progetti futuristici di Elon Musk che vuole fare con Hyperloop, che carica le macchine nei tunnel e le spara e le sposta molto velocemente.L'approccio è esattamente questo.Quello che vogliamo fare è far sì che tu non sali a piedi sul treno tu sali con la tua 4x4 così poi quando arrivi alla destinazione puoi prenderti la tua macchinina e andare dove vuoi.Ho altri termini ma sai che c'è? Quando arrivi c'è già la macchinina pronta che puoi prendere, arrivi in stazione c'è già la macchinina pronta e puoi prendere che puoi prendere per andare dove devi andare.In che modo lo facciamo? In che modo Platformatic reaggiunge questo? Prima di tutto ha due componenti, uno è Service e l'altro è Platformatic DB.Service sostanzialmente è uno componente molto barebone che ti fornisce esattamente lo scheletro della tua applicazione, in particolare ti dà cose del tipo un health check già inconfigurato.9 su 10 dei progetti che ho visto non è in grado di configurare un health check.Lo sai bene Mauro, capito? Non si capisce come mai.Tu fai un health check, implementi un health check, però al primo incident l'health dice "va tutto bene", e però l'autoplicazione non funziona, che è la cosa peggiore che tu puoi avere da un'altra parte.Non vuoi avere un falso positivo, vuoi avere al massimo un falso negativo.L'health dice le cose non vanno bene e poi vai a guardare.Questo è un aspetto fondamentale.L'altra cosa che è ottima invece e su questo poi abbiamo anche integrato la compilazione automatica di TypeScript, la gestione delle configurazioni, le variabili di ambiente, tutto questo tipo di cose che richiede sostanzialmente una settimana.Se dici "Ci metto una settimana e sono fatte bene" il problema non è che ci metti una settimana e sono fatte bene, il problema è che la gente ci mette una settimana e poi sono fatte male.Per darvi un esempio della cosa più orribile che tu non puoi avere in un'applicazione Node.js, ma non solo, varie cose.La prima cosa è l'utilizzo no-dev per selezionare l'environment.Non so quante ne avete viste, l'utilizzo di no-dev è una delle cose più brutte che possano essere aperte a parentesi no deve stato inventato da express non da node quindi non c'entra niente no da no da descorev non c'entra niente con no js è stato inventato da express e poi usato in altre librerie ma non no js non conosce il concetto di node anders con e non va usato sostantemente lo deve sti mettere a production quando sviluppi e togliere da e spegnere quando finisce.Tutte le librerie dovrebbero sempre girare in production mode se vuoi ok perché se no poi non sai come sta andando nella pratica, come le cose stanno andando in realtà.Qual è l'altro aspetto? Oppure caricare i file di configurazione, le configurazioni degli ambienti.Ah ma c'è un file di configurazione che si chiama staging development altre cose completamente sbagliate, capito? dall'inizio, da subito e tantissime aziende sbagliano queste cose, tantissimi team sbagliano queste cose e magari perché seguono un bellissimo tutorial online, ma come dicevo io ce l'ho con un po' con...diciamo che la barriera di ingresso dei produttori di contenuti è molto bassa, richiede oggettivamente veramente poco effort per creare un video o scrivere un blog post e pubblicarlo.O anche preparare un corso e metterlo su una piattaforma.Il problema è che se anche dici delle cagate pazzesche, perché poi usiamo le parole come sono, dico gente che dice delle cagate pazzesche questi corsi, queste cose, tu i sviluppatori che si approcciano a queste tecnologie per la prima volta cosa succede non sanno cosa c'è si fidano di sta gente.Specie in un mondo frammentato e vasto come può essere quello javascript dove non hai una documentazione di un framework specifico come può essere spring o spring boot che ti dice le cose si fanno così punto e basta o se in go dove ti dicono le cose si fanno così punto e basta perché l'ha detto Pike.Godice dice una cosa ancora peggio.Non perché ha detto Pike.Perché se non lo fai sei stupido.È vero.Ok il vero purista go ti dice si fa così se no se tu non capisci le variabili a un carattere sei stupido.Questo ti dice ti dice lo dell'ecosistema.L'ecosistema io non riesco a.Hai puri con i puristi go faccio veramente fatica a rapportarmici perché abbiamo uno schema di valori completamente diverso.Per cui per me bisogna aiutare gli sviluppatori a produrre di più, non dirgli che sono degli stupidi.Questo mi dispiace, ma non mi troverò mai d'accordo con le persone che dicono "Ah, non capisci le variabili da un carattere e sei stupido", ma non ti ricordi quando non le capivi neanche tu? Ok, nel senso sei nato imparato, se sei così intelligente sei nato imparato, pazienza.Matteo, volevo chiederti, hai parlato un po' della parte barebone dell'applicazione platformatik, però una delle componenti principali, se non pillar, che ottimizza un sacco di effort in fase di sviluppo è tutta la parte di platformatikDB.Yes.Allora, come è nato PlatformaticDB? Ok, PlatformaticDB nasce da un problema reale.Ok, abbiamo poco tempo, dobbiamo sviluppare tante cose.Ok, vogliamo svilupparle velocemente e voglio avere qualcosa che mi rimuove tutta la parte di lavoro scomodo, tra virgolette, o ripetitivo.PlatformaticDB nasce come idea anni fa, nella pratica è nato tra giugno e luglio e abbiamo cominciato a sviluppare questo software che è dati gli schemi sui database, tira su, delle query di introspection e date queste query di introspection crea delle API dello scaffolding se vogliamo.Non genera codice perché il codice genero io sono abbastanza contrario all'approccio dei generatori di codice.È sempre perché se ti genero del codice poi l'ho generato oggi se te lo genero con un baco io non te lo posso fissare.Quindi te lo devi fixare.O non hai bisogno che te lo generi e te lo puoi scrivere, o alternativamente forse è meglio se ti do qualcosa che non hai bisogno di rigenerarlo.Questo è un po' il problema di tutti i generatori di codici per me.Lasciano secondo me il tempo che trovano, che in molti casi l'evoluzione di questi generatori di codice è che si genera un po' di codice, ma in realtà il 90% del lavoro viene fatto da una libreria sotto banco che gestisce tutto.Uno di questi casi era per esempio in Create React App, c'era questa libreria che si chiama React Scripts, che faceva tutto lei sostanzialmente.Loro ti generavano del codice, ma era principalmente solo cose buttate lì ma nella realtà era veniva tutto fatto da una libreria da una libreria sotto banco ecco perché altrimenti mantenere tutto quel boilerplate come codice generato è veramente difficile.E poi c'è anche un altro fattore importante che il code generator ti velocizza in fase di generazione codice però quel codice rimane là come dici bene non può essere mantenuto ma le specifiche e le logiche di business e i requirements cambiano quindi quel boost iniziale ce l'è solo all'inizio quel boost quella cosa grazie ce l'è solo all'inizio l'approccio l'approccio di platformatic db è su due se vogliamo è a due step il primo step è appunto tu mi dai lo schema, io ti prendo lo schema e ti creo dell'API basic, più o meno CRUD, se vogliamo, per leggere e scrivere sul tuo database da un'applicazione web.Quindi sia OpenAPI che GraphQL in relativamente zero tempo.Tu scrivi una volta che hai lo schema, addirittura chiedi a chatGPT di farti lo schema, butti lo schema in una migration e hai finito.Magicamente tutto funziona, anche se poi ti fidi di ChargPT.Io lascio questo punto di domanda ai posteri.e quindi cosa succede? succede che abbiamo un...che noi appunto creiamo queste API, Open API, con OpenAPI e GraphQL, quindi hanno tutti i loro schemi, i loro tipi.Tu puoi prenderli, prendere queste cose che generiamo e metterle nel tuo generatore di codice front-end o in qualunque altro "posto" dove queste API possono essere utilizzate.Qual è però lo step successivo? Lo step successivo arriva quando tu devi in realtà aggiungere della business logic.E si possono aggiungere della business logic in due modi sostanzialmente.Il primo modo è aggiungo delle nuove rotte semplicemente o aggiungo dei nuovi resolver.Aggiungo dei nuovi resolver viene automaticamente inserito dentro il mio OpenAPI, il mio GraphQL non devo fare niente.Ok è tutto molto carino.Invece cosa succede? se devo andare a se devo andare invece posso anche andare a modificare le rotte e le cose esistenti come lo faccio? lo faccio tramite i concetti che noi chiamiamo "hook" mi piace molto questo termine e quindi tu in realtà è una catena di molto simile a quello che è un middleware Viene ispirato al concetto dell'aspect oriented programming, in realtà l'avremmo potuto chiamare aspect ma se poi lo chiamavo aspect non aveva un grosso appeal nel pubblico, quindi è stato chiamato hook.In sostanza tu aggiungi una funzione che ti wrappa il comportamento interno, per esempio della save, di una chiamata save.In questa cosa ci puoi aggiungere l'autenticazione o ci puoi aggiungere altri side effects che devono succedere all'interno di quella chiamata.Per esempio, puoi far partire una transazione e fare la chiamata originale più creare altre due o tre entità secondarie sul mio database perché mi servono che tu crei altre due o tre entità secondarie sul mio database a seguire.Questo approccio lo faccio vedere abbastanza bene nei video che ho fatto, che sto costruendo questo semplice coda, la scalable queue system.Lo sto facendo su Twitch, siamo puntata 13-14 mi ricordo, e abbiamo costruito un sistema.Adesso abbiamo implementato, nell'ultimo step, abbiamo implementato le lezioni del leader.e tu ne puoi far partire quanti ne vuoi, viene eletto un leader ed è quello che poi scoda ok funziona molto bene.Mettiamo nelle note dell'episodio tra l'altro immagino che in questo modo tu possa anche triggerare un certo evento quindi fare una gestione di eventi all'interno dell'applicazione.Certo, assolutamente, c'è anche tutto integrato dentro platformatic, c'è anche tutta la gestione degli eventi in un pacchetto che si chiama @platformatic/sql-events e appunto quindi tu puoi addirittura anche reagire alle cose o pubblicarli eccetera e automaticamente vengono poi convogliati dentro le GraphQL Subscription per esempio e comunque poi ti puoi interalciare con questo sistema di wrappers innestati e con questi per poi andare appunto aggiungere il comportamento che vuoi.Quindi io ho dato un salvo una cosa voglio chiamare quest'altro endpoint per tenere dati sincronizzati lo posso fare e funziona secondo me è un approccio che funziona molto molto molto molto bene ci stiamo costruendo un sacco di roba sopra e secondo me è veramente ottimo.Un'altra cosa che però ho notato molto utile io sono un amante di quello che mi piace chiamare half code quindi code ma non troppo se posso concentrarmi sulla business logic è meglio nel senso che è eliminare tutto il resto quindi da questo punto di vista sono un grande fan di questo mondo è una cosa che ho visto in tanti sistemi adesso non ho avuto ancora occasione di fare un di di di di di di di tuffarmi ciappieno su platformatic appena becco un attimo mi provo a fare uno dei tanti poche che rimarranno nella mia cartelletta dell'incompute però una delle cose che ho trovato molto utili di sistemi di questo tipo è la gestione della autorizzazione quindi noi sappiamo che ci sono due elementi autenticazione e autorizzazione come questi due elementi sono gestiti? in che modo hai gestito questa parte? Parliamo prima dell'autenticazione.L'autenticazione per me oggi è basata su TokenJWT.Secondo me oggi la soluzione più sicura e affidabile per fare un sistema d'autenticazione è usare i TokenJWT e anche usare i TokenJWT come soluzione se vogliamo machine to machine.è quella più semplice, sicura e anche facile da implementare.Un aspetto importante, bisogna comunque sempre andare a utilizzare librerie veloci per fare questa cosa.Quando ancora anni fa erano in near form abbiamo sviluppato questa libreria che si chiama FastCWT che risolve sostanzialmente la maggior parte dei problemi prestazionali di questo approccio alla radice ed è una libreria che tuttora è open source, prendetela, usatela, grazie a NearForm che la continua a mantenere e che anche noi usiamo all'interno perché funziona veramente bene.Quindi questo approccio ci consente di...Tu puoi usare OutZero piuttosto che chiunque altri dei dei delle librerie che ci sono pubbliche.Ecco se vogliamo.Scusami, dei servizi pubblici per fare autenticazione.Perché non facciamo autenticazione internamente noi e perché dici raccomandiamo a tutti ma usate qualcosa di esterno? In realtà tu vuoi usare il vuoi tenere il minor numero possibile di dati personali.è bruttissimo da dire ma le normative sulla privacy sono una spada di Damocles per tutti noi sviluppatori e quindi bisogna necessariamente andare a un po' a come vogliamo dire...distribuire la responsabilità...sì non vuoi averne a che fare ecco io è meglio non andarsela cercare quindi io sono per questo approccio e quindi per me funziona molto bene ecco e questa è la prima cosa e abbiamo fatto due cose a riguardo la prima abbiamo stato questo modello si chiama fastify user è un modulettino piccolino che non fa molto tra virgolette ma fornisce appunto lo standardizza due o tre modi diversi di creare un utente, di creare una proprietà user all'interno della request.Supporta sia JWT che un concetto di webhook.Un domani forse supporterà anche i cookie.Il problema dei cookie è di usare i cookie per l'autenticazione, ed è un approccio che sconsiglio enormemente a tutti, perché nel momento in cui parli di cookie entri in un mondo di cross site request forgery entri in un mondo bruttissimo di attacchi takeover, di double submit cookie, di cookie tossing di cose che non vuoi veramente affrontare, ecco sinceramente parlando per cui no, meglio non parlare di cookie, di non usare cookie per l'autenticazione utilizzo un bellissimo token GWT, il problema è che a un certo punto un cookie forse lo metti e quando metti quel cookie sei fregato, però diciamo che non supportare questa cosa qui come default è un approccio, è una mancanza voluta, non vogliamo implementare, non l'abbiamo aggiunta perché riteniamo che sia un approccio problematico.C'è un limite alla corda che si vuole dare agli sviluppatori per impiccarsi? Direi di sì, direi di sì, ecco, e quindi direi proprio di sì, ecco, quindi meglio di no, meglio non usarla.Per la maggior parte, parlando di corda, e per la maggior parte tanta gente utilizza Jest.Jest è principalmente corda placata a oro, ecco nel senso è una delle cose più sbagliate che puoi usare in un progetto non JS.Però la maggior parte della gente dice "no no, utilizziamo Jest per i testi".Ok, meglio di niente, rispetto non scrivere i test usi gesta almeno gli scrivi poi cosa fa sotto te ne accorgi solo dopo io quello che ti dice di che dice gesta è che nell'ambiente di gesta il test passa ecco che poi passi anche quando gira in produzione non è che abbiamo due ambienti diversi che non si assomiglia con l'altro quindi è fune finto quindi però invece per quanto riguarda l'autorizzazione che è una parte veramente importante.L'autorizzazione è interessante perché l'abbiamo sviluppato con questa cosa abbastanza basilare, è un sistema di autorizzazione molto basilare che è integrato direttamente in platformaticDB quindi tu puoi semplicemente configurare nel tuo file di configurazione un'archivation un'archivio authorization e a cominciare ad aggiungere un po di cosiddette rules.Con queste rules tu vai poi a definire o a limitare gli accessi alle tue righe sul database, ma è tutto in codice, non si basa su altri sistemi che fanno questo tipo di cosa, utilizzano il sistema di autorizzazione del database.In realtà noi non facciamo niente di tutto questo, il nostro è semplicemente il codice che gira e riteniamo che il Row Level Security non sia un approccio molto semplice ma non un approccio abbastanza flessibile, soprattutto quando vai a sviluppare cose in un sistema distribuito, a microservizi, che vai a creare cose in realtà poi non funziona più niente.Secondo me è un approccio che non scala, ti porta a sviluppare un monolite e basta.Il nostro approccio, noi vogliamo che in realtà la maggior parte dei sistemi che sono durante la vita dei sistemi tipicamente diventano dei microservizi, dei sistemi distribuiti, diventano delle cose più complicate.Per cui pensare che sta tutto dentro un database non è la scelta giusta.Queste regole che vengono specificate, come funzionano? Tu puoi specificare cose del tipo "guarda, puoi accedere a questa riga se fai parte di questa organizzazione".Come viene scritto però? Il tuo utente dentro il suo token JWT avere l'organization ID che fa parte e dall'altro lato la tua riga deve avere un'organization ID come proprietà.Non ti crea quello che viene detto, il "join multiple" per cui hai una tabella di permessi.Queste cose qui non vengono, non è supportato a oggi dentro questo tipo di soluzione.In particolare anche perché è molto, entro un mondo molto complicato, cioè tu se vuoi fare un sistema regole generiche devi sostanzialmente andare a dire "ok io ho questo utente con questo ID, ho questa regola devo crearmi una query che ti colleghi A con B e tipicamente diventa una join a 3-4 livelli e generare questa cosa automaticamente è difficile ma è anche poi lento quando poi vai a eseguire il codice in particolare per cui in realtà secondo me...E se poi parliamo anche di GraphQL questa lentezza viene proiettata nei vari livelli che tu poi vai a esplorare con la tua query grafica.Ah sì sì, è una complessità combinatoria di questa cosa, esplode, ti può esplodere in mano.Che poi anche se usi la cache comunque c'è una sua complessità di base, ma è comunque possibile creare regole custom per l'accesso? Sì sì tu puoi scrivere le tue righe di codice, cioè nel senso quello che ti dico io non te la creo in maniera automatica da configurazione ok ma tu puoi fornire le tue regole in codice come la vuoi ok.Passami il termine queste regole sono associate poi a quella che io chiamerei entità no? Quindi alla riga della tabella.Sono associate alla riga della tabella sostanzialmente non alla riga della tabella ma alla rappresentazione in memoria della riga della tabella.Ok perfetto è più chiaro quindi comunque tu puoi attivare quel livello di granularità arrivare a quel livello di granularità scrivendo il tuo codice custom? Puoi arrivare a quel livello di granularità scrivendo il tuo codice custom e andando a inserire regole come ti pare ecco.Tanta complessità stiamo sviluppando oggi una soluzione ci sono alcune questi problemi sono molto difficili.Non è un problema che noi come platformatica vogliamo risolvere, a parte la cosa più semplice, il caso base che è quello più semplice.Io sono Matteo, mi loggo nel mio sito e voglio vedere le mie foto.I casi base che in realtà rappresentano l'80% delle soluzioni di autorizzazione sono tutte molto basilari nel senso non hanno sistemi di permessi complessi del tipo "ah io ho uno specifico ruolo all'interno di una specifica organizzazione" certo è che se stai sviluppando un SaaS hai bisogno di qualcosa di un po' più strutturato.Stiamo sviluppando un un progetto nuovo che si integra con soluzioni esistenti, che ti consente di andare, per esempio, a finire a scrivere la policy con uno di questi gestori di policy, che ce ne sono 3-4 pubblici, non voglio andare troppo nel dettaglio, ma tu scrivi la tua policy in questi gestori di policy, a quel punto platformatics comunica con questo gestore di policy, crea il suo query plan se vuoi e poi lo va a eseguire.Ma appunto se è qualcosa su cui stiamo lavorando, aspettate news a breve.Questa cosa è molto figa in realtà perché permette anche immagino la possibilità di essere condivise le policy, di avere un centralizzatore, un'unica fonte di conoscenza.Esattamente, esattamente.Per cui quello che vedi lì ad oggi è il caso base, ok? Che però si riesce a usare per quello che usiamo per platformati cloud, noi oggi è tutto basato sul caso base.Quindi nel senso ti riesce a portare anche abbastanza su se vuoi.Dove però non arriva ci sarà quest'altra cosa.Matteo ti faccio una domanda che non c'entra niente, proprio così completamente random.platformatic ripeto che io sono sempre quello sviluppatore che cerca di concentrarsi solo sulla logica di business e niente più.è un platformatic front end? allora questa è una cosa molto molto interessante non vogliamo entrare nella front end war in maniera abbastanza chiara e definita.Noi nella frontend war non ci vogliamo entrare e per cui vogliamo supportare tutti e chiunque se vuoi.È un API e ce l'hai lì.Mi veniva la domanda perché in realtà è il pezzo che poi spesso cambia.Quindi in Sai se stai facendo la tua applicazione il front end è la parte user face nella quale ti concentri devi combinare tante cose probabilmente ha tanta roba custom talvolta i nostri back end sono spesso un sistemino crud con 30 righe di logica di business e un piccolo sistema di diritti.Buona parte di gli use case.L'hai descritto esattamente in maniera molto banale dove si vuole posizionare il platformatica sostanzialmente.Altra domanda perché io ti ho seguito su twitter e penso che sia una delle parti fondamentali non che uno degli elementi discriminanti per un prodotto open source o anche commerciale che voglia posizionarsi voglia attirare l'attenzione coinvolgere una base sempre più grande la documentazione che è la grande spada di Damocle per gli sviluppatori che a differenza di tanti altri ingegneri in genere nel senso ampio la vedono come un grande peso questo mi viene dalle tante conversazioni che ha avuto per voi come è stata scrivere la documentazione e quali sono state le linee guida che avete seguito per la creazione di questa? Allora, prima di tutto io vengo dall'esperienza di due progetti che hanno...diciamo che ho abbastanza esperienza al riguardo, nel senso che ho visto le persone come utilizzano la documentazione di Fastify, ho visto le persone come utilizzano la documentazione di Node.js, so quali sono i pro e i contro dei vari approcci e in particolare hai due aspetti.puoi fornire.In realtà la documentazione, ci sono vari tipi di documentazione.Tu hai bisogno di avere la parte più di reference, se vogliamo.Hai bisogno di avere una parte più di guides, di guide, che ti dicano cosa fare e come.E che sostanzialmente siano abbastanza dei tutorial che ti consentono di essere produttivo abbastanza velocemente.E questo è un po' la strada che abbiamo seguito.C'è molta documentazione da scrivere però tuttora, nel senso che alcune cose sono poco documentate e c'è ancora molto da fare.quindi non voglio dire che platformatic ha una documentazione perfetta anzi platformatic non può c'è tanto, se qualcuno vuole scrivere la documentazione ben volentieri ecco io siamo molto disponibili a fare la review di pull request per ogni cosa però è così ecco è abbastanza scriverdox e tosta sì su questo mi piace aggiungere una cosa che è una roba che ho scoperto qualche anno fa che in realtà mi ha cambiato il modo di vedere la documentazione di un framework fatto da Canonical, non è un software, ok? è un paradigma, io lo chiamo framework nel senso più lato del termine, si chiama Diataxis e vedere sta cosa mi ha completamente cambiato il modo di immaginare e di visualizzare la documentazione.Cosa dice Diataxis? Diataxis dice più o meno quello che ha detto Matteo poco fa, cioè che la documentazione è fatta da elementi diversi che hanno finalità diverse parlano lingue diverse, no? C'è tipo la parte di tutorial che sono quegli elementi pratici che sono più guidati alla parte di learning, quindi ti accompagnano nell'apprendimento.Poi ci sono le auto...auto guides che sono simili ai tutorial ma sono più legati a un task che devi svolgere, quindi sempre molto pratica ma con una finalità completamente diversa.Poi ci sono le spiegazioni che invece sono legate all'apprendimento sì, ma più teorico e c'è la reference che invece diciamo è più legata all'attività che stai facendo in questo momento e alla teoria.Insomma un bordello abbiamo detto.Quindi devi soddisfare tanti ambiti e questa è la complessità.Probabilmente difficilissimo scrivere la documentazione e probabilmente, e lo dico da sviluppatore, al di là del fatto che sia un progetto open source o meno, la documentazione diventa un elemento fondamentale proprio per il passaggio della conoscenza.Ti faccio un'altra domanda però.Saltiamo su un'altra piccola cosa noi conosciamo o almeno io conosco la tua "avversione" verso gli ORM come è stato scrivere un data mapper avendo questo punto questo questo questo principio? il problema degli ORM il mio principale problema con gli ORM è nasce relativo al concetto di model.Il concetto di model è una delle cose più sbagliate che la industria abbia partorito.Addirittura c'era un flusso di pensiero che diceva di fare il fat model ed è sostanzialmente quello che tu trovi oggi nella maggior parte dei sistemi MVC è un FAT model cioè cos'è un FAT model? Quando hai sviluppato un sistema, tu vuoi che un componente abbia il minore numero di responsabilità possibili.Quando scrivi una singola funzione, una singola classe, vuoi che questa abbia il minore numero di responsabilità possibili.Più responsabilità ci metti dentro, più diventa difficile scrivere quel codice.Mantenerlo nel lungo periodo, capire quello che sta succedendo è tutta una serie di cose.Cosa succede? succede che questi fat model cominciano ad avere variate responsabilità.Prima di tutto sono degli oggetti in cui mi contengono i dati che vengono dal database, sono dei mapping.Tipicamente poi hanno anche un metodo che si chiama load o un metodo che si chiama save ok per aggiornare le cose molto spesso questi fat model hanno anche le capacità di fare query sul database quindi tu puoi anche navigare la cosa ma siccome sono dei modelli gli sviluppatori cominciano a infilarci dentro anche business logic in 0 2 non capisci più quello che sta succedendo lì dentro è impossibile dopo un po' diventa quando cominciano a venire 100 200 di questi non sai più cosa sta succedendo.Mi ricordo quando lavoravo o comunque facevo anche talk sull'Aravel uno dei problemi principali era il model user perché uno dice tanto tutto ciò che succede in un framework MVC passa all'utente, cioè l'utente fa qualcosa quindi ci veniva messo dentro il model user tantissima business logic tant'è che dicevano state attenti a fare questo perché a un certo punto vi trovate 2.000 righe nel model user quando in realtà le cose andrebbero separate.Però concettualmente viene molto a dire "vabbè il model è lui che fa le cose, mettiamoci dentro la business logic".Questa cosa qui ti porta a scrivere sostanzialmente spaghetti gold.Trovi avere che è contrario a tutti i principi del buon codice, se vuoi, che chiunque ti dice "adesso non voglio io può fare quote lunghissime, ma i principi UNIX dicono "fai una cosa e falla bene" e costruisci sistemi complessi basandoti su cose che fanno una singola cosa e fatta bene.Questo per me è uno dei principi che seguo.Cosa vuol dire quindi? Come si traduce nella pratica? Nella pratica si traduce a questo, si aggiunge un altro aspetto.Una delle cose più difficili quando utilizzi un ORM è appunto navigare gli oggetti, navigare la catena degli oggetti.Nella pratica, nella mia esperienza personale, nel 9 casi su 10, la query SQL che genera l'ORM è sbagliata o è lentissima o è problematicissima.Ok.Per cui è meglio non fa.Cioè è meglio non fargliela fare.Siamo abbastanza vicini al non fargliela fare che sia meglio non fargliela fare piuttosto che fargliela fare ecco.Fargliela generare.Quello che vuoi fare tipicamente è scrivertela a mano.Perché? Perché tipicamente vuoi andare anche a sfruttare determinati indici vuoi far sì che la tua query sia strutturata in un certo modo.ti vuoi affidare al database, ok? Perché nel momento in cui tu all'ORM, tu vuoi affidare al database runtime, perché nel momento in cui se tu non lo fai ti stai mettendo in casa una ticking bomb.Sono tutte query che secondo me dopo un po' ti vanno a esplodere al primo problema di produzione.In un progetto che ho fatto non troppo tempo fa c'era questa bellissima query, aveva un problema di prestazioni enormi e c'era questa bellissima qui che per eseguire metteva un rollo facendo una transazione metteva un rollo su tutte le righe di una tabella bello è un utente per volta e si lamentava anche alla lenta capito il database moriva l'applicazione moriva c'era un time out era un macello.No io ho avuto un'esperienza simile quando ero giovane mi sono innamorato del ddd no? a quel punto avevo, con symphony lo ricordo ancora, ricordo ancora il dolore devo dire, avevo sviluppato un'applicazione anche complessa, era un sistema di booking per esperienze abbastanza articolato c'era una trentina di tabelle che entravano in gioco con relazioni e complessità e ho detto vabbè proviamo a usare il ddd e creiamo le fat entity come dici tu, quindi c'era un aggregato che faceva le sue cose, le entity, nestare logica di business fino a livello ennesimo, morale della favola, la chiamata dell'endpoint che mi faceva poi quel calcolo che era distribuito all'interno di tutto l'albero delle entity, 72 query.Adesso tu ci puoi anche mettere il Redis davanti, ok? Ma la prima query è quella che ti scassa tutto! E come fai se un un motore di booking dove redis davanti non lo puoi mettere perché ti servono i dati a real time e riscrivi l'applicazione e allora ti fai le query a mano dividi il dato dalla logica e qua una piccola una da qui si vede la mia disaffezione per la programmazione oggetti proprio da questa esperienza avviene il fatto che io non utilizzo più oggetti I modelli sono il problema, non gli oggetti.Il problema della programmazione oggetti è che se tu vai a vedere quando era stata pensata eccetera eccetera eccetera in realtà il problema di fondo è proprio lì, è nel fatto che tu metti nello stesso oggetto, nello stesso componente, l'oggetto, il dato e la funzione per operare su quel dato e per me è sbagliato è sbagliato come principio proprio esatto e da là è proprio da quell'esperienza che poi io non ho più utilizzato classi in vita mia da allora faccio solo funzioni e oggetti che contengono wrappano wrappano il dato tra l'altro il mio codice è diventato molto più semplice a leggere endomi di tutto quella di quella ambaradan visto che il tempo vola mi piacerebbe farti l'ultima domanda.Vai! Se Leo non ne ha altre.Cosa? Ti parlo non solo legato a Fastify e non solo legato a platformatic ma anche legato a fastify comunque da creatore e mantenere di progetti di una certa dimensione però cerchiamo di stare più vicini a platformatic che mi interessa parecchio come fai a decidere a farti guidare se una feature deve entrare o non entrare nel senso dove va la feature a livello framework a livello meta framework a livello linguaggio come fai a discernere o a livello utente che si deve scrivere il suo end point personalizzato come fa discernere dove debba andare questa feature.Allora se l'utente se la può la mia valutazione è prima di tutto quanto è facile da fare.Ok è alla portata di tutti.Si no è alla portata della mia persona.Cioè nel momento io scrivo codice o faccio cose sostanzialmente vedendo chi è la mia persona, l'utente tipo del mio software.E quindi se l'utente tipo del mio software può farsela da sola, se la fa da sola.Molto spesso però non se la può fare da sola.Perché non è sopra le proprie competenze.Banalmente non c'è niente di sbagliato nel dirlo.se mi dici come implementi un exchange di TLS sicuramente se mi dà la specifica è capace che te lo implemento, buchi di sicurezza che ci infilo 100.000 per cui forse è meglio che io non lo scriva quel codice per darti un'idea banale di pragmatica su qualcosa di per cui non vuoi scriverti la roba della libreria open ssl a mano ma vuoi avere qualcosa di sopra oppure ma guarda secondo me se tu vuoi utilizzare dei form forse dovresti andare a proteggerli col metterci un csrf token ecco un csrf token è una libreria è qualcosa che tu non vuoi fatti a mano.Perché? Perché per sapere quella roba lì bene, come fare quella roba lì, devi essere un security expert e se tu non lo sai lo diventi a suon di mazzate.Questo per esempio è un caso realistico.Io ho dovuto studiarmi tutta sta roba perché abbiamo avuto una vulnerabilità di sicurezza, un paio di vulnerabilità su sicurezza, su fastify, su csrf e mi sono reso conto che il 90% delle applicazioni che vedo sono vulnerabili a questo tipo di attacco capito? bello, veramente bello.In pratica se tu utilizzi un cookie per sbaglio e hai un form, un multipart, una roba per caricare sostanzialmente il tuo sito è vulnerabile per qualunque cosa.Cioè praticamente il 90% dei forum di upload oggi sono vulnerabili a attacchi di vario tipo.se non ci metti un CRF Protection sei vulnerabile per darti un esempio questa è bellissima i form di upload in multipart o form data o multipart non passano tramite CORS non passano tramite CORS vengono chiamati e definiti simple queries, e non passano tramite course quindi io posso caricarti una pagina qualunque, una cosa che manda una multiple, un upload form verso il tuo sito e se tu sei logato su quel sito e hai un cookie di autenticazione quel cookie va.è da un po' che non faccio form di upload perché utilizzo il buon vecchio S3 con i presignet URL.No ma è...cioè tante cose, capito? Sì sì sì.Usare questo tipo di scelte è anche una forma di sicurezza.Tu utilizzi quello quindi strabocchi non ti devi preoccupare, capito? Però dal punto di vista del maintainer tu dici io non mi prendo la responsabilità di farti la la feature che esula dalle mie competenze o se la faccio la faccio.Non te la faccio fare a te perché so che la farei.Quindi tocca a me fartela.E questo è un po' una dei dei dei dei principles che seguo quando sviluppo quando decido cosa sta dentro cosa sta fuori.E per cui se non mi rendo conto che la potula possa fare tu non la sto nemmeno a tipicamente la metto dentro.Che la metta dentro come un plugin, una feature nel framework principale, che la metta dentro come uno plugin ufficiale, un plugin o un'altra libreria che si usa, ma comunque blast ufficiale per fare quella cosa lì, dipende dal caso specifico della feature, però è qualcosa su cui tipicamente se mi rendo conto che l'utente non può farcela, normalmente sono cose integrate.Per dirti cose interessanti che abbiamo dentro Fastify, per esempio c'è tutto il discorso di gestione dei flussi OO.Tu non te la vuoi gestire da sola.Che palloso! A prima di tutto è palloso, ma poi se ci provi fallisci miseramente.Nel senso, non è qualcosa che chi ha bisogno di la maggior parte degli utenti non sarebbe in grado di implementarselo e quindi ed è palloso tra virgolette come hai detto ma questo è un altro è un altro discorso però la maggior parte di utenti non ha le competenze.LM: chiaro, io credo che guardando l'orologio penso di aver utilizzato quasi tutto il tuo tempo libero se non tutto.Il mio tempo libero non esiste, il tempo allocato a questa cosa.Il mio tempo libero è passato a cambiare pannolini e a stare con mia figlia, quindi di certo non è il mio tempo libero, però è così la maggior parte.Ti capisco, un dio quanto ti capisco.Passiamo quindi al momento del Paese dei Balocchi, il momento in cui i nostri host e i nostri guest condividono con noi un libro, un talk, un vino, qualunque cosa abbia catturato la loro attenzione e che hanno piacere appunto di condividere con noi, con la community, con gli ascoltatori di Gatebar.Quindi la mia domanda è Matteo hai qualcosa da condividere con noi? E con tu con il paese dei balocchi! Ah il paese dei balocchi! Sì con il mio amico Manuel e il mio amico Maxime abbiamo quasi finito di scrivere il libro su fastify edito da pact e quindi potete andare a comprare scaricare farlo insomma.Ah cool me l'aveva accennato ma è bello bello bello.C'è già un link.Posso condividere questo capito.Matteo c'è già un link per il libro.Sì ma aspetta.Ah sì, la vedo.Ok, la mettiamo nelle note dell'episodio.Leo, tu hai qualcosa da condividere con noi? Io sono arrivato un po' impreparato, però ho recuperato all'ultimo una storia.In realtà i balocco sarebbero gli Airtag.Mi è venuto perché mi ricordavo di una storia dove una persona ha perso una valigia dove c'era un air tag e è riuscito a recuperarla abbastanza velocemente però si è resa conto di come lei sapeva esattamente dove era la valigia mentre il sistema internazionale del tracking delle valigie no e visto che quando sono andato...Mi sembra di ricordare la tua situazione al FOSDEM...E poi sono andato a Milano a fare il team meeting con Matteo e tutto mi è stata persa la valigia non avevo gli air tag ho ho comprato gli airtag e quindi suggerisco la lettura di questo articolo e l'acquisto perché mi sono reso conto che in questi casi se non c'è anche un intervento da parte di chi perde la valigia, cioè proprio dell'utente, queste valigie vengono un po' perse.Avevo letto una statistica dove il 92% delle valigie che vengono perse vengono riconsegnate, che secondo me non è una percentuale così alta, perché c'è un 8% di possibilità che la vostra valigia venga persa e non la rivedrete più cerchiamo di evitare Sì, sì, ricordo com'era il tuo umore al Fosdem, lo ricordo benissimo.Io ho un libro, mi è arrivato avantieri, ho avuto modo di leggere solo il primo capitolo, è uno dei più bei libri che io abbia mai iniziato a leggere perché in realtà ne ho letto solo forse le prime dieci pagine ma è molto molto interessante ho fatto un casino per farmela arrivare perché su amazon francia e amazon italia non l'ho trovato e il titolo è "Working in Public" "The Making and Maintenance of Open Source Software" di Nadia Egbal, il nome più difficile del mondo da pronunciare è un libro veramente bello quindi se se volete...tra l'altro aggiungo un'altra cosa è impaginato da Dio ragazzi quindi se volete buttarci un occhio fatelo, secondo me è uno di quei libri che deve stare sulla scrivania di chi in qualche modo si connette, si avvicina o quantomeno osserva il mondo dell'open source detto questo io ringrazio Matteo per essere venuto a trovarci per aver bevuto con noi il suo caffè ciao ragazzi, è stato un piacere quando volete sono qua io ti direi che ci rivediamo, adesso la metti in calendario ok qua da inizio luglio che io sarò al mare, quindi possiamo fare una github bar session io mi collego direttamente dal mio bar preferito a Milano Marittima e mi sorseggio uno spritz io faccio la stessa cosa da Santiodoro in Sardegna io lo faccio dalla Bersilio mi facciamo una summer edition di questa cosa avrò anche delle novità tecniche da di cui parlare e quindi secondo me è molto carino, quindi se lo vogliamo organizzare qua da luglio così un po' più volante, adesso ho la telecamera, il microfono siamo tutti un po' così, una cosa un po' più come dire sciolta o simile, secondo me si può si può pensare perchè c'è anche quelli portati anche noi allora è aggiudicato per un GIT BAR in flip flop direttamente a luglio grazie di nuovo Matteo, grazie di cuore ciao ciao ciao ciao [Musica] GIT BAR 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 ed strumenti immancabili nella cassetta degli attrezzi dei full stack dev.[Musica]
