Bene e benvenuti su Gitbar, altra settimana e nuovo episodio fresco fresco e anche questa settimana non son da solo questo periodo Gitbar è ricchissimo di ospiti e questo mi rende veramente veramente felice ma prima di svelare chi sta dall'altra parte del microfono il mio ruolo anche un po' palloso come ormai sapete è quello di ricordarvi i nostri contatti Info che ho la git bar punto hit via email et brain repo su twitter oppure il nostro gruppo telegram gruppo telegram sempre più Affollato e casa non solo mia ma anche degli ammuttinati infatti alcuni degli ammuttinati ci raggiungeranno poi più tardi lungo lungo l'episodio oggi c'era il talk di Mattia su Kotlin a CodeMotion quindi ci raggiungeranno non appena sarà finito tutto.Detto questo possiamo iniziare.Benvenuti su GitBar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare, nel modo più efficiente possibile, quei prodotti digitali che quotidianamente usiamo.Oggi con noi abbiamo Roberto Gambuzzi, Principal Software Engineer a FabFitFun.Cacchio, ci son riuscito! Ex Amazon, Magento Specialist...Ha fatto un sacco di cose! ed è qua con noi per parlarci di Python.Ciao Roberto, come va? Ciao, tutto bene.Luciano ti ha incastrato questa volta.Sì, questa volta mi ha incastrato.Infatti il contatto di Roberto ce l'ha dato Luciano qualche qualche episodio fa e io mi ci son fiondato perché in realtà di Python non ne abbiamo parlato molto nel nostro podcast.e quindi ne parliamo con Roberto che è un esperto del linguaggio e di programmazione, talmente esperto che ho visto che il tuo LinkedIn ancora prima del nome c'è un emoji col pittone, quindi è proprio qualcosa che ti è entrato nel cuore no Roberto? Si, diciamo che ho cominciato a guardare Python che c'era già la versione 2.4 ma si parla comunque di 14 anni fa e mi sono approcciato adesso perché cercavo qualcosa di più semplice.Ai tempi facevo molto C e C++, Java ovviamente era sempre lì che girava, le ditte grandi chiedevano Java e cose del genere, però sentivo molto il dolore di dover scrivere questi linguaggi verbosi in cui dovevi dichiarare tutto, gestirti la memoria.Ok, Java ti dava il vantaggio gestirti la memoria, ma non era non verboso.E quando vedi la sintassi di Python, niente graffe, poche cose, poche linee espressive che facevano molto, fondamentalmente rimasi molto incuriosito.Cominciai a studiarlo, cominciai a studiarlo sugli help di Python.Installai Python per Windows, ai tempi usavo molto Windows perché facevo poi .NET, quindi usavi Windows.E insieme all'installazione di Python c'erano i CHM, i file di help di Windows, che erano questi piccoli ipertesti.Il manuale, la documentazione era fatta molto molto bene, tanto che potevi studiarlo offline, non c'era bisogno di avere risorse online, che al tempo erano anche un po' più scarse che oggi ovviamente.Però non c'era bisogno di avere questa risorsa anche solo seguendo l'help del linguaggio, una volta installato, era facile vedere tutto.Poi ovviamente col tempo e l'esperienza si imparano i moduli del core che sono un pochino più nascosti, che nessuno usa mai e cose del genere, ma quelle esperienze.Tu ormai lavori in questo settore da tanti anni, hai iniziato questa relazione con Python 14 anni fa, tra poco sarà maggiorenne questa passione, però nella tua carriera si sono avvicendati tutta una serie di linguaggi, da prima quando lavoravi su Magento, poi su Amazon per poi arrivare a FabFitFun.Come è iniziata la tua carriera da sviluppatore e come si è evoluta poi nel tempo? Ma io ho iniziato a programmare quando avevo 8/9 anni su un Commodore 16, quindi con tantissime ristrezioni di memoria e ovviamente si comincia col basic, in quel era lì.Si cominciava con questo basic del Commodore, muovevi due puntini sullo schermo e ti sentivi un programmatore, giochi e tu dopo aver mostrato tre pixel dicevi adesso faccio un gioco.Poi ti rendi conto che non sei capace e cominci a ridimensionare le cose.Dopodiché ho fatto studi nel campo dell'informatic che ci sono poi finito quasi per caso perché io alle superiori volevo fare eliti e volevo fare energia nucleare.Quando volevo fare energia nucleare hanno tolto la specializzazione.Perché hanno denuclearizzato l'Italia, no? Perché sì, ma il corso che c'era era stato convertito in tipo radiologia ambientale, quindi qualcosa per evitare che ci siano radiazioni nell'ambiente, quindi è diventato un corso che non c'entrava con quello che volevo fare io, che era lavorare nelle centrali nucleari.Di conseguenza dopo mi chiama il Presidente e mi dice "hanno chiuso il corso e io "e adesso cosa faccio? C'è informatica? Oh beh, mi piace scrivere codice".Scrivevo codice in BASIC, poi GVBASIC sotto i numeri 8086, quindi macchine con 20 mega di disco, non di RAM di disco, è un mega di RAM perché non esageriamo, e allora ho detto "sì, vabbè, facciamo informatica, se poi tanto non mi piace mi sposto".Alla fine in realtà mi è piaciuta, ho avuto degli insegnanti molto bravi, c'era molta elettronica che ai tempi aiutava a capire cosa succedeva veramente sotto.Mi sono poi spostato a fare l'università a Bologna di informatica.Nel frattempo ho cominciato a lavorare, ho lavorato all'inizio con Perl.è un ricordo doloroso, lo lasciamo perdere! Perle ha gettato le basi per un sacco di linguaggi che sono venuti dopo e per un sacco di modi di lavorare che sono venuti dopo, ma aveva tanti difetti, uno dei quali era Syntasic, tuttora guardando un programma in Perle ogni intanto ti viene male, cercando di capire tutto quello che vuole fare, i simboletti, la virgola, se c'è la virgola, se c'è due punti fa una cosa, se non c'è fa un'altra e tu ti perdi fatti tutte queste cose.Dopo quell'esperienza traumatica, Mimmo si dite che facevano Visual Basic ai tempi, i Rasp.net Classic, cioè non Notnet, i Rasp Classic, prima del .NET, da ditte che facevano Java, per le banche.Normalmente mi sono sempre mostro abbastanza spesso.Ho provato a fare la mia esperienza di startup, che ai tempi si chiamava "aprire una ditta".Non andò bene, era chiusi.Dopodiché sono approvato e nel frattempo ovviamente si usava tutto.Facendo cose in Visual Basic, facendo cose in PHP, Microsoft SQL Server, MySQL e tutto quanto.Sono poi approdato una ditta italiana che si chiama WebGrief che faceva, fa tuttora, e commerce, il Magento.Lì per cinque anni ho lavorato con Magento, sono iniziato con PHP5, ho finito con PHP5.6.Quindi solo Dolore...Si faceva già vedere all'orizzonte il set, però non c'era ancora.Ho avuto i miei scontri con HHVM, nel senso che non ha mai funzionato bene con Magento, quindi abbiamo provato varie volte, ma senza successo.Dopo questo ho avuto l'occasione di essere assunto in Amazon e di spostarmi dall'Italia all'Irlanda per seguire Amazon.Dentro Amazon è tutto un altro mondo, ti ragioni su tutta un'altra scala, che linguaggio fanno in Amazon? La risposta è tutti.Quindi qualunque linguaggio tu conosca, a qualcuno fidati che sarà utile.Tranne PHP, no? Perché lo odiano a basso.Allora, la leggenda narra che PHP si è abbandito da Amazon.In realtà quando joinai io, c'erano ancora dei sottosistemi interni che erano in PHP e che poi sono stati immigrati.Però in in realtà qualcosa non c'era.Sì, perché parlavamo con Alex e scherzando gli dissi quando Alex Casalboni, quando vediamo che Lambda, tra tutti i linguaggi, nativamente non supportava PHP ora, cosa che ora si può far girare senza troppi problemi, però dissi "Ma caspita, proprio per il design di PHP che fitta perfettamente con quel tipo di tecnologia non c'è PHP e Alex in modo molto intelligente ha detto sì, va beh, ma hai la libertà di implementartelo fondamentalmente di lì si vede anche un po' di policy che non so se è leggenda o è però goliardia ma sì, no, ma poi più che altro che non essendo...perché alla fine hanno anche poi assunto uno delle varie persone che lavorò su PHP quindi ma in realtà non hanno persone interne che lo seguono, che lo usino, che lo conoscono e di conseguenza ai tempi facevi fatica a fare una Lambda o fare un server di Lambda o di servizio su un linguaggio che non conosci, cioè come fai a farlo funzionare? Adesso puoi far girare i container, una volta che fai girare un container metti dentro quello che vuoi.Sì, con la questione dei layer è veramente facile.Devo però dirti che mi è capitato vedere l'SDK di Amazon per PHP e mai avuto problemi, io l'ho usato per tanti, invece con altri altri SDK ti dico la verità, ci ho fatto scendere tutto il purgatorio e il paradiso dal cielo.Eh ma per Amazon l'SDK sono qualcosa di customer facing, Amazon ha una cultura nel confronto dell'utente finale molto dovedi nel loro retail.Se hai un qualunque problema con qualunque cosa, prima te lo sostituiscono, poi ti fanno le domande.Loro vogliono che i clienti siano estremamente soddisfatti e l'Sdk serve per aumentare la soddisfazione dei clienti.Quindi ad esempio per Python l'autore di Bototre è stato assunto da Amazon una volta fatta la libreria ed è pagato per mantenerla allineata, funzionante, che funzioni bene, è sempre aggiornata con i nuovi servizi, perché per loro sono mancate opportunità di guadagno se Botto3 rimane indietro di un servizio rispetto a quello che loro vendono.Certo, perché ormai Botto ha un'adozione assoluta, è la porta d'ingresso verso i servizi di Amazon dal mondo Python e quindi è normale che loro abbiano tutto l'interesse anche se non ti nascondo che pensavo Botofo fosse proprio una libreria nata in seno ad Amazon.Da quello che so io è nata fuori poi mi piace e compro come fanno con tantissimi servizi.Chiaro, assolutamente.Beh loro hanno la base cliente quindi diventa molto facile può integrare però tu hai detto che hai lavorato per diverso tempo in php con con magento e quindi hai posso dire esperito anche il passaggio da magento a symphony scusami da magento a python da php a python riuscire al nostro eroe stasera a parlare senza devastare qualunque cosa.Dicevo hai proprio fatto questo passaggio di esperienza da PHP a Python e la mia domanda è cosa hai percepito a livello di boost che Python ti ha dato e ti è mancata qualcosa del mondo di PHP quando poi hai abbracciato praticamente full time questo linguaggio di programmazione? Io ho cominciato a usare python ancora prima di passare a farmacente, però ovviamente nei primi anni usi un linguaggio nuovo, non lo conosci bene, tutto il ricossistema è un po' oscuro.All'inizio lo usai per impiazzare degli script BAT sotto Windows che facevano cose, mandavano, uploadavano file in FTP, scaricavano cose, inserivano record in database MySQL, tutto da BAT e cominciai a ripiassare questi script.Quando cominciai invece a lavorare in questa data web in PHP, cominciai a vedere cosa potevo fare in Python per Magento, perché il database alla fine è un database, tu ci puoi accedere con quello che vuoi.Infatti per alcuni clienti ho fatto delle utility in Python per integrarmi con i loro gestionali, perché ovviamente tu hai un cliente che vuole fare e-commerce, però i dati si sono suggestionali, non è che gli puoi dire "sì, l'admin di Magento è bello, ma non è che puoi riscrivertelo, riscrivere tutti i prodotti da una parte all'altra a manella e se cambia un prezzo devi ricordarti di cambiare il prezzo".Quindi c'è tutte le integrazioni.Ho usato PHP, la ditta usava PHP ai tempi per fare questo, però PHP per le CLI, per i comandi da console era ancora un po' dieci anni fa, si parla, era dovevi installare PHP sulla macchina, dovevi lanciarlo e poi devi ricordarti di aprire il tag del PHP, che mi scordavo sempre ovviamente.Era lento, un sacco di cose.Lo sintassi comunque, sappiamo tutti che ogni tanto PHP ha le funzioni inconsistenti, cioè prima l'argomento, poi l'array, prima l'array, poi l'argomento, e quelle cose lì non hanno mai standardizzato nulla che accidenti a loro.Di conseguenza invece con Python mi trovo molto meglio, il codice era più piccolo, più compatto, più espressivo, non c'erano tutti quei dollari in giro ovunque.Sulla consistenza c'è la leggenda del creatore di PHP, aiuto, Rasmus Lerdor, che disse che la consistenza del linguaggio era una consistenza verticale mappata sul C."Terapia da pioggia come se fossi Antani, la supercazzola prematurata con dominus vis cum blinda"."Come, prego?" "Terapia sulla supercazzola con scaffiolamento a destra o a sinistra?" "Perché sì." "Non preoccupatevi, ho frappato il C in PHP, quindi la firma è la stessa." non aveva senso neanche prima.E' "ma io volevo mappare uno a uno".No, ma magari se mi fai un API che io riesca a ricordarmi...No, infatti molti si rimasero così da quella uscita, però era un PHP Day, quindi eravamo tutti con un buon livello di bias nella stanza.Comunque per rispondere a tua domanda, di solito all'inizio, quando c'era i primi tempi di composer per PHP, in Python avevi il PIP, quindi avevi il requirement.xt, non c'era ancora PIPenv, non c'era ancora Poetry.Forse all'inizio per la gestione delle dipendenze è vero che c'era il registro, ma forse era un po' più indietro Python da quel punto di vista lì.Avevi su del requirement.xt, pip di quel file lo installavi, avevi le tue dipendenze, dopo hai cominciato a poter locker.Mentre nel discorso di composer, composer lock, che poi adesso con pipen va il pipen e il lock, quindi ha copiato poi...C'è stato un po' quella essendo che PHP aveva tanti problemi con le dipendenze, anche con le dipendenze binarie, che anche lì si apriva un mondo di "ho la libreria sbagliata, oh mio dio".Per Opecle è tanto pianto.Sì esatto, dopo lì cominciava l'elirio.All'inizio con Python forse quella cosa di le dipendenze l'ho sentito un po' di più, però c'era poi il vantaggio che alla fine facevo quello che adesso viene chiamato "vendoring", cioè fai la cartella "vendor" con le tue librerie dentro e lo copi in tutti i progetti.Io ho così potuto farlo a manina all'inizio con Python invece di avere un tool che me lo facesse.Però poi sono maturati molto tutti i virtual environment, pipen, poetry, adesso sono arrivati ovviamente ad un livello molto molto buono e non sento più.All'inizio però un po' lo sentivo questa differenza.Mi chiedo come mai PHP in queste cose è più avanti di un linguaggio invece che mi sembra migliore.Sono sempre interpretati, qui non apriamo polemiche, però diciamo che alla fine mi trovavo più a mio agio con Python che con PHP.E non riusciva a capire questo gap in questo passaggio.Sì, il gap nel tooling.Poi in realtà se ci pensiamo adesso, ovviamente col senno del poi è tutto più facile, ma arrivi una base di utenti molto più ampia sotto PHP, quindi ovvio che con un base di utente più ampia, il tooling evolva più in fretta, perché hai molta più gente che spinge per sentire meno dolore quando lavora.Sì, vero, e poi soprattutto secondo me una parte di questa necessità nasceva anche dal fatto della tipologia di aziende che utilizzava il PHP, che era una tipologia di aziende medio piccole, possiamo dirlo, anche se c'erano delle grandi.Se eri grande andavi a fare Java, se eri grande prendevi Java e andavi spada tratta con Java.Sì, medio piccole che avevano bisogno di tempi di time to market piccoli, corti.Non avevano risorse per poter fare tanta roba a mano quindi dovevano automatizzare il più possibile perché non ce l'avevano le scimmie da tastiera 50/70 che si potevano smazzare una verbosità del linguaggio come quella di Java o un set di tool non perfetti.Per avere un jar in Java, io mi ricordo quando facevo Java per le banche, per avere un accidenti di jar da dare alla banca, Ant girava per delle ore su un progetto un po' grosso.PHP la modifica di produzione era "uploada questo file" fatto, fatto, benissimo, abbiamo la nuova versione in produzione, non devo aspettare un mese per avere la build e poi uploadarla su un modem 566.Vero, verissimo.PHP aveva Giorgi Boggiano che è un chapeau perché è stato veramente il creatore di Composer e di Packagist, è stato veramente grandioso, quindi gli riconosciamo questo questo.Ma tuttora stai lavorando ogni tanto in Java perché la dieta in cui lavoro adesso ha alcune parti dei sistemi che sono in Java e quando salti da Python a Java a volte senti che il tooling, cioè i Maven che vuole fare tutto, però come abbiamo visto a volte conviene avere tanti tool che ognuno fa il suo lavoro fatto bene, manutenuto, che si muove con le versioni a velocità diverse, perché invece in Java è tutta questa cosa monolitica e poi come dici tu, di solito quando una ditta lavora con Java ha molti più programmatori di una ditta medio piccola e di conseguenza ti interessa poco se il tooling è faticoso da usare, perché alla fine hai talmente tanta gente che lo fa che non hai più bisogno di avere un tooling efficiente perché ci sono due persone che lavorano e devono rilasciare sto codice.L: chiaro, chiaro.Però adesso iniziamo a scaldarci.Inizia la prima domanda che voglio farti che è un po' cattiva.La prima domanda è "ma Python è lento?" DL: allora Python è lento dipende da quello ci devi fare e dipende come lo usi.Nel senso, Le prime versioni di Dropbox erano scritte in Python.Perché? La gente diceva "ma accidenti, in Dropbox devi gestire quantità di file immensi, come faceva ad essere fatti in Python".Se ci pensate, Dropbox cosa deve fare? Sintonizzare dei file via rete.E qual è la parte lenta? Leggere il file del disco e calcolare uno SHA o un hash o qualunque cosa? O trasferire il file attraverso la rete? Il problema è trasferire il file attraverso la rete.Quindi nel momento in cui tu stai aspettando questo transfer via rete, Python si va a fare i fatti suoi, fa altro, se tu scrivi bene il codice.Ovvio che se spari l'upload e poi lasci l'interprete fermo sulla riga ad aspettare che finisca, ovviamente è lento.Ma se tu, prima degli async/await che adesso ci sono in Python 3, già con Python 2 avevi comunque 3D processi, quindi se tu semplicemente spornavi un processo, gli dicevi di fare il suo lavoretto e nel frattempo andavi avanti facendo altre cose, poi il processo a sua volta quando aveva finito tornava indietro, ti sincronizzavi con lock, pipe, qualunque cosa volessi.Alla fine tutte le cose che richiedono un forte IO-weight, Python va benissimo.Nel momento in cui le cose diventano CPU intensive, eh sì, Python non è proprio il tool perfetto per fare crunching di numeri e fare della matematica.Però in realtà sono uscite librerie come Pandas e Dumpy e tutte le altre che fanno esattamente quello, ma come fanno? Sono scritte in C.Quindi il grande vantaggio di Python è che avendo questa interoperabilità con C, cioè tu puoi scrivere un programma C che ha un piccolo interpreter Python dentro o puoi scrivere una piccola funzione C da mettere dentro a un programma che gira in Python, quindi puoi fare piccolo C dentro tanto Python, poco Python dentro tanto C, quindi tu puoi scegliere tutte e due le vie, e a quel punto usi Python per fare l'orchestration dei dati, per gestire dove si muovono i flussi, e poi dopo smazzi i numeri in C, Go, Rust, che si possono scrivere estensioni per Python anche in Rust, anche in Go, fondamentalmente in qualunque cosa compilato, si diventano un pochino più problematiche la gestione delle dipendenze perché a quel punto si torna nel fantastico mondo, se usi C, delle dipendenze.Per esempio Go e Rust risolvono bene questo discorso delle dipendenze, quindi se non si scrivono le dipendenze in C, che poi comincia a avere problemi con il libC della macchina su cui e cose del genere, ma vai su Go e Rust e scrivi moduli per le applicazioni CPU intensive che vuoi fare con Python, alla fine tieni Python come colla, come orchestratore delle attività che succedono, scrivi una logica con un linguaggio più chiaro da rileggere, che è importante la rileggibilità, più sintetico e più compatto, fai le cose complicate con codice più complicato, però alla fine guadagni prestazioni.Poi con Python 3 hanno introdotto la Sync/Await.Adesso io l'ho visto usare ancora, io lo uso a lavorare perché facciamo API, con FastAPI lo usiamo in maniera Sync/Await che era un obbligatorio, puoi usare anche in maniera classica però poi hai quattro worker e servi quello che servi.Ti dico, abbiamo raggiunto delle buone prestazioni su delle macchine fino anche a 10.000 call al secondo servite in questa maniera e che funziona esattamente come funziona.appoggiare lo script ai tuo main loop, tu lanci le tue cose, se ti serve di aspettare la final wait, nel frattempo altre cose in realtà girano nel main loop e si fanno i fatti loro, quindi tu alla fine trasparentemente hai tutto quello che sarebbe altrimenti callback su callback su callback di chiamate, ma in realtà tu gestisci tutto il linguaggio.Lì devi solo stare un po' attento perché se fai time slip dentro una funzione che è asincrona, in realtà blocchi tutto il main loop, quindi devi fare la sync IO slip per avere uno slip che faccia comunque girare il main loop.Quindi a parte queste piccole accortezze che poi ovviamente quando lavori non lavori, di solito quando lavori, ad esempio mi dite anche come la mia, non lavori da solo, ci sono sempre colleghi che ti fanno il review del codice, a volte lavori molto, noi lavoriamo molto in pairing, cioè in due o tre anche a volte, che lavorano insieme su un pezzo di codice, quindi uno scrive e gli altri lo criticano.Quindi Python è lento se gli fai macinare numeri a lui, se però lo aiuti o strutturi bene il codice non è lento.Inoltre recentemente Microsoft ha iniziato un'attività, fondamentalmente a base di sviluppatori Microsoft, pagati Microsoft, a migliorare il core di Python, a migliorare l'implementazione C Python di Python, attraverso Just-In-Time compilation, qualcosa tipo i JIT di altri linguaggi.Adesso cominceranno, da quello che ho capito, con cose semplici, tipo "ok, ho chiamato questa funzione dieci volte, sempre con due interi.Facciamo la versione ottimizzata per gli interi di questa funzione, e poi dopo la comincio a usare.La prima volta che mi chiamano con una stringa, la butto nel rusco e torno a usare la versione generica".non c'è ancora fuori niente per quello che so ci stanno lavorando però il fatto che una ditta come Microsoft punti su Python un po' mi spaventa perché cosa ci vogliono fare e dall'altra parte sono contento perché ci mettono risorse umane che potrebbero introdurre come stato il V8 per javascript dei grandi miglioramenti.E tra queste risorse umane mi è sembrato vedere che adesso adesso c'è anche Guido Van Rossum, no? È stato assunto da quello che ho visto da Microsoft.È stato assorbito.È stato più una manovra commerciale, perché tu dici "ah, Microsoft l'ha assunto, allora adesso quello che farà Microsoft su Python sarà ovviamente certificato Guido Van Rossum e di conseguenza tutta la comunità Python sarà contenta, non andrà con i forconi e le torce alla sede Microsoft a cercare di bruciarli.Non so se sia più un effettivamente farlo lavorare perché cominciava anche a sua età, poveretto, la pensione a questo povero uomo.Il suo lato fatto.Il suo lato fatto.Il discorso marketing in relazione col pubblico e cose del genere.Dicevo che mi spaventa un po' perché ok, Microsoft investe fortemente nell'open, ok, e cosa ci vuole fare con l'open su questo ti faccio una domanda che sto facendo spesso questo periodo e voglio rilanciarla ma la facciamo alla fine dell'episodio perché in realtà ragazzi miei oggi Microsoft ha una bella fetta dell'esperienza della developer experience di molti di noi a partire da WS Code, il suo bel linguaggio TypeScript che io uso tutti i giorni e mi piace, e mi piace anche tanto a GitHub, NPM, cioè raga, di Asur, cioè di robetta ne ha nel processo, nella vita dello sviluppatore Capire un attimino quali sono le intenzioni può anche essere giustificato dalla nostra parte della barricata.Si, sta allungando i suoi lunghi tentacoli su tutta una serie di tecnologie che tu dici "va bene, oggi sono open, è vero che io posso dire se GitHub fa una cosa storta mi mi muovo su Bitbucket, su GitLab, mi faccio il mio server Git in casa, però alla fine ti perdi tutta l'esperienza di community che c'è intorno, i tracker, le Git Abation, adesso sto usando molto le Git Abation ultimamente, hanno ancora tanto da lavorare, la loro roadmap è ancora piena di cose da fissare, ogni giorno escono cose nuove che rendono inutili quello scritto il giorno prima.Però sono belle esperienze, sono bei tool, sono belle cose che funzionano e sono in mano Microsoft che notoriamente è stata per secoli, per secoli no, per anni scusami, contro qualunque cosa open, col suo sistema operativo chiuso.No, se vuoi scrivere per il mio sistema operativo devi comprarti questo kit di sviluppo da 800 euro, Visual Studio Code, "si, non studio code, viso studio e basta, viso studio enterprise".Anche perché Microsoft si muove con un criterio molto semplice, dove guadagno? Non lo fa per una scelta morale, cioè non è un onlus, Microsoft vuole fare dei soldi, quindi adesso ha valutato che avere una immagine pubblica migliore gli porta guadagno, perché fra una balla e l'altra, tutte questa gente che si muove nel loro ecosistema, vuol dire che qualcuno comincia a comprare i servizi enterprise di github, qualcun altro dice "beh vabbè ma a questo punto, visto che WSL su Windows è come se io avessi un Linux, non mi installo Ubuntu, mi compro una macchina con Windows 10 e poi ci metto il sottosistema Linux" e quindi sono due soldini di licenza che partono.La la gente, io usavo PitchArm, poi dopo VXCode funziona bene, io l'ho rimpiazzato.No, ma io lo uso tutti i giorni.Quindi ha tolto soldi ad altre ditte, che ok è gratis, quindi non ci guadagnano niente, ma sei sicuro che non ci guadagnano poi veramente niente alla fine ad avere questo parco utenti che si dicono "se esce domani l'integrazione con AWS che costa un dollaro al mese e ti file deploy automatici con pulumi direttamente da VS Code sul tuo cloud.Tu gli dici di no.Le dita glielo danno un eurino.E un eurino per 20 milioni di persone sono 20 milioni di eurini.Chiaro.Aiuto.Abbiamo aperto, scoperchiato un vaso di panorama.Scusa, sei parte di un'altra gente.No, no, no.Ma ripeto, è una domanda che ho fatto spesso.L'ho fatta a Matteo Collina, l'ho fatta al nostro amico comune Luciano.Ognuno ha un po' la sua visione, però fondamentalmente lo stato delle cose è questo.Diciamo che io al momento sono abbastanza tranquillo, ma tengo un occhio aperto.E questa è un po' anche la mia posizione, devo dirti la verità.Andiamo in lì di più leggeri, passando sempre per un mondo che anche quello presidiato da Microsoft, il gaming, no? No, scherzo.Parliamo di gaming e parliamo di Python.Sono due mondi che trovano un punto di contatto o stanno agli antipodi? Ma avendo appena parlato di prestazioni, uno direbbe "un videogioco gli chiede prestazioni, allora non posso fare un gioco in un linguaggio pesante".Poi ti viene in mente che Minecraft è stato scritto in Java.Minecraft che gestisce tutti i cubetti è stato scritto in Java e di fatti le prime versioni sono un mattone.Se tu pensi a cosa ti costerebbe rifare la stessa identica cosa a livello di prestazioni scritto in C direttamente, gestiresti una distanza visiva dieci volte maggiore renderizzando tutto e tutto si muoverebbe perfetto e cose del genere.In realtà, si è preso un linguaggio che non era nato per scrivere dei videogiochi e ci hanno scritto un videogioco, perché alla fine era l'idea che ha premiato, non la tecnologia.Con Python lo stesso discorso, EVE Online, che è un simulatore spaziale online grossissimo, è stato scritto in Python, stackless Python all'inizio, che poi si è evoluto in PyPy, una versione ottimizzata dell'interpreter Python, ma alla fine sempre Python si tratta.E loro come hanno gestito il problema? "Ah, niente, tu sei un'astronave in un sistema stellare, quando ti muovi fra sistemi stellari lo fai attraverso un salto, di conseguenza io faccio che ogni server è un sistema stellare, e quando ti salti da un sistema stellare all'altro, ti faccio cambiare server, tanto tu non ti accorgi perché sei ovviamente in salto, quindi il tempo di caricamento e di spostamento del tuo account da una macchina all'altra non se ne accorge nessuno, e poi dopo in questa maniera erano divisi sul carico usando un linguaggio che non sarebbe nato per gestire cose computazionalmente pesanti come tutta una simulazione spaziale, fra navi che si muovono, oggetti, asteroidi, pianeti, stelle, tutta questa serie di cose, però alla fine con questi trucchetti diciamo si sono saltati fuori.Poi avevano una modalità molto semplice, se c'era troppo gente nello stesso sistema stellare, perché ad esempio quando facciano gli utenti poi sono anche loro, gli utenti sono sempre utenti, cercano sempre di romperti il software e cosa facevano? Si trovavano tutti in tremila allo stesso sistema, intorno alla stessa nave e poi cominciavano due fazioni a spararsi.Il problema è che Python a gestire tutto il fuoco incrociato ralentava.Allora loro hanno detto "va bene, quando ci sono questi eventi si va in modalità tempo espanso".In realtà il tick di gioco diventa più lungo perché Python non ci sta dietro.Io ti faccio vedere la simulazione con questo tic di gioco espanso, i calcoli prima o poi finiranno, il tuo universo finirà e avrai il risultato della simulazione.Questo impattava poco i server dei pianeti e dei sistemi stellari vicini, perché erano da un'altra parte.Il tempo si disalienava un attimo, ma è sempre un gioco, ragazzi, non è un pacemaker.Poi ci sono moltissimi giochi che, come dicevamo prima, ma tu puoi prendere un po' di Python e metterlo dentro un grosso monolite, un grosso gioco scritto in C.E quindi ci sono molti giochi, fra Civilization, Vampire Bloodlines, anche Sims 4, che utilizzano Python per gestire gli eventi, le logiche.Perché è più facile, se io devo scriverti una IA per giocare a Civilization, è più facile scriverla in Python che scriverla in C.E alla fine è un albero di decisioni con alcuni parametri che vengono presi dalla mappa, valutati e che producono reazioni.Poi dopo ovviamente il motore NC gestisce tutta la grafica e la simulazione che c'è sotto e tutto il resto.Però sì, alla fine...E poi se entriamo nel campo non dei giochi, perché ho parlato di EVE Online, ma dei giochi ovviamente dove ci sono team immensi e richiedono anni di sviluppo.Se passiamo nel campo dei giochi indipendenti, ci sono tante piccole cose sviluppate in Python, anche Godot ha preso, non è proprio Python, è una sintesi molto molto simile, liberamente tratto da Python e lo utilizza come linguaggio di scripting interno, perché appunto devi dare a chi fa giochi qualcosa di alleggerito, perché oggi giorno è già abbastanza difficile avere l'idea di gestirsi le grafiche e produrle, perché poi se uno non è artista, ci sono giochi fatti da una persona sola che deve fare tutto, musica, sprites o modelli 3d, programmarli insieme eccetera eccetera, non puoi pretendere che abbia l'expertise per scrivere un programma in C e deve fare anche tutto il resto.Quindi bisogna che gli alzi un po' la strazione a queste persone.Poi ovviamente ok, questo gioco diventa popolarissimo e spacca, ti compra Microsoft e lo riscrive.Chiaro, con un game engine.Sì, dopo una volta che tu hai il concetto il gioco è passato.Comunque con le macchine che abbiamo adesso, anche sui cellulari che abbiamo in tasca, ragazzi, sono delle potenze devastanti.Se uno deve fare un gioco può farlo anche girare su un interprete, non c'è bisogno di compilarlo.Chiaro, e poi tra l'altro ho visto che tanti giochi, come dicevi tu, hanno le interfacce per le mod direttamente in Python.Mi viene in mente, sempre per ritornare a Minecraft, se non ricordo male, è programmabile con Python.Mi sembra di aver visto qualcosa del genere in un un video didattico del mio amico Mario di Mondo Computazionale dove andava proprio a disegnare il mondo con i blocchetti col Python, con i bei cicli for di una volta.Ma vedi, alla fine l'interpretation di Python è stato portato anche in Java, ovvio tu metti una cosa interpretata dentro una macchina virtuale che produce bytecode, cioè stai veramente ha aggiunto tanti star rati di astrazione e ogni volta che aggiungi uno strato le performance si suicidano un pochino.Però alla fine dai una comodità alle persone che poi è tutto quello che c'è adesso nel mondo dello sviluppo.Pensa se dovessi fare un blog come si faceva una volta in Perl, in CGI, gestendo tutte le chiamate, ti ci vuole tre mesi.Adesso per fare un blog con Django lo installi, gli dici "blog" ed è fatto.Import blog, finito, hai il tuo blog.Quindi bisogna capire quando l'astrazione ti viene utile o quando l'astrazione ti danneggia.Poi ovviamente adesso si sta molto volte, la gente va dalla parte opposta, cioè esagera con le astrazioni o esagera con le dipendenze e poi succedono delle cose come il left pad di javascript che uno toglie da npm e metà dei siti del mondo vanno giù.Esatto, beh quello che è anche forse è stato anche sintomatico di un approccio al mondo che poi si è visto nel mondo javascript che era l'uso della libreria compulsiva.Sì esatto, lì ci vuole un po' di buonsenso.So che il buonsenso è un superpotere, c'è talmente poco in giro che è proprio un superpotere, però bisogna imparare a usarlo quando si fa gli sviluppatori di software, perché rischi di andare a metterti in un angolo da cui fai fatica poi a muoverti.Una cosa molto carina di Python, secondo me, tornando al discorso Python, JavaScript e ambienti e dipendenze, Python ha il concetto di batterie incluse, cioè il core di Python ha un sacco di librerie già dentro.Facciamo un esempio, nel Python 2.4 non c'era SQLite.E tutte le volte io installavo SQLite su Python 2.4.Con Python 2.5, mi sembra che fosse quel passaggio 2.5, hanno preso SQLite e l'hanno messo dentro nel core.E quindi hanno cominciato a prendere dentro il core librerie esterne e allargare questo.Invece in JavaScript c'è la teoria inversa.Io tengo il linguaggio snello e se voglio anche fare un left-fad una libreria esterna che io vado a importare.Mi trovo un po' meglio con il concetto di Python, anche perché ho fatto molti script per gestire server e quando tu ti trovi comunque su un server Linux e sai che c'è Python, tu sai che hai già tutta una serie di base di librerie per fare quello che ti serve.Se ci fosse già stato JavaScript con la loro teoria, anche il server con solo javascript installato, con solo node per esempio, sarebbe abbastanza inutile perché sì, devo fare una richiesta HTTP, allora devo fare un PM install della libreria per l'HTTP o questo o quello.Diciamo che Python da questo punto di vista, delle batterie incluse, è una filosofia che preferisco.E poi possiamo dire anche che il Python per tanto tempo è stato, per la sua semplicità, per la sua asciuttezza, per il suo essere così draino, una lingua franca.E questo l'ha portata a diventare un linguaggio cardine anche nel processo delle interview, giusto? Dico bene? Sì, la distanza fra un pseudocodice e il codice Python, se uno non fa cose esoteriche con Python.E' molto breve, cioè tu puoi fare un'interview, una volta l'interview quando ho cominciato a farle io si facevano solo in pseudocodice, non scrivevi veramente C, non scrivevi veramente Java, perché graffe, punte virgola, eccetera, eccetera, eccetera, su una lavagna ti scordi qualcosa e poi è un gran casino.Quindi quando se facevano le interviewe, ai miei inizi quando le facevo anch'io, le facevano in pseudocodice.Dopo è saltata fuori la tendenza a farle con codice vero, cioè scrivimi codice che realmente può funzionare.Questo perché quando facevano le interviewe in pseudocodice molto spesso si testava più che le capacità di scrivere codice una persona, le capacità, la memoria accademica dell'argomento, dell'algoritmo, che voglio dire se io mi trovo a lavorare e mi riconosco che mi serve un albero binario, non devo ricordare la memoria, ho dei libri, ho internet, mi guardo esattamente quale tipo di funzione sull'albero binario mi serve e la uso.Saperla a memoria mi serve veramente poco, mentre invece saper scrivere del codice che funziona, saperlo debuggare a occhio è molto importante invece come abilità, ma non puoi debaggare a occhio del pseudocodice perché tu puoi fare, puoi disegnare, scrivere cose che "ah sì, questo qui prende l'albero e lo ruota a 90 gradi, sì, grazie, divini allora che questo qui risolve il problema e punto".Quindi il fatto che Python sia molto vicino e molto pulito a questo pseudocodice nelle interview io mi sono sempre trovato a fare dopo, quando ho cominciato anche con Amazon, Amazon Wallet Interview, fate in un linguaggio che possa essere compilato e funzionato.Te lo fanno fare su una whiteboard, io l'ho fatto su una lavagna, e poi dopo loro se lo fotografano e poi probabilmente a casa se lo riscrivono e lo provano a far girare per poi valutarti.Quindi il fatto di poter non dedicare la tua attenzione a ricordarti 32 apparentesi graffe aperte, 28 punte virgola, i tipi davanti ad ogni variabile, perché poi anche scrivere tipizzato su una lavagna è dura, perché poi ti viene "ah, aspetta, devo cambiare tipo, perché ho messo un hashmap di stringa interi, ma adesso mi serve da interi e interi, ah, mi sono sbagliato", e cominci a cancellare, fare.Quindi un linguaggio che parte non tipizzato come Python ti dà il vantaggio, che poi è divisato dinamico, ma è comunque forte, cioè non è come javascript che tu dici a=a stringa con 1, a+1 e diventa 11.In Python comunque se provi a sommare tipi diversi si arrabbia, pur potendo assegnare qualunque tipo, riassegnare tipi diversi alla stessa referenza, alla stessa variabile.Quindi per l'interview mi sono sempre ho trovato meglio a farle in Python.Anche intervistando la gente, quando vedo che usano Python vedo che ci concentriamo molto di più sul concetto e sul problema che stiamo cercando di risolvere.Quando invece la gente le fa in altri linguaggi, tipo per esempio Java, vedo che a volte ci tocca di fermarci, dobbiamo andare a googlare come si fa un comparatore per ordinare un array quando fai il sort che devi scrivere il comparator.Ovviamente non te lo ricordi perché intanto scriverai due comparator l'anno e poi quando vedi la sintasi sono sei righe di codice e ovviamente devi googlare.Infatti la domanda è su quanti pennarelli ci vogliono per un'interviw fatta in java con la sua verbosità.Esatto, e quindi fatto di avere un linguaggio che devi scrivere tanto distoglie la tua attenzione da quello che devi fare, che è risolvimi questo problema.Se tu mi risolvi questo problema io ti assumo, se tu non me lo risolvi perché la ora che abbiamo di colloquio, mezz'ora, è googlare i sintassi di Java.Cioè noi nell'interview facciamo sempre googlare perché ovviamente noi non pretendiamo che la gente sappia a memoria le cose.Google e comunque Stack Overflow o qualunque altra cosa, è una risorsa che quando lavori hai, quindi perché non devi poter fare l'interview con la stessa risorsa? però il vantaggio di Python è che ti concede di concentrarti sul problema e non sul linguaggio.chiaro, assolutamente chiaro.tra l'altro una cosa che ritorna spesso è il fatto di vedere vedere python sia nel mondo accademico quanto nel mondo della didattica.Questo è dovuto sempre allo stesso motivo o c'è anche qualcos'altro che ha avvicinato questi questi mondi al linguaggio di zio Guido? Python, vorrò assumere visto che l'hai citato, prima di lavorare su Python lavorava su un linguaggio chiamato ABC, sviluppato in Olanda, scusate nei Paesi Bassi, Olanda è una regione, ed era un linguaggio puramente didattico.Perché se ci pensiamo, i linguaggi didattici dopo il Pascal non li abbiamo più visti.Cioè, il Pascal era nato come linguaggio didattico, ovviamente con tutti i problemi di essere un linguaggio degli anni S60, S70, però dopo di esso, ok, sì, la gente insegnava in Java, insegnava in C, ma è pesante insegnare, cioè tu devi già imparare gli algoritmi e come diciamo prima, li devi imparare dopo che ti scontri anche col mondo di "ricordati di allocare memoria e di disallocarla" o "ricordati come si scrive questa sintasi con 28 tipi diversi".Quindi nel momento in cui tu stai imparando a programmare che non è mai una cosa semplice, entrare nella forma mentis del programmatore, il fatto di poter usare ancora uno strumento che non ti aggiunge complessità ulteriore, che te ne aggiunge un po' ma veramente è indispensabile, l'ho fatto diventare un ottimo strumento per la didattica in quanto inoltre nasce da un linguaggio nato per la didattica.Quindi diciamo che si è tirato dietro anche probabilmente un po' di persone che lo hanno cominciato a utilizzare agli inizi per didattica e poi dopo è andato avanti.Per didattica hanno preso poi su tutta una serie di altre attività tipo Raspberry Pi, Python ci è già installato nel Raspbian, quando tu hai il tuo bello oggettino da 5 dollari, lo fai partire e hai il tuo bell'interpreter Python e puoi cominciare a scrivere codice.hanno fatto micro python e circuit python per i circuiti integrati e qui torniamo anche un po' al discorso delle performance.Python è lento e usa tanta memoria? Sì, usa ovviamente più memoria che una cosa scritta in C, per forza, ha dei costrutti in più, però alla fine su una cosa come il Raspberry Pico che ha 200 e rotti 256K, 264K di memoria o comunque una cosa del genere, e dopo che è partito l'interprete, tu hai il prompt dell'interprete, è usato solo 100K di memoria, quindi tu hai ancora 140K, 160K di memoria buona per fare le tue cose e quando lavori su un circuito integrato è tanta roba.Però questo dà la possibilità a gente che magari avrebbe la difficoltà di imparare il chip per scrivere su questi microcontrollori, gli dai la possibilità di scrivere in un linguaggio ancora ad alto livello dove se tu dici "LED on" il LED si accende, "LED off" il LED si spegne.Non dove devi caricare in un registro l'indirizzo della porta su cui mandare il bit, caricare in un altro registro che bit vuoi se è acceso o spento, ricordarti di settare il bit di direzione del pin in entrato e in uscita, mandare fuori tutti i tuoi bei bittini.Poi non ti vieta, nulla ti vieta di scendere a quel livello una volta che tu hai cominciato a lavorare con Python a quel livello, perché ancora Python ti dà la possibilità di avere cose compilate.Ad esempio in MicroPython, molto carino, nelle ultime versioni tu puoi dichiarare delle funzioni e dichiararle in assembler dell'ARM a 16 bit, oppure le puoi addirittura dichiarare con un decoratore che si chiama Viper, Python Viper, sempre serpente si tratta, e Viper ti ottimizza per gli interi, visto che i registri dell'ARM sono interi a 32 bit, ti ottimizza per il lavoro su interi, cioè tu puoi solo passare a parametri interi e restituire interi.Però tutto quel pezzo lì viene in realtà compilato in qualcosa che rimane già interi, non è più interpretato, è compilato.Se tu scrivi la tua funzione in assembler, fa esattamente quello che dici tu.Tant'è che quando ci giocavo un po', mi sono sbagliato, ho scritto un'istruzione, non funzionava, mi è esploso in faccia e mi ha fatto un dolore.quindi, senza copiantato secco alt, finito lì, ok, riavviamolo e vediamo cosa ho sbagliato.Quindi ti dà questo vantaggio di poter entrare facilmente, perché la curva d'apprendimento del Python è molto molto facile a prenderlo, e poi hai la possibilità di entrare veramente nei tagli, nei cavilli del linguaggio, puoi arrivare a dei livelli molto, anche di basso livello, livello.Però ovviamente se tu vuoi partire e tu dici "no, no, ma io mi accontento di questo, mi accontento di far rampeggiare tre led e di gestire l'irrigazione delle piante", poi se anche l'irrigatore delle piante si apre un secondo dopo, la pianta non muore, se la irrigo per un secondo di più o di meno, perché la routine che controlla se è abbastanza bagnata il coligometro mi arriva un secondo in ritardo.Poi dico un secondo, ma in realtà si parla comunque di millisecondi.Ovviamente se io devo fare un aeroplano, non uso un microcontrollore con MicroPython per fare i sistemi di bordo di un aereo.Lì siamo in una...è come il pacemaker, il pacemaker vorrei che girasse più in hardware e più in C possibile.Anche se poi anche lì ci sono storie di macchinare per radiazioni scritte in C con dei bug che hanno quasi ammazzato la gente, ma questo è un'altra puntata.No, fantastico, in realtà Python è molto di più di quello che sembra e l'ecosistema è vastissimo, come sappiamo.Tra i vari elementi dell'ecosistema non possiamo non citare Flask o Django.e qua mi porto appresso una domanda che avrebbe voluto farti Carmine ma non è non è riuscito ad arrivare per tempo Carmine viene dal mondo ruby in genere e dice e chiede se Django è associato uno a uno anche come sensazione al mondo della prototipazione, un po' come può essere Rails, no? Oppure approccia in modo diverso, quasi più, passatemi il termine, production ready? Django è un ottimo framework per Python, Diciamo che Rails sta a Ruby come Django sta a Python.Ed è più che essere una cosa per prototipazione, ce la faccio dirlo, è anche una cosa per production ready, cioè io ho bisogno di un sito di complessità media o semplice, che però mi dia la possibilità di andare con delle pagine in produzione rapidamente, mi dà la possibilità di potermi gestire i template facilmente, gestiti con i template creati da altro server, un po' alla vecchia, un po' come si faceva poi con PHP, però rispetto a PHP dove il template faceva tutto, dal caricare i dati, formattare i dati e tutto il resto, perché si poteva fare roba o scena, Django dà molta più struttura a tutto questo.Poi dopo, molto bello, ricordo che la prima volta che lo vidi...oh mamma mia, ormai sono quasi più di 10 anni fa, sono vecchio...comunque, quando lo vedi più di prima volta era fantastico il fatto che avesse queste interfacce di admin già pronte.Anche perché a metà del mio tempo andavo a fare interfacce di admin in Delphi.Quindi, Pasquale, sì, quindi, ah, ma io ho il database, ho collegato Django tramite SQLAlchemy al mio database e lui mi fa già da solo tutte le maschere di admin, ci sono già tutti i dati, gestisce le forain key, perché io lo sto scrivendo tutto a mano questa cosa, che questo tool magnifico me lo fa in automatico? Però ha anche il vantaggio di, finché sei medio, perché poi si comincia a crescere troppo, comincia a non essere più adatto.Però ad esempio una cosa che mi è capitata di fare una volta è di dire ok, la parte di front end va assolutamente rivista, dobbiamo andare verso single page application in React, dobbiamo scegliere React al tempo, cioè andare verso una single page application in React, ma dobbiamo prendere i dati fuori da da Django, come possiamo fare? Ah, niente, abbiamo preso un flask, l'abbiamo attaccato al database di Django e flask faceva la parte di API, Django ti serviva la single page application che poi parlava con l'API e la parte di admin comunque è rimasta tutta quanta sotto Django perché in fine nell'admin di un sito normale, di un CMS, di un qualunque applicazione non hai 20.000 utenti che lavorano sull'admin, sull'admin ci lavorano in 5, cioè quelle da una ditta piccola o media, ci lavorano da una persona a cinque persone.Quindi di conseguenza l'admin andava bene, anche se era un po' pesantuccio.Invece per la parte di frontend, se vuoi smazzare tantissima gente, devi cominciare ad avere la single page application, dove poi si tiene conto di tutti i problemi di rete, caching per servirla, cdn per servire la parte javascript e tutte le immagini, le API che sono sì veloci, però alla fine tengono il payload più piccolo possibile in maniera di poi aggiungere GraphQL per avere il minor numero di chiamate possibile.Ma quello poi entriamo nella...Bellissimo, ho fatto una presentazione e GraphQL per me da adesso in poi sono le Spice Girls, no? "Tell me what you want, what you really really want".Non so se ti ricordi quella canzone obrobrioia degli anni '90.Quella è Graf Quell.Con i problemi del caso, però comunque evidenzavi lo stesso problema che portava a Carmen, cioè quando l'app diventa grande e non è più un prototipo, una roba rapida, deve scalare x gozziliardi di richieste, a quel punto forse Django, Symfony, Rails non sono la soluzione adatta e bisogna di qualcosa di più.Lì bisogna concertare anche con i DevOps l'infrastruttura in maniera di...diciamo che lì il programmatore deve cominciare a ragionare un po' anche dal DevOps e dire "sì, io scrivo codice, ma poi i codici devo deployarlo da qualche parte, cioè io scrivo codice ma io devo sapere che il mio codice è concorrente con altre 38 istanze dello stesso codice e quindi non è che posso andare sul database, fare un update e fatto, perché se nello stesso momento me lo fa qualcun altro i dati saltano per aria".Quindi devi cominciare a quel punto a cominciare a ragionare molto più a sincrono e a sincrono, concorrente.Se vuoi chiamarlo a microservizi, mi piace proprio usare il termine a microservizi perché adesso è un po' inflazionato come termine.Adesso il microservizio sembra la soluzione a tutto, no? Tu prendi un monolite strutturato male, lo porti ai microservizi e tutto va bene.Il problema è che tu prendi un monolite strutturato male, lo porti ai microservizi strutturati come monolite, cioè male, e invece di avere 300 milioni di chiamate interne fra pezzi di codice hai 3.000 chiamate fra servizi di rete diversi.Il problema è che dentro il monolite la chiamata funzionava sempre, sulla rete la chiamata non funziona sempre.Stai evidenziando una cosa che io ripeto sempre.Alla fine non esiste il silver bullet che tu dici "oh questo approccio mi risolve tutti i problemi del mondo" e comunque ti dirò una cosa e magari ci rivedremo tra cinque o sei anni e ne riparleremo, il monolite tornerà di moda.Ma perché il monolite? Ora, se tu prendi un monolite strutturato male, quello che viene chiamato "big ball of mud", la grande palla di fango, e ci guardi dentro stai male.Ma per andare ai microservizi.Il primo passaggio da fare è prendere questo monolito non strutturato, strutturarlo, quindi cominciare a dividere i pezzi di codice che facciano il meno numero di chiamate possibile fra di loro, che abbiano competenze ben definite.Io so che è difficile, ma devi parlare con la gente che fa il processo in azienda e capire che cosa gli serve veramente, perché a volte c'è roba rimasta lì, codice morto, roba rimasta lì da dieci anni prima, Una volta che tu ristrutturi il monolite, così a quel punto puoi migrare ai microservizi.Il problema è che una volta che il tuo monolite è stato ristrutturato così, spesso non devi andare ai microservizi, perché a quel punto il codice è di nuovo manutenibile, chiaro, documentato, hai ridotto le righe di codice.Il bravo programmatore non scrive righe di codice, il bravo programmatore le rimuove le righe di codice.E una volta che tu ti trovi con questo monolite fatto bene, dici "ma sai che io sto col monolite fatto bene, che funziona, è più facile da scalare perché lo rimetto uguale su un altro server".Fatto, non ho bisogno di andare a fare i micro servizi, che poi hai bisogno di un orchestratore di micro servizi.Cosa succede se questa chiamata fallisce a metà della registrazione di un utente? Eh, non registra l'utente.Ah, quindi devo dire ai servizi prima di fare l'undo di tutto? Invece con un monolithe su un database, apri la transaction, fai le tue cose, fallisce, rollback, fatto.A quel punto il monolithe può avere il suo senso.E' che spesso ci facciamo catturare dall'hype, dell'architettura nuova, della tecnologia nuova e ci caschiamo.Ha poi i suoi vantaggi perché sul monolithe gli unit test magari prendono 40 minuti, quando hai tanti micro servizi i test girano in 30 secondi, però se tu hai dei buoni test del monolite che lanciano solo i test del codice che hai toccato e fanno i test completi solo prima del deploy in produzione per esempio ottieni lo stesso effetto e che devi investire un po di più nel tooling.Chiarissimo, altra domanda sempre di Carmine è Python e i tipi A che punto siamo? Sei d'accordo o la cosa ti puzza di bruciato? Allora, qui sono un po' obbligionato.E' quello che volevo, no? Allora, Python e Nisi mi piacciò, mi piacque, mi piacciò.Bellissimo.Scusate, il mio l'italiano è diventato un'option.Ti capisco.Stavo dicendo, all'inizio mi piacque perché non aveva i tipi, io potevo, avendo fatto molto C, avevo un po' il vomito a vedere un tipo.Mi piacque perché puoi dichiarare la variabile, la usi, non la usi più, ci pensa lui a buttarla via, tu sei tranquillo, non dei fare niente.Sono pigro, sì, sono pigro anche a disallocare la memoria, benissimo.Al tempo ero uscito da un progetto in C++ che faceva memory leak, ragazzi, come un matto, ma parliamo che dopo un'ora che era aperto c'erano gigabyte di memoria buttati nel rusco e il cliente doveva spegnere, chiuderlo e riavviarlo.E andare a trovarli tutti era un vomito.Quindi, vedendo un linguaggio che non dovevo fare niente di tutto ciò, per me era bellissimo, garbage collector, questa meraviglia, magnifico.Adesso, con Python 3, comunque il typing sta diventando un po' più integrato, Python 2 ormai non c'è più, dai ragazzi, usiamolo per favore, se fai tutti e tre, fine.Subito non ero molto a favore dei tipi, però a lavorare un collega ha cominciato a spingere molto per usarli, abbiamo cominciato un po' a usarli, ho detto sì, però ragazzi cosa servono? Tanto l'interprete non li caga, servono a noi per ricordarci che gli devi passare una stringa, servono a noi per ricordarci che gli devo passare intero, servono a noi per ricordarci che gli devo passare questo tipo di classe o di oggetto, data class, che contiene questi tipi di campi.Alla fine, me lo ricordo, ho i test, se gli passo l'oggetto sbagliato, i test fuma e io mi accorgo che ho fatto una cosa sbagliata.Però devo dire che annotare i tipi da solo, sì, non ha senso, perché guadagni molto poco, alcuni idesi ti aiutano però alla fine hai poco vantaggio.Abbiamo cominciato a lavorare a usare MyPipe, che è una libreria giuntiva che fa un controllo, è lenta, quando tu lanci MyPipe su un pezzo di codice ci pensa tanto e ci mette del tempo, ma ci mette del tempo perché si fa un grafo interno di tutti i tipi, di tutte le chiamate e ti dice se alcuni tipi non sono congruenti e qualche volta ci ha salvato, nel senso che i test erano verdi ma il tipo era sbagliato e guardandolo, accidenti questo è un errore logico, cioè quindi non ci ha salvato da errori di run time, perché run time sarebbe andato, il codice avrebbe fatto quello che avevamo scritto, e poi ormai avrà scritto una stupidaggine e quindi il computer fa quello che gli dice di fare e lui l'avrebbe fatto, però semanticamente era sbagliato.Finché il progetto è piccolo o medio, probabilmente annotarlo serve più per chiarezza mentale di chi lo vuole fare, poi annotarlo solo in parte e non integralmente, e così via.Nel momento in cui il progetto diventa un po' più complicato e ci metti dietro un tooling che usa i tipi per fare controlli, a quel punto diventa utile, devo ammetterlo.Però bisogna ricordarsi di metterci un pre-commit hook, che ogni volta che tu provi a fare commit ti lanci.Formatazione con black, controllo dei tipi con mypy, se vuoi fare il fighetto c'è i sort per ordinare gli import, così sono tutti uguali da tutte le parti e cose del genere.Se tu metti insieme tutto questo tooling, quindi hai una base di tooling e quindi non puoi farlo per un progetto di sei righe, se non lo fai per uno script che deve prendere i dati dal punto A e copiarli nel punto B, quello lo fai e basta.Se però tu fai tutto questo e magari lo metti anche nel tuo docker file, così quando fai la build dell'immagine lui comunque si fa tutti i suoi controllini prima di controllare le immagini, a quel punto comincia ad avere valore.Ovvio che tu fai tutto questo tooling, infrastruttura, la metti su, non per il progetto che dicevo da tre file, lo fai per un progetto che debba...tipo per le API è utile perché quando hai delle API che devono muovere molti dati, puoi controllare i tipi di entrati, i tipi di uscita, poi hai anche Pydantic che ti controlla e ti fa tutto il parsing, che è veramente strict, e poi poi ti scontri con l'altra parte della UI in JavaScript che cerca di mandarti...ma è merda! e tu dici "eh, a me non posso passarlo questo JSON, perché questo campo email non è una email valida" "eh certo, mi hai mandato una stringa vuota" "eh però o non mi mandi l'email o me la mandi che sia valida" "no no, ma io ti mando un email con la stringa vuota" "vabbè, aggiungi le sezioni di Pydantic con il validatore che il campo può essere vuoto se..." Sì, diciamo che una volta che cominci a entrare nel discorso dei tipi, a volte scrivi del codice solo per far funzionare i tipi, però hai dei vantaggi sul controllo di non fare stupidaggini, come dicevo, di non passare i dati sbagliati in giro, di avere una risposta sempre uniforme e cose del genere.mi sono un po' rivisto con l'adozione di TypeScript, io venendo dal mondo JavaScript sono passato a TypeScript e devo dire che ad oggi mi trovo a lavorare in una in una codebase importante, grossa, ma grossa molto, anche di codice scritto col martello e i tipi alle volte aiutano.Sì, ti salvano.Poi ti dico, adesso sto studiando anche Rust, perché è il prossimo linguaggio che voglio imparare, e c'è il modo di fare le cose tipizzate senza dover scrivere la classe sei volte? Rust è bello a volte perché il compilatore, tu gli dici "ok, crea questa variabile, poi assegni un valore a questa variabile e lui retroattivamente imposta il tipo della variabile.Non devi ricordarti di dichiararla tu come vuoi e poi dopo, se non la dichiari della maniera giusta, gli assegni il valore sbagliato, devi tornare indietro, cambiare il tipo e rifare il "new", in altri linguaggi di cui non facciamo il nome.Quindi sì, i tipi hanno la loro utilità.Certo che quando devi fare un prototipo non dover riscrivere l'aiuta.È vero, è vero.Ci sono delle cose che con Python, o come dice Matteo, per JavaScript vale la stessa cosa.Alle volte non dover combattere quei tipi ti rende più produttivo in una prima fase, nel senso che prendi, butti giù la roba e gira e se gira va bene, siamo felici tutti.Il problema è quando arrivi negli edge case che li devi individuare e allora vai o di break point se sei fortunato oppure vai nel caso di javascript vai di console.log Lì c'è anche un po' il discorso sui prototipi che ad esempio una volta mi aveva dato un'azienda che mi dicessero "ci siamo scordati di creare questo servizio aggiuntivo, domani spegniamo il vecchio portale e non abbiamo l'endpoint che fa questo calcolo, come possiamo fare?" "Ah, niente, lo butto giù in Python, in Flask, in mezz'ora, senza niente, senza nessun guardrail intorno, perché deve fare quello, lo mettiamo in produzione così voi potete spegnere il vecchio sistema, però poi ci torniamo dietro, vero?" ADD, Kamikaze Drive Development.Ti dà il vantaggio di poter fare un prototipo in produzione in maniera molto rapida, però poi devi sapere che non puoi tenerlo lì per sempre, dopo devi parlare veramente con il project manager e dirgli "no, no, quando io ti chiedo un giorno per eliminare il technical debt, tu me lo devi dare, perché se no qua salta tutto operare domani.Chiaro, assolutamente sì.Il tempo sta volando e stiamo andando lunghissimi, però io ho ancora una domanda, te la voglio fare.Ecosistema, qual è il toolset, la cassetta degli attrezzi che ti porti appresso quando lavori con Python? Ma, ti dicevamo prima che usavo PyCharm, però devo dire che adesso VS Code ha fatto un lavoro fantastico, come editor, come plugin, ufficiali Microsoft per Python sono fatti benissimo, anche per Rust, c'è la roba, ragazzi, ti suggerisce come migliorare il codice, le sessioni live, quando fai pairing con i cursori multipli, il fatto di poterlo far girare anche come un browser.Cioè io ho un server, non faccio più ssh nel server, vado sul terminale, vado sul su vs code web, metto la password, entro, apro il terminale lì, perché ho il mio codice pronto, ho il mio terminale, faccio le mie cose e sento una cartella che ha un virtual environment, lo attiva, quindi non mi devo neanche ricordare di attivarlo io.Sì, mi stai pigrendo, ammetto che mi sta viziando come cosa e mi rende più pigro, però il fatto che faccio tutte queste cose da solo ti aumenta la produttività.Ti fa perdere un po' il contatto rispetto a quello che sta realmente succedendo sotto, quindi quando hai un problema devi ricordarti che dove stai girando e cosa ti sta girando sotto, per metterlo a posto, ma devo dire che 95% delle volte ti aiuta.Poi per Python adesso c'è Poetry che è un ottimo gestore delle dipendenze.La uso ancora Ppenv perché sono vecchio e le abitudini vecchie sono dure a morire.Quindi quando ti trovi bene con un tool, funziona bene, è comunque abbastanza testato, ha prova di bomba.A muoverti in quello nuovo aspetti.Aspetti che prima ci vado nei giovani, si rompono un po' le ossa, lo mettono a posto, poi arrivi anche tu.Quindi mi tengo P-PEV, mi tengo il mio VS Code con tutte le estensioni del caso, installo sempre come dicevamo PreCommitook, MyPy, Black, io sono della teoria che ho cominciato a prendersù quando ho cominciato a fare Go, GoFmt.Perché dobbiamo avere una guerra di religione su dove mettere la graffa, a fine della riga o a capo, non me ne frega niente.Io lancio GoFmt su tutto il codice, lui me le mette dove vuole lui, a me va bene perché non devo più litigare con le persone, perché nelle mie PR, nei mie pull request non ci sarà più la graffa, tutte le graffe del file a capo perché è arrivato uno che ha l'intrasettato diverso.Quindi per Python uso Black che fa la stessa identica cosa che ti mette il codice come dice lui.Non mi interessa com'è, l'importante è che sia uguale per tutti.Perché quello era veramente tempo perso.Mi ricordo quando lavoravo per le banche, le ore perse a discutere sullo style guide.Ma ragazzi, ma noi eravamo pagati per scrivere codice, non per decidere come scrivere codice.Questa gente ci ha pagato due ore di riunione per decidere dove mettere una graffa.Se lo vengono a sapere ci uccidono, ci danno fuoco.Se vengono a sapere che abbiamo speso del tempo a decidere dove mettere un punto e virgola e una graffa.Quindi mi tengo questi tool normalmente nella cintura degli attrezzi, poi ovviamente cerco di tenermi aggiornato con le librerie, ovviamente installo sempre requests, storie interessanti di requests, volevano metterla nel core di Python, ma quelli che sviluppano request gli hanno detto "no, voi rilasciate troppo lentamente per noi".Ok, può essere vero, puoi aver ragione, però spero che un giorno, quando request rallenterà la velocità di release, magari la infilano dentro al core in Python 3.10, lo so, una cosa così.Ci spero sempre che aggiungano più e più librerie dentro al core, perché come dicevo prima a me piace avere il mio bell'interprete cicciottello che fa già tutto e io devo scrivere tre righe di codice e ho già il risultato senza scrivere 65 righe di file.Un po' si sente l'influenza di Go su questo.sì, ok.La gestione di Go ha avuto delle tribe sui module, il vendoring e devo dire che ho smesso di usarlo nell'ultimo anno quindi mi sono un po' perso dove stia andando adesso, però il fatto di poter fare Go Get a me piaceva.Go Get from GitHub, perfetto, fatto! Roberto, siamo andati lunghissimi ma finalmente un po' di Python anche a Gitbar, quindi ti devo ringraziare per averlo portato, ma non ti lascio andare, almeno non prima di averti chiesto un'altra cosina noi nel nostro podcast abbiamo un momento che è tipico e topico come dico sempre no che è il momento il paese dei balocchi cioè il momento in cui i nostri ospiti ci suggeriscono una lettura un video una libreria una qualunque cosa che possa essere che è stata importante nel loro percorso professionale e/o Tu hai qualcosa da suggerirci? "E conduco nel paese dei balocchi" "Ah, il paese dei balocchi" Guarda, parlando di Python potrebbe essere ovviamente un suggerimento da poco, perché molti lo conosceranno già, ma Raymond Ettinger, che è uno degli sviluppatori del core di Python, ha un sacco di video su YouTube e spiega le cose benissimo.ci crede tantissimo, è proprio un entusiasta, e spiega le cose semplicemente.Quindi anche se uno non è un grandissimo esperto di Python e si approccia per le prime volte, ci sono dei video bellissimi in cui spiega gli errori che fanno le persone quando si muovono da un altro linguaggio a Python, cioè magari fare dei for numerici per lavorare su degli elementi di una lista, non usare le numerate per avere gli indici numerici, e quelle cose lì.Poi ci sono altri video in cui spiega gli internal di Python, ma invece che spiegare gli in-sheet li rispiega in Python.Lui ha scritto il nuovo dict che è stato introdotto, penso, nella versione 3.5 o 3.4 di Python, che cambia un po' come vengono gestiti i dict.In Python è più svelto, usa un po' meno memoria.Considerando che in Python tutto è un dizionario, questo per uccisare il linguaggio, il suo primo prototipo era scritto in Python, quindi lui ha scritto il dizionario Python in Python per far vedere che funzionava e che era idempotente con quello che c'era già implementato in C.E poi dopo è stato poi implementato in C, poi nell'interprete alla fine.Però lui spiega benissimo.Quando tu lo senti spiegare, dici "eh beh, cazzo, era così semplice, perché non ci ha pensato nessuno prima?" Poi dopo due ore che hai visto il "Com'è che era che lo spiegava? Non mi ricordo più come funziona"."Ma te che me lo riguardi?" "Lo riguardo?" "Dici, oh, accidenti, è semplicissimo, come ho fatto a scordarmelo?" Cioè, ha la capacità, quando ti spiega le cose, di fartele sembrare semplici, poi te le scordi dopo mezz'ora, ma quella è colpa tua che non sei lui, fondamentalmente.Quindi Raymond Ettinger, Colacca, mi Hettinger, scusate la pronuncia oscena, YouTube, c'è tantissima roba, seguitelo veramente e consiglio di guardare tutto quello che ha fatto, che fa.Ovviamente l'ultimo anno è un po' calato a causa del Covid, le conferenze sono diventate un po' più ostiche da organizzare e fare.Chiaro, chiarissimo, beh è normale.Anche se devo dire che ho avuto la percezione che si sia prodotto tantissimo materiale nell'ultimo tempo, però le conferenze quelle di spessore hanno un po' sofferto.Le conferenze hanno un po' sofferto, una battuta d'arresto all'inizio, perché gente che aveva investito soldi per fare magari la conferenza a marzo del 2020 o aprile del 2020 ha avuto dei problemi a farle, non li ha fatte e ha perso dei soldi, e quindi dopo rimettersi a farle online, sì hai tutta la tecnologia e tutto quello che vuoi, però devi anche avere la voglia di farlo e dopo aver preso una battosta magari anche il morale non era alle stelle.Nell'ultimo anno si è prodotto, ho visto nascere talmente tanti fra streamer, youtuber, ormai anche la casalinga di Voghera fa lo youtuber su come fare la pasta in casa.Pensavo sul garbage collector.Forse anche sul garbage collector La differenziata del garbage collector, questo potrebbe essere un bellissimo video.In tutti i campi la gente ha cominciato a produrre veramente tanto.Non so se la qualità sia sempre buona, però va anche detto che la gente che vuole iniziare a programmare, che si approccia alla programmazione, da qualche parte deve pur cominciare.Ad esempio, pur sapendole molto di Python, probabilmente non sarei la persona più adatta a insegnare uno completamente di giuro perché partirei già con delle aspettative, con delle cose che io do per scontato ma il resto del mondo no.Quindi sì, essere bravi a insegnare è difficile.Roberto, io non so come ringraziarti, è stata un'oretta e mezzo super piacevolissima e come dico a tutti i nostri ospiti, non siete più ospiti.Da oggi Gitbar è un po' anche casa tua, quando trovi qualcosa di interessante, qualche novità che ti fa piacere e hai voglia di condividerla con noi puoi venire direttamente qua in puntata basta che mi pinghi oppure direttamente nel gruppo telegram quindi grazie al nome mio e di tutta la community per averci dedicato questo tempo se questo episodio vi è piaciuto è naturalmente merito di Roberto e non mio, ma se vi è piaciuto davvero tanto a quel punto un altro "se" quindi il ramo delle if si diforca ulteriormente avete un device apple potete scaricare l'applicazione podcast e mettere una stellina con un eventuale messaggio se vi fa piacere.Io ringrazio nuovamente Roberto per aver raccontato, aver portato un po' del mondo python qua nel nostro nostro bar degli sviluppatori e vi ricordo rapidamente i nostri contatti info@gitbar via email o @brainrapper su twitter e poi il nostro gruppo telegram la vera casa di Gitbar dove ci incontriamo costantemente ci facciamo delle grandi chiacchierate dalla Sardegna e dall'Irlanda i due posti delle birre quelle più buone naturalmente stanno dove dove roberto un grande saluto noi ci sentiamo alla prossima settimana Git bar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e combrer repo Parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.[Musica] [Musica] [Musica]
