Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.In realtà, viste le condizioni di salute potrebbe sembrare più tipo Villa della Pace, quella villa per anziani dove sono tutti un po' malattici, perché la mia situazione di salute è veramente precarissima, sono a un passo dal baratro, ma non volevamo commissare questo episodio.Per cui insieme al super ospite che vi annunciamo tra pochissimo, c'è chi si prenderà cura di questa puntata e ci accompagnerà nella scoperta insieme al nostro ospite di una roba molto figa.Infatti con me qua è Carmine e Luca.Ciao raga! Ciao ragazzi! Ma quanto fa anni '80? Ciao raga! O anni '90? Cioè mi sento ambra Angiolini a palla! Vabbè noi tutti, quasi tutti da lì veniamo, dagli anni '80.Ebbene sì, ebbene sì.E credo che anche il nostro ospite, forse più giovane, non mi sbaglio quindi anche tu sei degli anni '80.Comunque detto questo io ringrazio davvero davvero Luca e Carmine per essere qua a darmi una mano, forse anche due, prestarmi anche la voce.E nulla, vi ricordo rapidamente i nostri contatti.Info che ho c'è la gitbar.it, @brainrepo su Twitter e...E il gruppo Telegram.Potete trovarci vicino al Gitbar, nel vostro client Telegram preferito.Siamo più di 1300 persone e aspettiamo solo voi per poter discutere di quello che vi pare.Anzi, in realtà, ultimamente siamo molto molto più attivi di prima, quindi ci sono più conversazioni interessanti.Insomma, aspettiamo.E, sempre sul gruppo Telegram, anche se è tipo borderline a livello legale, perché la normativa italiana non permette di fare giveaway, abbiamo un giveaway abbiamo due ticket omaggio per WeAreDeveloper perché come vi dicevo la scorsa volta siamo diventati partner di WeAreDeveloper e quindi ci hanno regalato due ticket omaggio che noi regaleremo a chi lo scoprirete nel gruppo telegram, ci sarà qualcosa da fare e scoprirete come ottenere uno dei due free pass.Abbiamo anche un codice sconto individuale.Mettiamo tutto nel nostro gruppo telegram perché è il nostro punto di riferimento.Però detto questo io direi che possiamo iniziare.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.L'ospite di oggi ancora prima di essere un grande professionista è un amico un amico con il quale ho fatto tantissime...anzi, non tante devo dire poche chiacchierate ma intense e piacevoli abbiamo con noi Giorgio Boa.Ciao Giorgio! Ciao, ciao a tutti grazie di avermi invitato.Come stai? Molto bene, molto bene.Beh, mi fa super piacere.Ho visto che questo periodo stai facendo un pacco di roba.Sì, sì, sì, sono super impegnato in questo periodo e tra i vari in castri sono riuscito a essere qui con voi quest'oggi e sono molto molto contento Dai guarda io sono super felice anche perché avevamo pianificato questo episodio per qualche settimana fa Quale avevamo pianificato qualche settimana fa però tu mi hai detto mauro guarda fai una cosa aspetta un pochino qualche posticipiamolo di una settimana perché vedrai che qualcosa succede In realtà io ho visto che è successo qualcosa.Cos'è successo? è successo che il framework QUIC ha raggiunto la versione 1.0 e proprio ieri quindi l'altro ieri in realtà scusa hanno annunciato la versione 1.0 Scusate stavo tipo morendo davanti al microfono Prima di lasciare la parola, perché ormai moribondo dovrò sedermi sulla sede e godermi la chiacchierata, voglio chiederti, tu in Italia sei tipo l'ambassador numero uno, in Italia e non solo in Italia, ho la sensazione che tu lo sia anche tipo in buona parte dell'Europa l'ambassador numero uno di QUIC.mi sbaglio prima domanda seconda cosa come hai scoperto quick allora effettivamente di speaker che parlano di qui che non siamo tantissimi e devo dire che è stata per me una piacevole sorpresa nel senso che proprio a we are developer la conferenza dove appunto avete i ticket da regalare in omaggio e Ho conosciuto il creatore di Angular, io in realtà mi ero avvicinato a lui per fare un selfie perché comunque da utilizzatore di Angular mi faceva piacere comunque scambiare due parole e poi da lì è nata una collaborazione con Qwik, cioè mi ha detto "guarda sto facendo questo nuovo framework, se ti va di investire un po' del tuo tempo per vedere, darmi del feedback eccetera eccetera, sentiamoci" e così ho colto l'occasione.All'inizio era un po' titubante se accettare o meno, nel senso che comunque sapevo che sarebbe stato impegnativo a livello di tempo, però ho detto "mal che vada, comunque ho modo di parlare con il creatore di QUIC e quindi perché no".Allora comincio io subito, perché io parlo da ignorante, ho visto più o meno la Lazio di tutto.Ma che cos'è Quick? Se proprio dovessi descrivere in una frase, però in una bella frase, non mi descriveresti tasto tipo, oppure remix, però da un po' più forte.Ok, allora QUIC è principalmente un framework front-end che fa server-side rendering, quindi nasce come server-side rendering, che però basa il suo modo di renderizzare la pagina, quindi renderizzare le applicazioni su concetti totalmente diversi, quindi dove magari con Remix, SvelteKit, Solid, Next hai quel modo di fare rendering, quindi più o meno dietro le quinte funzionano uguali, con Qwik è diverso, cioè funziona in maniera diversa.È diversa come? Ok, allora, questa è una bella domanda.È una bella domanda.Allora, principalmente con le applicazioni che fanno server side rendering, attualmente si usa la tecnica dell'hydration, cioè viene generata la pagina lato server, viene servita al client, quindi spedito HTML, CSS e JavaScript, viene servito come uno snapshot, quindi alla fine i primi millisecondi che vediamo nella nostra pagina sono dei millisecondi di snapshot.Dietro le quinte che cosa fa il browser? Tramite il JavaScript, HTML e CSS riesegue tutta la logica per attaccare ai vari bottoni, alle varie parti interattive, attacca di nuovo la logica per poter poi rispondere all'utente.Quindi fa un doppio lavoro, fa un lavoro lato server più fa un lavoro lato client.Con QUIC invece è totalmente differente, cioè quando viene generato il bundle per la produzione, invece di andare a creare un unico JavaScript, vengono creati dei piccoli chunk, quindi dei piccoli chunkettini, siccome il core team di QUIC segue sia la parte di rendering che la parte di bundling, cioè quello che è la creazione del risultato finale da spedire al sito web, quindi al nostro browser segue anche quella parte lì, è in grado di dividere il JavaScript in piccole parti.Questo che vantaggio dà? Dà un vantaggio che nel primo rendering noi renderizziamo solo html e css senza renderizzare del javascript o pochissimo, solamente quel javascript quindi pochissimo, un kilobyte di javascript che è in grado di attendere l'iterazione dell'utente, quindi quando poi l'utente clicca sul bottone eseguiamo solamente il javascript che permette animare la pagina.Quindi in poche parole stringendo con i framework soliti diciamo si fa hydration quindi doppia logica server e client con QUIC si spedisce HTML CSS che con le connessioni moderne è super veloce ed è per questo anche che è molto performante con i core web vitals e solamente se l'utente interagisce con una determinata pagina noi eseguiamo quel javascript che serve è un discorso molto lungo, lo so, però forse è più facile provarlo che spiegarlo.Quando dici "eseguiamo" intendi lo scarichi e lo esegui o lo esegui soltanto? Perché tu hai parlato "do soltanto l'HTML e il CSS e poi esegui il JavaScript", però quando lo scarichi, in javascript, nel momento dell'interazione, subito dopo, o c'è qualche automagia in mezzo? Sì sì, allora io ho usato giustamente la parola "eseguiamo", sarebbe dire "parsiamo ed eseguiamo".Per quanto riguarda la parte di download ci si affida al service worker, quindi con il rendering della pagina c'è un service worker che dietro le quinte già prebufferizza tutti questi cianchettini un po come un video streaming che guardiamo su youtube noi guardiamo il minuto 1 ma dietro le quinte youtube sta già caricando il minuto 1 e mezzo 2 3 è pronto lì per essere utilizzato lo stesso fa quick e quindi poi alla fine mette da parte questi cianchettini e solamente quando noi li vogliamo andare a fruire lui in realtà andiamo a fare una chiamata che però arriva prima al service worker e poi esce al server e chiaramente siccome il service worker ha la risorsa gliela ritorna subito.Quindi diciamo l'obiettivo non è tanto da non eseguire JavaScript ma eseguire il meno possibile sul main thread per mantenere tutto più reattivo quindi con un service worker effettivamente deleghiamo tutta quella parte di esecuzione just perché normalmente bloccherebbe il main thread in un altro thread praticamente.Sì, il download avviene tramite il service worker, poi l'esecuzione è solo l'esecuzione di quella piccola parte che necessita l'applicazione per diventare interattiva.Però nel download di fatto c'è tutto.Giusto per avere un'idea, quanto piccoli sono questi chunks? Cioè, del livello di funzione, del livello di oggetto, di file? Beh, allora, innanzitutto per creare i chunk, poi c'è dietro tutta una configurazione che fa delle logiche sue dietro le quinte che sono anche tra le altre cose configurabili, però sostanzialmente non è che fa un chunk per ogni funzione che può essere isolata, mette insieme più funzioni magari anche guardando che magari una funzione va poi a modificare più componenti perché modifica lo stato eccetera eccetera, quindi non abbiamo mille cianchettini, abbiamo un insieme di cianchettini che fa dei bundle.Questi bundle poi dipende chiaramente dai codici che ci mettiamo all'interno e soprattutto una cosa interessante è che se noi abbiamo dipendenze esterne solamente se andiamo ad utilizzarle scarichiamo il cianchettino della dipendenza esterna.Quindi puoi immaginare, non so, utilizziamo "dejs" solamente se poi andiamo a chiamare le funzioni della libreria andiamo ad eseguire la libreria stessa, il javascript della libreria stessa.Questa è una cosa interessante.È interessante perché diciamo all'inizio quando mi hanno parlato un po' di Tempo5, Io inizialmente mi ero fatto un'idea diversa, un'idea che era più vicina a quello che fa Live View o Live Wire o comunque queste tecnologie che servono tutta la parte di interazione con sistemi di WebSocket, una parte viene eseguita sul server, una parte viene mandata, eccetera.Quello che mi chiedo è come funziona tutta la parte di eventi, perché gli event handler sono il core della pagina web, come interazioni.Quindi si fa che quel piccolo chunk che magari prendo mi va a mettere solo in quel momento l'event handler su quella parte del DOM, però quella parte del DOM deve esserci già, me la mette lui, nel senso come funziona? Il componente che io scrivo nel mio codice sorgente ha più o meno una rappresentazione in quella parte di pagina che sto vedendo, in quella parte di interazione con cui sto effettivamente facendo i compiti sul browser.Ho fatto questa domanda malissimo, se non sei capito dimmi.No, no, beh io ho capito, nel senso, credo di aver capito, nel senso che quello che io poi scrivo nei codici lo ritrovo nell'HTML più o meno.Sì, sì.Alla fine sì, nel senso che quando poi tu ad esempio fai un classico bottone che fa un contatore, quando tu agganci l'evento onclick, che in quick si chiama onclick dollaro, il dollaro non credo sia per richiamare PHP ma è...Perché bisogna fatturare! Ok, penso di sì.Il dollaro è un marker che serve all'ottimizzatore che è scritto in RAST, quindi noi abbiamo detto il core team scrive sia la parte di rendering che la parte di building e il building è scritto su un server che è VIT, un bundler VIT con del codice RAST e praticamente questo codice RAST guarda i nostri file e cerca di identificare questi cianchettini.Dietro le quinte poi che cosa fa? Va a generare dell'HTML e mette all'interno dell'HTML degli attributi che servono poi a lui per capire che c'è anche Tino a scaricare, quindi l'evento onclick lui lo trasforma se non erro in on due punti click e poi all'interno c'è una closure che fa un import di un file, quindi in realtà una rappresentazione di quello che tu scrivi c'è, è un po' cambiato però c'è.All'esempio, se penso a Next, abbiamo comunque tutta quella parte isomorfica che un po' viene eseguita sul client, un po' viene eseguita sul server, nel momento in cui si fa tutta la parte di server-side rendering.C'è anche questo tipo di funzionalità, nel senso c'è del codice che viene servito solo sul server o solo sul client oppure in entrambi i posti contemporaneamente? Sì c'è questa parte qui anche su Qwik quindi ci sono alcune funzioni soprattutto anche rendering dello stesso componente avviene lato server poi viene servito sul client addirittura se il componente non ha iterazioni non ha dinamicità viene proprio neanche inviato il javascript viene inviato solamente HTML e CSS.Inoltre una cosa super figa, se si può dire in questo podcast, figa, è che alla fine si può mettere nel client, si può scrivere "server$" e poi la nostra funzione e quella funzione verrà eseguita lato server.Quindi io scrivo "server$" e sono in grado di poter fare eseguire quel pezzo di codice all'interno del server e questa è già una prima cosa che solitamente un po' lascia di stucco nel senso che io poi scrivo un qualcosa nel nostro componente però quel codice lì avviene lato server.Una cosa ancora più interessante che non è ancora documentata se non sbaglio a meno che non l'abbiano aggiunta da poco è che si può scrivere worker dollaro quindi se io devo fare magari una trasformazione di immagine per magari ottimizzarlo applicare dei filtri posso mettere worker dollaro e li metto la mia logica per andare a modificare un'immagine applicarli dei filtri ed eseguire quel pezzo di codice all'interno del worker in modo da non fermare il main thread che è il nostro diciamo peggior nemico quando si tratta di eseguire del javascript.Possiamo delegare parte delle funzioni sia con valori in input e anche ricevere dell'output sia al server che al worker.Ok ma come...apriamo un attimo il cofano perché io sono sempre curioso di aprire il cofano e vedere come funziona.Facciamo la cosa più facile forse.Appunto questo server dollaro che segue una funzione sul server.Da sotto alla fine che cosa fa? Scatena un evento che fa, che chiama un endpoint che è nascosto da qualche parte o c'è una connessione socket o qualche altra magia che ignoro, posso ignorare.Alla fine fa una chiamata HTTP su un endpoint conosciuto ed esegue, gli dice eseguimi questa funzione e poi mette l'hash della funzione ed il server la esegue e poi ritorna indietro i dati, quindi utilizza una chiamata HTTP.Se noi la volessimo fare con un altro framework che non ha questa funzionalità dovremmo prendere la cartellina API, esporre l'endpoint e dire che quella magari è una POST piuttosto che una GET e quindi poi gestirci anche quel file lì, con la logica ovviamente all'interno di quel file.Una cosa che non ho detto prima, noi possiamo inserire questa parte server o worker all'interno del componente e magari per alcuni che hanno sviluppato, sviluppano in PHP, inserire delle logiche all'interno del componente, logiche server all'interno del componente front-end è cosa naturale, però magari per i front-endisti, quelli più accaniti, inserire e mischiare le logiche tra back-end e front-end è un'eresia, si può prendere quella funzione e spostare su un file apposito e tenerlo lì, quindi si possono suddividere le due logiche.Ok, quindi diciamo, volendo ritornare anche un po' al core concept che ho letto in questi giorni sulla documentazione di QUIC.Quindi c'è l'idratazione dell'applicazione, che è quello che sostanzialmente avviene negli altri framework, e invece in QUIC c'è tutto il concetto di "resumable", che non non so come tradurre in italiano, quindi lo lasciamo così in inglese.Quindi quello di cui abbiamo parato ora fa parte di questo concetto e perché si chiama proprio insomma "resumable"? Perché effettivamente tu è come se mettessi in pausa una cosa del genere.Sì esatto, cioè è stato coniato, in inglese non esiste "resumability" come termine, perché viene eseguita la logica lato server, viene messa in pausa, serializzati eventuali dati che bisogna appunto spedire, vengono spediti all'interno del nostro browser e l'applicazione di fatto è in pausa.Nel momento in cui poi l'utente interagisce, passa da stato pausa a stato resumed ed è qui che poi nasce il termine resumability, cioè si riaccende.Ok, quindi diciamo per i frontendisti che sono all'ascolto o per chi fa già la scritta in generale, è come se ci fosse questo grande function generator che può essere messo in in pausa e si continua l'esecuzione.Se è così, non voglio rappresentare.Scusa Carmine, giusto perché mi è venuta una metafora al volo.Sembra quando tu stai cucinando qualcosa e fai metta cottura sui fornelli e poi finisci la cottura al forno.Se proprio volessimo fare un esempio, per me è quello.Cioè metti in pausa, trasferisci in un altro contesto e premi.e spadelli.Esatto.È scritto il modo in cui io faccio la pizza.Per le ricette solo ai Patreon.Le ricette di Luca.Luca is the new Benedetta.Scusa Carmine stavi dicendo qualcosa? No no no.È una metafora molto più calzante di quella che avrei potuto trovare io.Quindi, in realtà c'è una domanda che è più una provocazione, un po' come tutte quelle che stiamo facendo qui, ormai siamo fatti così.Quindi, essendoci comunque un server che serve questa applicazione, diciamo dal punto di vista di performance e di scalabilità, funziona.Nel senso, se dovessi pensare ad una single page application classica, se non voglio preoccuparmi di questa cosa qui, la metto su un bello bucket, poi ci metto Cloudflare, oppure mi hosto questi file statici da qualche parte, più di tanto non mi preoccupo di questa cosa.Quando invece parliamo di applicazioni che vengono servite da un server, quindi c'è anche tutta la parte computazionale dietro, è una cosa da tenere a mente.Come funziona la scalabilità di QUIC? Si possono mettere diverse repliche? Non lo so, sto parlando a caso.Diciamo che con QUIC, oltre a server side rendering non abbiamo detto ma si può fare anche static site generation quindi la stessa logica che viene eseguita quando io vado su una determinata rotta viene eseguita nel momento della build quindi io produco l'html tutti i cianchettini e poi lo vado ad inserire su un s3 ed ecco che replichiamo non dico lo stesso modello della single page application perché quello funziona in maniera diversa, però andiamo a replicare un po' quello che può essere un Oswald kit in site generation, in static site generation.Quindi poi in termini di scalabilità di quello non c'è problema, in termini di scalabilità di un server side rendering si comporta come qualsiasi altro framework che fa questo.Questa domanda è fatta perché ultimamente parlando anche con colleghi così, stiamo vedendo sempre più spesso ad esempio Next utilizzato come un vero e proprio framework monolitico.Ci faccio il frontend, ci faccio il backend, ci faccio qualunque cosa.quindi diciamo si ritorna un po' verso il vecchio framework monolitico che per un periodo abbiamo detto che non andava bene, tra un periodo c'è stato addirittura il micro frontend con il servizio, ora invece si sta un po' ritornando così all'ovile, che è anche un po' la stessa cosa che puoi fare con revizzo similari.Con Qwik c'è questa possibilità? È consigliato farlo o è sconsigliato farlo? Perché ti faccio questa domanda? Perché se andiamo ad interpellare le persone che ad esempio utilizzo Next non c'è una vera e propria risposta a questa cosa.Nel senso puoi farlo, il grado di libertà dove ti puoi spingere a fare questa cosa, questa cosa qui non è ben definita.è direttamente proporzionale al dolore che provi appena ti sei sparato nei piedi sì esattamente esatto era proprio questa cosa qui ed è legato alla domanda che vorrei fare subito dopo ok ho visto utilizzare next come un brutto l'animal con ancora più complessità dentro quindi con quick questa questa cosa si può fare non si deve fare è sconsigliato farlo come funziona? Direi come con Next, non è opinionata la cosa, nel senso che al momento non c'è un'opinione forte, rimane poi nella sensibilità di chi sta sviluppando di capire quando è ora di inserire della logica all'interno della stessa applicazione o quando è il momento di dire ok, però se noi facciamo così andiamo a schiantarci sul muro quindi si può inserire della logica e esporre delle rotte lato back end e poi sta al singolo sviluppatore la sensibilità e all'anche maturità d'esperienza di non farlo in determinati momenti.E' interessante quello che abbiamo appena detto io voglio portare una mia esperienza in qualche progetto fa arrivò un cliente e ci disse io voglio questo sito super sbrillucicoso che si muove da destra a sinistra facendo un doppio balzo carpiato rimbalzando qua e là con le lucine colorate ma voglio anche che si veda con la gente nei device vecchi con tipo mezzo k di memoria, cioè una roba...adesso sto scherzando mezzo k di memoria, però dei device vecchi oppure dei device con javascript disabilitato perché siamo legati a alcune normative per cui dobbiamo supportare, che esistono ancora, per cui portiamo...dobbiamo per legge supportare queste cose e quindi si apriva la porta della progressive enhancement o del progressive enhancement, non so come declinarlo comunque sia in quel momento io avevo degli spike per delle discovery session per capire che cazzo usare quello che noi cercavamo era la stessa dev experience che ci dava React perché comunque in un modo o nell'altro React ha rivoluzionato la Dev Experience nel frontend che piaccia o meno, così è e a quel punto ho pensato noi abbiamo bisogno di avere questa zona di comfort per essere veramente produttivi o comunque per non lavorare con i template pug, io non so chi lavori ancora oggi con i template pug o mustache, poverino lui nel senso che se lo paragoni al JSX la developer experience è completamente diversa qual è stato il vero problema? posto che si potrebbe discutere su che cos'è il progressive enhancement si javascript, no javacrypt ma tutti i device hanno javascript se lo vuoi disabilitare devi andare forzatamente a disabilitarlo quindi sei tu che ti stai escludendo, non è il mondo che ti esclude su questo potremmo rimanere tipo settimane a parlarne ma io ho quasi finito l'autonomia vocale e quello che mi sono trovata a fare è trovare un framework per fare questa roba e a parte Remix che all'epoca era tutt'altro che stabile, tipo mi cagava in mano a portarlo in un client enterprise, abbiate pazienza chi è che si prende la responsabilità l'avevano appena rilasciato open source perché prima chi lo sa era un prodotto a pagamento morale della favola si cercava un tool per il progressive enhancement alla fine si optò turandoci pesantemente il naso su next e si andò a utilizzare next che è stato un po' come davvero spararsi nei piedi è una delle cose che ha complicato di più in assoluto l'utilizzo di next e a parte il fatto che tu puoi dire a next di non mandarti il javascript al client se non lo usa, ma glielo devi dire settando una variabile che tipo si chiama non settare questa variabile perché ancora in beta appunto non mandare il javascript al client una roba di questo tipo è una cosa che ho notato cercando, forzando, provando, tinkerando quella una cosa che ho notato è che la sfumatura tra ciò che era back-end e ciò che era front-end diventava sempre più blurred ok? sempre più sfumata e dove prima c'era una chiara distinzione che era legata al concetto di richiesta-risposta che settava bene i due limiti quando mi sono trovato a lavorare con Next in quel modo dove dovevo per forza definire i limiti e non avendo questi limiti mi sono un po' trovato spaisato anche nel capire come avrei dovuto fare con Quick tu puoi fare la stessa cosa, tu puoi eseguire del codice server-side decidere se farlo girare solo server-side, client-side e via discorrendo e tutta la parte che noi anziani del codice siamo abituati, da qui noi anziani del codice siamo abituati di richieste e risposta viene in qualche modo nascosta silenziata ok? Resa trasparente non pensi che questa cosa possa essere un problema io non lo so forse sto traslando la mia esperienza in un contesto dove non fitta però boh è un'ottima domanda e anche il caso d'uso che ci hai portato secondo me è interessante anche condividerlo con tutti secondo me ti direi che guardando anche un'altra libreria che è TRPC che più o meno fa la stessa cosa cioè da frontend chiami un unico endpoint che solitamente è /api/trpc e lì vai in query parameter a passare tutte le funzioni che vuoi eseguire per poi eseguirle lato server quindi diciamo anche lì di fatto ti nasconde la complessità di dover creare degli end point, gestirti le cose come diciamo siamo sempre stati abituati a fare.Quella libreria lì c'ha sui 25.000 stelle su github e 220.000 download su npm quindi è molto molto popolare quindi ti direi che ok magari ci può far storcere un po' il naso però probabilmente è è perché siamo, non dico vecchi, però siamo abituati a un altro modo di ragionare, che non dico che sia sbagliato, è solitamente diverso.Forse non tanto vecchi o non vecchi, ma forse maniaci del controllo, o almeno questo è il mio caso, io devo sapere quello che succede sotto al mio sedere, non so voi.Il mio grande limite è proprio questo.Sì che poi in realtà roba nuova, sì ok, non sono concetti comunque nuovi, alla fine è tutto un corso di corso storico come c'era ixmlrpc, c'era gzrpc, c'è grpc con i propri e c'era AMFPHP che solo i più impavidi conoscono e chi programmava in flex3 e aveva il back-ending PHP che funzionava allo stesso modo mi avete aperto un cassetto della memoria, c'ho fatto dei CRM complessissimi così in realtà perchè questa domanda sulla strazione della richiesta client server? perchè in realtà che è uno dei motivi per cui a me non piace tantissimo gRPC e tutta la famiglia tRPC pipo Pluto RPC perchè in realtà la percezione dello sviluppatore è quella che la rete non esiste che tu stai facendo una chiamata di funzione è solo una questione filosofica e non una questione meramente tecnica la rete è una delle fonti di entropia più grandi dei sistemi dove lavoriamo concordate con me e quindi questo mi porta a dire a un po' aver paura e non è solo quick a spaventarmi sono next in primis, ripeto io mi cagavo addosso e dicevo si va beh ma aspetta questa roba dove gira? ah no aspetta c'è una funzione nel componente che si chiama get server side props quindi quel cianchettino gira sul server il resto sul client ma in parte sul server questa unione dei concern che viene un po credo dall'approccio della della della dell'unione dei concern fatto da react dove ti butto dentro sul componente logica css logica javascript css html e divido in slice verticali un po' sarò conservatore, sarò vecchio, alla fine mi dice "va bene, finché il progetto ha uno scope contenuto è ok" e quando lo scope esplode riusciamo ancora a gestirlo senza prenderci in carico la responsabilità di avere un overhaul su dove sta girando il nostro codice io ricordo una cosa che mi diceva sempre il mio professore di informatica 1 e mi diceva Mauro tu devi capire non solo cosa stai scrivendo ma dove lo farei girare e minchia aveva ragione da vendere oggi questa cosa un po' l'abbiamo persa con i tanti layer d'astrazione che abbiamo inserito e l'inserimento di un ulteriore layer d'astrazione mi fa dire ok.Altra cosa tra l'altro, visto che parlavamo di astrarre certi concetti e prima parlavi di più opinionato o meno opinionato, noi sappiamo che Qwik viene dal creatore di Angular, la stessa mente.Che cazzo è successo Giorgio? Spiegamelo tu perché è un tuo amico, no? E quindi lo conosci.Come...cioè...hai avuto modo di capire per quale motivo da un tool fortemente opinionato come Angular che è un binario battuto dove diciamocelo se tu te lo sei studiato è difficile smerdare fuori.ha un tool veramente libero dove la distinzione back-end e front-end è una delle libertà che hai ma anche immagino tante altre e quindi mi chiedo c'è stato un percorso condiviso con la community o un percorso del creatore che l'ha portato ad aprirsi? Allora, lui ha raccontato, all'annuncio della versione 1.0, quindi pochi giorni fa, ha raccontato un po' quello che l'ha portato a scrivere Quick.Lui ha detto che in una conferenza che ha avuto nel 2018, se non mi ricordo male, parlava già di questa idea che lui aveva, di poter renderizzare solo quello che serviva, eccetera, eccetera.aveva messo un po' la pulce all'orecchio alla community su quello che voleva poi realizzare.Solo che ha detto che lui ha lanciato l'idea, però nessuno l'ha colta e poi nessuno degli sviluppatori che conosceva comunque delle community in generale si era poi messo a lavorarci seriamente.Quindi poi si è messo lui di sua spontanea volontà perché comunque ci credeva e poi ha trovato nella società che sta seguendo Quick un partner per poterla andare a sviluppare e realizzare la sua idea.Lui in realtà dopo anni di Google ha deciso, gli è venuto in mente come poter sistemare il problema che affligge molte applicazioni frontendiche, quelle delle performance, perché se andiamo a vedere le performance di molti siti, le andiamo a verificare su Pagespeed, che è un tool offerto da Google.Vediamo che molti dei siti non passano appunto questi famosi parametri necessari per rendere le applicazioni performanti, comunque fruibili tranquillamente.Lui aveva questa idea e quindi se l'è poi portata avanti nel corso del tempo, quindi è da un po' che c'è dietro.Quindi questo tipo di paradigma di Quikly maggior aiuti anche dal punto di vista serio, a questo punto che era anche uno dei punti tipoli di tutto il mondo delle single page application, che nonostante siano belle, fighe e sbrucicose sui core web-items non vanno benissimo, devi inventarti qualche soluzione un po' più così, dal punto di vista se sono proprio ben viste.Col corso degli anni sono state migliorate tante cose, però effettivamente, per come me lo stai descrivendo, bisogna avere un tool che aiuti anche da questo punto di vista.Io ho sentito frizzata la voce.Anche io.Ah ok, allora ripeto e tagliamo.Da come mi stai descrivendo, mi sembra che veni in conto anche a quell'esigenza di ottimizzazione dal punto di vista SEO, che è una di quelle cose che affligge comunque tutt'oggi seppur con tanti miglioramenti le single page application.Quindi con Qwik è possibile fare un first full render che sia veramente pensato, nel senso io voglio che appaiano queste sezioni con questo HTML con questa semantica perché fa bene anche alla mia parte SEO insomma.Sì sì ti dirò alla fine non bisogna neanche sbatterci più di tanto la testa nel senso che si sviluppa l'app come si ha sempre sviluppato e tra l'altro come sintassi per la parte di templating si usa JSX può piacere non può piacere però comunque è uno dei più famosi e quindi è stato deciso di utilizzare quello perché appunto è tra i più famosi e quindi io sviluppo l'app tranquillamente poi di fatto per come è pensato il framework mi ritrovo già ad avere delle performance che non sfiorano il 100 per cento poi chiaramente le immagini che sono in WebP ti portano al 100% oppure della dimensione caricata correttamente ti portano al 100% però già di suo sviluppando quindi potrei dire anche uno junior mi posso anche vendere questa cosa cioè lo junior sta sviluppando l'app e di suo non è che deve pensare questa parte di applicazione devo caricarla l'easy piuttosto che l'altra lo fa già di suo il framework quindi posso avere già un'applicazione che permette di avere performance e SEO che sono necessari per i siti pubblici per esempio.Faccio il ravecchio della situazione? Ho controllo di questo, posso avere controllo allora lo volessi sapere o controllare cosa viene renderizzato prima, cosa viene renderizzato a runtime, cosa viene renderizzato sul server che poi viene spedito al client, perché da quello che hai detto non ci devi pensare, ci pensa il framework, però siccome appunto vecchio, se ci voglio pensare posso pensarci?" Sì, c'è la possibilità, sì, c'è la possibilità tramite configurazione di poter decidere cosa renderizzare, come e perché.C'è la possibilità per chi vuole effettivamente spingersi al di là di quello che poi già il framework ti dà out of of the box, perché ci piace usare gli inglesismi, si può fare tramite configurazione.Una domandina che avevo in mente in questi minuti.Abbiamo detto che è un framework, perché è un framework, c'è la via triva su React che è una libreria, è un framework, quindi QUIC è un framework e che cosa non ha in suo interno che ci dobbiamo apportare, tipo non lo so, per fare richieste esterne, HTTP o interazioni col database o che altro, c'è qualcosa internamente che offre QUIC o ci dobbiamo apportare le nostre librerie di fiducia dentro.Allora è più o meno come gli altri framework, quindi come React, cioè non è come un Angular che già ti dà tutto un pacchetto pronto.Di fatto però quello che vai ad utilizzare adesso è che ormai Fetch è diventato lo standard.Si utilizza Fetch per fare le chiamate HTTP e poi già nel Core, quindi nel Core del Framework, ci sono tutta una serie di integrazioni che è possibile utilizzare tramite CLI, quindi io posso non solo andare a decidere di aggiungere ad esempio Tailwind e quindi c'è chi piace chi non piace comunque posso aggiungere Tailwind e quindi dico "quick add Tailwind" e lui già ci configura tutto, ma per parlare con il database c'è già l'integrazione con Prisma piuttosto per andare a fare end to end c'è Playwright piuttosto che Cypress e anche tutta la configurazione per quanto riguarda il cloud quindi abbiamo Azure, Cloudflare e Google non vorrei dimenticarvi qualcuno quindi poi c'è la lista non vorrei allincarli tutti.So che stavate facendo qualcosa con AWS perché te l'ho sentito dire nel podcast degli amici di continuous delivery no? Sì sì sì aziendalmente stiamo siccome siamo partner AWS stiamo portando avanti l'integrazione con AWS lambda quindi no not a margine risalutiamo come in quasi tutte le puntate edo paolo e tutti i ragazzi di continuous delivery.Hai parlato di testing è una roba che io ho utilizzato a parte playwright e cypress per fare gli end to end test una roba che io ho usato fino alla nausea e l'ho amata e odiata contemporaneamente era testing library nel caso specifico react testing library è utilizzata prevalentemente per fare dei test end to end, la utilizzavo io almeno per fare i test unitari di componente.Abbiamo qualcosa del genere in ambito Qwik? Attualmente che io sappia no, però comunque i progetti che partono dagli sviluppatori individualmente ne sono tanti, ad esempio c'è tutto il modulo per gestire le form, un po' come fosse React Hook Form, quindi alla stessa maniera più o meno c'è una libreria che ti permette di farlo.Quindi sono tanti sviluppatori che stanno un po' cavalcando l'onda e stanno creando la propria libreria per il proprio caso d'uso.Tra l'altro, qui mi faccio autosponsorizzazione, ho sviluppato il componente Image, che è il componente che ti permette di avere delle immagini ottimizzate e l'ho messo appunto come libreria per Quick.E questo dimostra il fatto che essendo un framework giovane e scommettendoci addosso rischieresti di comunque ritagliarti un pezzo importante in quella community che è una cosa interessante ed è un po' la scommessa che hai fatto.Tu hai fatto all in su Quick.Io mi ricordo sei venuto qua ai nostri microfoni e hai parlato di Svelte, Svelte e Svelte Kit, tra l'altro mi sono divertito un sacco in quell'episodio a fare lo stronzo a provocarti, ma non ti ho fatto arrabbiare, infatti ho detto "adesso devo capire se Giorgio è tipo un monaco buddista o cosa, perché aveva tenuto la plomb super tranquillo e io rompevo i coglioni come pochi".No, però a parte questo tu hai veramente fatto all in su Quick e la community sta crescendo e ci sono un sacco di spazi.So che hai lavorato anche ad altri elementi all'interno di Quick, no? Altri sottoprogetti, chiamiamoli così, o progetti correlati.Come è stato costruire un progetto all'interno di quella community? Come l'hai vissuta l'esperienza? Allora, diciamo che comunque come community è molto coinvolgente, non ci sono i cattivi di turno, quindi quando si fanno magari delle domande semplici, non ti dicono "vai a leggerti la documentazione", ti cercano comunque di dare una mano.e questo è un grande vantaggio e come ho detto forse da altre parti secondo me è l'API quella che non è con il codice è l'API quella feature che effettivamente ti può fare la differenza tra un framework che poi prende effettivamente piede e uno che invece rimane indietro essendo che ho scommesso fin dall'inizio su QUIC poi ho avuto la fortuna di poter entrare all'interno del server, c'è un canale che sono i Quick Heroes, chiamato così, che sono quelli un po' che sono gli early adopter, quindi molti annunci come quello dell'annuncio della versione 1 che sarebbe stato appunto fatto, l'ho avuto in anteprima, quindi alcune informazioni vengono comunque date in anteprima e alcuni progetti come quelli che sto seguendo, sto seguendo una libreria di componenti per Quick, quindi sono maintainer di quella libreria e l'idea è nata da lì, l'idea di fare una libreria di componenti e lì poi ci siamo messi, diciamo settimanalmente ci troviamo per andare a decidere come poter sviluppare il tutto e ci abbiamo investito diverso tempo, non lo nego, però comunque sono soddisfazioni.Ti faccio una domanda che è avuta ora mentre parlavamo.Come funziona, o almeno è integrabile, tutto il sistema di RPC, sostanzialmente col singolo e apponti le sezioni delle funzioni sul server con una possibile autenticazione, nel senso c'è già qualcosa pronto per tutta la parte di autenticazione, più nel dettaglio, autorizzazione della serie, se replico quella chiamata e la forgio e quel pezzo di codice che viene sul server e solo per gli utenti o per l'utente dei copallo.Il framework ha un modo nativo come integrazione per prevenire che io faccia questa cosa se non ho l'autorizzazione giusta? Sì, c'è l'integrazione con Out.js che diciamo è il vecchio Next Out.js, poi ha cambiato nome quando è diventato cross framework e c'è l'integrazione se non sbaglio forse fatta direttamente da un core del team, non vorrei sbagliarmi, e quindi direttamente si può integrarsi e avere la sessione tramite, che è un po' quello che mi chiedevi, la sessione dell'utente quando poi io eseguo le varie chiamate eccetera eccetera.Quindi c'è già questa integrazione e come prossimi step diciamo dalla versione 1 adesso abbiamo un qualcosa di di stabile, il team ha detto che vuole in un futuro, nelle prossime settimane, prossimi mesi, aumentare ancora di più queste integrazioni per poter dire "ok, abbiamo praticamente tutto, cioè voglio integrarmi con GraphQL, lo posso fare, ecco che con la CLI lo posso integrare velocemente, voglio fare quest'altra cosa, ecco che ho già tutto pronto".Quindi l'obiettivo è anche andare in questa direzione.Ok, ok.E Quick City invece? Sto parlando adesso sulla documentazione.No, mi ha detto Alberto.Chiedo.Allora, Quick City è praticamente la parte di Routing, quindi la libreria che dà Routing e fa il server-side rendering.È stata chiamata City, onestamente non so perché si chiama City, però credo che sia per le route, che sono le rotte, quindi ho immaginato fosse strade, quindi poi un gioco di parole e l'hanno chiamato Quick City.È un nome a mio avviso poco felice, però alla fine un nome dovevano dare e è andato quello.Quindi Quick, diciamo, è la parte di rendering, la parte di logica applicativa, cioè così la possiamo chiamare, mentre la libreria quella che ti dà routing e altre funzionalità è Quick City.Scusami, a parte che quando hai detto Quick City a me è iniziata a suonare in testa la canzone di matta fix giusto a dimostrare che sono super vecchio big city life no? lights però cazzo mi sono dimenticato la domanda sono proprio una merda no volevo chiederti in realtà hai parlato della kli il concetto di kli è un concetto potente che si vede pesantemente in angular ma che in altri framework è un po più remissivo lo spazio della CLI per la logica del codice generato dolore nel mantenerlo.Come lo vedi nel contesto di QUIC questo tipo di problematica? Lo so sono rompi coglioni non volerne io ti voglio bene ma sai faccio sempre domande stronze.Allora devo dire che sono molto attenti a questa cosa e qui posso portare un mio caso personale nel senso che avevano chiesto all'interno del server discord chi aveva voglia di poter implementare quella famoso componente immagine che alla fine cosa fa? Vrappa l'immagine ma ci aggiunge magari le funzionalità di pre-loading eccetera eccetera quindi ti arricchisce già quindi ti wrap un po' le difficoltà di poter renderizzare un'immagine che strizzi l'occhio alle performance e avevamo detto ok chi ha voglia di implementare poi le inseriamo nel codice core.Io ho detto va bene benissimo ho la possibilità di poter entrare dentro il codice core e ho implementato la funzionalità.Una volta implementata però passa il tempo passa il tempo la PR rimane lì e a un certo punto ho chiesto l'UMI e mi hanno detto guarda mi dispiace ma non vogliamo includere altro codice che poi dobbiamo mantenere all'interno del codice core e quindi poi io facendo parte di questi qui Kiros che abbiamo detto prima abbiamo anche un account github e quindi ho creato lì la libreria.Direi che loro sono abbastanza attenti a queste cose, diciamo che poi lo starter per le nuove integrazioni non è troppo codice da dover mantenere.Mi ero segnato questa cosa, l'ho ritrovata.Leggendo un po' in giro ho trovato anche persone che utilizzano React con Qwik, questa libreria si chiama Qwik React.Allora che senso ha? Uno perché immagino il motivo sia utilizzare quello che uno ha già, ma come riesce ad integrarsi il tutto e soprattutto è una cosa consigliata? Si fa che io posso vedere qualunque libreria React potercela applicare dentro? Grosso modo ti direi di sì, nel senso che è stato fatto perché comunque va beh React e JSX quindi il templating è simile e poi per aumentare l'adozione è stato deciso di fare questa API che sostanzialmente wrappa il componente React e lo rende utilizzabile in QUIC.Questo è pensato non certo per andare in produzione o comunque per portare questo tipo di approccio alla lunga, ma per appunto pensare a una migrazione graduale delle proprie applicazioni con QUIC.Diciamo che si va a perdere un po' i benefici che sono la resumability eccetera eccetera però in una fase di transizione è più che accettabile.Ok Carmine mi aveva rubato la domanda che era esattamente quello che volevo fare.No, trovo molto molto molto interessante il concetto che è alla base di Qwik, quindi dividere il javascript in chunk che vengono caricati in anteprima dal service worker senza interferire con il main thread e poi caricare ed eseguire anzi soltanto quello che solo quello che serve e tant'è che stavo pensando che aspita stavamo rifacendo il nostro back office in react che che quasi quasi mi sarebbe piaciuto provare, cominciare a mettere i tasselli di Qwik.Adesso ho considerato che siamo in una fase ancora di templating, di mockup quasi quasi, stavo vedendo se esisteva un tool o un qualcosa, non so, una LEA, un comando che potesse fare una migrazione automatica, ma questo mi sembra che non sia possibile.Quindi non usare React dentro qui che puoi migrare pian piano, ma proprio una migrazione uno a uno di componenti o moduli o modelli o non so che cosa.Cosa mi consigli fare? Di fare, detto in soldoni.Ha senso interrompere tutto, rifare da zero quello che stavo facendo o usare un approccio? Mi piacerebbe provarlo.Ok, allora, quello che solitamente consiglio è se tu hai un'applicazione che già ti dà dei soldi, ti sta facendo guadagnare eccetera eccetera, magari non prevedi dei nuovi sviluppi, prevedi che magari possa rimanere così a lungo, quindi senza nuove funzionalità non ti consiglierai di andare a migrare tutta la codebase per passare a QUIC solo perché esiste QUIC.Diverso invece che se hai un sito pubblico che ha bisogno magari delle performance che diciamo prima, che magari sono difficili da ottenere e bisogna ottimizzare parecchio per raggiungerle, lì invece ti direi magari prova in maniera incrementale a migrare il tuo sito, la tua applicazione.Sempre nel server discord ci sono molti esempi di magari dei siti che sono magari di diaste che magari l'home page che è quella che magari viene visitata di più e che viene raggiunta dai motori di ricerca, viene migrata solo alla homepage a quick, il resto invece è con la tecnologia che hanno sempre utilizzato.Quindi fanno anche questo approccio ibrido proprio per sfruttare il fatto che come performance è il top.Hai parlato di siti, ma secondo te è maturo abbastanza da provare a scommettere per fare un back office, quindi proprio un gestionale, un dashboard form su forma, immagini e chi più ne ha più ne metta? Sì sì, a mio avviso sì, per quanto riguarda invece il back office, se hai già un'applicazione che gira e funziona, l'utente del back office anche se aspetta quel secondino in più non fa la differenza.C'è da dire che comunque per l'approccio che ha, quindi se io vado a interagire con una determinata pagina e eseguo quel javascript, non importa se la tua applicazione è piccola o enorme, alla fine quello che sono le performance sono sempre le stesse, cioè lui spedisce HTML, CSS e quel singolo kilobyte di JavaScript.Quindi anche se la tua applicazione è enorme, non vai a pagare il JavaScript di tutta questa applicazione enorme perché tanto la vai a eseguire in maniera lazy.Questa è una grande funzionalità.Esattamente quello che appunto pensavo come vantaggio perché mentre un sito bene o male può rimanere fisso nel tempo, un back office di di un'applicazione che sempre in continua evoluzione può complicarsi anche a piacere oppure anche in modo esponenziale nel corso degli anni e quindi quello che per te non è una priorità, quindi la sovra-ottimizzazione dei tempi o il fatto di non tenere in considerazione le performance a un certo punto cominceranno, comincerà ad essere una priorità ma sarà anche troppo tardi per poter intervenire chirurgicamente, diciamo, a migliorare le prestazioni.Io ho una domanda, un beso di Giorgio.Se io dovessi, ad oggi, iniziare un nuovo progetto con Qwik, cosa mi consiglieresti di fare? Che percorso mi consiglieresti di prendere anche per apprendere quelle che sono i nuovi concetti per esempio la riesumabilità è uno ma so che ci sono altri concetti under the hood che un po' cambiano questa è una bellissima domanda se io doveressi approcciarmi alla nuova applicazione con quick o comunque in generale a questo punto è un discorso che farei più in generale.Con una tecnologia che non ho mai utilizzato, comunque nuova, andrei a cercare di capire quali sono i pezzetti che mi servono, cioè mi serve l'autenticazione fatta con Cognito.Ok, provo a fare un POC dove integro quel tool, quello strumento.Dopo devo utilizzare server Postgre, database Postgre e utilizzare Prisma, provo a fare un POC dove mi connetto al database e dialogo, quindi faccio delle prove per verificare che effettivamente la tecnologia, ok è nuova però, va a coprire le mie necessità, perché magari il rischio è quello di dire "ok partiamo con QUIC perché è il nuovo framework, è in AIP, tutti siamo contenti di lavorare eccetera eccetera poi ci troviamo che alla settimana 7 di 15 dove quindi siamo a metà del nostro percorso e dobbiamo rilasciare assolutamente ci accorgiamo che magari non riusciamo a integrarci con l'autenticazione e quindi ci troviamo fermi bloccati e quindi conviene pensarci prima magari con delle spike dei POC per verificare che tutti i pezzetti possano effettivamente tornare e poi lavorare, iniziare a lavorarci seriamente.O magari sarebbe una buona occasione per contribuire al progetto, sviluppando quello che ti manca e quello che ti serve.Piccola sponsorizzazione al mondo dell'open source.Chi è che usa la produzione Qwik davvero? Allora ci sono diverse aziende, poi chiaro che ci sono quelli che le usano e quelli che lo pubblicizzano.La stessa azienda che l'ha creato ovviamente ha il sito principale e altri siti, tra l'altro se non sbaglio anche il sito quello del Super Bowl che quando accade ha un carico non da poco, è stato fatto con Quick.E poi c'è un'altra persona che ha sempre presentato il proprio use case durante la presentazione della versione 1.0 ha detto che ha fatto un sito, no profit, eccetera, eccetera e gli era capitato appunto di fare una presentazione all'interno di uno stabile che era situato in una città dispersa e quindi poca connettività e oltretutto l'ha fatto in un sala meeting dove effettivamente prendeva poco segnale.Quello che è successo è che anche i partecipanti al meeting che hanno visto la presentazione si sono domandati se il sito che caricava in pochi millisecondi fosse un mock o un sito vero e proprio.Così poi il presentatore ha detto "ok andate con il vostro cellulare a vedere" e le persone coinvolte hanno detto che effettivamente tutti i siti che andavano a visitare, essendo che la connettività era bassa, solitamente ci mettevano diversi secondi mentre quello che poi ha creato lui e che presentava al pubblico ci metteva pochissimo devo dire che l'idea di Quick è geniale ditemi se mi sbaglio ma io la trovo molto molto molto vicina ha l'idea che ebbe Daniel Ek quando fece Spotify non so se vi ricordate no? Daniel Ek aveva come obiettivo, non mi ricordo forse 30 millisecondi per il caricamento della canzone e quello che fece con Spotify possiamo immaginarlo come un web worker ehm...perdonami un service worker che quando tu stai ascoltando una canzone in background ti sta scaricando anche le successive pronte per essere playate quindi un po' lo sento questo flavor quando ci parli di quick mi sbaglio ritorna un po' il concetto non conosco nello specifico il caso che hai portato però credo di sì visto delle somiglianze non posso che dirti secondo me sì.Naturalmente questa questa lasciamo la discussione al gruppo telegram però lo sentivo l'odorino di proprio di di ambito diverso ma più o meno stesso concetto no quindi io ti servo quello che ti devo servire subito nel minor tempo possibile e poi con calma ancora prima che tu me lo chieda o appena che me lo chiedi io te lo do subito.Mi immagino che adesso boh un domani si potrà arrivare a dei framework dove se tu passi il mouse troppo vicino a un pulsante lui quel pezzo di funzione se lo scarica ancora prima di cliccarlo sarebbe fighissimo una feature di questo tipo no? e quindi in questo caso controlli non solo quello che viene dato in carico al main thread di javascript ma anche quello che viene dato in carico alla rete si si ci sono dei concept che lo fanno diciamo anche ok che in base...credo che si chiami guess.js o qualcosa del genere cioè in base poi anche a delle metriche che vengono salvate dicono ok l'utente quando entra la prima cosa che fa è cliccare quel link e quell'altro link invece non lo clicca mai quindi è chiaro che magari si dà la precedenza al download di quel determinata sessione si ma proprio per come è costruito Quick e per come funziona Quick secondo me questa cosa sarebbe fighissima per i siti di contenuto ad alto trafico.Ho visto che intanto dovevamo sempre essere rapidi, ormai sono anni, tre anni che esiste il podcast, tre anni diciamo che dobbiamo stare dentro l'ora e siamo come di consueto abbondantemente oltre l'ora.Grazie Giorgio per aver condiviso guest.js nel gruppo interno.È arrivato il momento tipico e topico di Gitbar, il momento...il Paese dei Baluchi.Momento in cui i nostri guest e i nostri host condividono con noi qualcosa che abbia catturato la vostra attenzione, la loro attenzione e che pensano sia porti valore condividerla nella nostra community.Io non riesco più a articolare il discorso quindi lancio subito la palla a Giorgio hai qualcosa da condividerti con noi? E conducono il paese dei balocchi! Ah il paese dei balocchi! Sì allora io volevo condividere un libro per gli amanti anche della Module Federation Il libro è "Building a Microfront Dance", qui in camera si vede, ok, e del mio amico Luca Mezzalira.A me è piaciuto molto, soprattutto perché nella parte finale sono racchiuse tutta una serie di esperienze che i vari utenti che sono stati intervistati hanno lasciato.Quindi l'ho letto molto volentieri e lo ringrazio per questa perla, dai, che ci ha regalato.Bello, bello, bello, è stato… Luca venne la prima volta qua quando lo stavo ancora scrivendo, è venuto la seconda volta per parlarcene ed è veramente un bel libro e Luca è anche lui un amico di Gitbar, quindi super baloco, super apprezzato.Carmine, Luca? Allora, io vorrei portare qualcosa che ho scoperto qualche giorno fa, è un libro, si chiama "I programmers introduction to mathematics", puoi guardare anche la mia app, sono abbastanza tappato anch'io, ed è praticamente un libro in inglese dove sostanzialmente vengono trattati degli argomenti di matematica base che sono, secondo l'autore, una base solida da avere per chi sviluppa software.La chiamo matematica base ma in realtà è abbastanza variegato, dai polinomi ai grafi alle atrici alle equazioni alle serie numeriche insomma diciamo è un po eccetto c'è diciamo un po' un misto sia con degli esercizi sia insomma con la parte teorica che viene spiegata Io sono una caprissima matematica, ho fatto analisi 6 volte a NAS24, lo dico senza vergogna, anche per me è stata una ripetizione ed è spiegato molto molto bene, perché è spiegata in una maniera molto pratica e legata a concetti di programmazione che sono strettamente legati alla matematica, ma che spesso magari ignoriamo e che c'è più facile comprendere nella loro declinazione, nella loro declinazione della programmazione.È un libro gratuito che potete scaricare con 0 o più euro, se volete fare una donazione all'autore, oppure potete comprare la copia fisica mi pare una quarantina di euro.Bello, bello, è un backlog.Luca? Bello, allora proprio oggi mi è capitato tra le mani, anzi davanti agli occhi, un video di youtuber che fa riferimento a un libro che avevo già ballocato proprio nell'episodio con Luca Mezzalira che è da software di Architect Elevator, quel libro già ballocato e quindi non lo riciclo, in realtà oggi ho visto mi è capitato tra le mani un video dove proprio l'autore Gregor Hoppe fa sostanzialmente un riassunto di una parte del suo libro, di questo libro che è molto interessante e che cito quello che ho detto l'altra volta, dobbiamo lavorare in modo che il sogno di un software architect non diventi l'incubo dei programmatori, dei sviluppatori e in generale dell'azienda, dell'azienda stessa.Che lascerò il video, il link del video in descrizione, però...Mettiamo anche il link al libro che...Mettiamo anche il link al libro, certo.Che è valevole di condivisione.bello bello c'è praticamente io pensavo di avevo pianificato di farvi un po di vacanze tra qualche settimana e praticamente mi avete rovinato le vacanze raga cioè aspetta non mi avete rovinato le vacanze a me avete regalato le bellissime vacanze le avete rovinate a mia moglie ma ora vuoi uscire no aspe un altro capitolo per favore questa sarà la situazione standard io non vi porto un libro perché ne abbiamo condiviso abbastanza Vi porto due giocattoli.Il primo è un browser.Io ho su Mac ed ha tempo che utilizzo Arc in Preview, un browser particolare con un sacco di funzioni, ne ho già parlato in un altro episodio, però a questo periodo ho ripreso a utilizzare la mia macchina Windows e mi mancava Arc.mancava ARC, non esiste per Windows, esiste solo per macOS e cercavo un browser che mi permettesse di avere dei tab always on delle folder ben gestite funzionalità di notifiche integrata fatta bene con i beggettini nell'applicazione che riceveva l'annunzio.Insomma mi serviva un browser un pochino più intelligente del classico Chrome ne ho beccato uno che non è ARC ma in qualche modo ci si avvicina il suo nome è Sidekick, usa Chrome sotto il cofano, è un browser carino, ci sono diversi workspaces, puoi crearti diversi workspace è una roba bellina, quindi buttateci un occhio se anche voi avete Windows o simili perché credo sia per tutte le piattaforme, non vorrei sbagliare.Secondo balocco, balocco Game Changer se non sei un native speaker, balocco baloccato tante volte ma c'è stata una major release devastante, Grammarly raga.Allora io ho l'abbonamento pro a Grammarly e ho anche, siccome sono proprio capra, ho anche l'abbonamento pro a WordTune, un tool che fa sentence rewriting.Li ho fatti prima che uscisse con tutto il clamore GPT e i suoi baldi giovani amici e ho fatto i due abbonamenti da un anno.Questa settimana, credo, Grammarly è uscita con una feature che praticamente mi fa chiudere l'altro abbonamento che è WordTune che si occupava appunto della riscrittura delle frasi perché in realtà ti permette la riscrittura delle frasi ma la cosa più bella ed è il motivo per cui a me stavano antipatici questi tool e mi ero sviluppato il mio text editor ne ho parlato con qualcuno di voi e anche in un episodio credo se non l'ho fatto vi farò un episodio a breve dove vi racconto l'esperienza di farsi un text editor perché mi ero fatto il mio text editor? perché non riuscivo a integrare tutti questi strumenti e allora facendo un po' di reverse engineering e di impiastriciamenti e hacking vario mi ero fatto il mio text editor dove avevo sinonimi e contrari ben integrati avevo sentence rewriting, grammarly, le API di reverse che non sono pubbliche ma io lo sappiamo basta una fetch, fatta bene e insomma tutte queste belle cose e poi Grammarly esce con una feature dove il Grammarly plugin non è più solo ben integrato nel browser motivo per il cui io per lungo tempo ho utilizzato Slack nel browser ma si integra perfettamente col sistema operativo quindi qualunque casella di input di testo all'interno del sistema operativo sia l'input box di Slack che la chat qua su StreamYard c'è il plugin Floating, l'icona Floating di Grammarly e tu hai tutte le funzioni di Grammarly compresi il test Rewriting con la "i" ovunque all'interno del tuo sistema operativo per chi come me scrive un'inglese raccapricciante e anche per chi lo scrive abbastanza bene un ottimo modo per andare a spottare porcherie o alienismi che tanto ci scappano perché non siamo native speaker detto questo io ringrazio tantissimo Giorgio per essere venuto a trovarci come sempre e tu ben sai Gitbar è anche casa tua se riesci a ritagliarti del tempo Ho visto che anche tu stai facendo più date dei Rolling Stones stai girando parecchio questo periodo quindi comunque quando vuoi qua c'è sempre una birra fresca per quanto virtuale pronta a essere stappata Grazie mille, grazie mille è veramente un piacere innanzitutto parlare con voi spendere del tempo insieme parlare di tecnologia è qualcosa comunque di molto bello sapere che qui poi posso sempre trovare una birra fresca è una figata anche perché la birra calda fa cagare a me in comune quindi io ringrazio anche Carmine e Luca e devo dire una cosa io oggi sto veramente di merda ne siete accorti che la mia lucidità è praticamente assimilabile alla lucidità di Uncle Bobo mentre twitta quindi devo davvero ringraziare di cuore Carmine e Luca che praticamente sono gestiti la puntata e tra l'altro si sono gestiti una puntata che mi è piaciuta un botto e che quindi voglio dirvi che il fatto che i cost gestiscano buona parte della puntata sarà il mio obiettivo del 2023.Quindi, cazzi vostri, raga! Ma in realtà ti ricordi gli ammutinati? In realtà ti stiamo abbelenando pian piano, così ti facciamo fuori e prendiamo di nuovo finalmente...Si, no, è davvero bellissimo, io sono in un brodo di giugiole, grazie, grazie di cuore.Grazie a te e soprattutto speriamo di aver fornito gli strumenti necessari per essere anche oggi, anche questa settimana, sviluppatori migliori con un occhio alle performance che sono spesso distrattate, spesso sottovalutate, ma secondo me sono importanti e ci dobbiamo dare sempre più occhio e attenzione.Io vi ringrazio di cuore ragazzi e vi do appuntamento alla prossima settimana anticipandovi che ci saranno tantissimi tantissimi topic interessanti ve ne spoilero giusto uno per mettervi la culina in bocca uno sarà Parleremo di GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.Hai detto la parola magica? Piantalo! Maledizione! Che stronzi questi programmatoni! Telefona a quelli di Metri.A Cambridge.
