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 i nostri contatti Info che ho c'è da Geekbar.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 modi 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...

sono stanchissimo, si sente? Per chi non l'avesse ancora fatto, mi raccomando, iscrivetevi Benvenuti su Geekbar, 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 Detto questo è arrivato il momento di presentare il nostro ospite Ho con me Francesco Sciuti, ciao frà, come stai? Bene, 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, è diverso Sono grandi soddisfazioni anche quelle, se non maggiori Ti devo dire che una cosa che hai detto cambierà il mio omaggio, il mio tipo extra mondo dello sviluppo Vabbè, 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 tournée 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, non so neanche se l'ho salutato o non l'ho salutato 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, un day 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, 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 Ma 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, amico, questa è una domanda un po' curiosa, è un po' della risposta non scontata Lo stato di salute delle progressive web apps 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 le immaginiamo canonicamente Come ci siete presentate inizialmente Probabilmente la loro faccia e il loro aspetto Non è esattamente quello di una volta Quello che sono oggi le progressive web apps, 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 apps Una su tutte, le famose push notifications 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 apps Che sono cambiate e che sono interessanti E una di queste, anzi, più di una di queste Sono anche degli asiduso concreti E cioè, uno, la cosa interessante delle progressive web apps Che ci lasciano in qualche modo da subito Sono tutte le capabilities che sono state costruite Sia per far sì che le progressive web apps 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 delle web capabilities in genere Però devo dire che questo genere di migliorie hanno portato ad una miglioria più ad ampio spettro rispetto alle progressive web apps Secondo me quello che, invece, oggi fa veramente la differenza sulle PWA È averle come possibilità di installarle sul proprio computer Simulando un'applicazione standalone canonica che avremmo avuto sulla nostra applicazione Quindi l'installabilità sul nostro sistema operativo non mobile, desktop Questa, secondo me, è una delle cose più interessanti Infatti ci sono un sacco di API che sono costruite oggi, 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 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 del mio Chrome Oggi ce le ho come iconcina, come applicazione standalone della mia macchina 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 la nostra applicazione mobile, il nostro programma installato nella macchina Dall'altro lato c'è il web, quindi scusami prima ho detto male, non volevo dire nativo e mobile, volevo dire nativo e web come differenza Per le progressi web app di solito si pensa che posso installare le mie applicazioni sul telefonino, sul mio smartphone Non è quello, l'obiettivo della progressi 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, ma si sa che io se comincio a parlare non finisco più, poi tu taglia tutto Secondo me le progressi 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 le conferenze Diciamo che sono variate, in modo molto più trasparente, ma può andare bene come no, non può andarlo, spero ti piaccia lo stesso Sì devo dire che in realtà quello che ho notato è che è cambiata radicalmente al di là del fatto che il numero delle capabilities e 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 dà 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 chiacchierando stavo riguardando alcune web api che sono state rilasciate, poi se vuoi parliamo anche del processo di rilascio delle web api Una di queste ad esempio è la possibilità di gestire il multi screen window placement, 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é 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 è successo Ma il succo è che 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 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 contro delle Progressive Web App era appunto la performance, girando dentro un browser la performance è quello che è e ne siamo consapevoli però con l'apparire 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 E' la più rapida di là ad oggi Sì 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 questo approccio? Mi piace come domanda, approvata! A parte gli scherzi, tu hai sottolineato due cose interessanti, una è quanto queste due tecnologie, nel nostro caso specifico Webmaster da un lato e WebGL dall'altro, possano offrire tantissimo boost a livello di esperienza utente Però attenzione ad una cosa, anzi a due cose, innanzitutto WebAssembly e WebGL, WebGL è più un'esperienza migliore a livello 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, pensa lasciano la tagliare con le GPU Quindi se non mi ricordo male Babylon già lo supporta e ci sono anche un po' di test da vedere.

Su WebAssembly faccio un altro ragionamento e dopo concludo dicendoti una cosa sulle prestazioni, WebAssembly è un mondo assestante secondo me e ne stiamo facendo esperienza vedendo anche tutto quello che ci sta cominciando a ruotare attorno, quasi WebAssembly è 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 per me più generico, lo strumento poi il vero utilizzo lo darà l'utilizzatore stesso Per 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 se a posto di esserci un naufrago ce ne fossero stati più di quelli che giocano a pallavolo, automaticamente uno strumento si sarebbe trasformato, poi penso sempre alla scena quella dei Griffith, ma quella è un'altra storia, mi auguro tu non sia qui a ricordarla No, 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, e 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, 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 meglio dire l'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 ancora finito di farlo Però nel contempo ho pensato, beh, allora io prendo i dati, li sbatto dentro WebAssembly, 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, metto, quindi posso farlo anch'io, non devo prendere in mano, che ne so, Rust 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, no? Assolutamente sì, assolutamente sì, e prima citavi Figma, no? Tu pensa a Omiro, no? 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 ovvio, per un utilizzo comune di JavaScript, comunque di un'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, no? Cioè, a come cacchio funziona un browser? Ho fatto un talk, tra l'altro secondo me è divertentissimo, e qualcosa mi sto ricordando esattamente, noi 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, e 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 come non è facile Sì, sei su Gitbar, possiamo dire quello che è, siamo in un bar, quindi 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 Qwik da parte di Misko Hevery, il creatore di AngularJS, e anche di Angular, uno dei suoi usciti, ma vabbè altre storie E lui sottolineava questa cosa, diceva che stiamo attenti a quello che succede normalmente, e che oramai siamo tutti abituati ad utilizzare delle astrazioni o 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'iteration da risolvere in fase di caricamento Quello ce l'abbiamo perché prima di tutto dobbiamo saperlo, 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 volent o nolente, se prima non parte JavaScript, non possiamo fare niente Quindi diciamo che probabilmente prima di pensare a tutte queste cose, bisognerebbe ragionare a scrivere un po' meglio.

Io conosco pochissima gente che delega la roba ai web worker, ma pochissima gente che lo fa Dicono che io sono bravo, gli altri no, io mi lupo oramai una volta ogni sei mesi, quindi figurati, però diciamo che ci sono degli strumenti, ancora prima di ragionare, di dire, ma allora io faccio i web assembli così, ho le prestazioni migliori Non so se posso dire brutte parole qui, non me le ricordo, ma vabbè le evito.

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 web assembly, se prima non abbiamo provato neanche a delegare un'operazione magari più dispendiosa a un web worker O quando parliamo di audio magari cominciare a vedere come funziona il worklet a riguardo, che sono dei worker specializzati per determinati compiti Chiaramente è sempre un problema al di sopra di tutto, 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ò chiaramente 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 ancora non è matura, non mi conviene parlare, che a me frega, ho scritto di rom JS molto prima che se ne sapevi, già è stato scritto due volte Ho questo vantaggio di poter scegliere quello che mi piace studiare, e te lo dico perché, perché proprio su WebAssembly quello che sto studiando è WOT, se tu parli con chi lavora con WebAssembly, non hai neanche idea di che cosa sia Ma è sostanzialmente 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 quello che decompilerai Quindi anche lì ci sono livelli di astratto, ovviamente se ti metti a scrivere una cosa completa sei pazzo se ti metti a farla in WOT, ci mancherebbe per carità Diamo sempre un po' la colpa agli altri, per gli altri intendo a qualcos'altro, mai che ci chiediamo cosa ci posso mettere di mio per migliorare un po' questa cosa Poi ribadisco, ci tengo a dire perché non voglio essere il paladino di questo 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, o sto dicendo SOLID perché da fronte di vista è quello che mi viene da dire, ma prima fatti un esame di coscienza per andare a vedere SOLID, vedi se sai usare quello che ti dà a disposizione il tuo browser Poi per carità, conosci l'event loop, poi è giustissimo, 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, prima di innamorarmi di LIT, ho sbattuto la testa su WebComponent per due anni, ma ripeto non voglio fare una figura, ma sicuramente Tu hai evidenziato 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 E 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 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 soddisfazione rapida cioè ci devono essere una serie di elementi che triggerino la soddisfazione rapida in modo da alimentare l'alimentazione, alimentare 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, quindi imparare facendo.

La soddisfazione è importante, ma come fai a capirne il contesto quando utilizzi questo approccio? A forza di schiaffi in faccia.

Quando vedi che qualcosa non funziona nel rendering, la sto buttando così, ci vai, te lo guardi l'event loop come funziona, o potrei dire la stessa cosa del frame, utilizzi Fastify, mischi Promise con Callback, vedi che succede il finimondo e dici, ma allora come funziona l'event loop di Node? Ti faccio un esempio, credo esattamente calzante rispetto 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, Svelte, Ora, Flash, tutta questa roba che sta uscendo, si vantano di essere più fighi perché non basano la propria reattività su Virtual DOM.

Ok, facciamo tutti via.

Io 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 il Virtual DOM.

Non so scrivere anche 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...

Rick Harris ne ha fatto una campagna su questo non usare il Virtual DOM, ma se non sai esattamente qual è il limite del Virtual DOM, 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.

Però sono junior, ok, oggi, JavaScript fatigo, 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à sentire più vecchio di quanto sono là, però va bene.

Allora ti dico, in questa occasione c'è il problema della copertina troppo corta, 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 un award che raggiungi, mi ci metto anch'io assolutamente in questo genere di 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 React, si sposta su pincopallo, fermi tutti.

No, non è la cosa giusta da fare.

Spostati un attimino, 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 do neanche la colpa all'azienda, perché l'accelerazione in quel caso è… Leggevo una cosa che è abbastanza comune da leggere oggi, però un po' mi ha schiazzato, non c'è truttura.

Sono quelle cose che ti lasciano dire che noi non 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, se fosse stato scritto meglio avremmo avuto un risparmio energetico quasi del 15%, altro che l'industria del carbone.

Se ci pensi, noi ora cominciamo a coprire un ruolo che è 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.

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.

E questo è 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, questo è 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, con una mentorship, con un 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, c'è prima o poi gli schianti, ti schianterai così come mi schianto io quando mi viene a parlare di Kubernetes.

Per me Kubernetes è una cotoletta, cioè 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 imparare a usare Kubernetes senza avere il background di quello che è la condenalizzazione, la programmazione distribuita, la scala networking.

Io me lo posso andare a prendere un corso su, non di Kubernetes, ma anche su Yudasidi, su piattaforme più autorevoli, tutto quello che vuoi.

Ma poi prima o poi mi 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 posso tornare un attimino al discorso del browser, che secondo me è una cosa utile.

Ad esempio, studiaccando 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? 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 frontend, l'hanno preso e l'hanno messo a lavorare su Blink, sul render engine Blink.

E quello diceva, io quando sono arrivato, credetemi, non ci ho capito un tubo.

Non ci 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, ma qua devo fare una cosa, ma come la faccio? Come faccio a non creare regressioni su una roba del genere? Se non hai una conoscenza profonda, anche dei limiti che ci sono su determinate codebase, su determinate problematiche, su 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 argomento.

Sai perché? Perché pochissimi parlano di complessità e learning path insieme.

E invece 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, ma anche tutta l'astrazione che il cloud ci porta.

Tu, attenzione, non sai utilizzare Kubernetes, tu sai utilizzare la versione Managed, che ti dà 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, serve la consapevolezza, cioè la dobbiamo mettere a bilancio, questa cosa.

Hai ragione in quello che dici.

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 un'astrazione, prima o poi mi torno indietro.

Io ricordo un bellissimo tuo episodio con Salvatore Sanfilippo, dove parlaste proprio di questa cosa, e lo metterò nelle note dell'episodio, perché avete affrontato il punto della complessità, no? E 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, no, 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 Project Fogu in genere.

Si chiama in realtà come Progetto Web Capabilities, a dire il vero.

Il pesciolino è fighissimo, dai.

Come? Il pesciolino è fighissimo.

Ah voglia, voglia, ma c'è una storia, se potete la raccontate, senza nota però se potete la raccontate un attimino.

Sostanzialmente questo progetto, Web Capabilities, o comunque Project Fogu, ah, Project Fogu, 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, fino ad oggi, non abbiamo potuto fare.

Chiaro, quella più lambante di tutte, tiro 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 nel passato, tutte queste prove poi hanno portato ad utilizzare Electron per fare Visual Studio Code.

Tutto ha portato lì.

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 un genio, da un lato, 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, e ora diciamo come, consente di utilizzare appunto il nostro File System.

Vi ricordo, utilizzare ad esempio le Push Notifications, ma soprattutto utilizzare, come mi viene il termine, push da un lato e dall'altro, la Notification API.

Quindi le notifiche che noi vediamo sulla nostra macchina, o se siamo su Android, sul nostro smartphone, ma che gestisce 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, con 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, che 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 quell'invio all'analytics che tu imparesti 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, in piena follia del nostro browser che deve gestire un quantitativo notevole di cose.

Oggi è possibile attraverso le API che arrivano attraverso questo progetto, di fare la recognition della scrittura manuale, non hai 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, di una fesseria comunale, andare a riconoscere il tratto calligrafico.

Perché questo, se ci riflettiamo? Perché il sistema operativo lo sa fare? Il sistema operativo queste cose ce le ha.

Il sistema operativo, il detect macOS, 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, che ci consente di utilizzare le API.

Tu dicevi di NFC? Assolutamente sì.

Possiamo lavorare sulle seriali? E' una cosa che ci pensi che è 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 lampante, 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 scarico.

Non lavori con il tuo file system.

Giusto per capirci.

Sul discorso quindi 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 col nostro sistema operativo, non tutte le API di questo progetto, e per carità, buonissima parte nasce soprattutto per questo.

L'altra cosa che è importante è che questo genere di API seguono un workflow di creazione estremamente developer driven.

Cioè le API, cosa che succedeva in passato, le API venivano a un certo punto rilasciate.

Ok, sul browser c'è questa nuova funzionalità, tu dici è bellissimo, poi la usavi ed era usabile come un pallone da calcio fatto in Cemento Armato.

Finalmente la potevamo fare, ma è totalmente inusabile.

Ad esempio sul file system ci sono stati più di un esperimento, o sullo store WebSQL ad esempio.

Oggi invece queste API 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 ve li 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 plugin e puoi utilizzare la funzione WebGL quando usci.

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, di fare degli esperimenti e autorizzare per un preliudo di tempo, quelle API per il nostro progetto.

Quindi un utente che arriva 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 utilizzarla.

Non so se sono riuscito a darti questo escurso, ma poi puoi 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, 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, 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 dei sandboxing, non so se l'avrete capito i rush 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 dare, se questo sito fa 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 utilizzo, contempla una richiesta esplicita.

Tu non puoi utilizzare il file system del sistema operativo se prima non dici sì, sono disposto a farlo.

Come ti spunta l'iconcina nella tua barra? Come ti spunta l'iconcina quando utilizzi la cam? Tu la cam la devi autorizzare, non è che se usi Streamy, se usi Meet, le prime volte che le usi la devi autorizzare, così come il microfono.

Non lo so se l'avete notato, ma c'è l'iconcina che ti dice che lo stai utilizzando, puoi richiedere indietro l'autorizzazione che hai dato.

Poi chiaramente ci sono utenti e utenti, c'è l'utente che dice una maschera, c'è scritto ok, perfetto, premo ok a prescindere da tutto.

Ma poi c'è un limite a quello che si può fare.

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ù dettato dall'architettura del browser che dal sistema operativo in quanto dà.

Il sistema operativo alla fin fine una feature o te la mette a disposizione o non te la mette a disposizione.

Non c'è troppo da discutere a tal riguardo, non c'è una difficoltà a 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 a disposizione come API di sistema operativo la detection dei porti, benissimo se te la mette a disposizione deve essere il browser e questo layer di API a consentire di utilizzare in maniera, primo sicuro, secondo prestante, anzi no va bene 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, scusami il mio display o il mio viewport è a 1200 pixel piuttosto che a 600, ora puoi lavorare 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 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 numeri di render per fare una cosa del genere, che sostanzialmente avevamo un caldo di prestazioni mostruose, quindi non poteva essere rilasciata.

Quindi prima di rilasciare le API è stato necessario riscrivere una parte del engine, cioè tu pensa che è follia, no? Se ci pensi è assurda come cosa, però a me affascina un sacco.

Prima hanno dovuto riscrivere quello, poi puoi rilasciare quello che vuoi.

Quindi c'è tanto da ragionare.

Il progett Fugu in questo caso pensa a come debba essere realizzata 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 che sono illuminanti.

Di giù sono veramente illuminanti a riguardo, secondo me.

Guardavo l'orologio, lo sai no? L'ultima volta che abbiamo registrato insieme abbiamo fatto tre ore e mezzo.

Questa volta so che devi andare dai tuoi figli e non posso trattenerti troppissimo, altrimenti avremo occasione di farci la chiacchierata di persona davanti a una birra.

Ti voglio però prima di chiudere fare un'altra domanda.

La domanda è un po' una provocazione più che una domanda.

Chromium barra Chrome corre.

E gli altri browser? Questo scollamento può essere un problema? Oddio, sì, Chrome corre, cioè il progetto Chromium corre.

Attenzione che il progetto Fugu passa da Chromium, 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ù soldi di Mozilla.

Quindi è anche un problema abbastanza scontato.

Ci sono anche i problemi delle compagnie che portano avanti questo genere di cose.

Safari, di contro, tutti dicono che è 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 Safari sia il team più piccolo che ci sia in Apple, ma va bene, quella è un'altra storia.

Per tal proposito, l'altra volta vedevo un'immagine divertentissima, che era l'iPhone, se l'Apple 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, una batteria enorme per farlo durare tantissimo, sarebbe stato il prodotto che oggi è amato da tantissime persone e che ha dato da tantissime anni.

Quindi ti dico che questo è un problema che continua a esistere.

Ci sono dei progetti come Compact 2021, non so se l'hai visto, che ha messo d'accordo tutti i browser dicendo che è inutile che pensiamo...

facciamo un po' di storytelling...

inutile che ci andiamo, io da una parte, tu da un'altra, facciamo così, prendiamoci un paio di problemi comuni a tutti e troviamo la soluzione.

Ad esempio uno di questi era lo sticky footer, se non mi ricordo male, alcune rule...

non sto ricordando esattamente quali fossero.

Quindi questo progetto ha consentito di far collaborare le realtà che scrivono browser.

Questo progetto è cambiato, ora lo sto ricordando come si chiami, 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.

Oggettivamente è così, quindi sicuramente lo scollamento ancora è e probabilmente continuerà ad esserlo.

Però molte di queste API in realtà le trovate su più sistemi operativi, perché in questo caso non c'è solo il browser, l'affare si complica, però la direzione del progetto Fugu non è un progetto di Google, è un progetto multicorpore, guidato da Google perché chiaramente ha l'ownership di Unomium.

C'è anche Microsoft e Intel se non ricordo male.

Sì, sì, sì, assolutissimamente.

Quindi è comunque un impegno abbastanza comune e ampio.

Devo dire che in realtà da un punto di vista è una lenta rivoluzione, lenta perché comunque 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, siccome sto pensando di prendere il nuovo notebook e ho un po' di scherzo con Apple è un periodo che ce l'ho con Apple.

Ma non ce l'hai con Apple perché non hai provato l'architettura ARM, avrai ancora un'Intel.

No, no, ho anche un MacBook Pro con l'M1, ma è in salotto fermo, per una serie di scelte politiche più che altro.

Un vecchio idealista, 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.

Qualche anno fa è un po' la cosa che mi ha innervosito, quindi poi per colpa di 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à...

E conosco anche io.

Sì, però in realtà ne sto apprezzando la cosa, al di là dell'audio che rimane comunque una merda.

Detto questo, però, quello che...

mi sono dimenticato cosa volevo dire.

Ah, che alla fine facciamo un ragionamento 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 la stringhiata, magari lo scarico, lo modifico e lo ri-upload.

Non sento più il bisogno di utilizzare il mio sistema di backup.

Oggi parlavo con una persona e mi ha detto che sto facendo un backup.

Mi ho detto, ma che no, non faccio un backup nella mia vita.

Poi, andando a prendere qualche informazione, 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.

Ma sì, 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 so quante vite di Matusalemme potremmo mettere una dietro l'altra.

In assoluto il software più utilizzato di tutti è il browser, non quel browser.

Mi vergogno tantissimo a dirti, 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 intente per utilizzo.

Ma non è gratis.

Ad esempio una delle cose su cui stanno lavorando è ridurre il tempo di disattivazione della richiesta di risorse.

L'utilizzo di questo strumento è andato molto più veloce della realizzazione dello strumento stesso e del poter fare fine tuning.

È una cosa complicatissima.

È 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.

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, io mi prendo un Chromebook.

O usarlo con Codespaces.

O usarlo con Codespaces, ma sto provando Flit e c'è l'omologo.

E qui, 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 fregolina del nerd che dice è 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ù frequenti, tutto quello che vuoi e ci abbiamo messo i milioni di servizi e del qua e della.

Io oggi ho visto un progetto fatto da una persona, scritto in PHP, e che aveva solo JQuery.

Credimi, 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.

Magari, poi magari è una bomba, ma il nostro approccio è che lo usiamo perché è figo.

Guarda, parli con uno che deve mandare in produzione un progetto che deve supportare il progressive enhancement fatto in Next.

È il progressive enhancement dei più radicali, quindi anche con JavaScript disattivato.

Sai cosa vuol dire? Sì, credo.

Che se andavo con JQuery e pagine HTML forse avevo meno dolori.

Esatto, cioè comunque va valutato esattamente lo strumento giusto per il caso giusto.

Posso fare una domanda io? Vai.

Ma come cacchio lo chiami questi episodi che abbiamo parlato? La complessità di semplificare le cose.

No, mi invento qualcosa, non lo so.

Va bene, va bene.

E poi sei tu il master of titles.

Eh, lo so, però...

Non lo so, non lo so.

Ma questo master of headlines è fighissimo.

Sì, sì.

Te lo stampo, te lo mando e lo metti a fianco alle certificazioni e ai prize.

Malendirissimo.

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.

Ti 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 o un disco.

Decidi.

Assolutamente.

Allora, video, talk, quelli link, quelli poi te li giro volentieri.

Invece quello che voglio suggerire, allora, prima che cominciasse la puntata, volevo suggerire l'ultimo album del Mastodon, che è un album, secondo me, formidabile, si chiama Ashed and Grimm 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.

Esatto.

Bello, bello.

Io invece voglio suggerire un libro.

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, beh, 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, usare dei template già pronti, oppure utilizziamo Google per fare due slide al 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, ho fatto molto bene, in realtà c'è una parte interessante, c'è anche 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, fanno parte della nostra natura umana, e che in qualche modo ci possono venire d'aiuto quando dobbiamo trasferire della conoscenza.

Il libro si chiama Slideology, e fa il paio, la copia, 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 è 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 il 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 li lasci, no? 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ì.

Benissimo, 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.

Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS Sottotitoli e revisione a cura di QTSS.