Opa la stiamo registrando stiamo bellissimo ciao a tutti Bene e benvenuti su Geetbar nuova settimana e nuovo episodio qua sul nostro bar degli sviluppatori.

Allora io mi sento un po' così un po' shakerato perché registrare Geetbar 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 va di grappa la mattina scusa ma che le birre non lo bevono 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 framework 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 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ò tutto bene, tutto bene, alla 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 no? 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 se vuoi un po' di developer relations eccetera eccetera e le cose stanno andando relativamente bene o perlomeno relativamente nei piani ecco e 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 annunciamo 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 capito non lo so come sempre immaginate sono, Leonardo è un mio collega e quindi giochiamo un po' in casa con su con github si ma oggi sono solamente host quindi stesso è l'unico ospite ah ok, comunque io ti metterò sulla griglia tutto il tempo sappilo perché mi hai coinvolto in questa cosa ieri quindi tutto al volissimo capito? Si si 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 si oggi ti ritrovi a sviluppare per quanto sia open source un prodotto e anche a costruirci un'azienda sopra cosa è cambiato? ehm svariate cose eh la prima è, io ho fatto professional services, questo per probabilmente la maggior parte della mia carriera ok, circa dieci anni ho fatto professional services e oggettivamente parlando un cambiamento ci stava ok, ho stato otto anni e mezzo in near form e per vari motivi insomma mi stava relativamente stretta e quindi abbiamo dovuto, e quindi un cambiamento ci stava questo è il primo aspetto, uno aspetto probabilmente in cui tanti si riconoscono, ecco uno fa lo tra virgolette lo stesso lavoro tanto tempo e questo, in cosa consisteva il mio lavoro? il mio lavoro principalmente consisteva nel eh parlare con gente, con aziende, sviluppatori che usavano Node.js e date queste cose da prendere il loro feedback e aiutarli nel risolvere i loro problemi e nell'usare queste tecnologie al meglio e semplicemente migliorando la produttività del team piuttosto che i tempi di sviluppo, l'affidabilità e tutto 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 ok e nessuno ascoltava tra l'altro nessuno ascoltava, cioè ma io le dicevo anche pubbliche, capito? nel senso proprio nel 9 su 10 io le cose le ho sempre dette, quelle che dicevo ai privatamente ai clienti, sono le stesse che ho sempre detto pubblicamente nei miei talk o nelle mie cose, nessuno più che qualcuno ascolta, capito? ma tante aziende? no, relativamente no ehm tanti team? no, principalmente perché vanno a leggere quello che è il tutorial di ExoExpress del 2012, del 2013, del 2015 o il corso su Udemy di quegli anni lì che ha milioni di views, ok? ma è vecchio, ok? è roba, come dire non si fa le cose, non si fanno più le cose in quel modo lì per farle fatte bene ecco la tecnologia si è spostata e quindi danno retta a queste tipologie di cose, seguono questo tipo di trend, seguono 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 ok? o come si evita questo problema, avere questo problema in prima battuta e che cosa è successo? è successo che 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 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 darglielo, possiamo fornire questo tipo di di know-how, di esperienza in maniera molto più affordable se vuoi per quello che riguarda la maggior parte delle e 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, per migliorare come gli sviluppatori fanno software o 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 cioè se tu uno ha scritto degli XSLT direi che più o meno ha toccato il massimo possibile fondo della della developer experience, ecco, peggio di quello non c'è nulla forse il COBOL ma secondo me il COBOL è meglio io ho qualche strana ho una visione del mondo che insomma il COBOL è meglio di quella roba lì ok, ti giuro, sono abbastanza convinto che il COBOL sia meglio ok, quella roba lì è veramente brutta, il COBOL è stabile per lo meno, capito l'editor di quella roba lì crashava ogni 3x2 per dei Wi-Fi, cioè una roba, capito una roba atroce vabbè, aperto questo brutto parentesi però ecco, il mio lavoro è sempre stato quello di sviluppare tecnologie che consentissero agli sviluppatori di avere una vita migliore, ecco, sostanzialmente 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 front-end scusate, nello sviluppo back-end in OJS e quindi ho cominciato a svilupparlo nel 2016 con Thomas e Fast Forward adesso è un progetto established, cioè nessuno mi davano del pazzo più o meno quando ho cominciato a fare quella roba lì e 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 è un bel...

ed è da mangiare a tanta gente, me compreso, tra l'altro è da mangiare a tanta gente, capito? questo è normale, 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 e detto questo, questa è la prima cosa e cos'altro? non voglio entrare troppo nel discorso express, ecco tutto qua e mi vedete bene? mi vedi un po' di scatto di scatto dal mio lato? ma forse no? noi ti vediamo perfettamente, ti dicevo passaggio da Fastify poi a Platformatic? il passaggio è stato abbastanza come dicevo lineare, Fastify è opinionated ma è molto comunque molto molto freeform ok? 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 ma che è agnostico se vogliamo ad alcune scelte architetturali o in altri termini mi rendo conto che le mie opinioni sono abbastanza strette su alcune cose e tanta gente vuole, come io dico sempre, vuole corda per impiccarsi e io normalmente sono il primo che dice tieni tutta la corda che vuoi nel senso, non so che stai facendo una roba che non dovresti farla forse lo sai anche tu ma puoi avere, se vuoi, è una tua scelta 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 plugin e delle cose che sono poi stati che hanno portato poi ad avere l'API attuale di Fastify è stato un approccio molto utile negli anni e però mi sono reso conto che quello che la community chiedeva e mi continuava a chiedere ogni tre per due era appunto di avere un po' più di linee guida, un pochino più di struttura come usiamo queste tecnologie per sviluppare un API, un back-end 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 e questo spesso e volentieri per tanti punti di vista non c'è oggi sul mercato o se c'è è molto molto opinionated per cui io non...

molto più 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 avete presente che c'è questa sintassi che potete usare i decoratori 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 ok prima che venissero standardizzati da TC39 che è l'interregolatore di JavaScript quello che standardizza ECMAScript che poi è il linguaggio che usiamo tutti i giorni e cos'è 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 è valido JavaScript, non sarà valido JavaScript nel lungo nel medio-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 a 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 di approccio negli anni per darti un esempio di cose di cose di questo tipo e quindi cosa è successo con Platformatic tornando a Platformatic io mi sono reso conto che mancavano un sacco di...

sostanzialmente mancava tutto un approccio di tipo più simile a quello che è Ruby on Rails cioè il vantaggio di Ruby on Rails è che io ti do i binari tu vai sui binari, è un high speed train, ti muovi a cannone dopodiché qual è il problema di Ruby on Rails? Ovviamente è che tu sei sui binari per arrivare alla tua destinazione a un certo punto devi scendere dal trenno andare a piedi e questo è un po' il problema di Ruby on Rails e a molti dei framework fatti in quel modo e 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 il high speed train, io ti do la 4x4 e la 4x4 vada per tutto ok? Va nell'autostrada, va sullo sterrato, va dappertutto vai più piano che con il 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 e poi sei a piedi, ti devi tirare la valigia, successivamente ti metti la mano in spalla e camminare con la 4x4 vai dove vuoi e il successo di Node deriva da essere una 4x4 se vogliamo quello che vogliamo fare con Platformatic è prendere e unire questi due approcci 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 ecco 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 o altri termini ma sai che c'è quando arrivi c'è già la macchinina pronta che puoi prendere, arrivi in stazione e c'è già la macchinina pronta che puoi prendere per andare dove devi andare in che modo lo facciamo? In che modo Platformatic raggiunge questo? Prima di tutto ha due componenti, uno è Service e l'altro è Platformatic DB Service sostanzialmente è uno componente molto barebone che ti fornisce 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? si si si non si capisce come mai, tu fai un health check implementi un health check però al primo incident l'health dice va tutto bene però la tua applicazione non funziona che è la cosa peggiore che tu puoi avere da un health check non vuoi avere un falso positivo, vuoi avere al massimo un falso negativo l'health dice che le cose non vanno bene poi vai a guardare, capito? certo e 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 un sacco di una settimana in un progetto normale non escono una settimana perché il problema è che normalmente se dici io 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 ok? e 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 è utilizzo Node.env per selezionare l'environment non so quante ne avete viste, capito? l'utilizzo di Node.env è una delle cose più brutte che possono essere aperta, scusa parentesi Node.env è stato inventato da Express, non da Node quindi non c'entra niente Node.env non c'entra niente con Node.js è stato inventato da Express e poi usato in altre librerie ma Node.js non conosce il concetto di Node.env e non va usato sostanzialmente lo devi mettere a production quando sviluppi 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 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 c'è 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 succede 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 no no no, go dice una cosa ancora peggio non perché ha detto pike perché se non lo fai sei stupido è vero il vero purista go ti dice si fa così no se tu non capisci le variabili a un carattere sei stupido questo ti dice l'ecosistema l'ecosistema go io non riesco a 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 a un carattere sei stupido ma non ti ricordi quando non le capivi neanche tu? ok cioè nel senso sei nato imparato oi se sei così intelligente sei nato imparato pazienza, capito? Matteo volevo chiederti hai parlato un po' della parte barebone dell'applicazione platformatica però una delle componenti principali è il platform pillar che ottimizza un sacco di effort in fase di sviluppo e tutta la parte di platformatikDB yes allora come è nato platformatikDB platformatikDB nasce da un problema reale abbiamo poco tempo dobbiamo sviluppare tante cose vogliamo sviluppare velocemente e voglio avere qualcosa che mi rimuove tutta la parte di lavoro scomodo o ripetitivo platformatikDB nasce come idee anni fa nella pratica è nato tra giugno e luglio abbiamo cominciato a sviluppare questo software che è dati gli schemi sui database tira su, fa delle query di introspection e date queste query di introspection crea delle API dello scaffolding non genera codice perché io sono abbastanza contrario all'approccio dei generatori di codice è sempre perché se ti genero del codice l'ho generato oggi se te lo genero con un baco io non te lo posso fissare te lo devi fissare a te nella mia...

se non è di...

come dire...

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 ecco, se vogliamo questo è un po' il problema di tutti i generatori di codice per me, lasciano secondo me il tempo che trovano in molti casi l'evoluzione di questi generatori di codice è sì, sì, io ti genero un po' di codice ma in realtà il 90% del lavoro viene fatto da una libreria sotto banco che gestisce tutto vede, uno di questi casi era per esempio in create react app c'era questa libreria che si chiama react scripts che faceva tutto lei, ecco, sostanzialmente quindi loro ti generavano del codice ma era principalmente solo cose buttate lì in realtà veniva tutto fatto 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, 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 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 delle API basic più o meno crud, se vogliamo per leggere e scrivere sul tuo database da un'applicazione web quindi sia open API che GraphQL in relativamente zero tempo tu scrivi, una volta che hai lo schema addirittura chiedi a chat gpt di farti lo schema butti lo schema in una migration e hai finito, capito? e magicamente tutto funziona anche se poi ti fidi di chat gpt ecco perché poi c'è questo aspetto di io lascio questo punto di domanda ai posteri e quindi cosa succede? succede che chat gpt succede che abbiamo un quello che un secondo date che ecco vai e cosa succede? succede che noi appunto creiamo queste API open API con open API e GraphQL e 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 tra virgolette posto dove queste API possono essere utilizzate qual è però lo step lo step successivo? lo step successivo arriva quando tu devi in realtà deve aggiungere della business logic e si possono aggiungere della business logic in due modi sostanzialmente il primo modo è aggiungo delle nuove rotte o aggiungo dei nuovi resolver aggiungo dei nuovi resolver viene automaticamente inserito dentro il mio open API il mio GraphQL non devo fare niente è tutto molto carino invece cosa succede? se devo andare a se devo andare invece posso andare a modificare le rotte, le cose esistenti come lo faccio? lo faccio tramite i concetti che noi chiamiamo gli hook, mi piace molto questo termine e quindi tu in realtà sostanzialmente è una catena di molto simile a quello che è un middleware viene ispirato 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 un grosso appeal nel pubblico quindi è stato chiamato hook ok in sostanza cosa succede? tu aggiungi una funzione che ti wrappa il comportamento interno per esempio della save di una chiamata save e in questa cosa qui cosa ci puoi aggiungere? ci puoi aggiungere per esempio l'autenticazione o ci puoi aggiungere altri side effects che devono succedere all'interno di quella chiamata per esempio puoi o posso 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 e questo approccio lo faccio vedere abbastanza bene nei video che ho fatto costruendo questo semplice coda 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 l'elezione del leader tu ne puoi far partire quanti ne vuoi viene eletto un leader ed è quello che poi scoda 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 assolutamente c'è anche tutto integrato dentro platformatic c'è anche tutta la gestione degli eventi in un pacchetto che si chiama atplatformatics-sql-events quindi tu puoi addirittura anche reagire alle cose pubblicarli eccetera e automaticamente vengono poi convogliati dentro le graphical subscriptions per esempio ti puoi interalciare con questo sistema di wrappers innestati e con questi wrappers puoi andare ad aggiungere il comportamento che vuoi quindi io ho dato un salvo a una cosa voglio chiamare quest'altro endpoint per tenerli sincronizzati lo posso fare è un approccio che funziona molto molto molto molto bene ci stiamo costruendo un sacco di roba sopra 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 tanti sistemi non ho avuto ancora occasione di fare di tuffarmi cià pieno su platformatic appena becco un attimo provo a fare uno dei tanti POC 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 token JWT secondo me oggi la soluzione più sicura e affidabile per tenere per fare un sistema d'autenticazione è usare i token JWT e anche usare i token JWT come soluzione se vogliamo machine to machine è quella più semplice e quella più semplice più semplice e sicura e anche facile da implementare un aspetto importante bisogna comunque sempre andare a utilizzare le librerie veloci per fare questa cosa quando anni fa erano in near form abbiamo sviluppato questa ribellissima fast JWT che risolve sostanzialmente il problema la maggior parte dei problemi prestazionali di questo approccio è alla radice ed è una libreria che tuttora è open source prendetela, usatela grazie a near form che la continua a mantenere e che anche noi usiamo all'interno perché funziona veramente bene e quindi questo approccio ci da ci consente di usare out zero piuttosto che chiunque altri dei delle librerie che ci sono pubbliche se vogliamo 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 tenere il minore 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à si non vuoi averne a che fare ecco io è meglio non andarsene a cercare quindi io sono sono per questo approccio e quindi per me funziona molto bene ecco e questa è la prima cosa e abbiamo fatto due cose su a riguardo la prima abbiamo esatto questo modello si chiama fastify user è un modulettino piccolino che non fa molto tra virgolette ma fornisce appunto standardizza due o tre modi diversi di estrarre di creare un utente di creare una proprietà user all'interno della request e supporta sia JWT che un concetto di webhook un domani forse supporterà anche i cookie ecco il problema dei cookie è di usare i cookie per l'autenticazione del motivo per cui io ho 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 ok di non usare cookie per l'autenticazione di un bellissimo token JWT problema che a un certo punto un cookie forse lo metti e quando metti quel cookie sei fregato ok però io diciamo che non supportare questa cosa qui come default è un è un approccio ok è una mancanza voluta ecco non vogliamo implementare non l'abbiamo aggiunta perché riteniamo che sia un un approccio problematico ok c'è un limite alla corda che si vuole dare agli sviluppatori per impiccarsi eh direi di sì direi di sì ecco e quindi direi proprio di sì ecco quindi meglio di no ecco meglio non usarla per la maggior parte parlando di corda ok per la maggior parte tanta gente utilizza jest jest è principalmente eh corda placata a oro ecco in questo senso è una delle cose più sbagliate che puoi usare in un progetto non JS però la maggior parte della gente no no utilizziamo jest per i test ok meglio di niente meglio rispetto a non scrivere i test usi jest almeno li scrivi poi cosa fa sotto te ne accorgi solo dopo io quello che dice jest è che nell'ambiente di jest il test passa ecco che poi passi anche quando girano in produzione non è stiamo parlando di due ambienti diversi che uno non si assomiglia con l'altro quindi è fune finto quindi buh invece per quanto riguarda l'autorizzazione che è una parte veramente importante l'autorizzazione è interessante perché l'abbiamo integrata con l'abbiamo sviluppato questa cosa abbastanza basilare è un sistema di autorizzazione molto basilare che si basa che è integrato direttamente in platform ATTB quindi tu puoi semplicemente configurare nel tuo file di configurazione un'autorization, un'archive authorization e cominciare ad aggiungere un po' di cosiddette rules tac tac tac e con queste rules tu vai poi a definire o a limitare gli accessi alle tue righe sul database se vuoi, ma è tutto in codice non si basa su...

altri sistemi che fanno questo tipo di cosa utilizzano il sistema di autorizzazione del database Row Level Security 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 magari 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 queste regole che vengono specificate come funzionano? tu prendi, sostanzialmente dici puoi specificare cose del tipo guarda, puoi accedere a questa riga se questa riga ha la propria se fai parte di questa organizzazione come viene scritto però il tuo utente dentro il suo token JWT deve 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 multiply 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 a regole generiche devi sostanzialmente andare a dire io sono un 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 sta 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 GraphQL è una complessità combinatoria di sta cosa, esplode ti puoi esplodere in mano anche se usi la cache comunque c'è una sua complessità di base ma è comunque possibile creare regole custom per l'accesso tu puoi scrivere le tue righe di codice cioè nel senso, quello che ti dico io non te lo creo in maniera automatica da configurazione ma tu puoi fornire le tue regole in codice come la vuoi passami il termine queste regole sono associate poi a quella che io chiamerei entità 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 ad 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 platformatici vogliamo risolvere a parte la cosa più semplice il caso base che è quello più semplice cioè io ho un io sono Matteo, mi loggo nel mio sito e voglio vedere le mie foto ecco ok se vuoi i casi base che in realtà rappresentano se vuoi l'80% delle soluzioni di autorizzazione sono tutte molto basilari nel senso non hanno sistemi di permessi complessi del tipo uno specifico ruolo all'interno di uno specifico di una specifica organizzazione ecco certo è che se stai sviluppando un SaaS hai bisogno di qualcosa di un po' più strutturato ecco e stiamo sviluppando 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 vai a eseguire ok ma appunto se è qualcosa su cui stiamo lavorando aspettate news a breve ecco 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 per cui quello che vedi lì ad oggi è il caso base ok, che però si riesce a usare per dire che quello che usiamo per Platformatic Cloud noi oggi è tutto basato sul caso base 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 in più è un Platformatic frontend? Allora questa è una cosa molto interessante non vogliamo entrare nella frontend war in maniera abbastanza chiara e definita noi nella frontend war non vogliamo non ci vogliamo entrare e per cui vogliamo supportare tutti e chiunque se vuoi è un API e ce l'hai lì chiaro no mi veniva la domanda perché in realtà è il pezzo che poi spesso cambia quindi in realtà sai se stai facendo la tua applicazione il frontend la parte user face nella quale ti concentri devi combinare tante cose probabilmente ha tanta roba custom talvolta i nostri backend sono spesso un sistemino crude con 30 righe di logica di business e un piccolo sistema di diritti buona parte degli use case l'hai descritto esattamente in maniera molto banale dove si vuole posizionare il Platformatic 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 e 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 vengo da diciamo che ho abbastanza esperienza a riguardo nel senso che ho visto le persone che utilizzano la documentazione di Fastify ho visto le persone che utilizzano la documentazione di Node.js so quali sono i pro e i contro dei vari approcci in particolare hai due aspetti tu vuoi fornire in realtà la documentazione c'hanno vari aspetti vari tipi di documentazione tu hai bisogno di avere la parte più di reference hai bisogno di avere una parte più di guides di guide che ti dicano come fare e che sostanzialmente siano abbastanza dei tutorial che ti consentono di essere produttivi abbastanza velocemente e questo è un po' la strada che abbiamo seguito non abbiamo c'è molta documentazione da scrivere però tuttora alcune code sono poco documentate c'è ancora molto da fare quindi non voglio dire che Platformatic ha una documentazione perfetta anzi Platformatic c'è tanto, se qualcuno vuole scrivere della documentazione ben volentieri, siamo molto disponibili a fare la review di pull request per ogni cosa però è così è abbastanza scriverdox e tosta su questo mi piace aggiungere una cosa che è una cosa che ho scoperto qualche anno fa che in realtà mi ha cambiato il modo di vedere la documentazione ed è un framework fatto da Canonical non è un software, è un paradigma io lo chiamo framework nel senso più lato del termine si chiama diataxis e vedere questa 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 e parlano lingue diverse 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 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 no? come è stato scrivere un datamapper avendo questo punto questo principio ah 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 devi 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? ti controlla il fat model si dice il fat model è quando tu hai sviluppato un sistema ok tu vuoi che il tuo tu vuoi che un componente abbia il minore numero minore di responsabilità possibili e quando scrivi una singola funzione o una singola classe vuoi che questa abbia il minore numero di responsabilità possibili più responsabilità ci metti dentro più diventa difficile scrivere quel codice ok mantenerlo nel lungo periodo capire quello che sta succedendo è tutta una serie di cose cosa succede? succede che succede che questi fat model cominciano ad avere variate responsabilità prima di tutto sono degli oggetti in cui 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' quando cominciano ad avere 100, 200 di questi non sai più cosa sta succedendo mi ricordo quando lavoravo o comunque facevo anche talk su Laravel, uno dei problemi principali era il model user perché uno dice tanto tutto ciò che succede in un framework MVC passa all'utente, 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 2000 righe nel model user quando in realtà le cose andrebbero separate però bene, concettualmente viene molto a dire, vabbè il model è lui che fa le cose mettiamoci dentro la business logic però questa cosa qui ti porta a scrivere sostanzialmente spaghetti gold trovi a avere che è contrario a tutti i principi del buon codice, se vuoi che ognuno ti dice adesso non voglio 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 ok, questo per me è uno dei di quelli dei principi che seguo cosa vuol dire quindi? come si traduce nella pratica? nella pratica si traduce a questo si aggiunge un altro aspetto abbiamo una delle cose più difficili quando utilizzi un ORM è appunto navigare gli oggetti navigare la catena degli oggetti nella pratica per esperienza personale nel 9 casi su 10 la query SQL che genera l'ORM è sbagliata o è lentissima o è problematicissima ok per cui è 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 a sfruttare determinati indici vuoi far sì che la tua query sia strutturata in un certo modo, non ti vuoi affidare al database ok? perché nel momento in cui tu all'ORM, tu vuoi affidare al database al runtime, perché nel momento in cui se tu non lo fai ti stai mettendo in casa un una ticking bomb ecco sono tutte query che secondo me dopo un po' ti vanno a esplodere ti vanno a esplodere al primo problema di produzione cioè 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 query che per eseguire metteva un roll-off, faceva parte di una transazione metteva un roll-off su tutte le righe di una tabella, bello eh un utente per volta e si lamentava anche alla lenta 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 e a quel punto avevo, con symphony, lo ricordo ancora ricordo ancora il dolore avevo sviluppato un'applicazione anche complessa 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 ad 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 il 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 motore di booking dove il 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 da qui si vede la mia disaffezione per la programmazione oggetti proprio da questa esperienza viene il fatto che io non utilizzo più oggetti i modelli sono il problema, non gli oggetti si, si 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 che per me è sbagliato è sbagliato come principio proprio esatto, è proprio da quell'esperienza che poi io non ho più utilizzato classi in vita mia faccio solo funzioni e oggetti che contengono, wrappano il dato tra l'altro il mio codice è diventato molto più semplice a leggere endomi di tutto di quella ambaradan visto che il tempo vola mi piacerebbe farti l'ultima domanda vai! se Leo non ne ha altre cosa e qua ti parlo non solo legato a fastify e non solo legato a platformatic ma anche legato a fastify da creatore a mantenere dei 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 metaframework a livello linguaggio, come fai a discernere o a livello utente che si deve scrivere il suo endpoint personalizzato, come fai a discernere dove debba andare questa feature allora se l'utente se la può la mia valutazione è quanto è facile da fare è alla portata di tutti si, no, è alla portata della mia persona cioè normalmente 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 cioè non molto spesso però non se la può fare da sola perché non è sopra le sue proprie competenze banalmente e non c'è niente di sbagliato nel dirlo se mi dici come implementi l'exchange di TLS sicuramente se mi dai 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 pragmatica su qualcosa per cui non vuoi scriverti la roba della libreria open SSL a mano ma vuoi avere qualcosa di sopra ma guarda secondo me se tu vuoi utilizzare dei form forse dovresti andare a proteggerli con un CSRF token un CSRF token una libreria è qualcosa che tu non vuoi farti a mano perchè? Per sapere 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, ho dovuto studiarmi tutta sta roba perchè abbiamo avuto una vulnerabilità di sicurezza su fastify, su CSRF 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 di...

hai un form un multipart, una roba per caricare sostanzialmente il tuo sito è vulnerabile a qualunque cosa per darti un esempio praticamente il 90% dei siti dei form di upload il 90% dei form di upload oggi sono vulnerabili a attacchi di vario tipo se non ci metti un CSRF protection sei vulnerabile per darti un esempio per darti un'idea eh...

perchè questa è bellissima, i form di upload il multipart o form date o multipart non passano tramite course ok io questo non lo sapevo ahahahah non passano tramite course vengono chiamati definiti simple queries, qualcosa e non passano tramite course quindi io posso caricarti una cosina qualunque, una cosa che manda un upload form verso il tuo sito e se tu sei logato su quel sito e hai un cookie di autenticazione quel cookie va bello eh è 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? si si usare questo tipo di scelte è anche una forma di sicurezza tu utilizzi quello quindi strano o qui non ti devi preoccupare capito? però dal punto di vista del maintainer tu dici io non mi prendo la responsabilità di farti la feature che esula dalle mie competenze o se la faccio la faccio non te la faccio fare a te perchè so che sicuramente non te la farai, quindi tocca a me fartela ok e questo è un po' uno dei tenant dei principles che seguo quando decido cosa sta dentro e cosa sta fuori per cui se non mi rendo conto che tu la possa fare tu non la so nemmeno tipicamente la metto dentro, che la metta dentro come un plugin, una feature nel framework principale, che la metta dentro come un 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 OOTH ok, tu non te la vuoi gestire da sola che è palloso a prima di tutto è palloso ma poi se ci provi fallisci miseramente nel senso che chi ha bisogno di la maggior parte degli utenti non sarebbe in grado di implementarselo e quindi ed è palloso come hai detto ma questo è un altro è un altro discorso però la maggior parte degli utenti non ha le competenze 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 quindi è stare con mia figlia 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 Gatebard, quindi la mia domanda è Matteo hai qualcosa da condividere con noi? E con tu con il paese dei balocchi aaaah il paese dei balocchi siii 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 me l'aveva accennato Manuel bello bello bello io posso condividere questo capito? Matteo c'è già un link per il libro? si, aspetta ah si la vedo ok, l'ho postato lì lo 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 che in realtà i balocchi sarebbero gli Airtag mi è venuto in mente perché mi ricordavo di una storia dove una persona ha perso una valigia dove c'era un Airtag 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 a Polo mi sembra di ricordare la tua situazione al Fosdem e poi sono andato a Milano a fare il team meeting con Matteo e tutto e ho perso la valigia, non avevo gli Airtag 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 non so vengono un po' perse, ho letto una statistica dove il 92% delle valigie che vengono perse vengono riconsegnate e secondo me non è una percentuale così alta perché vuol dire c'è un 8% di possibilità che la vostra valigia venga persa e non la rivedrete più e 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 interessante, ho fatto un casino per farmelo arrivare perché su Amazon Francia e Amazon Italia non l'ho trovato e il titolo è Work 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 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 è sempre un piacere quando volete sono qua io ti direi che ci rivediamo, adesso te la metti in calendario ok qua da inizio luglio 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 Versilio 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 un po' più volante adesso ho la telecamera, il microfono siamo tutti un po' così una cosa un po' più sciolta o simile secondo me si può pensare a un'altra cosa anche noi allora è aggiudicato per un github bar in flip flop direttamente a luglio grazie di nuovo Matteo grazie di cuore ciao a tutti ciao ciao github 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 e di strumenti immancabili nella cassetta degli attrezzi di full stack web.