Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori Ormai il caldo sta arrivando, l'estate sta arrivando, il mio obiettivo è quello di coprire tutta la stagione estiva con gli episodi ce la metteremo tutta, vediamo un po' perché tra un po' si parte in vacanza come solito e come ormai da ascoltatori di fiducia sapete, giù in Sardegna non ho una connessione bellissima ma farò di tutto per farvi compagnia sotto l'ombrellone, per chi va al mare sotto l'ombrellone e per chi rimane da solo in città in ufficio triste davanti al suo monitor, farvi lo stesso compagnia insomma può anche essere una cosa gradita o carina detto questo e bando alle ciance vi ricordo rapidamente i nostri contatti infochiociolageekbar.it e tubrairepo su twitter oggi sono solo quindi ahimè vi devo ricordare del nostro gruppo telegram gruppo telegram che ormai vola dove si parla di tutto abbiamo parlato di gaming, di giochi, abbiamo parlato di monitor ieri insomma si parla veramente di tutto e di più per cui se non vi siete iscritti e io lo so che non vi siete iscritti perché vi vedo se non l'avete fatto beh fatelo perché è modo per entrare in contatto con tutti i membri della nostra bellissimissimissimissimissimissima community 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 è proprio partendo dalla community che voglio presentarvi il super ospite di oggi membro di Geekbar nel quale sono super orgoglioso ma anche full stack developer per flowing fa talk internazionali, è admin di diverse community e soprattutto è innamoratissimo di javascript e io lo so come si può essere innamorati di javascript non ho una spiegazione logica a questo ma sono anche io preso da quell'amore senza se senza ma e anche preso benissimo come diremo dalle nostre parti dalle tecnologie di front end beh dopo tutta questa introduzione non posso che dirvi il nome sono con Giorgio Boa ciao Giorgio ciao è un piacere essere qui e volevo salutare tutti gli ascoltatori hai detto bene sono un appassionato e sono innamorato di javascript e so bene il fastidio che hai ogni tanto quando parliamo di javascript delle sue magie che avvengono tante volte dietro le quinte però se pensi a un matrimonio dove magari le cose non vanno sempre bene però alla fine ci fai pace per me è un po' così con javascript io conosco i suoi difetti e me li faccio andare bene guarda mi è venuto in mente un'immagine veramente bruttissima cioè il fatto è che con javascript è un matrimonio proficuo nel senso che genera reddito quindi se vuoi far soldi sposati con javascript no scherzi a parte oggi con te vogliamo provare a dare un'occhiata a Svelte e non solo perché poi parleremo anche di altre cose tieni presente che io Svelte non l'ho cioè devo ammetterlo l'ho provato a tipo la puntata 2, 3 una delle primissime puntate di Gitbar poi sai non si può stare dietro a tutto qualcosa la devi mettere da parte e Svelte è stato uno di questi e per questo che con super piacere mi piace chiacchierare mi piacerebbe chiacchierarne con te però la prima domanda è come sei arrivato a livello professionale a javascript e poi come sei arrivato a Svelte? ok allora a javascript sono arrivato creando passando un po' da quelle applicazioni che facevano sia la parte back end ma anche la parte grafica a un certo punto è arrivata tra virgolette la moda del web application quindi delle single page application e così all'interno del mio team sono stato uno dei primi a metterle mani su javascript e da lì è nato l'amore a livello di Svelte invece è un progetto che ho seguito da tempo e l'ho seguito ancora quando non aveva il supporto a typescript ancora nella versione 2 adesso siamo arrivati alla versione 3 avanzata e typescript visto che la community lo richiedeva fortemente è stato adottato era il caso no? sì sì sì secondo me è il caso soprattutto in grossi progetti ha il suo perché mentre mi piace ancora sporcarmi le mani con il vanilla javascript se ci sono dei progettini così da one man project diciamo ma come fai? io non dovrei dirlo no? ci credi che se devo fare che ti dico un tool a linea di comando che mi scrive i capitoli dentro l'mp3 come ho fatto io non riesco più a fare un progetto javascript senza i tipi sarà qualcosa di malato non lo so però veramente mi viene difficile lavorare su progetti in plain javascript a lavoro mi capita no? anche di mantenere di fare piara, librerie open source dove i tipi typescript non è first citizen no? dove ci sono i file di tipi che risolvono grossomodo i problemi però stai lavorando con javascript è veramente...

mi pesa sì è vero, adesso ultimamente sto seguendo un progetto per un cliente per il quale stiamo creando una pagina per misurare le performance in vanilla html, css e javascript e proprio nella parte di javascript quando andavo a sviluppare il codice effettivamente mi sono reso conto che l'amico che ti siede a fianco che si chiama typescript che ti avvisa che magari la variabile non è stata dichiarata o che la funzione accetta tot parametri invece che altri mi mancava quindi...

esatto, cioè quando saltare qua e là per vedere cosa realmente stai passando e se glielo stai passando bene poi con typescript ci fai appugno un giorno sì e l'altro pure se ti spingi un po' avanti no? perché inizi a mettere roba tipo as undefined, as string dei mostri inguardabili giusto per controllare però se rimani nel giardino cintrato di typescript e non provi a utilizzare delle librerie con typings fatti male grosso modo c'è hai una dev experience della madonna diciamoci la verità però ritorniamo a Svelte, allora tu sei arrivato a Svelte provenendo da altri framework frontend giusto? sì allora precedentemente avevo utilizzato per anni Angular sia nella versione JS per poco tempo e per più tempo diciamo la versione quella nuova che ormai non si può più dichiarare nuova perché siamo arrivati a una versione se non sbaglio alla 14 ho visto con quante versioni lasciamo pensavo che fossimo arrivati anche alle tre cifre poi sono passato a React e infine viste le performance dichiarate di Svelte mi sono appunto buttato su questo nuovo compilatore perché effettivamente a tutti gli effetti non facendo utilizzo del virtual DOM come React utilizza la fase di compilazione per andare a generare del codice che poi a tutti gli effetti è reattivo quindi se noi andiamo a dichiarare una variabile o una funzione che poi cambierà la nostra variabile il compilatore siccome stiamo scrivendo in una sintassi che lui capisce dietro le quinte va a generare del codice vanilla JavaScript quindi degli event listener che vanno in maniera reattiva a modificare il nostro DOM questo è un po' il vantaggio di Svelte che al momento lo differenzia da librerie come React adesso ti faccio una domanda un po' cattiva, te l'avevo detto no? ho parlato un po' rompiballe quindi sopportami per quello che sono ma oggi chi usa Svelte secondo te lo fa davvero per la performance? o la performance è uno di quegli elementi che butti sul tavolo per vendere la macchina nuova che è la macchina elettrica poi scopri che ha tipo tre chilometri di autonomia e poi devi andare a benzina, cioè il valore della performance tu sei uno pragmatico, mi capisci quando dico a livello di business il valore della performance è veramente una cosa che assume così tanta importanza da poi riconoscere e garantire, sponsorizzare la posizione che Svelte ha si è ritagliato in questi anni allora inizialmente è stato sponsorizzato come qualcosa che faceva delle performance alla sua carta vincente di fatto però io punterei sulla semplicità perché proprio fin dai primi momenti in cui ho iniziato a guardare la documentazione di Svelte ho capito che poi non si distanziava tanto da React ed è molto molto semplice utilizzarlo, questo permette di inserirlo anche in pagine con Vanilla HTML e far rendere reattiva solo una singola parte della nostra pagina infatti inizialmente il creatore di Svelte lo utilizzava ai fini giornalistici cioè alle testate giornalistiche invece di andare a mostrare dei contenuti statici per i loro articoli l'andavano anche ad arricchire con delle parti grafiche che rendevano meglio l'articolo stesso infatti molte testate giornalistiche sponsorizzano Svelte e ho visto alcuni talk che pubblicizzano il fatto che lo utilizzano in produzione Sì, io su questo sono particolarmente opinionato, ne abbiamo parlato in una call tra me e te, no? Io ho avuto delle esperienze nel mondo dell'editoria sia come giornalista che poi come ingegnere e in realtà dal mondo dell'editoria è bellissimo vedere come ancora prima che i micro frontend diventassero buzzword venivano applicati perché esistono dei team ed esistevano dei team che si occupavano di fare delle aree specifiche dell'articolo i siti nel mondo dell'editoria sono strutturati e i CMS sono particolarmente blindati però per alcune parti ti permettono e ti permettevano di montare dei componenti, degli elementi componenti lo diciamo io e te adesso, però per loro erano degli elementi multimediali dove all'interno di quel multimediale era compreso anche HTML, CSS e del JavaScript avere quindi qualcosa di modulare che si potesse includere era un plus interessante in termini di approccio rispetto a un approccio omnicomprensivo alla Angular 2 e successivi e questo è stato, ti dico la verità, uno dei motivi per cui io mi avvicinai a React provenendo da Angular perché React fondamentalmente era ci butti dentro la libreria di React ci butti dentro quello che serve per passare il JSX anche a runtime e boom! Fantastico! Tutto funziona perché lo stai montando su quel particolare div che c'ha lì di componentino del piffero e questo è diciamo uno dei motivi per cui Svelte è stato adottato dal mondo editoriale però c'è anche un passaggio che non so quanto possa essere interessante è il fatto che essendo compilato quello che shippy con Svelte dal engineering team è visto come un JavaScript no custom o potrebbe essere visto così, quindi è probabile che agli albori il fatto di voler compilare e shippare una robina senza un sidecar di libreria che poi c'è perché ci sono una serie di funzioni helper che aiutano però riducendo al minimo poteva essere anche un modo, non lo so, per gestire la relazione tra engineering team e multimedia team che si occupava dello sviluppo di questi blocchi sì sì sì in pratica riuscire a far risultare che di fatto era solamente javascript e non c'era una overhead di libreria appresso effettivamente è una carta vincente anche questa ti volevo chiedere per quanto riguarda il compiler è scritto in javascript? allora ho avuto modo di vedere appunto nei primi esperimenti che facevo con Svelte mi ero anch'io domandato se era fatto con javascript e sono andato a vedere gli internals della libreria nello specifico mi ero soffermato nella parte di rimozione delle classi css inutilizzate quindi se noi abbiamo un file css con 50 classi ma poi ne utilizziamo solamente 10 lui nell'output finale mi tiene solamente i 10 quindi mi toglie via tutto il css non utilizzato e quella parte lì dove mi ero soffermato era in javascript poi andando a vedere nel dettaglio anche il resto della compilazione avviene con javascript appunto sai cosa mi stupisce? il fatto che per esempio questa cosa del cleaning delle classi non utilizzate fosse fatto direttamente con un compiler che è quello di Svelte al posto di usare tool come post css o simili io post css lo uso con Tailwind lui cosa fa? va a leggere nei miei componenti le classi che sto usando e poi purga tutto quello che non serve e quindi mi chiedevo perché se l'avessero scritto nativo proprio nel compiler di Svelte questo era un dubbio ma ogni tanto ne esco con questi punti interrogativi senza senso volevo chiederti, prima hai detto che una delle cose che ti piace di Svelte è la sua semplicità siccome so che hai lavorato anche in altri framework, angular, react come ci hai detto prima in cosa lo vedi più semplice? allora innanzitutto la sintasi che è un single file component quindi hai la parte di javascript, la parte di css e la parte di html in un unico file a me onestamente non dispiace, so che molti non sono amanti della cosa però a me onestamente non dispiace e poi a livello di semplicità è perché le api che ti fornisce sono veramente fatte bene abbiamo una parte di state manager che ci viene offerta direttamente dalla libreria quindi possiamo agganciarci in maniera reattiva allo store che lui ci mette a disposizione anche la parte di animazioni è fornita dagli internals di Svelte stesso quindi tutta una serie di api che ti rendono facile il suo utilizzo non ci sono use effect o altre cose da dover inventarsi o dei layer sopra al singolo componente da doversi preoccupare ok in realtà quello che io mi chiedo è si percepisce che è più semplice no? io però tu lo sai sono fortemente opinionato avrei dovuto mettere un disclaimer all'inizio della puntata come ben sapete Mauro difenderà fino alla morte reacta anche quando non avrà ragione ma lui lo difenderà a prescindere no, volevo dire in realtà parte della semplicità come hai ben evidenziato viene dal fatto che esistono meno alternative no? hai parlato di state manager, avendo uno state manager out of the box tu non devi o almeno chi approccia per la prima volta Svelte non è costretto ad andare a vedere come funziona Redux poi vedendo Redux trova altri 70 state manager poi per sbaglio capita in una pagina di documentazione vecchia e trova Flux e non capisce che cosa si è perché sia ancora là e poi trova altri 70 approcci e questa è la famosa React fatigue no? e quindi parte della semplicità viene proprio da un numero limitato di possibilità ma allo stesso tempo però questo numero limitato di possibilità non può essere limitante cioè tu hai lavorato con React e con Angular e hai avuto modo con React di selezionarti lo state manager che più ti stava comodo di usare CSS tutto lo styling come preferivi se volevi usare Emotion, se volevi usare Style Components, se volevi usare CSS Models e poi ti ritrovi nel mondo Svelte e dici ok lo styling si fa così Style è parentesi angolare, che cosa parentesi angolare? il template engine è così, il codice javascript è così, boh fine non l'hai mai percepito come un limite allora diciamo che comunque le varie librerie che sono scritte in javascript sono comunque integrabili se pensi ad esempio a Valtio che è un state manager che si utilizza in React nulla ti vieta di poterlo utilizzare anche in Svelte perché comunque è del vanilla javascript che tu puoi utilizzare all'interno della tua applicazione quindi in realtà Svelte ti offre la possibilità del suo state manager e poi se a te non sta bene puoi comunque andare a utilizzare delle alternative che magari nel tempo ti sei consolidato o comunque il tuo team è consolidato nel suo utilizzo chiaramente è magari meno consigliato però nulla ti vieta di poterlo fare chiaro però capisci bene che dandoti un'opzione out of the box è come Angular una situazione dove tu prendi, lanci il primo comando, il progetto è set upato e quello è quindi anche più facilmente gestibile e soprattutto più raramente avrai lo stimolo e l'autonomia di andare a cercare un nuovo state manager anche solo di avere uno stimolo per la ricerca di un'esigenza e io questo lo capisco, rilasciare un compiler, non lo chiamerei neanche framework perché se no il fondatore si incazza perché lui dice che il framework è senza framework però questo viene un po' dalla storia di Svelte Svelte viene dal mondo editoriale, Svelte nasce fondamentalmente per degli sviluppatori che avevano già il loro framework perché gli sviluppatori che hanno approcciato la prima volta con Svelte se non sbaglio al Guardian prima e al New York Times poi, erano degli sviluppatori che avevano D3 e D3 di per sé è il suo bel framework con la sua bella complessità e quindi non avevano bisogno o voglia di un ulteriore overhead perché sappiamo com'è il nostro carico cognitivo e credetemi D3 o 3JS che erano le tecnologie usate per questo tipo di contenuti hanno già la loro dote di carico cognitivo che si portano appresso quindi questo lo capisco bene però non posso d'altro canto neanche dire che quando tu ti trovi in una situazione lascamente opinionata poco opinionata come quella di React che è una giungla se ci arrivi con un certo livello di seniority a quel punto c'è da divertirsi perché c'è da divertirsi un'altra cosa che tra l'altro per collegarmi alla questione del livello di seniority ho notato è il fatto che molti usino come punto di vendita di Svelte il fatto che scrivere Svelte può far percepire di utilizzare il Java mi viene difficile da spiegare però fare un componente Svelte la parte di scripting ti dà la sensazione di utilizzare JavaScript punto di non avere niente attorno il fatto di inizializzare che ne so le properties del componente con let è così, un po' ti dà quella sensazione di dire ok sto usando JavaScript e la mia domanda cattiva è ok Svelte è facile ha anche una certa dev experience apprezzabile però non ci sarà un po' troppa magia cioè la reattività fatta come la fa Svelte e il fatto di passare le properties semplicemente inizializzandole con let nel componente non sarà un po' troppa magia? allora qui non mi trovi troppo d'accordo nel senso che lo so te l'ho fatta apposta la domanda qui capisco che dichiarando la variabile con let o con il dollaro per la reattività ha tutta una sua sintassi per andare a coprire determinate casistiche però ad esempio se pensi a linguaggi tipo Spring Boot dove si utilizzano le annotation io non lo vedo tanto diverso da l'utilizzare una notation scrivere il codice in un determinato modo noi lo stiamo scrivendo così perché poi il compilatore dietro le quinte sa già come reagire e che codice preparare la stessa cosa è per le annotation che si usano in Spring Boot io metto il chioccio da controller so già che dietro le quinte magicamente mi verrà fatto del lavoro per me quindi non lo vedo tanto diverso come concetto non so cosa ne pensi io sono contro qualunque tipo di annotation proprio a percezione secondo me ma è una questione proprio di gusto personale quindi non la prendo come battaglia io ragione tu hai torto non lo dirò mai questo anche perché per anni mi ci sono riempito il frigo scrivendo annotation su Symfony quindi insomma e Symfony ne ha di annotation volendo però tutto questo ragionamento della metà programmazione per questo tipo di ragionamento vi rimando a un altro episodio che inserirò nelle note dell'episodio dove parlammo proprio di metà programmazione ma sai io lo capisco no? ok Svelte ha la sua syntax Svelte utilizza il dollaro per registrare un listener ok ma se io dico Svelte è molto utile per l'entry level lo sviluppatore entry level che è un po' uno dei selling point diciamocelo per Svelte io leggendo in giro ho letto è un ottimo framework front end framework non framework appartento a parentesi anche per chi soprattutto per chi vuole iniziare e vabbè ma se io voglio iniziare ma Cribio questo dollaro va beh che è più conciso ma se utilizzi un ad event listener probabilmente o comunque una syntax più vicina a javascript che è uno sforzo che ha fatto React e che è uno sforzo che in qualche modo sto vedendo su SolidJS che comunque pare abbracci più javascript e meno custom code rispetto a Svelte pur secondo me sposandone la stessa filosofia in un modo diverso e secondo me poteva essere un approccio migliore però è una mia opinione da ultimo della classe e ci sta mi riconduco sempre al punto di partenza di Svelte Svelte viene da un mondo dove devi ridurre al massimo l'overhead perché registrare un event listener se puoi usare un dollaro prima del nome della variabile o dopo adesso non lo ricordo forse prima sì sì ho capito cosa intendi secondo me fa della sua semplicità come detto prima una delle carte vincenti ha queste annotazioni che non tutti piacciono tipo l'export let il nome della variabile per dichiarare una prop in ingresso il dollaro per sottoscriversi ai cambiamenti e ai cambiamenti anche dello store i watcher sono qualcosa di inguardabile dollaro due punti apertagraffa e ti decchi comunque secondo me al di là della sintasi che può piacere o meno rispetto agli inizi quando ho iniziato a seguire Svelte adesso sempre più aziende incominciano a utilizzarlo e a richiedere che gli sviluppatori poi lo sappiano padroneggiare e questo secondo me è un buon segnale per gli sviluppatori di Svelte appunto per chi piace questo strumento io lo vedo abbastanza semplice da poter insegnare anche uno junior che mi arriva in azienda nel senso che spiegare un angular invece lo vedo un po' più complesso anzi molto più complesso angular si porta dietro tanta logica opinionata a rexjs che sicuramente non aiuta la curva di apprendimento quindi non vedo perché no l'utilizzo di Svelte lo capisco lo capisco e soprattutto ripeto io si sono opinionato però riconosco il grande passo che è stato fatto da Svelte ci voglio ritornare in realtà Svelte abbiamo detto che possiamo posizionarlo come da una parte un compiler e una companion library che lavora con lui il ragionamento è che dato un componente Svelte c'è un compilatore che lo trasforma in codice vanilla javascript reattivo e quindi lo evolve, lo trasforma e gli permette di insomma aggiornarsi adesso l'approccio che utilizza React è molto diverso utilizza un virtual DOM quindi fa una sorta di fotografia di quello che è il DOM fa una modifica sulla fotografia e poi riconcilia facendo le operazioni sul DOM che sono quelle più esose a livello di costo computazionale quindi cambia solo quello che è realmente cambiato per fare questo tipo di approccio in realtà si è dovuti per forza abbracciare una cosa che si chiama one way data binding quindi io cambio un valore serve di nuovo un ciclo che mi aggiorna il virtual DOM cambia quello che deve cambiare e poi fa gli aggiornamenti sul DOM quindi riconcilia dalla fotografia ecco quello che in realtà con Svelte non succede è che fondamentalmente Svelte è come l'idraulico che collega tutti i tubetti tra le variabili e i template e le cose poi apre l'acqua e non deve riverificare tutti i tubetti ricollegare tutti i tubetti vedere quale tubetto sta passando no, quei tubi sono ormai connessi e collegati e l'applicazione viaggia così che è una cosa fighissima in realtà è molto bella e soprattutto molto più performante rispetto a un virtual DOM ma che abbraccia anche un concetto di one way data binding cioè il fatto di poter collegare due elementi che utilizzano lo stesso valore che cambia nel tempo e questi due elementi siano sincronizzati adesso perché tutto questo pappone? perché dalla mia esperienza specie in un ambito di juniority se così si può definire alto, quindi dove ci sono tanti junior sembra la two way data binding sembra qualcosa di...

mi risolve tutti i problemi io collego questa a questa, boh, finito bellissimo salvo poi in realtà talvolta creare dei problemi perché? perché se con React tu hai un flow in una sola direzione quindi è anche più facile da tenere a mente quello che sta succedendo nella nostra RAM mentale col two way data binding quel livello di complessità cresce quindi in fase di sviluppo hai mai percepito il carico mentale di tenere a mente tutte queste relazioni? te lo dico perché è una cosa che io ho percepito lavorando nel mio penultimo progetto su Vue sì, nel senso che comunque quando sono andato a sviluppare le mie applicazioni Svelte ho mantenuto le best practice del one way data binding ho comunque creato un service di astrazione per comunicare con il mio state manager quindi sebbene Svelte mi permettesse di fare determinate cose sono andato a scegliere le best practice per andare a implementare l'applicazione perché appunto memore degli esperimenti, degli errori fatti in passato come magari anche React e Angular decidono di farti strutturare l'applicazione anche le nuove applicazioni che sono andato a sviluppare con Svelte ho mantenuto le stesse best practice quindi non so se ti ho risposto un po' alla domanda nel senso che sebbene lo strumento mi permettesse di fare determinate cose internamente al team e anche poi alle persone che sono mid e facciamo crescere all'interno dell'azienda cerchiamo di impartirgli come le best practice migliori per sviluppare chiaro, chiarissimo lo so Giorgio tu non te l'aspettavi che io, anzi lo sapevi che io ero così opinionato però in realtà devo dire che non mi dispiace Svelte non mi dispiace affatto, uno dei però problemi che io ho è che in realtà adoro JSX e ritornare a lavorare con una logica di templating mi dà un po' quel flavor twig che tanto è stato presente nella mia vita passata e invece il JSX e il fatto di poter embeddare del javascript all'interno dei template è tanta roba, io so che tu come hai detto prima e abbiamo ripetuto più volte hai lavorato sia con React che con Angular come ti poni, qual è la tua percezione, perché qua parliamo di lato personale di gusto personale, come ti poni verso il fatto di utilizzare delle custom template elements per fare i loop, gli if e non poter embeddare in modo spinto del javascript come invece si fa con JSX allora beh JSX ha un suo perché nel mondo Angular faccio uno switch mentale quando utilizzo, scusate, perché nel suo mondo React è un lapsus in Angular e in Svelte invece ho il mio mindset e cerco di sviluppare come è stato richiesto dallo strumento a me onestamente fare questo salto non mi crea troppo fastidio poi se vuoi portare la logica di Svelte quindi la compilazione per evitare il virtual DOM hai giustamente tirato in ballo Solid per quanto riguarda React che riporta i concetti di Svelte, li riporta però nel mondo React a un suo modo non so se hai avuto modo di provarlo sì, mi piace, ci sono delle cose che ancora non capisco in termini di API, di scelte che sono state fatte anche delle naming convention che non mi suonano però secondo me è un buon passo dovendo utilizzare un framework compilato, non so se è giusto definirlo così ma un compila framework, un framework, non lo so, dovremmo coniare un neologismo per questo ecco, proverei SolidJS anche se lo reputo ancora un po' immaturo non lo utilizzerei per un progetto enterprise dove andrei dritto con React e Virtual DOM e chi se ne frega se ci mette il 70% più di un altro framework o libreria piccola nota a margine oggi utilizzeremo la parola framework, libreria e compiler in modo completamente intercambiabile chiusa nota a margine, no, in modo da puntualizzarlo perché poi alla fine sono strumenti che sono diversi però poi a fin dei conti in un modo o nell'altro ci portano tutti allo stesso obiettivo quindi talvolta utilizziamo con leggerezza questi termini per cui ritornando a Solid, sì, probabilmente ci farò un side project giusto per vederlo mi sembra una buona esperienza e mi sembra che appunto molte delle critiche che io sollevo su Svelte siano in qualche modo un po' aggiustate e sistemate nell'ecosistema Solid sì, poi hai detto bene, tutto dipende dal contesto nel senso che se noi abbiamo un'applicazione Angular che ci mette qui due secondi in più a caricare però effettivamente una volta caricata serve per un back office di un'azienda ha poco senso stare lì a guardare le performance, magari conviene pensare più ai benefit che mi dà un determinato tool infatti con Angular la parte di form è fatta moltissimo, molto bene e quindi alla fine se io ho tanti form nella mia applicazione potrebbe essere la scelta giusta per evitare di sbattere su mille, mille problemi se poi è un back office poco importa se carica in due secondi in più rispetto a uno Svelte che è più reattivo differente invece se dobbiamo creare un blog post o un giornale come abbiamo detto prima dove la reattività spesso fa la differenza io a livello editoriale detto tra mette non so quanto userei Svelte oggi o andrei di Web Components se proprio è Shadow DOM, se proprio devo essere sincero cioè non posso dire in realtà che Svelte non è un ottimo prodotto cioè mi violenterei a dirlo, però allo stesso tempo mi rendo conto che molte delle cose che reputo fighe tipo non dovermi preoccupare della reattività in realtà con Svelte mi devo preoccupare della reattività, con Vue mi devo preoccupare della reattività con Solid mi devo preoccupare della reattività una cosa che grazie al Virtual DOM era completa, cioè uno sviluppatore che approccia React non ci pensa neanche a studiarsi la reattività potrebbe non sapere che cos'è RxJS o cosa sia proprio il paradigma eppure sviluppare per cui mi chiedo, sì Svelte è semplice, è della stessa critica che muovo verso Vue Vue è semplice, è un par di ciuffoli, io sono ritornato a Vue 3 dopo X anni che lavoravo su React, un po' di mesi fa e ho condiviso con voi le bestemmie perché usare i ref quando si è abituato a utilizzare solo le variabili perché tanto il componente viene refreshato, è uno switch mentale che devi fare, una cosa in più da preoccuparti capisco però che comunque ha il suo perché, cioè io Svelte me l'immagino in un contesto di editoriale o di questo tipo e secondo me va da Dio, ho qualche difficoltà, aiutami a capire se si tratta di un bias o no a immaginarmi la dashboard fatta completamente con Svelte, per esempio a livello di form come ci si muove con Svelte? Nel form abbiamo le librerie che ci vengono in aiuto da poter inserire all'interno di Svelte stesso abbiamo tutta una pletora di librerie da poter utilizzare non solo per i form ma anche per lo styling abbiamo la parte di material e quant'altro secondo me è un tuo bias perché ho lavorato per una famosa azienda francese che vende articoli sportivi qui non posso fare il nome ma penso abbiate capito tutti e la parte web è in Svelte proprio perché comunque Svelte ti permette di essere verso l'approccio amico al front end cioè caricare la parte di javascript al volo, a run time quindi di fare un po' quelle cose che con altri strumenti è un po' più difficile fare loro sono molto contenti di utilizzarlo anzi lo hanno segnato tra i loro requisiti interni quindi le nuove applicazioni che vanno a sviluppare le vanno a sviluppare proprio con Svelte interessante io in realtà sono fortemente vittima dei miei bias da questo punto di vista però lo ammetto quindi cerco di superarli è uscito SvelteKit quindi server side rendering allora secondo me sebbene ti permetta di scrivere dello Svelte lato server ancora è un po' forse immaturo prima si chiamava Sapper adesso si chiama SvelteKit ha fatto un po' di evoluzioni strane per arrivare al punto dove adesso se dovessi scegliere uno strumento per fare server side rendering adesso andrei su Next.js ad occhi chiusi proprio per la maturità che ha assunto nel corso del tempo SvelteKit ancora non lo vedo in grado di essere in grado di equiparare quello che riesco ad avere con Next.js chiaro nonostante su Next.js potrei rimanere ore a parlarne male è not a margine provate a fare progressive enhancement con Next.js e poi vedete quanto use e quante funzioni tipo not yet stable function dovete chiamare per far finta di farlo funzionare su questo probabilmente faremo un episodio di non fatte server side rendering usando React questo sarà il titolo ma per cui da questo punto di vista pensi che vabbè non siamo ancora a una 1.0 quindi non è maturo però una cosa che ho visto a livello di promozione di SvelteKit è che un po' lo vendono come Next.js quindi vendono un po' più la dev experience rispetto alla parte di server side rendering parlano di router, parlano di pagine create come SvelteComponent e io mi chiedo si va bene ma un framework full front end non può utilizzare questo approccio senza mettere in mezzo il server side rendering bella domanda se io dovessi togliere il server side rendering da Next.js sarebbe un bellissimo framework fatto usando React e opinionato questa è la mia percezione, vedendo come è promosso SvelteKit ho lo stesso questa sensazione che i punti che toccano la dev experience e che attirino siano il 90% questi e il 10% il server side rendering che comunque rimane un problema, comunque rimane un costo per le aziende e comunque secondo me la community in generale del front end deve affrontare in modo più serio e strutturato tra Next.js e SvelteKit entrambi hanno un server loro proprietario in javascript quindi a livello di performance non saprei dirti chi ne esce vincitore, probabilmente nessuno dei due quando abbiamo forte carico lato backpressure e lato server onestamente guardando la documentazione di SvelteKit e conoscendo l'API di Next.js non dico che ci siamo copiati ma ci andiamo molto molto vicino, avranno altri nomi nei vari API però siamo lì uno usa il tag link l'altro usa A perché può compilare e può trasformare io ho avuto la stessa identica sensazione e secondo me lato server side tutto il vantaggio in realtà che Svelte in termini di prestazione può portare lo perde perché sta comunque lavorando con un DOM virtualizzato e chiunque abbia usato un JS DOM o simili sa quanto faccia a cagare chiunque ha mai fatto un test jest sa quanto faccia a cagare quella rappresentazione di DOM quindi a questo punto secondo me ma così a logica poi mi piacerebbe vedere i benchmark se qualcuno nella community ce li ha per favore scelateli perché sono veramente curioso però secondo me a livello di benchmark potremmo essere allo stesso punto o probabilmente React potrebbe essere anche più performante perché lavorando tutto sul virtual DOM potrebbe mettere da parte un certo livello di complexity nella rappresentazione del DOM questo ho questa sensazione non è verificata anzi se avete dei benchmark lo ripeto condivideteli all'interno del gruppo possiamo aprire una discussione la so che nella community ci sono persone molto preparate su questo quindi suona una campanella ne parliamo di lì eh si in realtà devo ammettere una cosa scusate la qualità infima dell'audio ma in montaggio e proprio mentre montavo l'episodio con Giorgio abbiamo visto un tweet del mio collega Jonas Galvez che sta lavorando a un tool bellissimo che si chiama FastifyDX e che si occupa appunto di server side rendering usando Fastify dove insomma Jonas ha fatto una serie di benchmark con Autocannon per vedere quale framework era più performante con il server side rendering e in realtà al primo posto c'è Svelte con 4256 richieste al secondo che sono tantissime quindi Svelte è performante quello che vi ho detto prima è una fesseria Solid segue a ruota ma con meno della metà perché ha circa 2000 richieste al secondo quando Svelte ne ha 4256 React sta appena sotto con 1672 e Vue con 737 quindi grazie Giorgio per avermi condiviso questa nota appunto sulle performance in ambito server side rendering c'è da dire che questo tipo di testing è stato fatto utilizzando FastifyDX e non SvelteKit quindi anche la sarebbe interessante vedere quanto performa e come performa SvelteKit nel server side rendering vedo che il tempo sta volando ma io ho ancora delle cose da chiederti in realtà so che in uno degli ultimi progetti dove hai lavorato però non hai utilizzato Svelte sei andato su un'altra tecnologia qual'era e perché e soprattutto ci vuoi raccontare qualcosa in più di questo progetto sì l'ultimo progetto che ho seguito prevedeva la migrazione da Angular a React quindi abbiamo definito assieme al cliente quali erano i sottodomini principali dell'applicazione quindi i core subdomains per migrarli ovviamente per primo, ci siamo fatti guidare un po' anche dalle metriche dell'applicazione stessa per vedere se c'erano delle funzionalità che non erano utilizzate e poi abbiamo migrato a React ma non abbiamo migrato per pazzia, abbiamo migrato perché effettivamente l'ambiente dove dovevamo girare richiedeva l'utilizzo di React, in pratica l'applicazione permetteva l'acquisto di servizi tramite criptovalute e la volontà del cliente era quella di embeddare nel marketplace di Binance l'applicazione mobile che permette lo scambio di criptovalute, embeddare la propria applicazione per far fruire agli utenti Binance dei propri servizi, quindi poter acquistare direttamente da lì i propri prodotti vincolo però era quello di utilizzare o React o Vue, internamente conoscevamo meglio React e quindi abbiamo iniziato questa migrazione che onestamente ha portato ottimi risultati in termini di business quindi abbiamo avuto un incremento misurato dei guadagni Ti faccio una domanda, abbiamo detto che Svelte, questa è una speculazione, voglio una tua speculazione su questo abbiamo detto che Svelte sarebbe ottimo per questo tipo di contesti, io mi immagino un marketplace che deve montare delle applicazioni e mi immagino proprio il caso d'uso tipico di Svelte secondo te perché no? Una questione di market size o ci possono essere altri elementi in gioco? Allora io mi sono dato una risposta a questa domanda, nello specifico all'interno dell'environment Binance quello che ci poteva andare a disegnare come applicazione faceva leva sull'SDK che lo stesso Binance ti metteva a disposizione ti metteva a disposizione tutta una serie di componentistiche, quindi ti metteva la input, il text, la view, la web view quindi tutta una serie di componentistiche come se fosse un React native quindi sfruttando il concetto che con React si può poi avere un rendering finale custom tutto ha un senso secondo me su come mai hanno scelto di utilizzare React quindi praticamente tu non utilizzavi i nodi DOM, il div della situazione, l'input della situazione utilizzavi i loro components esatto, utilizzando i loro components che erano molto simili a quelli che sono i DOM normali dell'HTML però si poteva andare a costruire l'applicazione proprio grazie ai componenti che ti mettevano a disposizione poi chiaramente erano anche customizzabili a livello di CSS e avevano moltissimi properti da poter sfruttare però di fatto si basava su una serie di componenti che già loro avevano messo a disposizione ok ok ok, adesso ha senso perché dimmi se sbaglio, mi immagino che queste applicazioni girino su diversi tipi di piattaforma me le immagino anche nell'ambito mobile per cui là dipende un po' come è fatto il loro stack tecnologico ma se non dovessero girare su browser o simili comunque hanno un livello di controllo maggiore, dando a te la possibilità di utilizzare solo i loro components e a livello di SDK tu avevi questi components ma avevi anche dei services da chiamare, potevi chiamare dei services? sì, avevo tutta una serie di servizi da poter chiamare per quanto riguarda il controllo del device quindi geolocalizzazione, giroscopio, tutta una serie di informazioni che potevo andare a ottenere tramite API messe a disposizione dall'SDK nonché poi la più importante che è quello che ci serviva maggiormente che era triggerare la chiamata di pagamento all'applicazione esterna, diciamo al contenitore della nostra applicazione privata quindi tramite queste API lanciamo il trigger per la richiesta di pagamento super interessante questa parte, per un attimo mi sposto un attimo nella parte di porting cioè voi avete migrato un'app Angular, Angular o AngularJS? Angular a React praticamente con solo custom components siete riusciti a salvare del codice? allora la parte di CSS siamo riusciti a salvarla pressoché tutta per quanto riguarda la parte di HTML abbiamo dovuto fare gli aggiustamenti corretti quindi ad esempio se l'ngif di Angular l'abbiamo tradotto in un ternario piuttosto che il loop che in Angular si ha con l'ng4 abbiamo utilizzato il map degli array insomma abbiamo dovuto fare degli aggiustamenti, anche la stessa class dobbiamo cambiarlo con class name quindi tutta una serie di aggiustamenti però sostanzialmente la parte di applicazione siamo riusciti a salvarla per un buon 80% ma voi avete comunque dentro l'applicazione continuato a utilizzare i div che usava Angular? sì come struttura dell'applicazione sostanzialmente sì, al netto di qualche fix che andava fatto comunque funzionalità che andava tolta perché magari non più utilizzata, era magari un refuso visto che l'applicazione era in piedi da molto, funzionalità sopra funzionalità erano cose non utilizzate al netto di quello però la struttura del DOM abbiamo mantenuto la stessa e abbiamo utilizzato Valtio come state manager mentre nell'applicazione Angular c'era ngRH perché Valtio? Valtio perché è plain JavaScript quindi anche in un ambiente complicato come quello di Binance che comunque sei all'interno di una struttura dove non hai controllo essendo plain JavaScript dava meno problemi possibili abbiamo avuto delle difficoltà ad esempio con la parte di Google Tag Manager di Recaptcha proprio perché lo strumento non permetteva il salvataggio dei cookie quindi abbiamo dovuto reimplementare quella parte di custom e uno dei takeaways che ci siamo portati via da questa esperienza è sicuramente testare la funzionalità ancora prima di renderla bella e finita come Clean Code, provarla subito nel device finale in modo da evitare delle sorprese che magari possono arrivare quando ormai abbiamo già creato il codice bello che è pulito Quick and Dirty e poi Refinement esatto chiaro, questo è l'approccio pragmatico secondo me da sposare spesso siamo tentati di voler fare una PR bellissima e poi, questa un po' per l'effetto pavone, no? anche quei colleghi rispetto alla PR, non so quanti di voi si fanno la Code Review con una PR in draft prima di pubblicarla, io lo faccio sempre no, in realtà questo lo capisco avrai avuto modo di esplorare anche altre app dentro lo store di Binance ma dall'esperienza dello store di Binance, cosa percepisci? secondo te c'è un mercato e c'è un mercato per quale applicazioni? io guarda, da come me l'hai raccontato lo vedo un po' come il mercato delle applicazioni di Shopify, no? ne abbiamo parlato con Francesco un po' di episodi fa cioè, un qualcosa che ha un potenziale enorme ma che non è visto come un posto dove posizionare la propria app effettivamente Binance non sponsorizza tantissimo la parte marketplace però analizzando un po' il take away che aveva l'utente finale nell'utilizzo dell'app all'interno del marketplace stesso di fatto, l'utente una volta che ha trasferito i suoi euro in criptovalute e ci ha guadagnato se è fortunato, quando poi deve ritornare le proprie criptovalute in euro deve pagare una fee a Binance stesso ed è lì poi che ci guadagna il vendor invece di andarli a cambiare in euro, li può andare a spendere nelle applicazioni del marketplace e va a spendere direttamente in criptovalute così invece di pagare la fee, si va a acquistare della merce tramite queste applicazioni quindi secondo me ha senso, chiaramente il nostro cliente già era predisposto all'acquisto al pagamento tramite criptovaluta se ci fosse stata magari un'altra applicazione sarebbe dovuto sviluppare tutto un back end per dialogare con la parte di criptovalute e blockchain quindi sarebbe stato più complicato però per lui in quel contesto aveva molto senso molto interessante, comunque ci butto un occhio è un mondo di cui raramente ne parliamo, specie qua a Gitbar e sapere che c'è un punto di connessione il punto di connessione solito per noi full stack dev è il mondo del criptovalute e tutto ciò che riguarda comunque l'utilizzo di librerie di Ethereum, Web3, JS o come cavolo si chiama quello è il punto di connessione sapere che c'è un altro punto di connessione e comunque con quel mondo è una piacevole scoperta naturalmente si tratta di un giardino cintato di Binance io non dirò cosa penso di Binance però diciamo le mie opinioni saranno facilmente reperibili nel balocco che andrò a dire tra pochissimi minuti quindi abbiamo parlato di framework, librerie e compiler front end dovendo iniziare il tuo site project oggi cosa useresti? Sincero? Solid, solid perché lo voglio provare questa è la risposta più sincera che mi potevi dare, la apprezzo e dovendo fare un progetto un po' più serio e da tenere nel tempo? Dipende dal contesto in primis però un progetto serio lo vedo un buon strumento per un progetto serio Ok Sarche ridi, non è questo che hai torto ma te l'ho detto, quando si parla di framework praticamente le puntate relative ai framework e alle librerie sono flame generator io cerco di essere sempre molto democristiano però quando si parla di React non riesco a esserlo quindi o di framework front end non riesco a esserlo ed è un problema sapete io ci provo no? adesso la sparo grossa quando parlo di React ed è un lavoro anche psicologico che sto facendo su me stesso perché è un lato che noi sviluppatori trascuriamo l'orgoglio della tecnologia che utilizziamo partendo da questo pensiero sto provando a migliorarmi da quel punto di vista io adesso ci scherzo no? però il fatto che quando guidiamo e siamo molto confidenti verso una tecnologia noi tendiamo a difendere la spada a tratta spesso anche quando non ha tanta ragione cioè io ti ho detto si virtual dom, performance vabbè ma ti servono? questa è stata la mia risposta cioè come liquidare un ragionamento in 0.3 secondi perché? proprio perché facciamo il motivo per cui facciamo questa cosa è legato al carico cognitivo è una cosa che sto studiando questo periodo no? come gestiamo il carico cognitivo a livello psicologico e presto ne parlerò in uno degli episodi di Gitbar e il fatto di difendere la spada a tratta è il proprio tool, framework e riguarda il proteggere il carico cognitivo il cervello da un eventuale maggiore carico cognitivo che probabilmente non siamo in grado o non vogliamo abbracciare no? anche il proprio codice tante volte anche il proprio codice qual è il metodo migliore per riuscire a liberarsi di questo highly opinionated quello di giocare e di sperimentare certo che se hai una bambina piccola tutto questo diventa molto complicato ma non vuole essere una giustificazione per cui comunque c'è un lavoro che dobbiamo fare su noi stessi e noi sono in primis a farlo che è quello di provare a liberarci del giudizio di protezione chiamiamolo così no? il giudizio che utilizziamo per proteggerci su questo comunque è un piccolo teaser presto ne parleremo in modo approfondito e dettagliato ma guardando l'orologio vedo che come sempre siamo ormai quasi a luglio e io non ho ancora rispettato una volta la regola che ci siamo posti a gennaio di stare dentro un'ora ma va bene abbiamo parlato di robe che ci divertono e va bene se arriviamo al paese dei balocchi e conduco nel paese dei balocchi aaaah il paese dei balocchi quindi la mia domanda è Giorgio hai qualcosa che ti fa piacere condividere con la nostra community o la tua community? allora non fosse che me l'avevi già anticipato e comunque dagli altri episodi so che c'è il paese dei balocchi mi sono portato due libri allora il primo è Thanks for the Feedback The Science and Art of Receiving Feedback Well di Douglas Stone poi metteremo il link nei commenti questo mi ha ispirato molto nel senso che in azienda siamo consiani a darci del feedback positivi ma quelli che poi ti fanno crescere di più sono quelli negativi che ti permettono di riflettere di capire come poter miglionare e un altro invece è Il Cigno Nero di Nicholas Taleb che sto sono in audiolibro adesso quindi sto sperimentando anche quella parte lì e lo voglio consigliare perché mi sta aprendo la mente verso qualcosa che certi argomenti che solitamente non sono da dev o comunque non sono nelle mie corde mi sta aprendo molto la mente bello io per quanto riguarda il primo libro voglio aggiungere o almeno collegarlo a un episodio abbiamo parlato approfonditamente di feedback nell'episodio 86 con Luca abbiamo ragionato su come dare feedback come ricevere feedback è probabilmente uno dei testi di riferimento che hai citato, era uno dei testi che Luca ha utilizzato per approfondire l'argomento quindi io rilancio con questo e porto i miei due ballocchi allora oggi abbiamo, anche se in modo tangente parlato di criptovalute io ho la mia opinione in merito alle criptovalute anche abbastanza sad come si suol dire ma anche abbastanza triste perché ho una brutta storia legata alle criptovalute e Mount Gox non so se ve lo ricordate cercatelo su Google se non sapete cos'è è un exchange che poi è saltato a gambe all'aria e voglio portare un podcast che trovo molto ben fatto anche questo molto opinionato va bene ma com'è giusto che sia perché fondamentalmente le nostre opinioni le costruiamo anche ascoltando punti diversi con opinioni diverse e poi ragionandoci sopra si chiama Bitcoin Italia Podcast è molto ben fatto se non ce l'avete aggiungetelo alla lista c'è poi un film su Netflix voglio proprio essere super light a questo giro cerco il titolo adesso non me lo ricordo ma che parla del Maxi Scam di Quadriga CX l'ho visto tipo tre giorni fa era un exchange canadese se cercate Quadriga CX dovreste trovarlo direttamente su Netflix e poi voglio finire con una riflessione legata a un balocco in questo periodo ho avuto la percezione di aver sovraccaricato con la roba tecnologica e avevo il bisogno di staccare per un attimo la testa non so se vi capita mai che pensate, pensate, pensate studiate, studiate, studiate quasi una bulimia informativa e ci sono dei momenti che è necessario calcare reset io avevo un desiderio rileggermi il Signore degli Anelli e rileggerlo a 37 anni che è un po' diverso da come lo puoi leggere a 16 o a 17 o comunque alle superiori con la bambina non ce la faccio però ho beccato un bellissimo audiolibro non so quanto legale su YouTube in realtà pare che questo tizio abbia letto diversi libri e li ha fatto molto bene e li pubblica lui quindi non so quanto legale in merito ai diritti del libro però, so, io me ne lavo le mani in un'azione del tutto ponziopilatesca però è veramente ben fatto l'audiolibro nonostante l'odio che ho verso YouTube che mi tiene lo schermo del telefonino acceso a meno che io non paghi la tangente però la sera quando vado a letto metto gli Airpods e mi addormento ascoltando il Signore degli Anelli e credetemi mi alleggerisce di brutto perché il poter andare su un altro mondo fatto come fatto il Signore degli Anelli è tanta roba quindi il consiglio che vi do visto che sta arrivando l'estate sì, bellissime le letture tecnologiche ma se per un attimo provate a staccare il cervello fidatevi ne avrete indietro tanti tanti vantaggi e anche di questo ne parleremo nell'episodio sul carico cognitivo Giorgio uh è stata una bella sudata oggi devo dire che sei un soldato resistentissimo io ho provato in tutti i modi a romperti le palle e non ci sono riuscito o almeno hai risposto a tutti i colpi in maniera impeccabile no, grazie a te di avermi messo qui a disposizione in questo spazio e aver registrato assieme a me questa bellissima puntata piacevo salutare anche gli ascoltatori che sono sempre tanti e tutto il gruppo Telegram che mi tiene in compagnia nelle giornate sì, certe volte io credimi ho proprio difficoltà a seguire i messaggi mi capita che sono in deep con il lavoro e devo dirlo in questo periodo sto smadonnando dietro Asur e torno dopo un'ora e mezza e vedo 47 messaggi 102 messaggi 133 messaggi e dico no, adesso come faccio perché abbiamo detto giusto che c'è il gruppo Telegram abbiamo il gruppo Telegram grazie per aver agevolato a questo punto il momentino di ricordo del gruppo mi raccomando i modi per contattarci sono due info.github.it e planrep che sono quelli canonici e poi c'è il gruppo Telegram c'è 845 membri di puro delirio perché come di questo si tratta ci divertiamo un mondo se non l'avete ancora fatto e io so che voi siete là e non l'avete ancora fatto in molti mi raccomando aprite Telegram cercate Github Podcast e trovate il nostro fantastico gruppo il cui ultimo post è uno condiviso da Luca il cui titolo è Il ritorno di Monkey Island e...

aspetta è uscito o è solo un annuncio questo? add to wishlist tu hai mai giocato a Monkey Island the original? eh no purtroppo no purtroppo no sei giovane tu sei giovane con tante G beata gioventù no guarda recuperalo e giocalo perché è tanta roba vedi Monkey Island per ritornare al ragionamento della lentezza e di staccare la testa è uno di quei giochi che è lento a morire cioè proprio lento e che ti costringe a staccare la testa è veramente veramente figo e allora dai se esce non mancherò di provarlo top ci dobbiamo organizzare e fare un commento su questo Giorgio io guardavo l'orologio sono le 10 e mezzo della sera e io non ho ancora cenato però questa volta mia moglie non mi ha fatto nessun segnale con le tapparelle della cucina quindi vuol dire che non è ancora pronto ma insomma io c'ho fame e prima di salutarci io ringrazio Giorgio grazie davvero a nome mio ma anche dei membri della nostra community che si sono deliziati con questa piccola fight divertente tra di noi grazie davvero per essere venuto a raccontarci le tue esperienze e ti ricordo come facciamo spesso che Gitbar è casa tua e questo lo sai bene quindi quando hai qualcosa di nuovo qualcosa di interessante da condividere con la nostra community contattaci noi siamo qua e siamo pronti ad accendere i microfoni e farci un'ulteriore chiacchierata prima di lasciarci ci ricordi al volo i tuoi contatti potete trovarmi su twitter il mio handle è Giorgio underscore Boa oppure su Linkedin cercando semplicemente Giorgio Boa detto questo io rinnovo il ringraziamento a Giorgio vi do appuntamento alla prossima puntata giovedì prossimo in realtà spero giovedì io di solito vado un po' lungo con i montaggi però spero giovedì prossimo detto questo alla prossima ciao ciao a tutti.