Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori La temperatura è sempre più calda, noi potremmo andare in ferie ma siamo ancora qua E con me ho un super amico, uno dei primi, una delle persone che è stata tra i primi ospiti Di Geekbar ed è rivenuto a bersi una birra con noi quando Ed è un miracolo perché a più date di Vasco Rossi dei tempi d'oro infatti nell'immagine mia lo immaginavo su...non so se avete presente i camper americani delle tournee delle rock band lo immaginavo su un camper a fare da una conferenza all'altra ma prima di presentarvelo il mio ruolo quello un po palloso è di ricordarvi rapidamente nostri contatti.Info@gitbar.it e @deathbrainrepo su Twitter sono i modi canonici per entrare in contatto con noi.Anche se devo dire che il gruppo Telegram è ormai diventato la nostra casa.871 membri che si danno una mano a mo' di banco del mutuo soccorso ma anche con i quali appunto scambiamo opinioni spesso contrastanti e ci divertiamo talvolta a condividere meme per chi non l'avesse ancora fatto mi raccomando iscrivetevi benvenuti su github il podcast dedicato al mondo dei full stack developer i mezzo artigiani mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo detto questo è arrivato il momento di presentare il nostro ospite ho con me Francesco Sciuti ciao frà come stai? Bene, molto bene.Non vado in tour da una conferenza o un'altra, ma vado in tour di notte dondolando da un bambino a un altro.Sono grandi soddisfazioni anche quelle se non maggiori.e ti devo dire che una cosa che hai detto cambierà il mio omaggio, il mio tipo extra extra mondo dello sviluppo quello, vabbè dopo ti dirò, dopo ti dirò ah sono curiosissimo mi hai messo la pulce sull'orecchio beh in realtà però l'immagine sai di vederti dentro un camper che fai una lunga turné per tutti gli States ci sta a palla, tra l'altro so che sei anche musicista tu no? Lo ero, lo ero, ho suonato per tanti anni la batteria, intanto ciao a tutti, insomma cosa mi ho salutato quando faccio adesso, ho suonato per tanti anni la batteria, con scarsissimo successo, però devo dire che mi divertiva molto e ti devo dire che già una cosa The Road negli Stati Uniti l'ho fatta, avevo una Focus, non era un camper, però è stato super divertente.Certo combinare le due cose sarebbe stato il massimo, ma per adesso ci facciamo abbassare quello che abbiamo.Chi lo sa, chi lo sa, magari un domani.Beh, mai dire mai.Domanda.Tu è da tanto tempo ormai che ti occupi di web, no? Ed è un mondo dove ci sguazzi abbastanza abilmente come casa tua.Lo vedi un po' come casa tua.Allora, la mia domanda è, siccome sei stata una delle persone che ne ha parlato di più in giro per l'Italia di questo concetto, volevo chiederti, qual è lo stato di salute delle progressive web apps? se ne parla ancora, se ne parla di meno, stanno perdendo appeal? Come lo vedi? Allora, questo è una domanda un po' curiosa, è un po' dalla risposta non scontata.Lo stato di salute delle progressive BAPP, allora, io la vedo un po' così, che ovviamente è un mio parere personale che però ha delle fondamenta che secondo me possono essere abbastanza solide.Allora così come ce li immaginiamo canonicamente, come ci sono state presentate inizialmente, probabilmente la loro faccia e il loro aspetto non è esattamente quello di una volta.quello che sono oggi le progressive web, o meglio, secondo me, nonostante lo stato di salute dovrebbe essere migliore perché nel mondo Apple finalmente si stanno sbloccando un po' di cose che sono stati i limiti delle progressive web, una su tutte, le famose push notification, mai pensate come fattibili e invece in realtà cominciamo a vedere che molte delle feature che erano totalmente impossibili da avere su Apple stanno arrivando, e ora non ricordo la versione di iOS, ma sono lì pronte per cominciare ad essere utilizzate.Però secondo me ci sono due aspetti delle Progressive Web App che sono cambiate e che sono interessanti.Una di queste, anzi più di una di queste, sono anche dei casi d'uso concreti e cioè, uno, la cosa interessante delle Progressive Web App che ci lasciano in qualche modo da subito, sono tutte le capabilities che sono state costruite sia per far sì che le Progressive Web App potessero essere quelle che sono oggi, sia on top, cioè per migliorare l'esperienza di vita di un'applicazione web, dopo magari ne parleremo anche parlando appunto delle web capabilities in genere.Però devo dire che questo genere di migliorie hanno portato per una miglioria più ad ampio spettro rispetto alla progressiva.Secondo me quello che invece oggi fa veramente la differenza sulle sulle pva è averle come possibilità di installarle sul proprio computer, diciamo simulando un'applicazione stand alone canonica che avremmo avuto sulla nostra applicazione, quindi l'installabilità sulla nostro sistema operativo non mobile desktop.Questa secondo me è una delle cose più interessanti infatti ci sono un sacco di API che sono costruite, sono pensate, sono in lavorazione, sono calde mettiamola così, tanto il periodo come dicevi tu aiuta col caldo, sicuramente hanno fatto sì che molte scelte rispetto a prima non passassero magari da electron, cioè non per forza qualcosa che volevi avere installato sulla tua macchina passasse per forza da electron.Questo grazie anche a tante web api che sono nate, ma io ne sono un esempio.Molte delle applicazioni che precedentemente utilizzavo aperte in un tab della mia Chrome, oggi ce le ho come i Iconcina come applicazione stand alone della mia macchina e così le seguo e le chiudo esattamente con un'esperienza analoga a quella, cioè chiudendo un po' l'esperienza tra nativo e mobile.Questa è una cosa importante, quando si fa riferimento alle progressi web app si pensa sempre che il Gap da nativo a mobile sia netto, cioè che ci sia da un lato il nativo inteso come abbiamo la nostra applicazione mobile, abbiamo il nostro programma installato nella nostra macchina, blablabla.Dall'altro lato c'è il web, quindi scusami prima ho detto male, non volevo dire native web mobile, volevo dire native web come differenza.Per i progressi web app di solito si pensa "ok posso installare le mie applicazioni sul telefonino, sul mio smartphone".Non è quello, l'obiettivo della Progressive Web App è colmare l'esperienza tra nativo e web.Poi il web lo puoi vivere chiaramente su mobile, lo puoi vivere sul tuo desktop.E quindi concludo sulla domanda, ci sono solo tre ore, si sa che io se comincio a parlare non finisco più, poi tu taglia tutto, domanda secondo me le Progressive Web App paradossalmente sono più in forma oggi nonostante se ne parli di meno è rispetto al passato quando era una buzzword da utilizzare o da mettere nel proprio talk per farsi selezionare alle conferenze.Diciamo che sono variate e in una maniera molto più trasparente, ma è un termine, può andare bene come no, non uno di viaggio allo stesso.Sì, devo dire che in realtà quello che ho notato è che è cambiata radicalmente al di là del fatto che le capabilities, il numero delle capabilities, la qualità delle capabilities stia evolvendo e crescendo, ma una cosa che ho notato è che è cambiata proprio la consapevolezza con la quale si utilizza questo tipo di applicazione.Adesso, secondo me, un po' il fatto di poterle installare da un boost in un certo senso, ma come dici tu non è la discriminante per l'adozione, invece prima lo era.Quindi quello che hai evidenziato tu fa notare che in realtà è proprio una questione di consapevolezza di chi le usa e di chi le fa.Assolutamente sì, infatti quando ti dico colmare il gap è molto diverso da dire "ok puoi avere la tua applicazione installata".Ti faccio un esempio che secondo me può essere determinante mentre stavamo stavo riguardando alcune web api che sono state rilasciate, poi se vuoi parliamo anche del processo di rilascio appunto delle web api per come sono pensate oggi.Una di queste ad esempio è la possibilità di gestire il multi screen window basement cioè gestire effettivamente il posizionamento delle finestre con multi screen quindi con più screen più schermi.Questa cosa se ci pensi non è tanto "ok posso installare la mia applicazione sul desktop" no! è un boost incredibile di incrementare l'esperienza utente ma in senso molto più ampio.Poi lo fai installando l'applicazione perché ad esempio questa è un'API che lavora se installata la Progressive Web App, però ripeto il valore aggiunto non è che ce l'hai installata, tu ce l'hai installata perché l'utente deve avere consapevolezza di quello che sta succedendo, tutte queste delle cose poi magari ne parliamo dopo, ma il succo è che migliora l'esperienza di vita in genere, migliora l'esperienza utente in genere.Quindi non le isolerei più per come erano state proposte, come dicevi tu, per come sono state lanciate, ma le progressive web app oggi fanno parte di un'evoluzione secondo me molto più grande.Vediamola così.Esatto, infatti volevo arrivare là.Volevo buttare dentro al calderone altri due concetti.da una parte abbiamo WebAssembly, dall'altra WebGL, cioè fino a ieri, fino a ieri, uno dei pain point, dei punti, dei contro delle progressive web app era appunto la performance, girando dentro un browser, la performance è quello che è e ne siamo consapevoli, però la parire nel mercato di queste due tecnologie pensi che davvero possa avere un boost? Perché io ancora ho visto un pezzettino del boost ma non ho ancora visto la spinta forte di queste due tecnologie nella direzione delle progressive web app, cioè non ho ancora grossissimi esempi di applicazioni che utilizzano appalate, in realtà ce l'ho Figma è una di queste.Si esatto però oltre a quella diciamo non vedo che questo verbo, questo approccio si sia disperso, si sia moltiplicato e replicato in altre situazioni.Quindi quanto questo approccio può dare ancora il boost? Quanto c'è da fare e secondo te quali sono le insidie nascoste da quest'approccio? Mi piace come domanda, approvata.A parte gli scherzi, tu hai sottolineato due cose interessanti.Uno è quanto queste due tecnologie, nel nostro caso specifico WebAssembly da un lato, WebGL dall'altro.Possono offrire tantissimo boost a livello di esperienza utente, però attenzione ad una cosa, anzi a due.Innanzitutto WebAssembly e WebGL, in particolar modo WebGL è più una un'esperienza migliore a livello di strettamente di contenuto, non di esperienza utente a tutto tondo.Quello è un altro discorso.Tra l'altro WebGL in realtà verrà pian piano soppiantato da quello che è WebGPU, che è una delle nuove API che lavorano molto più a stretto contatto.ha detto contatto! Pensa lasciano la tagliare con le GPU! Ok? Quindi diciamo che infatti se non mi ricordo male Babylon già lo supporta e ci sono anche un po' di test anche da vedere.Su WebAssembly invece faccio un altro ragionamento e dopo concludo dicendoti invece una cosa sulle prestazioni.Su WebAssembly è un mondo a sè stante secondo me e ne stiamo facendo esperienza vedendo anche tutto quello che ci sta cominciando a ruotare attorno, quindi la possibilità di avere...WebAssembly anch'esso è nato strettamente con uno scopo, ma poi in realtà per quanto si possa immaginare uno scenario per uno strumento.Lo chiamo strumento ma chiaramente sto utilizzando del me più generico.Lo strumento poi il vero utilizzo lo darà l'utilizzatore stesso.Faccio un esempio stupido, anche se mi viene in mente sempre una scena quando penso a questa cosa.Un pallone da pallavolo normalmente è pensato per giocare a pallavolo, ma Tom Hanks lo utilizza per farci un compagno.Perché? Perché in quel momento, in quel caso Wilson ha avuto un altro scopo.Tu pensa che se a posto di esserci un naufrago ce ne fossero stati più di quelli che gioca una palla a vola, automaticamente uno strumento si sarebbe trasformato.Poi penso sempre alla scena quella dei griffi, ma quella è un'altra storia, mi auguro tu non sia qui a ricordarla.LM: quello che dici è molto interessante.Io ricordo spesso qua nel podcast, cito Vittoria, la mia amica che faceva la poetessa, e lei diceva "quando tu scrivi un libro, in questo caso possiamo inquadrare il libro come uno strumento, nel momento in cui tu lo pubblichi o comunque nel momento in cui tuo marito o la persona che è accanto lo legge, quel libro non ti appartiene più perché è calato in un contesto dove sono gli altri i proprietari di quel concetto, di quello strumento, in quel caso di quel libro.Per cui se tu vai a dire "no, non lo devi usare così, lo devi usare così", non funziona più, ormai è in mano alla community, è in mano all'ecosistema che ne farà quello che vuole.Quando ti ho citato WebAssembly non l'ho citato a caso, ma perché ho fatto un ragionamento qualche giorno fa, in questo periodo ci sto ragionando attorno al concetto di Progressive Web App a livello più filosofico, nei termini della filosofia da bar, no? a livello più concettuale possiamo dire e faccio l'esempio stupido dovevo realizzare un'applicazione che mi calcolava una waveform ok? Il modo più semplice per me che sono fortemente ancorata al web è quello di utilizzare comunque l'API audio di javascript o per essere meglio per per meglio dire, le API audio del browser e fare l'analisi della waveform.Non fatelo perché se il file audio è di un'ora e mezzo, un'ora e venti come gli episodi di Gitbar, non fatelo perché potete metterla a fare, andare a bervi il caffè e poi a ubriacarvi con il vostro migliore amico.E quando tornerete non ha ancora finito di farlo.Però nel contempo ho pensato "Beh, allora io prendo i dati, li sbatto dentro WebAssembly, c'avevo già uno script Rust che è quello che utilizzo per estrarre la waveform, tiro fuori i picchi, genero l'SWG e il gioco è fatto.Quindi questa cosa per me che sono uno sviluppatore web, quindi posso farlo anch'io non devo prendere in mano che ne so RAST o le librerie grafiche per andare a farmi l'interfaccia X oppure no lo posso fare semplicemente e questa cosa mi gira nel browser quindi posso distribuirla come completamente client side? Assolutamente sì, assolutamente sì e prima citavi Figma, tu pensa a Omiro, pensa a degli infinite canvas come quelli, ovviamente lì c'è forte utilizzo di questo genere di esigenza che prima non era pensabile.attenzione ad una cosa però e ci tengo a dire prima ho detto voglio aggiungere una cosa e cioè è vero sicuramente non puoi pensare con l'api di javascript di fare quello che vuoi ok non è pensabile per tutti i limiti che ci stanno dietro però ti dico una cosa un caso come il tuo chiaramente assolutamente per un utilizzo comune di java scritto come applicazione web però attenzione quando prima invece dicevamo comunque l'esperienza web non è mai così appagante a livello di prestazioni io mi permetto di dirti una cosa di recente mi sono un po dedicato allo studio del browser.Cioè come funziona un browser? Ho fatto un talk, tra l'altro secondo me è divertentissimo perché siamo tutti bravi con il browser degli altri e quello che ho notato è che verissimo, ci sono grossi limiti, c'è un main thread che fa talmente tante cose che bisogna stare attenti.Quindi, attenzione, spesso e volentieri siamo più noi sviluppatori a fregarcene abbondantemente piuttosto che a cercare la soluzione.Qui aggiungo anche un'altra cosa, viviamo di eterne estrazioni.C'era un caso, ho visto, non so se sto divagando ma tu lo sai con me, non è facile.Vedevo l'altro giorno un talk molto interessante, o perlomeno era molto interessante, la primissima parte di questo talk.Poi il resto era interessante.Quello che mi ha colpito particolarmente era la presentazione di Quick da parte di Misco Avery, il creatore di AngularJS e anche di Angular, uno dei suoi usciti.Lui sottolineava questa cosa, diceva "stiamo attenti che quello che succede normalmente è che ormai siamo tutti abituati ad utilizzare delle astrazioni comunque dei framework non rendendoci conto che il primo ostacolo da superare è proprio quello.Cioè il problema che abbiamo una esperienza più lenta o il problema pensa dell'idration da risolvere in fase di caricamento, quello ce l'abbiamo perché prima di tutto dove salire il framework.Non so se la sto semplificando chiaramente per carità però è giusto per riuscire a dare un'idea abbiamo bisogno prima di una pscella perché poi volentonolente se prima non parte javascript non possiamo fare niente.Quindi diciamo che probabilmente prima di pensare a tutte queste cose probabilmente bisognerebbe ragionare a scrivere un po' meglio.Io conosco pochissima gente che delega la roba ai web worker, ma pochissima gente che lo fa.Ora dico non è che io sono bravo gli altri no io mi lupo oramai tipo una volta ogni sei mesi quindi figurati però diciamo che ci sono degli strumenti ancora prima di imparare a suonare di "ma allora io questo lo faccio io e basta così ho le prestazioni migliori" si possono dire brutte parole qui? Non me lo ricordo.Vabbè l'edito.Assolutamente sì vai sereno.Ma non si può fare no ma non esiste sto tentando di contenere in qualche modo.No, prima pensiamo a risolvere i problemi con quello che abbiamo.Cioè è utile che pensiamo a delle soluzioni incredibili con WebAssembly se prima non abbiamo provato neanche a delegare un'operazione magari più dispendiosa a un WebWorker, o quando parliamo di audio magari cominciare a vedere come funziona il worklet a riguardo che sono dei worker specializzati per determinati compiti.Chiaramente è un problema al di sopra di tutto, ok? Però questa cosa poi deve girare un po' dappertutto, quindi ci sono casi e casi, non per i web worker, per quello non ci sono scuse secondo me, però diciamo che chiaramente poi ci sono casi e casi.Ti dico anche di più, perché io poi non sviluppo più, è vero, però di contro ho una fortuna in questo momento, nonostante non abbia molte facoltà mentali a disposizione di recente, ho la possibilità di scegliere quello che voglio studiare.Io non studio quello che fa più hype in quel momento, o sai se la libreria magari ancora non è matura, non mi conviene parlare, che me frega! Ho scritto di rom.js molto prima che se ne sapevo già, è stato scritto due volte! Ho questo vantaggio di poter scegliere un po' quello che mi piace studiare, e te lo dico perché? Perché proprio su WebAssembly quello che sto studiando è WOT.Se tu parli con, che lavora con WebAssembly, non ha neanche idea di che cosa sia.Ma è sostanzialmente il modo, cioè il linguaggio testuale per scrivere WebAssembly, che poi sostanzialmente è ciò che tu otterrai se decompili un WASM fatto in Rust.Mica ti torna in Rust, mica ti torna in Rust, non torna in "last" quello che decompilerai.Quindi anche lì ci sono livelli di astrazione, ovviamente se ti metti a scrivere una cosa completa non sei pazzo se ti metti a farla in vuota, ci mancherebbe per carità.Diamo sempre un po' la colpa agli altri, per gli altri intendo a qualcos'altro, mai che ci chiediamo "scusa, mi metto che cosa ci posso mettere di mio per migliorare un po' questa cosa.Poi ribadisco, ci tengo a dire perché non voglio essere il paladino de sto fatto, sto continuando ad automoderarmi incredibilmente, ma io lo dico perché in questo momento non ho il fiato sul collo per dover fare la consegna o risolvere il problema nel più breve tempo possibile per carità, me ne rendo conto, però ogni tanto a posto di andare a vedere Solid, posso dicendo Solid perché da fronte di vista è quello che mi viene da dire, prima fatti un esame di coscienza per andare a vedere Solid, vedi se sai usare quello che ti ti dà a disposizione il tuo browser.Poi per qualità...- Ti conosci l'event loop.- Anche se...poi è giustissimo perché poi io sono il primo affascinato da questo genere di cose.Mi sono innamorato di Lit.Ma mi sono innamorato di Lit io personalmente per una ragione che è molto vicino allo standard per quanto quasi così però ad esempio e poi prima di innamorarmi di lì ho sbattuto la testa su web component per due anni per due anni ma ripeto non voglio fare però però tu hai evidenziato il il problema.Io ho provato a fermarmi un attimo perché il problema è un problema di consapevolezza sul contesto nel quale ci stiamo muovendo.Io credimi ci ho perso qualche neurone dietro questa cosa, non tanti perché non ne ho in abbondanza, ma credo che tutto dipenda, perché uno studio che sto facendo in questo periodo riguardo al carico computazionale e allo stimolo correlato all'utilizzo e alla gestione del carico cognitivo, il carico cognitivo e a tutti gli elementi che entrano in gioco per la gestione del carico cognitivo e credo che c'è un meccanismo che è quello che utilizziamo quando apprendiamo, che è un meccanismo della la soddisfazione rapida, cioè ci devono essere una serie di elementi che triggerino la soddisfazione rapida in modo da alimentare l'alimentazione, alimentare scusami l'interesse, l'adrenalina, una serie di elementi che poi ti spingono a investire più effort nello studio.Quello che in realtà tutte queste astrazioni fanno è quello di semplificare una serie di livelli sottostanti, tali per cui tu riesci ad avere una soddisfazione molto rapida e dei bocconcini di soddisfazione molto rapide.Siccome io non sono molto diverso dagli altri, anch'io ho iniziato quei framework.Come ho imparato le basi? A forza di schiaffi in faccia.L'ho già detto qua nel podcast, c'è un solo framework del quale ho letto e ho studiato tutta la documentazione prima di scrivere una sola riga di codice ed è React.Tutti gli altri li ho approcciato con learning by doing, no? Quindi imparare facendo.La soddisfazione è importante, ma come fai a capirne il contesto quando utilizzi questo approccio? Beh, a forza di schiaffi in faccia.quando vedi che qualcosa non funziona nel rendering, la sto buttando così, no? Eh ci vai, te lo guardi l'event loop come funziona, no? O potrei dire la stessa cosa del frame, utilizzi Fastify, mischi Promise con Callback, vedi che succede il finimondo e dici no, ma allora come funziona l'event loop di Node? Ma guarda, scusami se ti interrompo, ma ti faccio un esempio, credo esattamente calzante rispetto a quello a quello che dicevi di aver letto e studiato a men a dito React.Oggi si vantano tutti i framework nuovi a ragion veduta per carità, vedi Solid, vedi Svelte, vedi ora come si chiama Fresh, tutta questa roba che sta uscendo.Si vantano di essere più fighi perché non hanno, non si basano, non basano scusami, la propria reattività su Virtual DOM.Ok, parliamo di Virtual DOM allora.Cioè, ok, facciamo tutti via.No, io allora mi sposto di quello, non lo uso il Virtual DOM.Ma tu lo sai come si scrive un Virtual DOM? Non pretendo che tu sappia scrivere un Virtual DOM.No, non so scrivere neanche io come l'hanno scritto i quelli di React, ma per carità.però quello che voglio dire è che anche nelle scelte che ti dà l'oggetto luminoso al quale l'uomo è attratto, ma è attratto perché è così, è proprio l'insito nell'uomo, se vede qualcosa che bluccica ci si avvicina, vuole capire che cosa c'è di interessante.In questo caso studiamo quello che volete, facciamoci attrarre".Però, se c'è scritto grosso "così siamo fighi perché non usiamo il Virtual DOM", stavo dicendo Steve Harris, riccio Harris ne ha fatto una campagna su questo "non usiamo il Virtual DOM", ma se non sai esattamente qual è il limite del Virtual DOM, ma perché ti dovrebbe convincere quel framework? Perché te lo dice un altro? E allora ti faccio una provocazione perché in realtà hai ragione in quello che dici.Però io tendo sempre a fare l'avvocato del diavolo e soprattutto a vestire le scarpe degli altri, mi metto sempre nei panni del junior perché lo siamo stati tutti.Io sono junior, ok, oggi JavaScript fatigue, un framework ogni due secondi, ho bisogno di costruire i miei punti di certezza, l'ecosistema nel quale mi trovo sono catapultati in un ecosistema.Come mi oriento? Dall'altra parte ci sono sviluppatori che sono sempre più fissati con una dev experience in modo che sia più smooth possibile l'adozione? Perché? Perché ci si valuta contando le stelline su github, che per me è una vanity metric.Assolutamente.Quindi mi chiedo e non ho una risposta a questo, stiamo andando per come stiamo inquadrando il mondo della dev experience, stiamo andando nella direzione giusta? Cioè, oggi, nello stesso tempo mi dico, quante persone usano internet senza conoscere i sosi? Allora, questa risposta mi farà sembrare più vecchio di quanto sono allora però va bene allora ti dico in questo in questa occasione c'è il problema la copertina troppo corta no? Nel senso che da un lato è vero uno sviluppatore junior si trova catapultato in uno scenario immenso per quanto tu possa suggerire un learning path a meno che quello non si veda due anni senza dormire probabilmente avrà grosse difficoltà a colmare e a chiudere un po' il centro.Dall'altro lato ci sono le esigenze che sono cresciute, le esigenze che portano enormi difficoltà da parte degli sviluppatori perché devono adeguarsi nel più breve tempo possibile.Quindi, al netto della vanity matrix delle stelline o di qualunque altro tipo di vanità, che può essere anche una awards che raggiungi, mi ci metto anch'io assolutamente in questo genere cose.Ti dico che qualunque cosa si affronti, secondo me è più saggio partire dal basso e arrivare verso l'alto piuttosto che fare il contrario.Quello che voglio dire è banalmente che se lo sviluppatore junior gli viene richiesto React, per carità è la prima cosa che dovrà imparare per entrare sul mercato io lo comprendo però piuttosto che poi mentre sta lavorando con Riak si sposta su Pinco Pallo fermi tutti no no non è la cosa giusta da fare spostati un attimino fai scendi un po' verso il basso poi risali e tra l'altro la risalita sarà molto più veloce.Sono d'accordo con te, infatti quello che sto dicendo è...Questa cosa è fortemente inquinata dal mercato.Io non do la colpa allo sviluppatore, in realtà non donne anche la colpa all'azienda, perché l'accelerazione in quel caso è...oggi guarda, leggevo una cosa che è abbastanza comune da leggere oggi, però un po' mi ha schiazzato.Non c'è truttura, ma sono quelle cose che ti lasciano dire "ma guarda che noi non è che scriviamo righe di codice, noi cominciamo ad essere una leva dal forte impatto su questo mondo".Io oggi leggevo qualcosa come se il codice che è è attualmente presente al mondo che lavora per risolvere problemi in genere, se fosse stato scritto meglio avremmo avuto un risparmio energetico quasi del 15 per cento, c'è l'altro che è l'industria di carbone.Se ci pensi noi ora cominciamo a coprire un ruolo che è veramente è game changer, veramente game changer.Ma su questo io sono pienamente d'accordo, tanto che adesso lo recupero e giusto per chi se lo fosse perso, noi qualche tempo fa abbiamo fatto un episodio con padre Paolo Benanti che credo sia il frate più figo del mondo.Nel pianeta, Esatto, esatto.E parlavamo proprio questo, della nostra responsabilità.Il discorso che voglio fare è, preso atto che viviamo in un mondo dove anche nel nostro ecosistema sta avvenendo quello che secondo me è un po' la diluizione, si sta tutto diluendo, sta tutto diventando un mare magnum di framework, di tool, di cose, un po' come funziona con l'informazione oggi, cioè è un trend che abbiamo già vissuto ed esperito.C'è qualcosa che possiamo fare per stimolare quello che dici tu, il processo che dici tu, cioè adotta il framework, adotta la strazione, però quando ti sposti cerca di fare questa specie di arco verso il basso, assumere conoscenza per poi ripassare a un'altra strazione.C'è qualcosa che noi quando costruiamo i framework, noi quando facciamo librerie, noi quando facciamo divulgazione possiamo fare per stimolare questa cosa? Probabilmente non esiste una risposta, però è una domanda che ci dobbiamo porre.Assolutamente, allora guarda, chiaramente questo è un qualcosa che dovrebbe agire come motore di fondo e non è chiaramente pensabile, però io ritengo che una persona che ad oggi comunque si espone con un canale di divulgazione, divulgazione, con una mentorship, con una...per programming con uno sviluppatore più giovane dovrebbe trasferire questo genere di concetti.Già partendo da questo genere di apporto che si può dare probabilmente si può migliorare, ma ripeto anche perché soprattutto questo genere di esperienza.Cioè prima o poi ti schianti, ti schianterai così come mi schianto io quando mi viene a parlare di Kubernetes.Per me Kubernetes è una cotoletta, un'enorme cotoletta.Conosco i concetti di fondo, va bene, capisco a che cosa mi serve, ma se io domani dovessi avere la necessità, ma non posso pensare di "ok ora imparo ubernet senza avere il background di quello che è la condenalizzazione, la programmazione distribuita, la scala networking".Su the networking? Che pochissimi conoscono.Io me lo posso andare a prendere un corso su, non ti dico Udemy, anche su Udacity, su piattaforme più autorevoli, tutto quello che vuoi, ma poi prima o poi mi ci schianto, anche perché domani se le cose cambiano che fai? Quanta vita ancora deve avere React? Oggettivamente lo vediamo che cominciano le prime vere difficoltà, lo vediamo che Angular ha avuto, parlo sempre del frontend, perdonatemi ma è quello che conosco.Lo vediamo che c'è stata comunque una battuta d'arresto.E qui torno un attimino, posso tornare un attimino al discorso del browser? Ad esempio studiacchando un po' questo genere di problematica mi sono reso conto del perché, spesso e volentieri si dice "ma questo browser che lo fa, ma perché quello non lo deve fare? perché c'è un problema dietro a queste cose? Ci sono un sacco di problemi a riguardo.Io ho studiato un attimino l'evoluzione di Blink e ci sono un paio di articoli che sono illuminanti.C'era un tizio di Google che faceva front-end, l'hanno preso e l'hanno messo a lavorare su Blink, sul render engine Blink.E quello diceva "io quando sono arrivato non ci ho capito un tubo, Ma non c'ho capito un tubo, perché c'erano talmente tanti pezzi di codice presi e avvalangati lì dentro.Stiamo parlando del render engine che ci fa vedere le pagine web di tutto il mondo.Tu dici "eh ma qua sì io devo fare una cosa, ma come la faccio? Cioè come faccio a non creare regressioni ad esempio su una roba del genere?" Se non hai una conoscenza profonda, anche dei limiti che ci sono determinate code base, determinate problematiche, determinate architetture, tu ci puoi sperticare quanto vuoi, non ne uscirai assolutamente vivo.Guarda, su questo argomento penso che ci faremo un episodio, quindi riverrai a trovarci perché voglio coinvolgere un po' di persone a parlare proprio di questo disintervento, di complessità.uno da casa? Ah anche due! Ok grazie! Sai perché? Perché pochissimi parlano di complessità e learning path insieme.Credo che tutto venga, cioè quello che noi stiamo vivendo nel mondo javascript, venga proprio sia conseguenza proprio dell'unione di questi due concetti.Non lo so, ho questa sensazione.Ora, senza allontanarci, poi la chiudo giuro, ma anche tutta l'astrazione che il cloud ci porta.Cioè tu, attenzione, tu non sai utilizzare Kubernetes, tu sai utilizzare la versione Managed dettina AWS ad esempio.Che è un'altra cosa! Che è un'altra cosa! Cioè quindi è giusto che l'astrazione porti progresso, accelerazione per carità, però è un prezzo da pagare.Questo è chiaro.Lo dobbiamo mettere in conto.Parlo personalmente, non parlo di catastrofi mondiali.No, no, no.Ci serve la consapevolezza, cioè la devi mettere a bilancio sta cosa.Hai ragione in quello che dice e se hai un livello di esperienza tale perché hai preso calci nel culo da dire ok tanto io qua sto prendendo la scorciatoia qua sto usando una strazione prima o poi mi torno indietro io ricordo un bellissimo tuo episodio con Salvatore San Filippo dove parlaste proprio di questa cosa e lo metterò nelle note dell'episodio perché avete affrontato il punto della complessità, è del costo della complessità, io lo ricordo bene quell'episodio e dicevo lo devi mettere in bilancio, lo devi mettere in bilancio, però ritorniamo per un attimo di nuovo alle progressive web app e al project Fogu che è un modo per creare astrazione.No no esatto, ti dirò che è...guarda come ti ricollego la cosa eh, come se fosse preparato! No in realtà è vero, è un'astrazione, assolutamente sì, ma è un'astrazione utile per avvicinare in questo caso ciò che fa il sistema operativo con ciò che può fare il browser.Quindi non la chiamerei tanto un'astrazione in senso ampio ma un layer di congiunzione tra il sistema operativo e il nostro browser.Se vuoi racconto un attimino in che cosa consiste proprio un project fu in genere si chiama in realtà come progetto web capabilities a dire il vero però...il pesciolino è fighissimo...come? il pesciolino è fighissimo...ma c'è una storia se potete la raccontate, è abbastanza nota però se potete la raccontate.Sostanzialmente questo progetto Web Capabilities, o comunque Project Fugu, acca, Project Fugu, sostanzialmente nasce per far sì che si possa colmare il gap tra l'esperienza nativa e l'esperienza web.Che cosa intendiamo? Intendiamo semplicemente che ci sono delle cose che con il nostro browser fin oggi non abbiamo potuto fare.Quella più rilampante di tutte, che tiro su fuori sempre questa ma perché è veramente di estrema e facile comprensione, è la file system access API, cioè la possibilità di utilizzare il file system del nostro sistema operativo, cioè della nostra macchina, attraverso il nostro browser.Ci sono state un sacco di prove in passato, tutte queste prove poi hanno portato ad utilizzare Electron per fare Visual Studio Code.Bene, oggi se vedete avete la possibilità di utilizzare Visual Studio Code direttamente da browser.Perché? Perché grazie a delle API, e ora qui facciamo una riflessione che quadrerà il cerch e tu direi "Francesco sei ingenio da un lato, l'altro da l'altro, sto improvvisando clamorosamente, ti dirò che in questo caso, sostanzialmente, questa API non fa altro che mettere in comunicazione il nostro browser con quelle che sono le API del file system, cioè non un'ulteriore abstrazione proprio, ma le chiamate del nostro file system, del nostro sistema operativo.Benissimo, grazie a questo, un'architettura delle API pensata in un determinato modo, ora diciamo come, consente di utilizzare appunto il nostro file system.Vi ricordo utilizzare ad esempio le push notification ma soprattutto utilizzare le, come mi viene il termine, push da un lato e dall'altro la notifica scusatemi, la notification API, quindi le notifiche che noi vediamo sulla nostra macchina o se siamo su Android sul nostro smartphone, attualmente non c'è il sistema operativo, mica le gestisce il browser.Il browser dialoga con il sistema operativo che ora è in grado di fare questa cosa, passando dal nostro browser.Così come tantissime API che ad esempio dialogano con USB, Bluetooth, ce ne sono alcune di vecchissime, quindi non è che sto parlando di cose così recenti, così assurde.così come ce ne sono tante altre che ci danno la possibilità di avvicinare l'esperienza anche su altri fronti e magari sono meno lampanti, ma se ci pensi oggi attraverso delle API come non lo so, la barcode detection piuttosto che NFC, Bluetooth, ma anche Little Detection, cioè c'è un API che consente di capire quando andare a posizionare un processo, e qua quando parliamo di prestazioni, hai la possibilità di delegare un processo magari dalla bassa priorità, ma magari anche discretamente oneroso nel momento in cui il browser è scarico.Cioè pensa un po' non avere l'idea che si possa utilizzare qualcosa del genere oggi, ti farà fare l'invio all'analytics che tu faresti con le beacon API, ma vabbè, poco importa.Potresti delegare una scrittura di un log, sto dicendo una fesseria comunale, nel momento in cui il browser è scarico.Una follia del nostro browser che deve gestire un quantitativo notevole di cose.Oggi è possibile attraverso le API che arrivano attraverso questo progetto di fare recognition della scrittura manuale, non è più bisogno di andare a chiamare un servizio in cloud per far sì che tu scrivi qualcosa con la tua matita, con la tua tavoletta grafica, che si riconosce l'intratto calibrativo.Perché questo se ci riflettiamo? Perché il sistema operativo lo sa fare? Cioè il sistema operativo queste cose ce le ha? Il sistema operativo, il detect mac os, la detection del viso, la sa fare? Perché ci dobbiamo spertigare a provare nuove soluzioni quando basta un dialogo coerente, scritto con un approccio developer driven, e ora ti dirò anche il perché, che ci consente di utilizzare quelle API.Quindi quando noi scriviamo, tu dicevi di NFC, assolutamente sì, possiamo lavorare sulle seriali, che è una cosa decimensi che è anche piuttosto anacronistica.Quando quindi, e qua ti torno a due punti importanti, quando quindi parliamo di progressivo e babba, attenzione, ricordiamoci sempre che è una cosa che si ripete da quando sono ci, progressivo non vuol dire che ci danno la musica progressiva, progressivo vuol dire che deve essere utilizzato un approccio di progressive enhancement, cioè che tu devi avere la possibilità di utilizzare quella feature, il tuo sistema, la tua macchina, il tuo hardware ti consente di farlo, se no non lo utilizzi.O utilizzi un fallback oppure ti dici "fratello questa cosa non la puoi fare".Esempio l'Ampante, sempre su Visual Studio Code, su browser.Se sei su Firefox, che non ha ancora quell'API, ti dice "vuoi lavorare su questo progetto? Ok, fammi l'upload del progetto e lo scarichi".non la poligon, con il tuo file system.Giusto per capirci.Sul discorso astrazione in questo caso ci sono due dettagli importanti e qui quadro il cerchio finalmente.Il primo è quello che dicevo, in questo caso è un layer di astrazione, ma in realtà è un layer di comunicazione con il nostro sistema per l'ipo non tutte le piai di questo progetto e per carità buonissima parte nasce soprattutto per questo l'altra cosa che è importante è che questo genere di ipi seguono un work flow di creazione estremamente devello per driver cioè le piai prima cosa che succedeva in passato le piai venivano a un certo punto rilasciate ok sul browser c'è questa nuova funzionalità.Poi la usavi ed era praticamente usabile come un pallone da calcio fatto in evento armato.Finalmente la potevamo fare ma è totalmente inusabile.Ad esempio sul file system ci sono stati più di un esperimento o sullo store web sequel.esempio.Ok, oggi invece queste API vengono innanzitutto proposte, possono essere proposte direttamente dai developers che le utilizzeranno, saranno discusse, c'è proprio un processo, poi se tu vuoi mettere il link a corredo figura di supervolentieri poi vieni in giro, questa discussione poi si trasforma in una prima fase di lavorazione da parte del team che scrive browser quindi non da rinco pallo, queste API non vengono rilasciate.Non è che ti dico "ok qua ci sono le API abbiamo fatto quello che volevamo, siamo stati tutti bravi" assolutamente no.Vengono rilasciate in due tipologie di modalità.Una attraverso il plugin, cioè quello che tu te ne vai nelle impostazioni del tuo browser, attivi il flag e puoi utilizzare la funzione webgl quando sci era così ad esempio non so se ti ricordi ma tu sei vecchio ricordi oppure c'è un altro modo di rilasciare questo genere di api che sostanzialmente si chiama origin trial cioè ci dà sostanzialmente la possibilità attraverso un token che possiamo richiedere bla bla bla di fare degli esperimenti e ad autorizzare per un preziodo di tempo quelle pi per il nostro progetto quindi un utente che arriva nella mia nel mio esperimento potrà tranquillamente utilizzare questo mi darà la possibilità a me di provarla sul campo a me sviluppatore non a me che l'ho pensato non a me che l'ho sviluppata perché secondo me così poteva funzionare.Ho la possibilità di raccogliere i feedback da parte degli sviluppatori, da parte degli utilizzatori e lì finalmente rimetterla in discussione ed eventualmente trasformarla in un API che il nostro browser ci mette a disposizione e che noi, ovviamente plurale assolutamente maestà, noi che l'abbiamo pensata, commentata, criticata, rilavorata, provata e fatta provare, finalmente possiamo utilizzare.Non so se sono riuscito a darti questo discorso, saprò che poi può essere rilasciata e tutti siamo felici.Questo crea un'astrazione, vero? Ma molto più vicina all'esperienza dello sviluppatore.Chiarissimo.Porto però "tutti siamo felici" e un po' di tristezza.No, faccio sempre l'avvocato del diavolo tu ormai mi conosci e mi supporti anche per questo.Web APIs, Project Fugu e giardini cintati dei sistemi operativi, sandbox dei sistemi operativi, com'è la situazione? Allora, allora, anche sul discorso sandbox ci sarebbe dei ragionamenti da fare a livello di browser ma li possiamo trascurare per adesso tra l'altro con le ultime release di Chrome stanno lavorando molto sulla parte di sandboxing non so se li lasci che stanno facendo ma al netto di questo c'è da dire una cosa mi soffermo solo sull'API se per te può essere esaustivo.Le API attenzione sono tutte pensate per offrire un approccio esplicito nei confronti dell'utilizzatore quindi diciamo prima la criticità più canonica che possiamo, se questo sito ha qualcosa che l'utilizzatore non vuole che si faccia, se l'utilizzatore non vuole che si scriva sul sistema operativo io non lo posso costringere da sviluppatore io non lo posso costringere da browser benissimo sarà un po' scomodo forse sì ma questo genere di richiesta di scusate di utilizzo contempla una riesta esplicita tu non puoi utilizzare il file system del sistema operativo se prima non dici sì sono disposto a farlo l'iconcina nella tua barra come ti spunta l'iconcina quando utilizzi la cam? Tu la cam la devi autorizzare non è che se usi streamed, se usi Meet le prime volte che le usi la devi autorizzare così come un microfono e non lo so se l'avete notato ma c'è l'iconcina che ti dice che lo stai utilizzando, cioè puoi richiedere indietro l'autorizzazione che hai dato.Poi chiaramente ci sono utenti e utenti, c'è l'utente che dice "una maschera" e c'è scritto "ok" perfetto, premo ok a prescindere da tutto.Ma poi c'è un limite a quello che si può fare.No no ma aspetta la domanda che ti facevo è tu hai buttato un occhio anche allo sviluppo di questo tipo di API.Hai percepito delle complessità date dal sistema operativo, cioè complessità che ha il team di Chromium nell'implementare questo bridge verso il sistema operativo, dato dal sistema operativo, visto che comunque faccio l'esempio di Apple, è risaputo che molte cose non sono facilmente accessibili o direttamente accessibili.Allora ti dico due cose a riguardo ovviamente per come la vedo io, poi anzi te ne dico due più una.Uno è spesso il limite è più dall'architettura del browser che dal sistema operativo in quanto è sistema operativo alla fine fine una feature o te la metto a disposizione o non te la metto a disposizione.Non c'è troppo da discutere a tal riguardo, non c'è una difficoltà implementare.Io sto semplificando e chiaramente io non lo saprei mai fare una cosa di cui c'è attenzione, però diciamo che il sistema operativo se ti mette la detection, se ti mette a disposizione come pi di sistema operativo la detection dei volti, benissimo se te la metto a disposizione deve essere il sistema operativo, il browser e questo layer di API a consentire di utilizzare in maniera primo sicuro, secondo prestante, anzi no vabbè lasciamo questo come è oggi, primo sicuro, secondo prestante, terzo ergonomico, la possibilità di farlo.Purtroppo non è così scontato che un browser lo possa fare perché possibilmente insito nella sua architettura che ci sono delle complessità di realizzazione che sono molto più grandi rispetto al problema poi da risolvere.C'è una cosa che ora è uscita nel mondo CSS, sono tutti felici, sono uscite le content query, cioè sostanzialmente la possibilità di fare quello che si faceva sulle media query, che appunto si appoggia sulla media, sul contenitore che contiene un elemento.Quindi tu puoi fare le query a livello di media, quindi se la mia pagina il mio display o il mio viewport è a 1200 pixel piuttosto che a 600 ma ora puoi lavorare facendo facendo capo al tuo contenitore, al contenitore dell'elemento.Se ci pensi non è una cosa così assurda, no? Io vedo molto più complesso la media query, se ci pensi.In realtà non è così.In In realtà l'architettura del browser, soprattutto di Chrome, non offriva la possibilità senza la riscrittura di alcune parti di Blink, non consentiva di realizzare questo genere di cose in una maniera rapida e prestata, perché venivano eseguiti talmente metodi di render fare una cosa del genere che sostanzialmente avevamo un calo di prestazioni mostruose e quindi non poteva essere rilasciata.Quindi prima di rilasciare le API è stato necessario riscrivere una parte dell'engine, cioè tu pensa che è follia no? Se ci pensi è assurda come cosa, però a me affascina un sacco la cosa del genere.Prima hanno dovuto riscrivere quello, poi puoi rilasciare quello che vuoi.Quindi c'è tanto da ragionare.Il progett Fugu in questo caso pensa alla come debba essere realizzato un'API, alla proposta, allo sviluppo e poi dice che questi problemi poveracci, se lo sbrigano quelli che si sono che hanno un milione di cose assurde a cui dare seguito.Anche qui c'è una serie di articoli veramente illuminanti, sono veramente illuminanti a riguardo secondo me.Guardavo l'orologio, lo sai, l'ultima volta che abbiamo registrato insieme abbiamo fatto tre ore in mezzo.Questa volta so che devi andare dai tuoi figli e non posso trattenerti troppissimo altrimenti ma avremo occasione di farci la chiacchierata di persona davanti a una birra.Ti voglio però prima di chiudere fare un'altra domanda e la domanda è un po' una provocazione più che una domanda.Chromium/Chrome corre.E gli altri browser? Questo scollamento può essere un problema? Beh oddio, sì Chrome corre, cioè il progetto Chromium corre.Attenzione che il project passata chrome ma per consentire che possa essere un progetto ad ampio spettro non un progetto relegato a un singolo browser.Sicuramente abbiamo i tre concorrenti, Firefox che comunque ha un'ottima base di utenza, sicuramente non quella di una volta, ha un'ottima architettura su molti fronti, però effettivamente ha ancora delle difficoltà da colmare.Probabilmente c'è da dire, mi dispiace dirlo in questi termini, che Google ha molti più so di Mozilla, quindi è anche un problema abbastanza scontato.Ci sono anche problemi delle compagnie che portano avanti questo genere di cose.Safari, di contro, tutti dicono "è il nuovo Explorer, è il nuovo Explorer".Da un lato è assolutamente vero, da un lato sposa esattamente la filosofia di Apple che se le cose non hanno la dovuta maturità e chi se ne frega di quello che dice la gente noi continuiamo così.Poi c'è da dire che credo che il team Safari sia il team più piccolo che ci sia in Apple, ma va bene, quella è un'altra storia.A tal proposito, l'altra volta vede un'immagine divertentissima che era l'iPhone, se l'Apple l'avesse dato retta a tutto quello che chiedeva l'utenza ed era tipo una specie di mostro titanico con l'HDMI, il laccetto per non farlo cadere e che ne so una batteria enorme per farlo durare tantissimo no? Non sarebbe stato il prodotto che oggi è amato da tantissime persone e che ho dato da tantissime anni.Quindi ti dico sì, questo è un problema che continua a esistere.Ci sono dei progetti come c'è stato Compact 2021, non so se l'hai visto, che ha messo d'accordo tutti i browser dicendo "ok facciamo così, è inutile che pensiamo...la sto facendo un po' storytelling...Inutile che ci andiamo, io da una parte, tu da un'altra, tu da un'altra ancora, facciamo così, prendiamoci un paio di problemi comuni a tutti e troviamo la soluzione.Troviamo la soluzione, ad esempio uno di questi era lo sticky footer, se non mi ricordo male, alcune rule CSS, non sto ricordando esattamente quali fossero.Quindi questo progetto ha consentito di far collaborare le realtà che scrive Brose.Questo progetto è cambiato, ora lo sto ricordando come si chiama, ma c'è una grande intenzione sotto questo punto di vista.Poi chiaramente il mercato è il mercato, non c'è troppo da discutere e troppo da ragionare questo oggettivamente è così quindi sicuramente lo scollamento ancora è probabilmente continuerà ad esserlo su però molte di queste pi in realtà ad esempio le trovate su più sistemi operativi perché in questo caso non c'è solo il browser di ricordo ma l'affare si complica però diciamo la direzione, attenzione Project Fuguro non è un progetto di Google, è un progetto multicorporee guidato da Google perché chiaramente ha l'ownership di Gnomem.C'è anche Microsoft e Intel se non ricordo male.Sì sì sì sì assolutissimamente assolutissimamente.Quindi diciamo è comunque un impegno abbastanza comune e ampio.Devo dire che in realtà da un punto di vista è una lenta rivoluzione, lenta perché comunque sai si parla di standard quindi i tempi sono quelli che sono però dall'altro canto se proviamo a guardare un po' com'è il nostro uso del computer oggi è spaventoso.Io facevo un ragionamento l'altro giorno e siccome sto pensando di prendere il nuovo notebook e ho un po' di scazzo con Apple, è un periodo che ce l'ho con Apple non ce l'hai con Apple perché non hai trovato l'architettura e armi, avrai ancora un'info? No, no, c'ho anche un MacBook Pro con l'M1 ma è in salotto fermo per una serie di scelte politiche più che altro, un vecchio idealista e secondo me il fatto dei 70.000 dongle, il fatto della RAM bloccata, del disco bloccato, io oggi mi ritrovo una macchina che avevo pagato 5.000 euro che non è in grado di reggere neanche il divano se lo metto sotto, poco qualche anno fa è un po' la cosa mia mi ha innervosito e quindi poi per colpa del Paolo e Alessio sto usando Arch Linux sembra un ritorno alle origini l'audio funziona di merda.Tu ti sei messo anche dietro ad alcuni estremisti sotto questo punto di vista.Lo so, però in realtà...Lo conosco anch'io.Però in realtà ne sto apprezzando la cosa, all'ira dell'audio che comunque rimane comunque una merda.Detto questo però, quello che...mi sono dimenticato cosa volevo dire...Ah, che alla fine facciamo un ragionamento, no? Sulla nuova macchina dove ho messo Arch.Io in una settimana ho fatto tre file.Ho creato e salvato nella macchina tre file.Tutta la mia vita digitale passa per il cloud, da GitHub, in questo caso per lavoro Azure DevOps, all'audio che rimane da stringare.Magari lo scarico, lo modifico e lo ri-upload.Assolutamente.Cioè io non sento più il bisogno di utilizzare il mio sistema di backup.Ma esatto, oggi parlavo con una persona e mi ha detto "sto facendo un backup" e io ho detto "ma "Ma che faccio? Non faccio un mecca punto da vita!" E poi, andando a prendere qualche informazione a leggiucchiare del progetto Fugu, ho letto una dichiarazione di Intel che dice che a oggi il 50% dei cicli macchina del processore servono per far girare il browser.Posto che c'ho un mega punto di domanda perché vorrei capire come cazzo fa Intel a sapere che il 50% dei cicli macchina sono per il browser.Non è neanche così difficile pensarlo.Sicuramente avranno fatto un'analisi statistica campione.Oggettivamente il browser l'applicazione in assoluto più utilizzata.Ma attenzione, non solo oggi, ma storicamente oramai a livello di tempo d'uso.Se noi prendiamo tutte le persone che hanno utilizzato un browser, non lo so quante vite di Matusalemme potremmo mettere una dietro l'altra.In assoluto il software più utilizzato di tutti.Browser, non quel browser.Mi vergogno tantissimo a dirlo, ma non mi vergogno troppo a dirti che io almeno avrò 300 tab aperte in questo momento.Organizzate perché per carità ho le mie tab raggruppate, ho i miei profili utente per utilizzo.Diciamo così, ma la notura mica è gratis.Una delle cose su cui stanno lavorando è proprio ridurre il tempo di disattivazione della richiesta di risorse proprio perché è diventato...c'è qualcosa...cioè l'utilizzo di questo strumento è andato molto più veloce della realizzazione dello strumento stesso e del poter fare fine tuning è una cosa complicatissima.E anche della consapevolezza nella quale lo si usa.Io su questo ci batto spesso, nel senso che io non me ne rendo conto ma davvero lo uso un pacco, lo uso veramente tanto.Faccio l'esempio di VSCode che molti sanno che è l'editor che io amo.Il fatto di poterlo far girare da browser mi scolla.L'editor era uno dei pochi tool che ancora mi tenevano ancorati a un sistema operativo.A questo punto ti posso dire che nel momento in cui Visual Studio Code mi gira su browser e nel momento in cui posso emulare un terminale su browser, cioè io mi prendo un Chromebook.O usarlo con Codespace.O usarlo con Codespace, ma sto provando Flit e c'ha l'omologo, no? E quindi alla fine mi dico, sta cambiando qualcosa? ne siamo consapevoli, ci siamo fatti le giuste domande, perché noi oggi siamo figli di questa passione, di questa la fregolina del nerd, che dice "oh è uscita l'ultima cosa, la devo provare, la devo fare".Siccome la nostra è un'industria, tu hai detto prima all'inizio, ci stiamo basando una importante parte del mondo su questa industria, ci stiamo facendo le giuste domande? Assolutamente! Ti dico una cosa soltanto, che non me ne voglia male nessuno, io ti dico soltanto una cosa giusto per farti capire.Ho visto applicazioni pazzesche con i framework più aggressivi, più per tutto quello che vuoi e ci abbiamo messo i milioni di servizi e del guarda là, io oggi ho visto un progetto fatto da una persona, scritto in PHP e che aveva solo JQuery.Credimi, io un prodotto non banale, attenzione non banale, io una cosa più veloce di quella non l'avevo mai vista.Giusto per farti capire che probabilmente quella cosa scritta con ciò che oggi schifiamo però è scritta molto meglio perché quella persona ha molta consapevolezza di quello che sta facendo rispetto a qualunque altro strumento super figo che usiamo perché è super figo e magari c'è poi magari una bomba attenzione ma il nostro approccio è che lo usiamo perché è figo.Guarda parli con uno che deve andare in produzione un progetto che deve supportare il progressive announcement fatto in Next.Il progressive announcement dei più radicali, quindi anche con javascript disattivato.Sai cosa vuol dire? Si, credo.Se andavo con jQuery e pagine HTML, forse avevo meno dolori.Esatto, cioè comunque va valutato esattamente lo strumento giusto, per il caso giusto.Invece te la posso fare una domanda io? Vai.Ma come cacchio lo chiami questi episodio che abbiamo parlato? la complessità di semplificare le cose.No, mi ho inventato qualcosa, non lo so.Ma bello, ma bello! E poi sei tu il master of titles.Eh lo so, però...non lo so, non l'ho fiazzato.Ma questo "master of headlines" è fighissimo.te lo stampo te lo mando e lo metti a fianco alle certificazioni e ai prize maledettissimo Fra io ti ringrazio prima di lasciarti andare però ti devo chiedere se hai qualcosa da condividere con la nostra community che sia un libro un video un talk o un disco "E conduco nel paese dei balocchi" "Ah, il paese dei balocchi" Però ti devo chiedere se hai qualcosa da condividere con la nostra community, che sia un libro, un video, un talk, un disco, decidi.Assolutamente, allora video, talk, quelli link, quelli poi te li giro volentieri.Invece quello che voglio suggerire, prima che cominciasse la puntata, volevo suggerire l'ultimo album dei Mastodon, che è un album secondo me formidabile, si chiama "Ashed and Grimm" del 2021.Ma poi tu prima hai tirato fuori il banco del mutuo soccorso, che per me è un gruppo importantissimo nella mia cultura musicale, quindi invece quello che vi suggerisco è Darwin.Ascoltate, Darwin del banco del mutuo soccorso.Questo è quello che provo a lasciarvi.Prima di registrare il prossimo episodio tra qualche minuto me lo ascolto.Io invece voglio suggerire un libro, perché? Perché in realtà una parte del nostro lavoro è anche comunicare quello che facciamo e talvolta sia che stiamo presentando delle nuove feature al team o stiamo facendo una retrospettiva o stiamo presentando le feature all'altra parte della società o al prodotto owner che c'è dietro l'angolo, oppure stiamo parlando a una conferenza, abbiamo bisogno di fare delle slide e noi generalmente in quanto sviluppatori siamo abbastanza capri con le slide, le facciamo o utilizziamo dei tool dove dobbiamo solo scrivere il testo, compilare e usare dei template già pronti, oppure utilizziamo Google per fare due slide dal volo powerpoint qualcuno, ma alla fine non ci prestiamo tanta attenzione e soprattutto non prestiamo attenzione a come rappresentiamo i concetti.In realtà la rappresentazione del concetto, e questo mi viene dagli studi che sto facendo adesso riguardanti la psicologia e il carico cognitivo, la rappresentazione del concetto è il miglior modo per trasportare il concetto da una cosa che si chiama memoria di lavoro, quindi il primo livello di memoria quando stiamo assimilando le cose, a trasformarla in connessioni neuronali che poi è la memoria a lungo termine, quella che ci rimane finché non moriamo.Il modo migliore, se il concetto è molto grande, ci sono tanti concetti che entrano in gioco, è visualizzare le cose.Bene, esiste un libro, fatto molto bene, in realtà c'è una parte interessante, c'è un po' di riempitivo come tutti i libri, però c'è una parte che parla appunto dell'utilizzo dei diagrammi e delle illustrazioni all'interno delle slide, che non bisogna essere necessariamente dei disegnatori o dei grafici per metterle, ma ci sono dei concetti, che adesso il concetto è il grande e il piccolo, il concetto del vicino e del lontano, che sono degli archetipi, parte della nostra natura umana e che in qualche modo ci possono venire d'aiuto quando dobbiamo trasferire della conoscenza.Il libro si chiama Sleidology e fa il paio, la coppia, con un altro libro bellissimo che si chiama "In the back of the napkin".C'è anche una versione italiana, il titolo è "Nel retro del tovagliolo"."Nel retro del tovagliolo" è, diciamo, il libro più legato alla teoria di rappresentazione del concetto, Slideology la prende un po' più alla leggera e si basa sulla creazione delle slide.Se una parte del vostro lavoro è anche raccontare quello che fate utilizzando le slide, secondo me averli nella libreria e leggerli anche può essere un buon investimento.Altrimenti avete solo riempito la libreria, non li avete letti, fanno colore nella libreria.Su questo comunque se ti posso dire io sono un grande fan invece io ci sono molto attento a fare le slide perché secondo me...poi comunque alla gente quella e li lasci, cioè ora magari siamo abituati che ci sono i talk online, con tanto contenuto registrato e via dicendo, ma fino a prima del covid non era così scontato, rilasciavi le slide.E comunque far sì che quelle slide possano trasmettere qualcosa senza dover scrivere un capitolo di un libro per ogni slide è importante.Quindi sicuramente riuscire a avere focus su questo genere di cose è super importante, assolutamente sì.Io dico sempre che se tu sei il cicerone che porta l'ascoltatore in un viaggio, le slide in qualche modo vogliono essere i punti di riferimento che tu dai mentre percorri questa strada, questo percorso, quindi la cura nelle slide vuole anche dire un livello di cura verso il tuo auditorio.Assolutamente.*musica* Una birra please! *musica* Eccoci qua, eccoci qua, è il momento di ringraziare i donatori chi si fa carico di sostenere in qualche modo una parte delle spese di Gitbar perché Gitbar sì è gratis, ma in realtà ha dei costi, costi fissi, costi ricorrenti insomma, alla fine, affinché ogni settimana o quasi riceviate il vostro episodio direttamente nel vostro client di podcast qualcuno ci deve mettere il lavoro e qualcun altro si fa carico appunto di pagarne le spese e questa settimana dobbiamo ringraziare Franz e gli amici di Mowi Space perché in realtà offrendoci 10 birre si sono fatti carico di una parte delle spese del mese di agosto.Quindi ringraziamo Franz e gli amici di Mowi Space che e ci hanno anche lasciato un messaggio che vi leggo adesso un saluto e un piccolo aiuto da Mowyspace complimenti per tutto l'impegno che state mettendo nel podcast continuate così, noi vi ringraziamo grazie a te Franz grazie a tutti i ragazzi e le ragazze di Mowyspace e a questo punto non possiamo far altro che brindare alzando i 10 calici appunto 10 birre che ci avete offerto e brindiamo alla vostra salute.Grazie! Come sempre ragazzi io non so perché vengo sempre messo in mezzo in questa cosa probabilmente perché sono l'unico che non si vergogna a parlare di soldi ma non vedo perché vergognarsi è una cosa così bella parlare di soldi perché i soldi sono veramente la cosa più bella del mondo, quindi donate perché dobbiamo fare la cena da massimo bottura con i vostri soldi, quindi è una cosa molto importante e siamo molto poveri, quindi donate copiosamente, veramente in tantissimi, mi raccomando dateci i vostri soldi e noi ne faremo l'uso più responsabile che se ne possa fare ovvero metterli su delle cripto uscite da mezz'ora potremmo rimanere un altro giorno a parlare anche solo di questo, ogni volta che ci sentiamo è così le endless conversations.Esatto, esatto.Fra, io ti ringrazio tantissimo, grazie di cuore per esserci venuto a trovare, come dico sempre quando hai qualcosa da raccontarci mi raccomando, contattami.Qua una birra fresca per te c'è e ci sarà sempre.E io la berrò con tanto, detto questo io vi saluto ringraziando nuovamente fra a nome mio e di tutta la comunità ciao ciao a tutti gitbar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con re repo parliamo di linguaggi e tecniche di sviluppo web web di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dead.
