Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar oggi mi sento un po solo anche perché I miei compagni di viaggio erano un po' incasinati quindi ahimè sarò solo ma solo io non sono mai solo dentro questo podcast in fondo Gitbar è un bar e qui di gente ne viene tantissima e di gente interessante ancora di più e infatti oggi abbiamo un super ospite ma prima di presentarvelo devo ricordare i nostri contatti info@gitbar.it la mail @brainrappoland su twitter e il nostro fantastico gruppo telegram siamo un bel po e ci incontriamo tutti i giorni per chiacchierare delle cose che ci piacciono di più quindi da un lato tutti gli elementi e le robe tecnic che ci divertono.Dall'altra anche tutto il mondo legato alle soft skills e via dicendo.Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti, che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Io non voglio trattenermi ulteriormente e penso che sia il momento di fare questo collegamento transoceanico che suona un po' vecchio, old school, no? ancora si facevano i collegamenti via via via satellite infatti mi sposto virtualmente a Seattle per parlare con Alessandro Segala, product marketing manager per VS Code quindi in Microsoft ma anche scrittore di libri tecnici, blogger, software developer e chi più ne ha più ne mette.Ma quante cose fai Alessandro, ciao! Ciao, grazie di avermi qui come ospite nel tuo podcast, mi fa molto piacere.Dove lo trovi il tempo per fare tutte queste cose? Dove lo trovo il tempo? Questa è una bella domanda.Diciamo che quando c'è la passione il tempo lo si fa, magari anche si dorme un po' meno, però il tempo lo si fa.Leggendo il tuo profilo, che è poi quello che ha catturato la mia attenzione, vedo "Product Marketing Manager per VS Code", che è il Product Marketing Manager in Microsoft, quindi di strada ne hai fatto.E allora io voglio chiederti come è iniziata la tua carriera, anche perché io mi documento prima sui nostri ospiti e io ho visto che nel tuo profilo LinkedIn, a livello di formazione, tu hai un pacco di economia, quindi che percorso hai fatto? In realtà, quando la gente mi chiede come sono arrivato qua, ti direi che c'è stata tanta fortuna di essere al posto giusto e al momento giusto, devo essere sincero.Io ho iniziato a programmare quando ero al liceo, era un po' la mia passione, ho cominciato a creare delle app.Mi ricordo che nel 2007, quando è uscito il primo iPhone, che ancora non c'era in Italia, praticamente un familiare era andato negli Stati Uniti, mi aveva portato una a casa.Adesso non so se ti ricordi perché passato tanta acqua sotto i ponti, però il primo iPhone aveva un problema che teneva solo mille messaggi in memoria.Allora io ero a liceo all'epoca, mille messaggi li mandavo in una settimana, perché ovviamente, come tutti gli studenti di liceo, soprattutto all'epoca quando non c'era Messenger, non c'era WhatsApp, eccetera.E quindi lì è stato il momento che ho creato la mia prima app, si chiamava Uarchive.it, che prendeva gli SMS, i messaggi dall'iPhone, li metteva sul, oggi diremmo cloud, all'epoca il cloud non esisteva, però li metteva sul cloud.E avevamo anche diversi migliaia di utenti, era principalmente gratis, ma è stata un'esperienza molto divertente.E poi, quando è stato il momento di decidere allora cosa volevo andare a fare all'università, quello che pensavo all'epoca, e sinceramente lo penso ancora, è che volevo parlare di più dal punto di vista di gestire il prodotto, che essere quello che lo crea, che comunque mi diverte, lo faccio ancora, programma ancora nel mio tempo libero, però volevo imparare il discorso di product management, volevo imparare come si gestisce un business attorno a un prodotto ed è per questo che sono finito di studiare economia e poi il resto è un po' storia.E da quando studiavi economia a quando sei arrivato poi in Microsoft e nel team di VS Code.Quali sono state le milestone, gli elementi che reputi importanti in questo percorso? No, quei "salti quantici", come mi piace chiamarli, cioè quegli sprint in questa via, insomma.Diciamo che forse ce ne sono...questo sarebbe il terzo, diciamo, salto importante che ho ho fatto nella mia carriera.Il primo è appena aver finito la specialistica all'Università di Waterloo, che è vicino a Toronto.Ho lavorato per circa un anno in una start-up lì come lead e only developer.Per la maggior parte del tempo ero anche l'unico.E poi ho ricevuto una telefonata una notte, era febbraio.Tieni presente, questo è vicino a Toronto, era un freddo bestiale, perché ovviamente sempre freddo era in inverno.E ricevo una telefonata da un recruiter di Microsoft che aveva fatto application mesi prima, come una di quelle career fair, una di quelle job fair.Sai come, lasci il curriculum e poi un po' anche ci provi tanto, come si dice un number game, più lo fai, più c'è possibilità che qualcuno ti richiami.E insomma mi hanno richiamato, non me lo aspettavo, e mi hanno offerto un ruolo che non avrei mai pensato prima, che era praticamente sales engineer.Il titolo era Azure Technology Solution Professional.Essenzialmente il mio lavoro era di andare insieme alle persone che vendevano, ai venditori, ed essere quello che raccontava la verità e aiutava i clienti a capire se il prodotto era efficace dal punto di vista tecnico, risolveva i problemi che volevano loro e mi occupava di Azure principalmente.Mi è piaciuto un sacco perché comunque ero nel field, ero in contatto con i clienti, ho imparato tantissimo.Però dopo un paio d'anni, un'altra notte d'inverno, che nevicava, come sempre a Toronto, sempre molto freddo, un altro collega mi chiama, che lui lavorava qui a Seattle, nel quartiere generale, ce l'avevamo conosciuto un paio di volte all'interno dell'azienda, in varie opportunità, mi chiama e mi dice che il suo team stava assumendo e lui pensava che io potessi essere un buon candidato e ancora un altro lavoro che non avrò mai pensato di fare, però alla fine mi sono ritrovato a fare il Product Marketing Manager per Microsoft nel quartier generale.Adesso sono qui da 5 anni e occupo più di due lavori su VS Code.Capito, bellissimo.Comunque un'esperienza strana, non è stato uno di quei percorsi lineari diretto a...è super super interessante e comunque cosa ti sei portata a casa dall'esperienza di Technology Solutions Professional, quindi di fare questo tramite tra la parte commerciale e poi gli architetti o chi utilizza quella soluzione? Sì, guarda, quella è stata forse una delle esperienze più formative dal punto di vista dei propri possibilità di imparare, perché era a contatto con i clienti e questo mi ha permesso di vedere come le cose funzionano in giro per il mondo, vedere come aziende di tutti i tipi operano nel loro interno.principalmente mi occupavo di vendere Azure, quindi soluzioni cloud, quindi parlavo principalmente con persone dell'IT, a volte anche programmatori, però principalmente IT, però solo per poter vedere come le cose funzionano in una varietà di aziende, di organizzazioni, di enti, è stata un'esperienza incredibile, che sinceramente consiglierei a tante persone anche come che vogliono mettersi un po' fuori, che vogliono imparare qualcosa di farlo e poi la mia fortuna è che sendo il Canada un mercato un po' più piccolino rispetto agli Stati Uniti, avevo l'opportunità di parlare con aziende per start-up di tre persone, tra cui una tra l'altro era anche stata finanziata da una di Shark Tank, se conosci il programma.Quindi un'azienda di tre persone fino in Canada ci sono cinque banche e io parlavo con due di quelle 5 banche.Quindi una varietà di esperienze, una varietà di capire come funziona l'azienda che è incredibile.E questo penso che mi ha aiutato ad avere il ruolo successivo, ma mi aiuterà anche per il resto della mia vita, sia che decida di restare nel marketing, sia che decida di muovermi in qualunque altro ruolo, anche se vorresti diventare un programmatore di nuovo.Questa esperienza è molto utile.Lavorare oggi nel team, questa è una domanda un po' strana, se è assurda mandami pure a quel paese, tutti i nostri ospiti hanno la licenza di farlo, quindi stai tranquillo.Ieri lavoravi a contatto col cliente che poteva essere il team di architetti di una banca o il single developer all'interno di una startup o il team lead all'interno di una startup.Oggi lavori invece verso i developer quindi grosso modo parli allo stesso segmento no? Anche se potrebbe essere un po' diverso.Col prodotto, col cambiare del prodotto, prima le soluzioni cloud, oggi Visual Studio Code, esiste una differenza in linguaggi, modo di porsi, modo di presentare il prodotto? Sicuramente.Diciamo, la cosa più immediata che posso dirti è nel modo in cui mi vesto.Ultimamente mi sto mettendo molte più hoodies, molte più felpe, mentre quando ero con gli architetti era molto più giacca, camicia, magari non la cravatta, ma era un rumore molto più formale.La ragione per cui mi piace di questo lavoro, la ragione per cui anche penso di poter dire, insomma, sono bravo al mio lavoro, posso sempre migliorare, è perché praticamente sono un programmatore anch'io nel mio cuore, nella mia passione e quindi cerco sempre di mettermi nei panni dei miei clienti, cerco sempre di capire, i clienti, i miei utenti, cerco sempre di capire cosa posso fare che è meglio per loro.Chiaro, e quindi fondamentalmente è questa caratteristica legata all'empatia che poi ti porti da una professione all'altra, come sospettavo.Ti voglio però fare un'altra domanda che è più una curiosità.a livello di percorso di recruitment io te lo dico noi ci siamo già parlati hai capito la mia spontaneità quindi senza mezze parole l'hai resa facilissima no? ma io ho lasciato un curriculum mi han chiamato e bom fatto ma è proprio così semplice il percorso perché dall'altra parte io ho tanti amici che fanno application magari tecniche devono fare esercizi di 5 ore con algoritmi, reversare alberi, fare cose e alla fine mi viene da dire, dalla tua esperienza e anche da quello che hai sentito dire dentro gli headquarter dove ormai vivi e lavori, cioè lavori, vivi immagino vicino.anche vivo l'intervista.Però cosa hai sentito in merito al percorso di recruiting? Come lo percepisci e come è stato poi anche il tuo percorso di recruiting? Sì, che poi tra l'altro guarda, se vuoi parlare di reversare alberi come domanda per un'intervista, ho molte opinioni su questo, penso che sia una terribile idea, ma comunque stiamo divagando.In realtà dipende tanto dal ruolo che uno vuole ed anche dal percorso, dal processo in cui uno entra.Io il primo lavoro a Microsoft l'ho avuto tramite il programma Graduate, anche se stavo già lavorando da 7-8 mesi quando ho cominciato le interviste.Comunque mi hanno fatto entrare come Graduate, avevo appena completato il mio MBA e quindi sono entrato con quel programma lì e quindi un po' diverso rispetto a quello che un professionista che sta già lavorando da magari 5, 6, 10, 15 anni potrebbe fare.In generale quello che posso dire è c'è un sito careers.microsoft.com, lì postano tutti i lavori, sia quelli graduate, quindi per chi ha appena finito il master o anche chi ha appena finito l'adrienale, per chi ha più esperienza e poi il processo dipende molto dal team che sta per assumere anche dal tipo di ruolo.Ovviamente io entrando come sales engineer avevo un certo tipo di interviste che erano più, per esempio ho avuto una panel interview, 5/6 persone ho dovuto dare una presentazione e cercare di vendere a loro sostanzialmente.Adesso però per un un attimo vorrei spostarmi a capire un po' di più sul ruolo del marketing manager.Cioè, la mia domanda è, tu la mattina ti svegli, vai nell'headquarter, ti siedi sulla tua scrivania e cosa fai? Ogni giorno è diverso, a parte che la mia scrivania non la vedo da marzo 2020 come tante altre persone, però ogni giorno è un po' diverso.Intanto, permettimi di dire che marketing soprattutto quando si parla con programmatori è un po' una parolaccia.Non mi piace tanto parlarne perché viene con un certo bagaglio di aspettative che sono quelle persone che ti mostrano la pubblicità su internet, che non è del tutto sbagliato, però il mio lavoro è più di product marketing.Il mio lavoro, diciamo, il capo stipend, la parte importante del mio lavoro è decidere come presentare i prodotti che il nostro team di ingegneri In un senso, il team di ingegneri, persone geniali tra l'altro, sono veramente, come si dice, blessed per lavorare con gente così.Loro creano questi prodotti e poi la domanda è adesso come li presentiamo sul mercato, cosa ci scriviamo, come li annunciamo, a chi li targhettiamo, cioè chi sarebbe il cliente ideale, quali necessità solve per loro eccetera.E questo percorso avviene prima, al momento di feature realizzata o il product marketing manager è coinvolto anche, non so, la butto così, sulla decisione, la definizione delle feature da inserire o meno in una certa release? La maggior parte, diciamo, generalmente no.Generalmente i product manager e via scoda, al momento credo circa 5-6 product manager, sono loro che sono i responsabili e hanno la parola finale su quello che viene inserito nelle release.Questo però non significa che io non possa dire le mie opinioni, possa portare dei problemi o possa portare delle opportunità e poi in questo caso devo poi convincere i PM che è quello che penso possa essere utile, però non è la mia responsabilità diretta.e gli obiettivi a questo punto del tuo ruolo sono abbastanza chiari, ma gli strumenti che utilizzi nel day by day quali sono? Allora ci sono due, diciamo, momenti di cui possiamo parlare, nel senso due momenti del vent'anno dell'anno.Il primo momento è quando c'è una nuova release, soprattutto VSCOI viene rilasciato ogni mese e diciamo le release mensili per la maggior parte sono cose minori e non lavoro tantissimo su quelle.Però ogni tanto facciamo qualche release più grande o qualche nuova feature che è importante e che vogliamo comunicarla.Allora lì è quando io entro in gioco anche in modo più importante.Uno degli ultimi esempi, per esempio, se non sbaglio, a novembre, ottobre-novembre abbiamo rilasciato VS Code for the Web.Praticamente ogni persona può aprire il browser e scrivere vscode.dev e Visual Studio Code appare nel browser e è eseguito completamente nel browser, non c'è bisogno di installare niente, eccetera.Questo è stato un momento molto importante per noi perché, come sai, penso che ne faremo più avanti, ma come sai, VS Code è iniziato come un'app web e quindi è stato un po' portarlo indietro, riportarlo nel browser.Il mio lavoro qui è stato principalmente decidere come ne parliamo.Nel senso, questo VS Code for the Web è fantastico, penso che sia un'innovazione geniale, però ha anche dei limiti, perché non c'è nessun server dietro che fa il processing, per esempio, tutto deve essere eseguito all'interno della sandbox del browser e quindi ci sono limitazioni, per esempio non puoi compilare applicazioni, non puoi usare un terminale, eccetera.E quindi tenendo conto di queste limitazioni, chi è l'utente, chi è il cliente a cui dobbiamo presentarlo questo? Come mostriamo a loro che sì, è vero che non puoi fare il debugging, però puoi sempre usare questo per decine di altre situazioni e queste sono quelle che noi pensiamo siano migliori.Così un esempio era l'idea che tanta gente sentiamo che vorrebbe usare VS Code su un iPad, però per varie ragioni, e questo non è così semplice come uno può pensare, però usando VS Code for the web è possibile usare VS Code anche su un iPad.Ovviamente non puoi compilare, però se tu vuoi fare dei piccoli commit, correggere o scrivere un markdown, magari un readme, fare una review di una pull request, eccetera.Sono tutte cose possibili.E poi stiamo esplorando varie opportunità che anche se non puoi compilare, però magari qualche piccolo codice lo puoi eseguire lo stesso.Ho creato un'estensione per esempio per VS Code for the Web che permette di eseguire codice Go.Era più un esperimento, però un esperimento è anche una dimostrazione.Su questo poi ti faccio una domanda dopo, quando parleremo di VS Code, perché la cosa mi ha incuriosito parecchio anche in termini di sviluppi.Appunto, quindi dopo aver deciso di cosa ne parliamo, il resto dell'attività era di come ne parliamo.Quindi abbiamo creato, io a volte lavoro con altri che poi li creano, dei video che vi abbiamo messo su TikTok, VS Code, ha un account TikTok, tiktok.com/@vscode, andate a guardarlo, perché per noi è un po' divertimento anche fare quelle cose lì.Abbiamo messo video su YouTube Shorts, che è la versione YouTube di TikTok, abbiamo creato dei tweet, un live stream che parlava dei dettagli di cosa succedeva, ovviamente un post, un blog, eccetera.Quindi questa è un po' la prima parte del lavoro, gestire le release, soprattutto quelle un po' più importanti.La seconda parte è quella di continuare a aiutare il prodotto a crescere, facendo un po' dirigendo le attività di marketing.Una parte è eventi.Il 3 di marzo abbiamo BS Code Day 2022.Se andate sul nostro sito code.visualstudio.com potete vedere tutti i dettagli.Un'ora e mezza gratis su internet.È più anche divertimento anche quello.Quindi andate a vedere se siete interessati.Quando ci sono gli eventi più importanti, quelli dell'azienda, come Builder Ignite, due volte all'anno, è un periodo molto interessante per tutti quelli che lavorano in marketing, diciamo così.E poi c'è il discorso di gestire anche attività come social.Abbiamo un account Twitter, twitter.com/code, un canale YouTube, e anche se non sono sempre io che crea i contenuti per quello, sono una delle persone responsabili che decide come gestirlo.Insomma la linea editoriale.Esattamente.Questa è l'attività principale di un PMM.Ovviamente ci sono tante altre cose ogni giorno un po' diverso.A volte so anche la possibilità di creare delle demo, scrivere articoli, quello che capita.E l'altra cosa poi Mauro dipende anche un po' dalla persona.Io come ti dicevo prima ho un background abbastanza tecnico, alcuni miei colleghi sono meno tecnici, tutti sono abbastanza tecnici, ma alcuni più di altri e quindi anche ogni persona decrina il lavoro in un modo un po' diverso.Chiarissimo, insomma l'attività non vi manca.Adesso però la mia domanda è una, cioè tu hai studiato prodotto e marketing anche nel tuo percorso accademico e allora ti chiedo qual è la peculiarità, la caratteristica del fare marketing per i dev, cioè sono davvero questi animali così strani da mettere in una categoria separata? Siamo questi animali così strani da mettere in una categoria separata? Non mi permetterei mai di chiamare i miei clienti utenti animali, però come...L'ho detto io infatti! Però come clienti i programmatori sono diversi, i dev sono un po' diversi, nel senso che nel senso che il product marketing per developers è un po' una magia nera, che non è qualcosa che ti insegna l'università, perché ovviamente è una categoria nuova, è una categoria un po' più di nicchia.Però la cosa principale dei dev è che ai dev non piace il marketing, con questo dicevo prima, marketing è un po' una parolaccia.Adesso non so quanti della tua, gli ascoltatori usano ad blockers, però io per esempio sono uno di quelli, odio vedere la pubblicità, odio quelle cose e quindi cose che sono più tradizionali come marketing non funzionano.E anche il modo in cui parliamo con i dev, se io scrivo una pagina web, tra l'altro un'altra cosa che ci occupiamo in PMM è gestire il sito internet, se io scrivo una pagina web che è piena di, in inglese dice buzzwords, cioè di quelle parole tipo tanto "fluffy", "fumo a poca sostanza", "agilità", "velocità", "dinamismo", cose così, tutte parole che tanti marketer adorano.Io so già che un programmatore lo chiuderà, cioè non legge 30 secondi e poi chiude.I programmatori vogliono sapere cosa c'è per loro, devono sapere cosa c'è per loro, vogliono sapere in modo preciso, tecnico e direttamente al punto, Non interessa il fluffy, tutto il contorno.E quindi quando io mi occupo di creare contenuti di qualsiasi tipo, che sia un tweet, che sia un articolo, un video, qualunque cosa, so che deve essere tecnico, deve andare giusto al punto e deve spiegare come aiuta il dev a migliorare il loro lavoro, la loro giornata, ma che non sia vendere più un "stiamo qui per aiutarti, siamo qui per renderti più efficace".Ledo: chiaro, raccontare la posizione del tuo prodotto nella loro vita fondamentalmente.Ci sono in realtà delle regole, vabbè un po' ce le hai anche già dette, quelle di fare il market taro fondamentalmente nella comunicazione perché il dev ti chiude subito.Quindi in realtà questa domanda mi hai già risposto, no? Sì, la prima risposta è appunto essere onesti.I dev sono persone intelligenti, ovviamente.In generale tante persone sono intelligenti, però tra i dev c'è una percentuale più alta di persone che le puoi categorizzare come intelligenti.Quindi se tu riracconti stronzate lo capiscono, nel senso non puoi mentire, non puoi girarci attorno, devi essere onesto, devi essere direttamente al punto, non promettere cose che non ci sono, cose che non esistono.chiarissimo, beh allora facciamo un salto su Visual Studio Code, no? è la prima domanda giusto per tirare fuori un argomento che insomma un po' si sente in giro, ma Visual Studio Code è un IDE o un editor e soprattutto ambisce a diventare sempre più IDE oppure a tenere il suo lato da editor? Sto ridendo perché, diciamo, è una domanda molto complicata, non ho una risposta precisa da darti al momento.La risposta è molto diplomatica, che diciamo è che VS Code è a metà fra un IDE e un editor e l'idea originariamente era che fosse come editor, per cui è molto più simile ad un editor, cioè lo lanci, lavora sui file, non ha dei gran progetti, però ha molte caratteristiche, soprattutto nel tempo ha assunto caratteristiche che sono più di un IDE.È difficile dirti una risposta esatta, è un po' una zona grigia, dipende anche da con che stack, con che linguaggio lavori.Per esempio uno che lavora in JavaScript è più facile che ti dica un Python, è più facile che ti dica un IDE.Uno che lavora in .NET e crea applicazioni per Windows Desktop è più facile che ti dica un Editor che manca il UI designer e cose così.Io credo che questa ambivalenza unita alla sua modularità che è molto spinta al di là del flame da bar che io ho citato in modo goliardico sia un vantaggio e sia stato un vantaggio che ha permesso appunto a Visual Studio Code questa adozione massiva, no? Sicuramente, e qua devo dare credito alla lungimiranza di Eric Gamal, che come sai è stato la persona che ha ideato VS Code, che è stato quello che poi quando lui è entrato in Microsoft, lui è entrato per creare VS Code, sono stati circa dieci anni fa.Eric come sai, ha avuto esperienza a creare altre IDE prima.Erika aveva creato Eclipse.Eclipse ha un certo livello di estensibilità, però Erika ha preso le cose buone che ha imparato, ha preso le cose che potevano essere migliorate, e così ha deciso come, quando, dove VS Code poteva essere esteso.Ed è venuto fuori questo Editor/IDE che è estremamente personalizzabile, per cui è difficile trovare due programmatori che hanno la stessa identica configurazione di VS Code.Vero.Ti faccio una domanda.Rispetto ad altri editor/IDE, la configurazione di VS Code ha una particolarità che ho notato.può essere configurata anche attraverso un file di configurazione, quindi editando un file di configurazione.Questa feature, perché io la chiamo tale, è una conseguenza dell'architettura del programma o è quasi una cosa voluta perché dà dei certi benefici a chi sviluppa? Questa è un'ottima domanda, ti dirò che è un po' prima dei miei tempi, e quindi penso che questa decisione sia stata fatta forse a 10 anni fa, quindi i dettagli esattamente non li so.Soprattutto i dettagli di perché è stato deciso così.Quello che ti posso dire è che VS Code, la configurazione usando l'interfaccia grafica, in realtà è semplicemente un frontend per quello che c'è scritto nel file JSON.Quindi la source of truth, la verità, quello che lui davveramente conta è il file JSON.Penso che, la mia, ripeto, non ho i dettagli, quindi questo sono io e Alessandro che cerco di immaginare il perché.Penso che sia stato fatto così perché VSCode è un'app JavaScript, sostanzialmente TypeScript per essere precisi, quindi usa Electron, e in JavaScript/TypeScript la configurazione spesso viene scritta su un file JSON e quindi penso che semplicemente avesse senso.Sono proprio salvati sul disco come JSON, quindi non è che quello che tu vedi lì è un rendering, è proprio quello che c'è scritto sul disco alla fine fine.Esatto, l'hai detto poi che fondamentalmente VS Code è un'app Electron.Su questa volevo farti due domande ma le facciamo dopo.continuare un attimo sulla linea dei plugin e della configurazione.Pensi che essendo VS Code un'app TypeScript e comunque con JavaScript sotto il cofano, possa avere in qualche modo aiutato a a sviluppare un ecosistema di plug-in che fossero facilmente sviluppabili? Ovviamente è difficile darti una risposta precisa perché non sapremo mai in un universo parallelo come le cose avrebbero potuto andare.Diciamo che BS Code è il seguente principale dei nostri utenti, sono programmatori che lavorano in JavaScript e TypeScript.Questa è stata una scelta dall'inizio che hanno voluto creare BS Code.Ovviamente puoi usare qualunque linguaggio di programmazione, però gli unici che sono disponibili senza estensioni sono proprio JavaScript e TypeScript.L'idea che era nata all'inizio è che volevano creare un editor per questa nuova generazione di programmatori che lavorano...non importa che linguaggio usi, anche se tu programmi in Python e Frontend, devi scrivere in JavaScript o TypeScript.Quindi volevano creare un editor specialmente per queste persone.E penso che il fatto che sia stato scritto, VS Code stesso, sia stato scritto in TypeScript e quindi le estensioni possono essere scritte in TypeScript, aiuta perché i programmatori che scrivono codice JavaScript TypeScript sanno già il linguaggio di programmazione che poi possono usare per creare estensioni.Quindi penso di sì, però poi ci arriveremo a questo tra un momento.La ragione per cui VS Code è scritto in TypeScript, diciamo, è una conseguenza di altre decisioni, non è che Eric volesse creare un'app Electron dal primo giorno, è stata una conseguenza.Infatti volevo arrivare là, no? Electron è croce e delizia un po' del mondo delle app desktop, è un piacere svilupparlo dall'altra però è anche un grande pain point dovuto a performance e cose di questo tipo.Ma la prima cosa che ti volevo chiedere in merito a Electron è perché Electron? Come dicevo, Electron non è stata la scelta originaria.Viesco di arrivare su Electron per conseguenze di aver fatto un paio di pivot.Come ti dicevo qualche momento fa, Eric Gamma, un'altra persona brillante che ovviamente posso solo imparare da lui e tanta gente posso solo imparare da lui.Eric è entrato a Microsoft circa dieci anni fa, cos'era? 2010-2011, e la sua proposta era di creare un editor che fosse interamente nel browser.Lui voleva creare quello che oggi è VS Code for the Web, sostanzialmente.Il problema è che dieci anni fa la web platform era molto diversa e non c'erano le funzioni che abbiamo oggi.Non parlo solamente dei browser che erano più lenti, ma parlo proprio che le API della web platform non erano quelle che ci sono oggi, non c'erano le API per accedere ai file nel file system, non c'erano tante altre API che hai bisogno se vuoi creare un editor.e quindi questo sogno di creare un editor generico per il browser era troppo presto, un po' avanti coi tempi.Quindi c'è stato un pivot e il primo è stato, hanno deciso di crearlo come editor che poi potesse essere usato all'interno di altri prodotti Microsoft, come il portale di Azure, come Azure DevOps, eccetera.E poi, siccome comunque avevano qualche numero di utenti, però non abbastanza per giustificare tutto il lavoro lì, Poi non so esattamente come sia successo quello, però so che hanno deciso di prendere VS Code e metterlo come app desktop e siccome il lavoro finora era stato fatto tutto in JavaScript e TypeScript, a quel punto hanno deciso di usare Electron, perché penso che fosse una cosa abbastanza nascente al momento Electron.Se non sbaglio la storia di Electron è che è stato creato per un altro editor, Atom, infatti il primo nome penso fosse Atom Shell.Ovviamente il contorno dell'atoma è l'elettrone quindi hanno deciso di rinominare l'electron e poi il VS Code è stato portato su questa piattaforma in un momento successivo.Il resto è storia.Nello sviluppo di VS Code hai mai sentito colleghi anche del team di Dev avere dei problemi che sembravano quasi insormontabili dovuti ad Electron o comunque problemi importanti, limiti importanti da girare? Ovviamente il fatto che sia costruito con tecnologie web crea dei limiti, però il fatto che uno che sia eseguito all'interno di Electron invece che un browser permette di poter usare codice nativo nei vari casi in cui questo è necessario, o comunque alternative così.Electron di suo, essendo basato su Node, ha già delle API abbastanza massive, che permette di fare un po' di tutto.Chiaro.Quanto, in realtà, il fatto che ci sono delle emergenti tecnologie come WebAssembly, può giovare agli sviluppi futuri di Visual Studio Code? La mia domanda è, è usato da qualche parte? Da qualche parte sì, non in modo estensivo, però da qualche parte sì e abbiamo anche notato che ci sono delle estensioni che stanno venendo scritte in WebAssembly al momento Soprattutto quando vuoi portare codice che già esiste scritto in un altro linguaggio, portarlo all'interno di VS Code, lo puoi portare come codice nativo, però poi a quel punto sei responsabile di avere binari pre-compilati per tutte le piattaforme e architetture che VS Code supporta.Al momento penso, se non sono dieci, siamo quasi lì.E quindi abbiamo visto che negli ultimi mesi qualche estensione sta arrivando che esegue codice in WebAssembly.Chiarissimo, altra domanda, qualche tempo fa, non ho approfondito l'argomento, quindi se dico una fesseria bloccami o come usano fare i nostri ascoltatori, mandatemi un messaggio per dire "Maurai ha appena detto una cazzata", però ho visto che sta emergendo una nuova tecnologia che ambisce a portare i container nella parte di front-end, qualcosa tipo browser container, mi è sembrato di vedere qualcosa del genere.C'è qualcosa nell'aria, nell'ambiente VS Code? Stai parlando di quella tecnologia che permette di eseguire codice Node.js, non solo javascript ma Node.js all'interno della sandbox di un browser? Sì.Ok.Allora per VS Code come desktop app non ce n'è bisogno perché ovviamente abbiamo accesso a Node.js intero come parte di Electron.Per il web, per VS Code for the web, è una delle cose che i nostri ingegneri stanno guardando.Adesso non so i dettagli di cosa, come, quando, perché, però come dicevo prima, VS Code per il web ha alcuni limiti dovuti al fatto che non c'è nessun server, quindi non si può compilare il codice.Quindi stiamo guardando in giro opportunità per inserire qualcosa specifico per certi linguaggi di programmazione e stiamo considerando tutte le opzioni.Era una mia curiosità proprio legata a VSCode per il web.Adesso però voglio farti una domanda che mi ha incuriosito guardando un po' il blog di VisoStudioCode tra l'altro è uno dei punti dove diciamo c'è sempre traccia di tutte le nuove funzionalità.Ho visto in realtà un articolo che parlava della web UI toolkit, del web UI toolkit, Ci puoi dire che cos'è? Sono super super curioso.Quello è parte di un progetto che un mio collega si sta lavorando.Abbiamo un paio di persone che sono UX designers, che fanno parte del team, e hanno creato questo toolkit che serve per chi crea estensioni per VS Code, se vogliono creare estensioni che hanno una web view, e possono usare questo toolkit per creare bottoni, interfacce, insomma tutte le interfacce e dagli un look and feel che ha senso all'interno di VS Code in modo da dargli un look and feel quasi come il resto dell'applicazione e inoltre hanno aggiunto la possibilità, tutti questi componenti che sono lasciati sono anche accessibili e fanno in modo che comunque l'estensione sia usabile anche da chi ha bisogno di tecnologie assistive.Adesso capisco, a livello di editor, adesso capisco alcuni talk che mi è sembrato di intravedere, a livello di editor è una cosa comune supportare questo tipo di tecnologie o no? E soprattutto nello sviluppo e lavorare con delle tecnologie web nella costruzione di Visual Studio Code ha aiutato il supporto appunto di tutto il mondo dell'accessibilità all'interno dell'editor? Abbiamo un paio di developers che si preoccupano particolarmente di far per rendere VSCode accessibile.A questo punto i nostri clienti ci dicono che VSCode è uno degli editor più accessibili che ci siano.Diciamo, non so quanto il fatto che sia un'app web aiuti o no.Posso dirti comunque che fin tanto che questi colleghi non hanno veramente deciso di occuparsi di rendere l'editor accessibile, non era completamente accessibile di suo.Cioè, usare tecnologie web, Può essere che aiuti, ma anche se aiuta, non è che il fatto di usarle in automatico rende l'app accessibile.Infatti per questo, lo stesso problema ci sono anche i siti web.Se uno crea un sito web e non spende un po' di tempo per rendere accessibile tutti gli standard, di suo non lo è accessibile, bisogna investirci un po'.Altra domanda sempre legata a Visual Studio Code e anche legata alle mie ultime esperienze, devo ammetterlo, io sono sempre stato utente Apple da ormai tempo in memoria, ero un bambino quando papà arrivò con un Apple, esatto, ma non so perché fondamentalmente ho sempre trovato un ambiente per sviluppare anche poi in età un po' più adulta, più confortevole, sviluppando io poi nel web.Ma da due o tre mesi circa sto usando una macchina con Windows, no? E una cosa che ho trovato è che io comunque uso Linux sotto il cofano per fare le mie cosine perché la mia shell voglio che sia così, i tool che utilizzo girano su Linux come molti di noi no? E quindi utilizzo WSL no? Una cosa che mi ha stupito è l'integrazione di Visual Studio Code con questa tecnologia, nel senso che la cosa che veramente mi ha lasciato senza parole in termini positivi è stata quella di aprire il terminale di ubuntu dentro windows scrivere code spazio punto e di avere in automatico visual studio code aperto su quella cartella ma in qualche modo come come posso dirlo completamente integrato con l'ambiente WSL e la domanda è quanto è stato complesso sviluppare questa integrazione e State iniziando a percepire i benefici di questo linux subsystem in termini di adozione massiva del sistema operativo da parte degli sviluppatori che prima non facevano parte dell'ecosistema Microsoft e che quindi spesso utilizzavano Linux o piattaforme Apple.Ottima domanda, ti rispondo alla seconda parte prima rispetto a come sta andando WSL.Come ti dicevo anche io sono un utente Apple sinceramente, il mio computer principale è un Mac, però il lavoro che i miei colleghi hanno fatto su WSL, proprio il team che ha creato questa tecnologia, grande fan, penso che abbiano fatto un lavoro eccezionale e sicuramente la ragione per cui hanno creato WSL, e non è un segreto, è per offrire qualcosa ai programmatori che lavorano con tecnologie che poi vanno eseguite su Linux.La realtà è che la maggior parte delle app cloud native che creiamo in questi giorni, tutti noi programmatori, poi vengono esibite su un server Linux.I tool, tanti tool, se non tutti, molti, funzionano meglio su un ambiente POSIX, quindi un ambiente Linux o Mac, e i miei colleghi nel team di Windows si sono resi conto di questo, che se vogliono offrire una grande esperienza per i programmatori è più semplice offrire qualcosa come WSL che no spendere ore e ore per convertire tutti questi tool.Quindi sono veramente un grande fan di quella tecnologia, quando uso Windows la adoro, è fantastica sicuramente.Non ti so dire i numeri, non è soltanto che non posso dirteli, ma proprio non li so perché quello non è qualcosa di cui mi occupo io personalmente.Dal punto di vista di VS Code, questa è una cosa molto interessante che, questo punto che fa è molto interessante ed è uno dei benefici del fatto che VS Code è un'app scritta con tecnologia web anzi.Qualche anno fa, penso questo punto tre anni fa forse, il team ha investito molto per far sì che ci sia una separazione solida tra VSCode UI, user interface, l'interfaccia, e VSCode server.Quando una persona esegue VSCode, in realtà anche nel tuo laptop, nel tuo computer, l'applicazione è un'interfaccia che comunica con un server.La cosa incredibile che sono riusciti a fare, e che in buona parte è dovuta al fatto che usiamo tecnologia web, è che il server può essere anche in altri posti, non deve essere un processo nello stesso sistema operativo, può essere spostato da qualche altra parte.Ed è così che siamo riusciti ad avere via SCODE Remote le tre estensioni, Remote SSH, Remote Containers e Remote WSR.Remote SSH ti permette di avere il server in un server Linux che gestisci te da qualunque parte, per esempio può essere una BME su Azure, può essere un server nel tuo seminterrato e tu hai l'interfaccia di VS Code nel tuo portatile, però stai lavorando sul server remoto, quindi i comandi che esegui sono sul server remoto, quando compili un'app viene compilata su Linux nel server remoto, eccetera.Remote containers è simile, però il codice viene eseguito all'interno di un container docker, quindi puoi creare ambienti di sviluppo ripetibili e dinamici.Per esempio, io ho un container che se ho bisogno di scrivere il codice Python 3, o questo container, se bisogna scrivere codice in Java, un altro container.E c'è isolamento totale tra i tool, così non si incasino fra di loro.E i container possono anche essere distribuiti ad altri.Quindi se tu hai dei colleghi che lavorano, sicuramente hai esperienza del problema che magari tu hai una versione della libreria, il tuo collega ha un'altra versione della libreria, e le cose non funzionano, ed è perché l'environment è diverso, quel container lo risolvi.E l'ultimo è il Remote WSR, che permette di eseguire VS Code come app nativa per Windows, ma il server è eseguito dentro WSL quindi in realtà VS Code comunica con un server all'interno della VM di WSL e tutto il codice è eseguito su Linux.E tutta questa cosa fantastica è anche quello che ci ha permesso di avere GitHub Codespaces che è, immagino che tu abbia sentito parlare, questo ambiente di programmazione in cui il server di VS Code è eseguito in server che gestiscono Github, dentro container, e uno può andare sul repository di Github, premere un pulsante e gli appare VS Code nel browser oppure tramite l'app e lavora su questi server remoti di Github.Alessandro, ti volevo fare una domanda, ma giusto per chiarire un attimino una cosa.Quando tu parli di Visual Studio Code Server, di quale funzionalità parli? Cioè parli di un language server o di un qualcosa più grande? Hai ragione, la parola server è molto...ci sono troppi usi diversi.In questo caso specifico si parla di questo motore, che è quello che esegue tutti i comandi di s-code, che si interfaccia con il sistema operativo, si interfaccia con il file system, eccetera.È una cosa che gli utenti normalmente non toccano.Tanti utenti non sanno neanche che Remote SSH installa un server nel server remoto, semplicemente sanno che si collegano via SSH e tutto funziona.Però questa è la differenza tra un vero VS Code server e no.Tanti anni, non so da quanti anni programmi, però sei passato abbastanza tempo.Qualche decade.Qualche decade.Forse ti ricordi il momento in cui usavamo FTP per caricare e scaricare i file da un server remoto, giusto? Esattamente.L'FTP su Aruba era cosa di tutti i giorni.Esattamente.FTP è "morto", adesso si usa FTP su SSH, quindi un modo per accedere ai file sul server remoto potrebbe essere usare SSH, FTP, e semplicemente VSCode potrebbe mostrare i file che sono lì per fare l'editing, quando salvi il file viene salvato sul server remoto.Però avendo un VSCode server che è eseguito lì, funziona in modo diverso, per cui i file Non è che vengono inviati al tuo computer, cioè non è che li scarichi, li modifichi e li invi indietro.Il VS Code Server, che è dentro al server SSH, direttamente modifica i file in modo locale e l'applicazione desktop comunica col server e gli dice cosa fare.Quindi quando tu compili un programma, viene eseguito nel server remoto o nel container o su Codespaces.Purtroppo è difficile spiegare un podcast senza immagini, però sul nostro sito ci sono anche dei grafici che possono aiutare a capire.Quindi praticamente adesso se vogliamo rendere sotto forma di immagine quello che hai appena detto, tutta la parte di lavoro sui file, di computazione è stata strappata, come si strappa un cuore in uno di quei film d'azione, E' una serva Electron, quindi disaccoppiata, e in qualche modo portata in altri ambienti, anche remoti, no? Cosa del genere.C'è un server che praticamente usa Node.js, perché veramente BS Code è scritto in JavaScript, quindi c'è questo server che usa Node.js quando VS Code si collega, l'applicazione Node.js viene eseguita nel server remoto e l'applicazione Electron, che è il frontend, comunica con questo server usando un protocollo e gli dice cosa fare.E invece quando non si usano le feature remote, questo server viene utilizzato ma in locale sulla tua macchina, quindi viene in qualche modo lanciato nella tua macchina, no? Credo che sia nello stesso processo a questo punto, c'è sempre una comunicazione, però potrei sbagliarmi qui perché non sono sicuro al 100%, però fa parte del stesso processo, solamente invece di comunicare invocando funzioni in modo diretto dovrebbero usare un protocollo prestabilito che può essere usato o in modo locale o in modo remoto.A questo punto ho una domanda, questa è una mia curiosità.Prima di farmi questa chiacchierata con te leggevo un articolo nel vostro blog rispetto a un'estensione che io utilizzavo in modo intensivo, che era quella che colorava le parentesi, che adesso è stata integrata da quello che ho capito nel core di Visual Studio Code, per una mera questione di performance.Ma allora, il mio dubbio è, quindi le estensioni dove girano? Cioè è un problema che le estensioni girano nel frontend o anche le estensioni girano nel server? Ottima domanda.Ci sono due extension host.Anzi, alcune estensioni...innanzitutto le estensioni di VS Code interfacciano con il resto dell'applicazione usando delle API predefinite.Una delle cose che Eric aveva imparato, per esempio, da Eclipse è che bisogna definire i limiti delle estensioni in modo preciso, altrimenti è un po' un disastro, altrimenti le estensioni confliggono fra di loro, altrimenti le estensioni rendono l'editor molto lento.Quindi ci sono un set di API che dicono esattamente cosa possono fare le estensioni.e ovviamente continuiamo ad espanderle, ogni pot aggiungiamo altre API, però sono abbastanza definite.Le estensioni ci sono di, diciamo, tre tipi.La prima sono le estensioni che non hanno codice, per esempio Temi, questi vengono eseguiti direttamente all'interno della UI, quindi all'interno della UI, all'interno di quella parte dell'applicazione.Poi ci sono due extension hosts.Per le estensioni che hanno bisogno di eseguire codice, soprattutto codice che hanno bisogno di Node.js, c'è l'extension host, che è un processo separato dove le estensioni vengono eseguite.Per le estensioni web, che abbiamo introdotto assieme a VS Code for the Web e Codespaces, e queste sono estensioni che possono anche essere eseguite all'interno del browser, quindi sono scritte in JavaScript, però vengono eseguite all'interno di un browser o di un ambiente che con un browser non ha accesso a Node.js quindi per esempio puoi fare richieste esterne usando fetch ma non puoi usare le librerie Node.js per fare le richieste per esempio c'è un web extension host che è un altro processo che esegue queste estensioni Ok, quindi è un pochino più articolato di come lo immaginavo Però che mondo ragazzi, alla fine un tool che usiamo tutti i giorni, tutta questa complessità per noi è trasparente, noi lo apriamo e magari ci passiamo dieci ore al giorno, ma quello che succede sotto il cofano spesso lo ignoriamo io in primis, non sapevo del fatto che per esempio Visual Studio Code, avesse questi server che sono super super interessanti.Però ti voglio fare una...È un feature, non è un bug.Lo scopo nostro è quello di creare un'app che sia semplice per le persone.Poi se uno è interessato, ovviamente, è tutto documentato, può anche andare a leggersi il codice sorgente e vedere come sono fatte queste cose.Però appunto vogliamo offrire qualcosa che funzioni, che sia semplicemente un wow.questo è anche il discorso delle estensioni, dei vari extension host, eccetera è perché vogliamo far sì che VS Code rimanga il più rapido possibile e il più performante possibile parlavi prima, Mauro, di fatto che il tuo collega ha una relazione un po' complicata con Electron, no? è una cosa che sento tanto spesso VS Code è un'app in Electron per quanto questo abbia un limite Diciamo che il nostro team sono persone fantastiche e continuano a fare tutto il possibile per far sì che l'overhead di Electron sia il più piccolo possibile.Per esempio, un pezzo di curiosità è che VS Code nel frontend non usa nessun framework, non è scritto in React, non è scritto in Angular, non è scritto in Svelte o qualunque altra cosa.Manipola direttamente il DOM, che uno pensa sia un po' un'eresia, però la ragione per cui è stato fatto, due ragioni, la prima è perché ovviamente usare un framework significa che poi sia un po' l'ambercello di questo framework e quando la gente smette di usarlo poi sei un po' fregato, ma il problema principale è per un discorso di performance.Il nostro team ha scoperto che per avere la performance più alta bisogna andare più vicino possibile all'HTML, quindi al DOM, e quindi usare un framework avrebbe aggiunto più overhead.Quindi stanno veramente facendo tutto il possibile per rendere l'app il più performante che si può.Fantastico.L'ultima domanda in realtà legata a Visual Studio Code riguarda i notebooks.nuova introduzione dentro Visual Studio Code che vanno a sostituire alcune estensioni.Ci puoi parlare un po' di come funzionano e di quelli che sono gli obiettivi di questo nuovo tool? se sono pensati per, questa è una domanda un po' cattivella, passamela, se sono pensati per il classico caso d'uso quindi o accademico legato alla data science oppure se possono diventare utili anche in ambito di experiment mentre stai sviluppando.Mi viene in mente il Mauro che si apre, adesso non mi ricordo come si chiama, non Codesandbox, quell'altro sito dove puoi scrivere e testare rapidamente dei pezzettini di JavaScript per poi ritornare nel suo codice.Codepen? CodePen, esatto.Grazie Alessandro.Sì, ottima domanda.I notebook ovviamente sono più famosi, sono più conosciuti da un punto di vista, come dicevi, accademico, di data science, per chi si occupa di analizzare dei dati, eccetera.di Jupyter è famosa come estensione per notebook per questo scopo.E tra l'altro Jupyter può essere usato in VS Code, cioè un'estensione che la via di taruza di Jupyter è esattamente come in ogni altra parte.Però l'idea che abbiamo investito di recente, questa idea dei notebook che sono indipendenti dal data science, proprio per quello che dicevi di come fare esperimenti, Può essere che io sto cercando di scrivere un algoritmo o una funzione e voglio capire qual è il modo migliore per farlo, voglio capire come si comporta, voglio capire come ottimizzarla o qualunque altra cosa, voglio andare step by step.E allora usare il notebook è un ottimo modo per fare esperimenti.Alcuni notebook in VS Code poi non sono necessariamente legati al codice, Cioè, il codice può essere qualunque cosa.Per esempio, abbiamo un notebook che un collega ha creato, si chiama RESTbook, che scrive l'URL e i parametri e fa una richiesta HTTP e ti mostra il risultato in parte del notebook.Cioè, il nostro team ogni giorno durante il stand up usa un notebook che è pubblico, che praticamente chiama gli API di GitHub e mostra tutti gli ticket, tutti gli issue che sono aperti su GitHub e quindi lo usano questo per decidere come lavorare.In generale l'idea del notebook è questa idea del "programmazione letteraria" o "literary programming" in cui si mischia codice e testo che spiega cosa fa il codice ed è un po' un modo di lavorare che segue il modo in cui le persone sperimentano, in cui le persone giocano, nel senso inglese di play, di fanno test, di fanno prove, eccetera.Quindi esistono delle API, cioè quando hai parlato del REST Notebook, quello che nella mia mente, magari malata è venuto in mente, come l'hanno fatto? Cioè esistono delle API che ti permettono di customizzare questa specie di documenti con una sorta di template o come funziona questo lato? Esattamente, beh ci sono due modi.Il primo è ovviamente usare Jupyter.Se puoi scrivere un kernel Jupyter che funziona in Jupyter allora funziona anche in Jupyter via Score.Questo è quello che funziona per Python, ci sono altri notebook per JavaScript che che usa questo, eccetera, qualunque kernel funziona.L'altro modo è di usare le API di VS Code per creare estensioni notebook.Così come ci sono estensioni di altro tipo, ci sono estensioni notebook, VS Code ha l'interfaccia e le API dicono questa cella, che tipo di cosa ci scriviamo dentro e come lo eseguiamo.Quindi può essere che, appunto, questo RESTbook, chiamato REST, dice che ogni cella contiene un URL e quando premi "esegui" allora poi ci penso io a eseguire e ti do il risultato, e il risultato appare.Sto semplificando ovviamente.Sì, sì, no, ma adesso è più chiaro, quindi comunque di lì ci sarà tutta una linea di sviluppo di nuove estensioni per VisuStudio.Quando hai visto che questa feature è abbastanza nuova? Leggevo quando era a novembre? Quando è uscita? Mi pare di sì, che sì, abbiamo rilasciata forse l'estate scorsa in preview se non ricordo male, primavera scorsa in preview e poi è stata stabilizzata l'autunno scorso.Sì, guarda, quello che hai appena detto ti odio in senso benevolo perché questa cosa dei notebook mi ha fatto venire in mente altri 16 side project e quindi saranno mi hai messo tanta carne al fuoco che per forza dovrò andare a vederlo perché sto già, che ne so, immaginando la relazione per lo sprint planning fatta dentro un notebook o cose di questo tipo, oppure il day by day diary fatto dentro il notebook figo, bello.Ovviamente sei sempre benvenuto a creare estensioni, anzi sarò curioso di vederle pure io.Tieni anche presente che questi notebook di cui parlavo prima, RESTbook e quello GitHub Issues che usiamo noi, sono tutti open source, quindi puoi anche andare a vedere come li abbiamo fatti e usarli.Fantastico, metteremo i link nelle note dell'episodio.Adesso però voglio spostarmi per un attimo da Visual Studio Code e intanto ringraziarti per avercelo fatto esplorare.Però voglio arrivare un attimo alla tua attività di Technical Writer e ti voglio chiedere, una delle tue pubblicazioni è Svelte 3 up and running.E allora la domanda mi sorge spontanea, perché Svelte 3 e perché c'è scritto un libro? Allora perché Svelte 3? Svelte ovviamente, so che questo ha il rischio di cominciare una guerra santa, quindi lo presento dal punto di vista della mia opinione, questo è questo è quello che io preferisco.Svelte è il mio framework JavaScript per il frontend preferito.Lo usavo già quando era in versione 2 e poi quando è uscito la versione 3 c'è stato un momento di shock perché ha cambiato tutto completamente, però mi piace molto usarlo, mi diverte.Questa è la cosa, la ragione prima di tutto è che mi diverte usarlo e come ti dicevo il programma è principalmente per me, per divertimento, per hobby e quindi che sia divertente è la versione numero uno.Poi ovviamente Svelte è anche veloce e rapido.Svelte è anche veloce e rapido, le applicazioni sono più compatte in dimensione, eccetera.Dal punto di vista del perché del libro mio quest, ero nell'ambiente di Svelte prima, avevo creato anche un componente che è abbastanza popolare, si chiama Svelte SPA Router, che è un router per front-end che usa di hash-based routing, quindi il cancelletto alla fine del URL e poi usa quello per decidere la route.C'è una storia su perché ho dovuto creare questo router, ma è un'altra storia.E poi avevo già esperienza a scrivere dei blog, ed è un po' che ho, da un po' di tempo che ho il mio blog withblue.ink E questo publisher, Pact, sono stati loro che mi hanno trovato, sono stati loro che mi hanno chiesto se è interessato a scrivere il libro e io ho detto sì, intanto pensavo fosse un'esperienza interessante e lo è stata, è stato anche divertente, mi ha permesso di imparare un sacco di cose.E pare che ci hai preso gusto, no? Diciamo è un po' una penitenza anche, non nascondere un libro, è tanto lavoro e ci vuole tanto tempo.Guarda, ne parlavamo qualche episodio fa con Gabriele Santomaggio che ha scritto un libro su Rabbit e ha detto la stessa identica cosa.Però io so che tu hai in uscita un libro che voglio assolutamente avere premetto.Questa non è un'inserzione sponsorizzata, ma proprio mi ha incuriosito, che è "Essential Cryptography for JavaScript Developer".Ci puoi dire qualcosa di questo libro? Già il titolo ha catturato la mia attenzione, però puoi aggiungerci qualcosa? Perché questo titolo, perché questa tematica? Certo, questa è stata l'idea invece che ho fatto io al teaching, al PACT, per proporre questo libro.E sostanzialmente è una collezione delle cose che ho imparato facendo tanti errori all'interno della mia esperienza come developer.L'idea è che la criptografia è fondamentale ormai per creare app che ci piacciono, Le funzioni come hashing, come criptare e decriptare, oppure firme digitali, sono un po' dappertutto e sono anche molto utili quando uno vuole creare un'app che ha certe necessità in termini di sicurezza o di privacy, anche dal punto di vista di compliance con GDPR, eccetera.Criptografia può essere molto utile.Però quando io ho imparato queste cose, tutte le risorse che trovavo, ce ne sono tante, erano tutte molto finalizzate dal punto di vista di addestrare altri criptografi.Quindi andavano nei dettagli di questo è come RSA funziona, spiegavano l'algoritmo nei dettagli.Ma dal punto di vista mio, di programmatore, questo non mi interessava.Cioè, a me interessava sapere come usare RSA in modo sicuro, che poi come funziona l'algoritmo, come funzioni la matematica che poi è molto complessa, dietro quello non interessa niente.E quindi questa è l'idea di questo libro, di aiutare altri programmatori come me a spiegare come possono usare gli algoritmi in modo sicuro, a cosa servono, quali sono, come si usano in modo sicuro e altre cose legate all'uso, ma senza entrare nei dettagli di "ah, funziona perché ci sono questa matematica e queste sono le iteration dell'algoritmo eccetera.Quindi è molto molto pratico, se ti serve X usa Y e usalo in questo modo.Chiaro, particolare, anzi ti dirò di più, a questo punto ti rinviteremo una volta che il libro è uscito, se ti fa piacere, per parlare dei contenuti del libro, quindi andare un po' più in dettaglio in queste cose.Che ne dici? mi farebbe molto piacere, però magari aspettiamo prima a vedere quando questo podcast esce quanta gente mi dice che ho detto troppe stronzate prima di invitarvi ancora.Ma che vai tranquillo, guarda nel podcast quello che dice stronzate sono io, quindi no grazie Alessandro.Io guardavo il nostro timer e come sempre l'obiettivo del buon proposito di inizio anno di farci stare le puntate in un'ora, anche questa volta è sfumato, ma ormai continuo sempre più a convincermi che la durata fisiologica dei nostri episodi è un'ora e mezza e non ci possiamo fare niente.siamo arrivati al momento quello che io dico tipico e topico del nostro podcast che si chiama il Paese dei Balocchi, il momento nel quale i nostri ospiti e i nostri host portano in dono un libro, un talk, qualunque cosa insomma hanno visto interessante e quindi vogliono condividerlo con la nostra community."E conduco nel paese dei balocchi!" "Ah, il paese dei balocchi!" Io ho pensato di portare due cose.La prima è la mia estensione VS Code preferita, perché sembrava a tema.La mia estensione si chiama GistPad.Praticamente permette di lavorare con le gist all'interno di VS Code, all'interno del Laritore.Ora, le gist sono quelle che si trovano su gist.github.com e sono dei file di testo che uno può scrivere e scrivere quello che vuole, salvarle possono essere note, possono essere snippet, possono essere script, eccetera.Puoi usarli per tutto quello che vuoi, è il tuo spazio dove puoi scrivere cose.Mi piace gistfile perché le porta all'interno di DS Code e permette di leggerle, scriverle e averle come riferimento senza lasciare merito.La seconda cosa che vorrei portare è un libro che parlando di product management così, una lettura che ho letto diversi anni fa e mi è stata estremamente utile e ancora adesso la uso come riferimento, si chiama "The Lean Startup" di Eric Ries, che è concentrato soprattutto in una startup, però quando uno ci pensa le stesse idee possono essere portate anche in aziende più grandi e mi ha aiutato molto dal punto di vista di trovare product management, di trovare esperienza per capire i mercati eccetera e quindi lo consiglio.Poi anche è una lettura divertente.È un bellissimo libro, io ce l'ho qua accanto a me, lo sai? Ah, non lo sapevo.Sì, sì, ce l'ho proprio qua.Se non ricordo male c'è anche una versione italiana, no? È possibile, mi ricordo che...Mi sa che si intitolasse "Partire Leggeri", qualcosa del genere.Naturalmente i titoli italiani sono vultevoli, come sempre, no? Sembrano dei titoli da libro di programmazione neurolinguistica.Bellissimi, assolutamente bellissimi balocchi.Io ne ho due.Uno l'ho un po' spoilerato, nel senso che erano appunto i notebook dentro Visual Studio Code che era una roba che sta catturando la mia attenzione da un po' e ne avevo anche un altro che poi è un gingillo, un balocco di cui ho già parlato però mi piace parlarne in questa nuova veste Io qualche tempo fa ho preso uno Stream Deck, che è una sorta di dispositivo con dei pulsantini con gli schermetti, tu calchi il pulsantino e lui fa qualcosa.c'è un tool che poi è il pannello di controllo dove si configura lo string deck e all'interno di questo tool c'è un'estensione per lo string deck che parla con visual studio code e ti permette di eseguire un comando, eseguire un comando da terminale, cambiare il linguaggio, aprire il terminale, aprire una cartella oppure inserire uno snippet.Io è da due giorni circa che ci sto giocando e devo dire che all'inizio mi sembrava un'idiozia visto che io utilizzo l'autocomplettamento per creare degli snippet dal template, però per alcune cose l'ho trovato simpatico e rapido nel senso che se devo passare da un progetto all'altro ho già il tasto mappato, se devo eseguire i comandi al posto di andarmi a scrivere una stringa un po' lunga o richiamarla col tasto su calco direttamente il pulsante nella mia pulsantiera e mi attiva il tutto ed è una cosa carina che volevo condividere con voi.Bene, siamo...Voglio riprovarlo anche a me, devo comprarmi uno streamback.Sì, guarda, io, credimi, è una di quelle cose che all'inizio ho detto "vabbè dai, sono altri soldi spesi e andrà a finire insieme a tutti i controller midi nel cassetto dei controller midi", no? Però in realtà, vabbè, a parte per la registrazione del podcast che lo uso tanto, ma come dicevo ai ragazzi ho configurato che non è solo l'apertura del calendario piuttosto che l'apertura della mail o delle cosine con gira comunque si è integrato bene nel mio flow e soprattutto c'è quei pulsanti illuminati davanti per cui ti viene quasi automatico e questa integrazione a visual studio kod mi ha mi ha fatto venire la cuolina in bocca e quindi ci stavo giocando [Musica] Anche questa settimana è arrivato il momento di ringraziare i donatori, le persone che ci aiutano, ci supportano in questa esperienza, in questo progetto, ecco.e anche questa settimana abbiamo un generosissimo Andrea Quintino che ci dona ben tre birre fresche, ghiacciate birre che ci aiuteranno a sostenere i costi di questo podcast in fondo abbiamo tante subscription da pagare, non per ultima quella Spreaker, StreamYard Insomma, di costi ce n'è, noi lo facciamo gratis, ma non è gratis farlo.Se vi va di supportarci, trovate il link direttamente nel nostro sito, sito che stiamo provvedendo a restaurare.Il link è in alto a sinistra, c'è scritto supporta git/, cliccandoci vi porterà direttamente da Paypal.La cosa interessante che c'è adesso con il nuovo sistema di donazioni di Paypal è che c'è la possibilità di fare una donazione mensile.Così come voi pagate l'abbonamento alla palestra o pagavate l'abbonamento a riviste come io programmo, beh, potete farlo con Kitbar se vi fa piacere.detto questo io mando la linea al podcast ringraziando nuovamente Andrea Quintino per le birre che ci ha offerto [Musica] Bene, stavo guardando l'orologio, siamo andati abbastanza lunghi, però siamo sempre nell'ora e mezzo, quindi è il momento ahimè di salutarti Alessandro perché qua ormai è quasi notte fonda da te, penso che sia l'ora del tè Eh, ora di pranzo allora ti lascio andare a mangiare ma non prima di averti ringraziato a nome mio a nome di tutta la community per esserci venuto a trovare come è nostro solito diciamo che da oggi Gitbar è un po' anche casa tua quindi quando c'è qualcosa di figo qualcosa interessante che hai piacere di condividere con la nostra community, insomma vienici a trovare senza...anche senza bussare, entra direttamente.Grazie mille Mauro, è stato un piacere parlare con te.Il piacere è tutto nostro.Noi ci diamo appuntamento alla prossima settimana, mi raccomando qua sempre sul podcast Gitbar, rapidamente così da riuscire a essere più rapidi possibile.Info che ho c'è la Gitbar.it @brainrepo su Twitter, gruppo Telegram se non l'avete fatto, mi raccomando potete anche supportarci perché nel nostro sito abbiamo un bel pulsantino che è quello che attraverso Paypal ci permette di ricevere le vostre donazioni e quindi coprire i costi vivi del nostro podcast perché il nostro impegno è gratuito però le bollette dobbiamo pur pagarle.Detto questo io vi do appuntamento alla prossima settimana ringrazio nuovamente Alessandro per la sua disponibilità e alla prossima ciao Gitbar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con BrinRepo parliamo di linguaggi e e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.
