Bene e benvenuti su Geekbar, seconda puntata dell'anno e quest'anno iniziamo veramente alla grande dopo un primo episodio dove si parlava di side project e là le cartelle dei nostri computer esplodono o perlomeno il mio ma vedendo il sondaggio del gruppo Telegram mi sembrava un po' una situazione generalizzata passiamo a un argomento che a me interessa tantissimo non so se ai miei compari di viaggio Leo e Mattia interessa altrettanto non saremmo qua alprimenti esattamente però io sono qui anche un po perché mi mancavate voi però mi interessa anche l'argomento di oggi benvenuti su Gitbar il podcast dedicato al mondo dei full stack developer i 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.Dicevo, l'argomento di oggi non l'abbiamo ancora detto, ma sarà Rabbeter NQ.e lo affronteremo con, come si dice, come si scrive nel profilo LinkedIn non nel suo, ma molti scrivono nel profilo LinkedIn "LinkedIn massimo esperto" "Leader del settore di Rabbithood" *risate* "Il famosissimo Gabriele Santo Maggio" *risate* Ciao Gabriele, benvenuto Grazie, grazie mille per l'invito, innanzitutto Noi ci abbiamo scherzato però Gabriele è un super ospite.Chi è Gabriele? è un staff senior engineer o engineer non ho ancora imparato a dirlo eppure sono tipo 20 anni che faccio questo lavoro quindi bellissimo a VMware ma è stato per tanti anni senior software engineer a SUSE insomma ha fatto un sacco di cose lo trovate quando cercate un argomento interessante su youtube o su la rete spunta lui, quindi se c'è un talk andatelo ad ascoltare.Gabriele ho una domanda giusto per rompere il ghiaccio che in realtà abbiamo già rotto però mi interessava approfondire, come hai costruito questa carriera dalle basi? Perché la strada che porta, la posizione che hai immagino sia stata lunga e anche impegnativa.Come l'hai costruito, come hai fatto questo percorso e quali sono le milestone che puoi definire nel tuo percorso professionale? Allora sì, è stata una strada piuttosto lunga, infatti sono arrivato in VMware diciamo tipo un anno e mezzo fa, dopo una serie di tentativi falliti, quindi quando leggete i non è vero, non ce la farete però quando non lo fate non ce la farete per un po' di tempo giustamente.Sì diciamo che la mia carriera è piuttosto lunga anche perché non sono più un ragazzino mi avvio verso l'età della pensione e Mariston importa magari quel è l'obiettivo ma guarda io ho sempre detto il mio desiderio è arrivare a cinquantadue cinquantatre anni e lavorare part time e part time e mio desiderio è arrivare a 52-53 anni e lavorare part time e part altro.Io di professione voglio fare, proprio voglio scrivere nel mio job title quello che ha lavorato nel core di RabbitMQ, cioè io voglio fare questo e poi non voglio fare nient'altro.E passare il tempo a fare riunioni, questo è quello che ho lavorato per RabbitMQ.Comunque, maestro importante, Io ho lavorato per molti anni in un'azienda italiana, dove facciamo software un po' particolari e ho avuto la possibilità di lavorare in software a basso livello, in C, in Java, in C++, con diversi linguaggi, ma non è tanto importante il linguaggio, ma la possibilità di aver potuto mettere mani a cose che normalmente se lavori con gestionali o con applicazioni il genere non lo fai, quindi per dire problemi legati a basso livello di Linux, socket, thread, tutta questa roba, tutta completamente scritta a mano, tutta completamente scritta a zero perché un po' di anni fa tutti questi framework non c'erano, quindi in pratica te lo dovevi fare tu.Dopo circa 10 anni che ho lavorato per questa azienda, sono andato a lavorare per Erlang Solution a Londra, non so se conoscete.Per chi si occupa, per chi lavora in Erlang, in Elixir è una delle aziende di riferimento, anche perché non è che siamo molti a lavorare in questo linguaggio.Voi conoscete Erlang, Elixir? Avete mai sentito? Conosciamo Alexio Biancalana, quindi di conseguenza abbiamo sentito parlare di lui.Ci parla solo di quello.Siamo stati evangelizzati.Ma ecco, tra l'altro, a proposito di questo, io ti volevo chiedere se quando tu sei andato lì conoscevi già Erlang oppure no.No, nel senso ero appassionato di Erlang, l'avevo studiato perché comunque già conoscevo era un utente e quindi era appassionato al mondo di Erlang, soltanto che non è che trovi moltissime aziende che ti dicono "ah vieni a lavorare con Erlang con noi" anche perché non le trovi.Però è stato tutto molto bello perché sono arrivato il primo giorno, sono arrivato il primo giorno e il secondo giorno mi hanno detto "questa è una issue su RabbitMQ, chiudila".Vabbè, tutto molto bello.Se posso mi aggancio un attimo a questa cosa per raccontare la mia esperienza in MongoDB che sono due mesi e mezzo che lavoro lì e loro hanno un processo di onboarding che i primi tre mesi praticamente quasi non tocchi il codice perché quindi questa cosa mi ha detto il giorno dopo a me mi ha aumentato i battiti.Sono gli opposti praticamente, gli antipodi.Tanto comunque c'è la review, non è il senso che lo fai da solo, c'è sempre chi ti valida la review poi erano comunque bug, sai quando ti mettono va bene quelli semplici non mi viene il termine italiano comunque.Good first issues.Esatto erano bug piuttosto semplici però ti danno la possibilità di imparare a interessante anche avere cioè il giorno dopo già subito alle mani lì.Ma sì Sì, considerate che fino alla settimana prima lavoravo per la mia bella azienda italiana dove conoscevo tutti, sono stato lì a Londra dove non conoscevo nessuno, il mio inglese lascia il tempo che trova e lavoravo come consulente per il team di Rabbit, quindi tu facevi due salti e quindi è stato un po' impattante, però non è che mi sono perso molto d'animo.Sì, insomma lì ho cominciato a fare un po' di tutto, nel frattempo prima di tutto ciò ho scritto un libro su RabbitMQ, l'ho scritto nel 2013, ormai è troppo vecchio, mi raccomando non lo comprate perché è veramente troppo vecchio.La cosa molto carina è che quando sono andato in questa azienda rondinese per fare il colloquio avevano il mio libro nello scaffale e quindi diciamo che sono partito abbastanza.Si che bello qualcuno la compra.Ti da dei punti in effetti credo quando vai a fare un colloquio.Si, si, si.Diciamo che già il fatto che hanno il tuo libro, l'hanno letto e t'hanno chiamato e non te l'hanno tirato dietro.Ma questo libro fa cagare.No Gabriele io ho due domande proprio su questo.La prima è quando tu entri in una di quelle società che sono un po' il tuo sogno o comunque inizi a lavorare sull'ecosistema che diciamo vedevi come un miraggio, a livello personale ed emotivo, emozionale, è stato difficile gestire l'impatto, l'effetto sindrome dell'impostore, la paura di muoverti in una cristalleria no? Allora sì nel senso io tuttora ogni mese che prendo lo stipendio penso e dai pure sto mese è andata ancora non sono accorto di quanto sono schiappa nel fare le cose.Come quel meme "Day 45 they still don't know I'm a dog" l'altro giorno mi chiama il capo supremo USA, io ho detto ecco mo mi licenza, non lo so che mi licenza, non lo so, già me lo preparo psicologicamente, invece mi ha chiamato per farmi complimenti per il lavoro, quindi penso che questa cosa non passerà mai.E te gli dovevi dire no guarda forse ha sbagliato, non non sono io.Un altro Gabriele Santomaggio.Esatto.Sì sì esatto c'è un altro Gabriele Santomaggia che che quindi non lo so io ancora non la riesco a gestire, non la riesco a portare in giro.non lo so, io ancora non la riesco a gestire, non la riesco a vivere benissimo perché sei sempre lì con la paura di fare qualcosa di sbagliato, quindi poni sempre la massima attenzione sia nel linguaggio, sia nel codice, sia in tutto.A me per quanto mi riguarda è così.LM: Questa cosa la vivi con piacere o hai comunque la paura che si trasformi in un terrore? io conosco amici che lavorano in grandi società che dopo un paio d'anni iniziano o un anno iniziano a sentire proprio il peso di avere quest'ansia di non fare cappellate giganti proprio dovuta a non sentirsi all'altezza.Questa è una bellissima domanda e penso che prenda un po' molti programmatori insomma penso che un programmatore normale viva di questa ansia di programmatori rilassati che dicono "Madonna quanto son bravo!" solitamente è sempre gente che lascia un po' di tempo di trova, però il fatto che questo tipo di situazione mi dà lo stimolo per andare avanti.In un'azienda dove vengo considerato bravo, troppo bravo o il più bravo non mi sento a mio agio per due motivi.Il primo perché non ho niente da imparare, il due perché non mi piacciono troppo i complimenti e tre perché dopo ti scassano ogni tre minuti "come si fa questo, come si fa quell'altro, come si fa quest'altro" e basta, studia, ho fatto io, lo fai pure tu, capi? Io adesso mi metto muto e applaudo per 92 minuti.C'è una bella differenza tra essere senior e essere tuo nonno, insomma, tuo nonno ti un senior developer, però a un certo punto ragazzo leggi almeno il gettistart, non ti dico tanto, almeno come farlo partire, però questa è una battaglia personale.L'altra domanda in realtà sempre legata a quello che hai appena detto è la scrittura di un libro tecnico.A livello di carriera, anzi ancora prima della carriera faccio un passo indietro.A livello di apprendimento tuo personale nell'argomento, scrivere un libro tecnico ti è stato utile? E poi a livello di carriera, praticamente la stessa domanda, ti è e come ti è stato utile se lo è stato? Allora scrivere un libro tecnico in inglese poi, considerando che quando ho cominciato il mio inglese era un po' così, quindi il pomeriggio facevo corsi inglesi e la sera, la notte dovevo scrivere il libro, l'ho scritto insieme al mio ex collega, tuttora amico, Sigismondo.È stata un'esperienza personalmente piuttosto devastante perché ci ho lavorato un anno, un anno intero, poi voi lo conoscete l'Open Source, Leonardo ho capito che lavora a MongoDB, tu scrivi una cosa, dopo ti cambiano la feature, porca miseria, mo perché non posso dire parolaccia, allora cancella tutto il capitolo.Io ricordo che a un mese dall'uscita, sai, non so se voi avete esperienza in merito, a un mese dall'uscita stavamo facendo i fiocchettini, le righe, eccetera, io avevo scritto una cosa nel libro che non si poteva fare, rilasciano la nuova versione, cacchio si può fare, vabbè ho capito, ma allora fate apposta, quindi smonta tutto il capitolo, rifai tutto il capitolo, eccetera, perché è stato devastante, veramente un'esperienza devastante.Mia moglie mio figlio la mattina andava in almario e io stavo in albergo a scrivere il libro, non lo voglio fare mai più, però nella carriera mi è stato utile, sì, con un po' di delay, nel senso che quando l'ho scritto non mi si filava nessuno, poi proprio Rabbit la mi hanno messo come i libri suggesti, me lo sono ritrovato lì fra i vari libri suggeriti e da quando l'hanno messo sul sito è cominciata un po' la mia "carriera", sembra una stupitaggine, avrei il tuo libro come il libro raccomandato nel sito di Rap Time Q che ha milioni di accessi mensili mi ha fatto la differenza.Ho visto le vendite proprio schizzare in alto e poi le ho offerte di lavoro come se non ci fossero domani e quindi è un'esperienza che se avete voglia di fare io la consiglio assolutamente però mettetevi in testa che ci vuole veramente molto molto molto tempo.E fu così che Gabriele si comprò la seconda casa al mare.No! I guadagni sono stati veramente veramente pochi.Poi in Italia con le tasse, anche per fare un generale di sul libro è stato un casino, vabbè che la metà basta, con quel poco guadagnato, tipo il 40-50%, innanzitutto è la metà del guadagno.Perché siamo io e Sigismondo, quindi è diviso due.poi di quel diviso due un 40-50% lo regala lo Stato perché mi piace farlo e in pratica mi dice boh boh non so mi ci sarò fatto una una vacanzetta probabilmente con i soldi.Infatti volevo chiederti se scrivere un libro lo possiamo considerare come un passive income oppure no? Non penso.Ok la domanda voleva questa risposta no? Perché sembra sono quei come si dice quei percorsi, se sono sviluppatore allora potrei anche fare questo perché almeno poi dopo prendo le royalties però ecco forse l'effort che uno mette forse hai avuto più income dal fatto di avere più reputazione successivamente per avere dei lavori di più alto livello.È un investimento che fai per il futuro a meno che non scrivi dei libri con la gente seria che scrivi libri fatti per bene e che ne vendi magari migliaia di copie probabilmente sì però non vendere mai che ne so come che ti devo dire Dan Brown con il codice da vinci.Infatti l'esercizio mentale che stavo provando a fare era cercare il Fabio Volo dei libri tecnici italiani, no? Ancol Bob! Sì, ma è italiani! Assolutamente Ancol Bob! Ancol Bob è italiano! Ma la gente che scrive libri tecnici italiani credo che siano 5! Sì, e che pagano per scriverli! Perché il mercato è veramente piccolissimo, credo.Però è stata una soddisfazione quando ho trovato il mio libro pirata, e però sono sono anche scaricato pirata.È stata una bella soddisfazione perché quando qualcosa...io penso, va bene, ho questa opinione un po' comune di tutti quanti, che quando ti insultano su internet vuol dire che stai facendo bene.Quando c'è una copia pirata di qualcosa di tuo vuol dire che stai facendo ancora meglio.Quindi ben vengano gli insulti e ben vengano le copie pirata vuol dire che stai facendo qualcosa di buono.Esatto, ragazzini di 13 anni scaricate libri gratis, quando fatevi fregare non entrate più in libreria.Warning do not try this at home.Io naturalmente non dissocio per dovere di ruolo.Assolutamente, si scherza, si scherza.Certo, certo.Ok prossima domanda.Esatto andiamo avanti.Ah se questi hardisk potessero parlare, vai.Mai scaricato niente di illegale in vita mia.Allora, cerchiamo di riportare tutto alla serietà che ci è d'obbligo in queste situazioni.No, proviamo per un attimo a capire un po', a entrare un po' nel mondo di RabbitMQ, quindi nella tana del bianconiglio.La prima domanda che ti voglio fare è che cos'è Rabbit? Allora Rabbit è un broker sostanzialmente per scambiare messaggi, quindi manda messaggio per ogni messaggio diciamo messaggio fa questo però lo fa.Sigla abbiamo finito e per oggi abbiamo dato però lo fa con protocolli diversi eh di di default utilizza MQP eh zero novantuno supporta stomp, web stomp, MQTT insomma un po' di protocolli sono anche C'è differenza tra questi vari protocolli? Nel senso, ci sono poi altri software che parlano questa lingua e quindi Rabbit interfaccia con questa o hanno dei casi d'uso diversi tipo per determinati tipi di dati o cose? Sì, allora di base utilizza MQP901 che è un B2B protocol, quindi in pratica serve per per far parlare server, non end user, e quindi si basa tutto su questo protocollo nato un po' di anni fa, ve la ricordate la vignetta? Abbiamo bisogno di uno standard per mandare messaggi? Abbiamo bisogno di uno standard per mandare messaggi? Ora facciamo un altro, è arrivato un altro standard per mandare messaggi.L'idea di base di questo protocollo perché i vari client che puoi utilizzare sono scritti anche da terzi perché ci sono anche altri broker che utilizzano lo stesso protocollo, questo nella carta, nella realtà invece Rabbit è il più famoso che utilizza il 901 come protocollo.Poi per rispondere alla domanda di Leonardo ci sono protocolli che per esempio MQTT che che viene utilizzato per la parte di IoT, che è un po' completamente diverso, un protocollo molto leggero, e quindi questo tipo di messaggio arriva a Rabbit come un IoT message, come un MQTT message, e internamente Rabbit lo traduce e lo mette nel formato che gli piace di più.Lo stesso per Stomp, WebStomp, fa un po' da bridge.Nell'ultima versione di Rabbit c'è un protocollo dedicato proprio alla parte di streaming, perché ci mancava, per gestire insomma milioni e milioni di record al secondo, che era una parte mancante dello stack di Rabbit.Fondamentalmente, che sai, quello che ho detto serve appunto per far comunicare server diversi.Io l'ho cominciato ad utilizzare la versione 2.6, mi ricordo in tempi assolutamente sconosciuti, nessuno, poi è esploso nel mondo dei microservices, che è uno dei broker più utilizzati per integrazione.Io ricordo quando il team cominciava a lavorare in Rabbit su questa roba erano tipo tre o quattro persone, adesso il nostro team sono, siamo non so quante persone di vitile in categorie diverse perché è veramente esploso come broker.Esatto, domanda completamente random scusami Mauro.Noi, almeno l'azienda per cui lavoro io, usa estensivamente RabbitMQ come message broker tra microservizi perché era quello che ti consiglia Heroku ed è nei plugin di Heroku che lo accendi con un click.Quanto di avere i servizi di platform as a service, infrastructure as a service o quello che cazzo vuoi, as a service ha dato una spinta effettivamente all'adoption di Rabbit secondo te? Allora, sicuramente molto.Considerate che anche Amazon stessa adesso ha RabbitMQ as a service.quindi ormai penso che i maggiori vendor ce l'hanno più o meno tutti come come supporto di broker e come strumento di integrazione per appunto per i migliori servizi.Certo ha dato una bella ha dato una bella mano però non ti so non seguo cioè non seguo queste questo tipo di statistiche però parecchio insomma il numero di utenti sono veramente veramente tanti.Certo ci sta.Dovendo immaginare Rabbit come un piccolo ecosistema quindi mettendo la lente di ingrandimento su quella concetti vanno a giocare che ruolo cioè come funziona rabbit dentro nel sistema dove lo si utilizza.Detto in poche parole, una delle parti principali di Rabbit, dei concetti principali di Rabbit sono gli exchange e le code.Gli exchange sono degli elementi virtuali, in pratica non mantengono dati, fate conto che è tipo un nastro che passa, tu butti i dati e c'è qualcuno che raccoglie questi dati che sono le code, dove chi vuole se le prende, non necessariamente tutti, in base a delle regole che puoi definire, questo messaggio mi interessa, questo messaggio non mi interessa e si salvano nelle code.La cosa che a me piace molto di questo protocollo è che il producer, cioè chi produce i messaggi non sa assolutamente niente di chi li consuma, un producer dice io metto questo messaggio su questo bus che è l'exchange, poi di chi lo va a consumare, di chi prende effettivamente questi dati il producer non ne sa niente.Considerate che magari un messaggio sia replicato per 100 mila code, una coda oppure nessuno, tu puoi anche pubblicare un messaggio che non c'è nessuno che lo ascolta.Questi sono i concetti principali, quindi c'è il producer che manda questi messaggi questo bus e poi ci sono i consumer che prendono i messaggi dalla coda e effettivamente li tolgono e li elaborano come dire il consumer è legato uno a uno alla coda, mentre il producer manda e non si sa dove, il consumer sa esattamente dove andare a prendere questi dati, questo qui nel comportamento standard di Rabbit.Una volta che il consumer ha preso un messaggio in carico può decidere se il messaggio lo rimette in coda, lo consuma, lo toglie, lo mette in una serie di stati lunghi e noiosi, però ci sono diversi stati del messaggio che il consumer riesce a gestire, per esempio se vai in errore puoi decidere di riaccodare messaggio oppure puoi mandarlo, lo puoi ridiriggere in un altro exchange, gli fai fare un percorso diverso e lo puoi insomma puoi giocare moltissimo con il routing dei messaggi.Questa secondo me è una delle parti più potenti di Rabbit.Che succede a un messaggio se non viene consumato? Cioè può essere configurato Rabbit NQ per dire che un messaggio potrebbe non essere ancora consumato e magari viene consumato tra un'ora perché non è necessario consumarlo ora oppure viene scartato? Ci sono delle regole che si possono fare o c'è un comportamento standard? Allora di default il messaggio sta là.Tu lo metti e vabbè sta là nella coda e spera che qualcuno ce lo prenda, capito? La coda è in memoria o viene poi anche salvata non so su disco? Cioè per esempio, cioè mi interessa sapere esiste la possibilità che un messaggio venga perso da Rabbit e Q? Allora eh Rabbit c'ha tipo forse quattro quattro tipi di code quindi non voglio annoiarvi altrimenti sarebbe un po' troppo lungo però per rispondere alla tua domanda eh diciamo eh prendiamo una coda quelle più utilizzate i messaggi vengono salvati in memoria e dampati sul disco quindi vengono sì vengono salvati in memoria.Li puoi perdere i messaggi se tu decidi che quella determinata coda non è importante per te e vuoi utilizzare un tipo di perché ci sono messaggi tipo messaggi di notifica che magari se se si chiude il broker, cose di questo tipo a te non interessa eh che vengono persi sì le puoi c'è nel senso però tu sei cosciente volontariamente che quei dati tu li puoi perdere perché li vuoi perdere, non li vuoi salvare sul disco per questioni di ottimizzazioni, perché magari salvare sul disco per una notifica, un qualcosa che non ti interessa moltissimo è uno spreco di risorse.Tu dici, se ci sta, bene, se non ci sta, va beh, salute.Per configurare moltissimi messaggi, diciamo, per mandarli, non so, ai milioni e milioni di messaggi, sono delle code fatte apposta per storicizzare milioni di record.Considerate che Rabbit di default, come ogni sistema di code che funziona con questo tipo di protocollo, idealmente ha quasi zero messaggi nelle code standard.Viene garantita l'ordine dei messaggi in cui viene mandato su una singola coda? non necessariamente? Allora sì, a patto che, e questa è una domanda che veramente, cioè ti ringrazio per averla fatta, però spero di chiarire per l'ennesima volta questo concetto di questo concetto, è garantito sì a patto che tu inserisca i dati con un thread e consumi i dati con un thread, perché già se c'è due thread fa tutto quanto un po' a… però così te la sei cercata fondamentalmente.Sì sì sì sì sì no però vi assicuro che ci sono moltissimi moltissimi software purtroppo che basano fondamentalmente tutto quanto su questa sull'ordine dei messaggi questo seppur Rabbit lo garantisce io lo sconsiglio sempre perché perché tutti i vincoli troppo cioè magari c'hai il cluster con 18 core 24 core e poi metti metti uno e togli uno, metti uno attento che se si trompe qualcosina.Devi utilizzare degli strumenti che ti permettono di andare veloce in maniera asincrona facendo una correlazione dei messaggi che c'è proprio il correlation ID in modo asincrono tu te li ricolleghi alla fine però non stai lì capito con il contagoccio.Adesso ne metto uno e poi ne prendo un altro.non so se è chiaro il piccolo piccolo no no no ma sai cos'è Gabriele che spesso Rabbit lo si installa si fa una configurazione di massima leggendo le prime 10 lighe del quick start lo si fa funzionare e poi è una di quelle cose che se funziona più importanti del...si parla anche di Rabbit in un'ottica di stream e di streaming, a cosa serve? quali sono i casi d'uso e soprattutto come funziona in questo caso? allora lo stream è una nuova funzionalità che abbiamo messo dentro nella versione 3.9 e funziona in maniera completamente diversa è un tipo di coda completamente diversa anche volendo un un protocollo custom dedicato e serve per salvare milioni e milioni di dati al secondo in app and only.Mentre nella sua struttura classica tu metti un messaggio, lo consumi e lo cancelli, lo stream è in app and only, metti i messaggi tutti quanti in sequenza e qual è il vantaggio di questo tipo di approccio? Che è un approccio che utilizzano tutti i sistemi di streaming, streaming di messaggi più famosi.L'approccio è che avendo un app and only, come sapete, è la cosa più veloce che tu possa fare per salvare dei dati, non c'è niente di più veloce che fare un app and only e salvare i messaggi e poi a seconda delle politiche di retention tu vai a cancellare i segmenti all'inizio dello stream, quindi tu inserisci, inserisci, inserisci e poi cominci a cancellare dalla fine.Questa è una tecnica abbastanza standard, che però funziona.Rabbit soffriva di un problema che quando tu dovevi dispacciare lo stesso contenuto a 100 mila consumer, tu dovevi avere prima 100 mila code e questo era un problema, esattamente.Perché Rabbit non era nato per questi numeri, è esploso e la gente ha cominciato a utilizzare un po' come vuole e come è giusto che sia.Per cui adesso con questo tipo di approccio allo stream tu hai uno stream solo e ci puoi attaccare 2000-3000 consumer, però è il consumatore che si muove, che naviga nello stream.Quindi che tipo di problema risolve? Innanzitutto ti tiene lo storico di quello che hai avuto e quindi puoi navigare nel tempo, fammi vedere, voglio consumare i dati dalla settimana scorsa, dall'inizio, dalla fine, eccetera.Questo è il primo problema.Il secondo che puoi salvare veramente milioni e milioni di record senza avere impatto sulla memoria perché non utilizzi la memoria, tutto quanto disco.Il terzo, quello di gestire migliaia di consumer, non dico con poco impatto perché non è vero, però decisamente con meno impatto rispetto ai consumer standard che devono avere una coda dedicata solamente per loro, per questo tipo di use case.Uno use case classico, non lo so, devi notificare che se tu vuoi dare lo stesso tipo di informazione a eh che ti devo dire eh duemila device che stanno collegati c'hai uno stream c'hai duemila consumer prendi questa informazione e le e fai il dispatch è chiaro chiarissimo ho una domanda eh le connessioni mh dei consumer dei produttori sono connessioni deve essere sempre agganciato al broker o ci sono altre tecniche? Allora, di per sé tutto quanto il protocollo è disegnato per avere delle long running connection e quindi tu stabilisci la connessione, ce l'hai aperta, se la utilizzi la utilizzi, se non la utilizzi non la utilizzi, insomma sta lì.Io quello che dico sempre però e questo ripeto anche a tutti gli amici che mi ascoltano da casa, è presupporre che tu apri una connessione TCP e che questa connessione stia aperta lì per mesi, che funzioni sempre, è un'assunzione assolutamente sbagliata.Quindi ogni tanto chiudete e riavviate la connessione in maniera volontaria, perché se vi aspettate che sia sempre su, per sempre, è un concetto che di per sé non regge nell'informatica, una disconnessione ce l'hai.Non basiamo il nostro software sul fatto che quella connessione ci sia? Sì, nel senso che per un milione di motivi che conosciamo tutti quanti a un certo punto la connessione si può perdere, però tendenzialmente ha una long running connession.Noi abbiamo parlato di numeri enormi eppure Rabbit rimane comunque un software altamente performante.Che cosa lo rende? Qual è la ricetta vera che rende Rabbit così performante? Allora...SIGLA! SIGLA! SIGLA! Allora, Rabbit è diventato famoso per un motivo per la sua stabilità infatti le nostre conferenze solitamente non sono molto famose, non vengono moltissime persone perché uno dei problemi, e questo vi assicuro che è un problema reale, uno dei problemi che ha Rabbit è che tu lo installi funziona, la gente manda messaggio, riceve messaggio, funziona, non è che gli interessa moltissimo di come funzionano gli internals, di come si può ottimizzare, quindi quando tu fai una conferenza che parla di Rabbit la gente non ci va perché dice "va beh funziona a me che me ne frega".Funziona troppo bene.Sì, cioè sul Rabbit poi vabbè se lo utilizzi male vedi la gente che ci insulta perché che ci insulta, ci sta sempre a tutte le parti, però tendenzialmente è una roba che funziona e quindi sta lì e funziona.Per quanto riguarda le performance, in realtà di per sé Rabbit sulla parte MQP non è che sia proprio velocissimo, parliamo di 20.000 messaggi al secondo, riesce a sopportare la parte MQP perché i messaggi hanno un ciclo di vita estremamente complesso.Nella parte di stream abbiamo queste performance perché la ricetta è molto semplice, cioè non ci sta niente, non c'è niente di segreto.Quando utilizzi un protocollo custom invece di MQP che è MQP solamente per mandare un messaggio devi mettere nell'header sono MQP ma guarda che sono MQP e quale MQP sei? Sono 901 ma sei sicuro che sono 901? Sì sì sì sono io cioè solamente per per dire capito che che 6 MQP ci passano 15-20 byte solamente per definire il protocollo, mentre con un protocollo custom estremamente ottimizzato con i byte contati, quando mandi un buffer sostanzialmente mandi l'essenziale.Poi abbiamo una feature che è il sub-batching, che implementiamo la tua client e la compressione, magari in un'unica sequenza mandi 7000-8000 messaggi e tu mandi 8000 messaggi in un singolo send TCP, che è fatto con praticamente 8000 messaggi, che ti devo dire un microsecondo li hai mandati, non è che ci vuole molto fatto dei test, che veramente in un PC locale mandi 3 milioni di messaggi in poco più di un secondo, ma perché così è semplice.LM: chiarissimo.E comunque sotto parte della stabilità sembra una barzelletta, ma credo che anche il linguaggio con cui è scritto abbia gioco da padrone.Linguaggio è estremamente stabile e aiuta molto sulla parte di distribuzione, quello sicuramente.Il linguaggio ha 22-23 anni, quindi ha una sua stabilità.Resta un linguaggio in icchia e resterà un linguaggio in icchia perché non può prendere piede, è troppo complesso.Nell'utilizzo everyday lo sconsiglio a meno che non voglio veramente, ma no, se gli voglio male gli consiglio il PHP.Oddio non si poteva dire questo.Fa ridere perché è vero.Control Z, Control Z annula.Scusate metto il check qui in su.Allora anche questa puntata abbiamo parlato di PHP.è male soprattutto.In che altro modo si può provare? Ok, proviamo, dovendo provare a immaginare una serie di casi d'uso, da quelli più comuni a quelli più assurdi che hai visto nella tua carriera, quali sono i casi d'uso caratteristici? Il caso d'uso uno ce lo può dire Mattia, se lo può dire per cosa lo usa.Banalmente credo che sia il caso d'uso più standard, è quello di cui parlavi tu all'inizio, cioè fare da message broker tra microservizi.L'azienda per cui lavoro ha un ecosistema di microservizi che parlano tra loro in maniera asincrona mandandosi messaggi su delle cose di rapide.è molto semplice.Più o meno è un'architettura a eventi, non necessariamente ogni messaggio è un evento, però more or less diciamo che quello che guida il design è quello.Io vi posso parlare, sì, questo qui Mattia è diciamo quello di UseCase, uno di quelli più… Sì esatto, mi sembra quello… il capitolo zero del get inside.esatto io vi posso dire che ho fatto da consulente per un anno, facevo consulente su RabbitMQ però diciamo consulente consulenze anche interessanti su grandi sistemi e l'ho visto utilizzare malissimo una roba veramente assurda.Un'azienda della quale non posso fare assolutamente il nome utilizzava Rabbit come sistema di chat perché quando vedi il sistema di messaggi infatti se tu vedi anche in giro cerchi RabbitMQ, how to implement a chat, eccetera messagge non significa messaggio di Whatsapp messagge significa un messaggio B2B e quindi che cosa succede? succede che moltissimi hanno dopo Whatsapp, e questo è stato veramente un altro side effect, dopo Whatsapp hanno fatto due più due, ma hanno fatto cinque, non hanno fatto quattro Whatsapp = Erlang WhatsApp WhatsApp uguale Erlang quindi se tu cerchi Erlang Messages bene o male va a finire a Rabbit ci finisci e quindi siamo sì vabbè ragazzi è stato è stato veramente tutto molto bello quel periodo e quindi ti ritrovavi tutte queste aziende che hanno detto facciamo il nuovo WhatsApp e utilizziamo Rabbit cosa assolutamente sbagliata perché Rabbit è nato per Corolli per cui ti ritrovi queste aziende che hanno messo cluster con fantastiglioni di di di euro che magari ci avevano trentamila, quarantamila utenti collegati e scoppia semplicemente perché perché Rabbit non è disegnato con MQP cioè non è Rabbit, MQP non è disegnato per fare questo tipo di di di cose.Se tu lo utilizzi come backhand e magari ci metti sotto MQT Web Socket che ti fa da front end allora cambia completamente il se tu lo colleghi come end point direttamente alla chat così e lì è stato veramente molto molto divertente perché c'avevi questi questi cluster che facevano uuuuh quello lì è un utilizzo sbagliato.AWS ringrazia poi ogni mese con la bolletta? che non è lo strumento più è però eh però queste sono esperienze secondo me io lo dico sempre, esperienze eh dove vedi quello che non si deve fare secondo me sono più formative delle esperienze in cui dici questo eh questo è un'esperienza che non è la mia, non è la mia, non è la mia, non è la mia, queste sono esperienze, secondo me, io lo dico sempre, esperienze dove vedi quello che non si deve fare, secondo me sono più formative delle esperienze in cui dici questo è come si deve fare.Quindi andare dai clienti e cercare di capire il ragionamento, il percorso mentale che hanno fatto, che li hanno portati in quel casino e cercare di aiutarli, in quel senso secondo me è un'esperienza utile e significativa un po' per tutti quanti i sviluppatori, spesso i sviluppatori si chiudono un po' in loro stessi.Faccio io, faccio la cosa più figa del mondo e non me ne frega niente assolutamente di come il cliente lo utilizza.Questo è sbagliato perché bisogna capire perché il cliente è stato portato a pensare una cosa del genere.Probabilmente, non lo so, gli esempi sbagliati, la documentazione sbagliata, qualcosa di sbagliato, perché l'utente ha fatto questa scelta, c'è qualcosa di sbagliato in tutto ciò, almeno questo è il mio pensiero poi.Voglio fare...ragazzi avete qualche domanda Mattia e Leo? Io non ho una domanda però ho molta solidarietà rispetto a questa cosa di quando qualcuno usa uno strumento a cui lavori nel modo sbagliato e ti viene spontaneo dire "ma non si fa così, ma smettila" invece è la cosa costruttiva da fare.ci stava un consulente a dire "no, no, l'avete fatto bene, ma spiegatemi solo perché..." ho pensato alla mia esperienza di maintainer di un framework di mocking open source in cui regolarmente qualcuno cerca di stuprarlo, mi apre un issue su github dicendo "ma io ho provato a svitare una vite con un martello e non funziona" e la prima risposta è "ma scemo!" e invece è il modo più costruttivo e da bravo maintainer, forse ho sbagliato qualcosa io nelle documentazioni.Scusate metto la spunta sul fatto che abbiamo parlato di MOC in questa puntata.Lo sapete è la tassa da pagare quando ci sono… No però vedi una cosa che raramente ho visto nelle documentazioni dei tool, delle librerie di questi elementi è un capitolo con le bad practice, cioè una cosa che sto capendo sempre di più in questo periodo è che spesso la documentazione riesce a fare la differenza.Faccio un esempio, io credo che per ritornare al PHP che vedo che qua va per la maggiore, lo amiamo.Io ricordo che la documentazione di Symphony a suo tempo quando lavorava in PHP fu game changer perché era proprio fatta talmente bene e talmente precise, dettagliata, strutturata con i vari elementi che la documentazione deve avere quindi tutorial, elementi dove si va a fondo che alla fine è stato è stato importante per la costruzione di una community e l'adozione di quel framework.Posso parlare per esempio per la documentazione di Laravel sempre per stare in PHP, che è disegnata apposta proprio tailor made sulla persona che dovrà andare a utilizzare Laravel.Se voi guardate ci sono gli esempi talmente vicini ai casi d'uso delle persone che utilizzano Laravel che basta fare copy paste e si ha la cosa funzionante con le spiegazioni proprio di quel caso d'uso.Quindi mi chiedevo "ma Mettere un'area con le bad practice, come per dire "ok, quando si supera questo limite sto tirando il tool per le orecchie, quindi occhio che potrebbero esserci dei problemi".Secondo voi può essere interessante o semplicemente superfluo? È una bella domanda.Non lo so, nel senso che...Buh.Sto pensando alla...Io ho un caso effettivamente molto comune di gente che fa una roba con la mia libreria che non si dovrebbe fare e che secondo me è sbagliata.Però se lo fanno in tanti...Forse non lo so.Forse ha senso cercare di supportarla? No.Forse ha senso tirargli un'eccezione in faccia quando provano a farlo? Magari sì, non lo so.Dico l'ennesimo dipende della mia carriera in questo podcast.No, io penso che per spiegare le bad practices ci voglia molto tempo.Ogni best practice dovrebbe avere un post in un blog per spiegare esattamente perché funziona male o perché quel contesto non va bene.Forse spiegare le best practice è un po' più veloce.Questo è il pensiero che mi è venuto in mente.Allora, personalmente questa è una discussione che esce, che è uscita molte volte anche all'interno del team.Il problema fondamentale è che non hai dei numeri, cioè non hai dei numeri fissi, capito? Dopo dieci non funzioni più, non c'è un numero fisso, capito? tu dici puoi stabilire qual è una una cattiva pratica.Faccio un esempio se io utilizzo Mongo e permetti se dico scusami se dico eresema non lo conosco quasi per niente però se io dico boh non lo so lo utilizzo con 100 tabelle funziona tutto quanto, ho prova da fare due milioni di tabelle però perché non funziona? Ora tra 10 tabelle dove sono sicuro che funziona e che ne so, quattro milioni di tabelle dove sono magari e magari le supportano, non lo so, però diciamo che tra quattro milioni c'è un punto che non sai esattamente qual è in cui si rompe, quel punto varia a seconda della situazione, secondo me ci vuole un po' di buon senso.Sì, o anche banalmente a quante volte accedi a quel database, a quei record che potresti avere appunto quei numeri lì però non ci accedi mai, oppure puoi permetterti di aspettare un secondo per risposta perché non stai eh gestendo un'operazione ancora aperto e quindi per questo magari ci sono tante variabili per cui eh sì uno ci fa il blog e gli dici guardate l'ho usato così non ha funzionato eh quindi non lo fate anche voi vi vi risparmio un tempo però forse è difficile generalizzare dal dal vendor dal vendor difficilmente vedrai una cosa del genere è un po' eh non dico tirarsi la zappa sui piedi da soli però le persone veramente interpretano poi internet è pieno di gente che interpreta male qualsiasi cosa quindi diciamo che se nessuno l'ha mai fatto forse...io invece voglio lanciare l'ennesimo side project che mai vedrà la luce che è un social dove si prende la tecnologia e le persone possono scrivere le bad practice e le good practice aperte alla community.Non sarebbe male però per scrivere le bad practice lo devi conoscere veramente veramente bene.Con gli opportuni thread per mandare a cagare la gente quindi succede praticamente una casa per flame questa cosa forse non è proprio una bella idea.Ah ma c'è già Facebook per quello allora possiamo usare quello appoggiamoci.Qualche tempo fa c'era un blog che seguivo quasi quotidianamente che si chiamava "The Daily WTF" e il sottotitolo è "Curious Perversions in Information Technology".Ha un post al giorno di malle pratiche e violenze commesse nei confronti di software e linguaggi di programmazione assortiti.e si è appena trovato un balocco esatto infatti ti chiedo di mandare un giri che lo condividiamo poi nelle note dell'episodio è appena passato Natale, sono orrito di volare il tempo vola ma io ho ancora delle cosine da chiedere a Gabriele intanto, deployare Rabbit, qual è il modo migliore per farlo? La cosa più semplice dell'universo, vai sul sito di Rabbit, o ti scarichi il package e fai yum install rabbit, è finito, parte, non devi fare nient'altro.oppure sono i script già che abbiamo pronti per prendere Rabbit dai diversi repository perché abbiamo qualche mirror e per magari policy diversi, uno non può accedere a GitHub, uno non può accedere a un'altra parte, eccetera.Quindi è veramente semplice, non è una cosa complessa.Veramente in due minuti lo installi.Abbiamo la Docker Image, che con un pizzico d'orgoglio dico che è una delle Docker Images più scaricate da Docker.Abbiamo superato il billione di download che sono tanti, sono veramente tanti.Se non io la serie metto a casa Vuegetta.E poi Gabriele nel salvaschermo del televisore, nella schermata del televisore ha le statistiche di download del container, è dell'immagine.In realtà quindi ci confermi che il provisioning e il deploy di Rabbit è abbastanza semplice.Cosa un po' più difficile in realtà è fare ML Ops quindi tirar su quel tipo di sistema.Ma ne parliamo subito dopo aver ringraziato i donatori che in realtà questa settimana ancora, fino ad oggi non ce n'è quindi andiamo super veloci, vi rubo solo un secondo per dirvi che abbiamo cambiato la modalità di donazione, la trovate nel nostro sito come supportaci e adesso è direttamente su paypal risparmiamo qualche centesimo che investiremo in microfoni e attrezzatura.Adesso dovete aiutarci a provare se funziona la nuova modalità per le donazioni quindi per favore fateci dei test donate dei soldi per assicurarvi che tutto funzioni correttamente.Una consulenza gratis per ogni Donazione no non è vero.No ma vedi i 2,50€ arrivare.Però è una donazione sopra le 6 cifre.Sì esatto.In quel caso sì.Ci tenevo a ricordarlo perché di solito noi usavamo Buy me a Ko-Fi e invece siamo passati direttamente a Paypal riducendo così i costi e avendo un gruzzoletto di qualche centesimo più grande per acquistare le nostre attrezzature investirle in piani di miglioramento per la qualità del nostro podcast.Ma chiuso questo momento Marchetta voglio ritornare invece al concetto che in qualche modo ho voluto introdurre ed è l'MLOps.Quali sono le problematiche che si hanno quando si vuole appunto portare, tirare su un ambiente per fare machine learning? Allora intanto metti in piedi perché...Stavo testando per troppo tempo.Stand up for ML Ops.Pensavo che mi mettevi in piedi perché è un argomento che richiede...No, no, tanto la telecamera non registra, vero? solo poca ragazza, quindi posso utilizzare l'altra.Dove sta? Allora, praticamente...Dall'altro Gabriele questo cambio di telecamera sa molto di Rai.Sì, sì, allora mi metto dei conti.Allora, MLO...Scusami, ti fermo ancora.Visto i quadri che hai dietro ho più Roxy Bar, credo, no? I quadri che ho dietro? Che sono bellissimi.Ho i Pink Floyd, Guns Rosas, ciao Jimi Hendrix e David Bowie, sì.Figato! Però quello di cui ne vado più orgoglioso è quello di Pink Floyd, nel 1972.Eh, capolavoro! Comunque, allora, sì, parliamo di MLOps.MLOps è stata un'attività che ho fatto per un paio d'anni quando ero in Suse e perché volevo cambiare un po', sai, intanto fa bene cambiare e ci siamo accorti sostanzialmente di questo meraviglioso mondo del machine learning che è tutto un casotto che sta crescendo, poi se uniamo machine learning e Kubernetes abbiamo un po' di buzzword tutte quante insieme, poi ci mettiamo anche Cubeflow e abbiamo fatto 13.Comunque per farla breve uno dei problemi maggiori che c'è nel mondo del machine learning è l'installazione dei pacchetti, sembra assurdo, però installare una roba di machine learning è una cosa estremamente complessa.Quindi quando eravamo in SUSE, quello che abbiamo cercato di fare è cercare di facilitare l'installazione dei pacchetti e da lì è nato il progetto K3i, che in realtà è nato con un mio amico d'ex collega Alessandro Festa, era nato perché per disperazione noi dovevamo fare dei deployment dei script di machine learning e ogni volta che dovevamo fare questi deployment era un casino, io ero arrivato a scrivere bash di continuo per ogni cosa, abbiamo detto non possiamo andare avanti così, cerchiamo di fare un toolettino, ma era nato come progettino interno, non pretendevamo di metterlo esternamente.Poi abbiamo visto che funzionicchiava, cominciava a funzionare, l'abbiamo messo fuori, abbiamo fatto la proposta Cubeflow.Conoscete Cubeflow? No.Cubeflow, se andate su cubeflow.org, è un sistema che per gestire script, insomma, è piuttosto complesso, però per farla breve, per gestire script di machine learning dove dietro c'è il nostro amico Google, quindi è una roba con fantastiglioni di stelle su GitHub e fantastiglioni di committer around the world.Abbiamo fatto la proposta su Cubeflow, abbiamo detto guarda noi abbiamo fatto questo tool, magari può servire per installare le cose in locale e ce l'hanno accettato e quindi adesso sta nella documentazione ufficiale di Cubeflow come tool perché un lavorino carino che abbiamo fatto è quello di poter installare i sistemi, diciamo una sorta di essential, una sorta di sottopacchetto di tutto quanto il mondo devastante che sono le pipeline di Cubeflow, che le pipeline di machine learning le dovete pensare come le pipeline di un qualsiasi sistema di continuous integration soltanto che invece di avere i vari step di deployment hai dei step di machine learning, ho fatto il training, ho fatto questo, ho fatto quell'altro e bla bla bla, ho fatto la decisione quindi sono andato di qua sotto e sopra e eh in questo modo installavi un subset di Cubeflow che ti poteva girare anche il locale sulla tua macchina perché altrimenti avevi bisogno almeno di mi pare trentadue sessantaquattro giga e almeno sedici core solamente per far girare Cubeflow invece abbiamo fatto questo lavoro di scomposizione e ti installavi tutti quanti i pacchettini.È stata una bella esperienza, il progetto va ancora avanti, lo porta avanti per la maggior parte Alessandro, io veramente faccio poco perché sono impegnato, però secondo me l'idea era buona ed è ancora valida perché il mondo Machine Learning è veramente un casino.Spero di essere stato chiaro.Sì, soprattutto sull'ultima frase.Esistono degli standard da quel punto di vista sul provisioning di ambienti per il machine learning o è ancora tipo una giungla? Allora, questa è una bella domanda e cercherò veramente di essere breve.Su Kubernetes lo standard era Cubeflow, però Cubeflow secondo me, ma questa qui è un'opinione di Gabriele Santomaggio e non pretendo di essere assolutamente nessuno, Cubeflow è diventato troppo complesso, quindi per tirarlo su è veramente pesante, poi magari devi fare una pipeline solamente e ti devi portare su tutto quel sistema che è veramente esagerato.e per cui le aziende che cosa hanno fatto? C'è lo standard per azienda come si chiama in standard Netflix, si è fatto una roba che mi pare che si chiami ML Flow, qualcosa del genere che però non gira su Kubernetes, poi c'è quello del progetto di Apache che si si chiama iFlow, insomma qualcosa del genere, insomma si sta cercando di standardizzare come al solito ognuno se lo sta facendo un po' per conto proprio.Uno dei problemi fondamentali del machine learning è che i training richiedono veramente moltissimo tempo, per cui all'inizio si era partito "ah facciamo tutto quanto il machine learning sul cloud", tutto molto bello, però quando cominci a prendere le GPU sul cloud che ti costano fantastichioni di euro al mese per fare il calcolo per fare il training dei dataset su del machine learning su avs moltissime aziende hanno detto ma riportiamoci tutto quanto a casa perché ci conviene comprarci la gpu piuttosto che metterlo sul cloud.Poi ci fu lo shortage di componenti e dissero no ma riportiamo di nuovo tutto sul cloud mamma mia che casino.Ho lavorato su un sistema molto scusa con questo concludo ho lavorato su un sistema molto interessante che facevano secondo me una mossa molto intelligente.Sul cloud mettevano una sorta di prototipazione del tutto, quindi spendevano il giusto.Quando passava la prototipazione di tutto quanto delle pipeline, del dataset che dava dei risultati soddisfacenti, il training vero e proprio veniva fatto in casa.Considerate che i training possono anche impiegare delle ore, cioè dei giorni, capito? Quindi non è che dici "ah beh, faccio un test".Magari due giorni di training e poi non funziona, cioè tu hai perso due giorni, che al mondo d'oggi è veramente un'infinità.Fare una sorta di valutazione sul cloud è una cosa intelligente anche se nel mondo machine learning è un'indicazione, non significa necessariamente che poi vada bene, però l'ho trovato una cosa molto intelligente da fare.Tu hai fatto open source, questa domanda è figlia un po' di quello che dicevi su cube flow, secondo te, adesso la sensibilità data dalla carriera, dai progetti nei quali hai lavorato, nel mondo open source come un maintainer riesce a capire quali feature metter dentro e quali feature invece danneggiano il progetto perché lo portano verso quel gigantismo che poi spaca tutto? Ah questa è una bellissima domanda, io rispondo un po' con le parole di Salvatore che è grandissimo, veramente devo mettere la sua foto lì dietro a fianco, che lui disse durante un'intervista una cosa di cui mi sono pentito è quello di aver ascoltato troppo la community e aver messo delle feature magari instabili eccetera eccetera perché la community le richiedeva.Io non gestisco Redis e neanche ho le capacità per farlo, però gestisco insomma anche altri progetti, un po' di progetti open source.Decidere cosa mettere e cosa non mettere è è sempre un gioco di equilibri che devi trovare fra la stabilità e quello che ti richiede la comunità.Se la comunità comincia a premere un po' troppo su una determinata feature, tu a un certo punto la devi mettere anche se non sei completamente convinto.Rimandi oggi, rimandi domani, rimandi dopodomani, ma a un certo punto la devi mettere dentro.Una cosa che molti maintainer open source fanno è quella di focalizzarsi su quella che è la feature che secondo lui o lei è quella più figa in assoluta, però la comunità interessa è giusto.Quindi è veramente un gioco di equilibri che a volte è difficile da gestire.Anche perché appunto l'esempio che facevi tu di Anti-Reds con Redis, secondo me è un esempio molto comune.Io ricordo, ne abbiamo parlato, io non c'ero, ma ne abbiamo parlato in una puntata, poi mi spiace che sembra sempre che faccio bashing sulle stesse cose, ma ne abbiamo parlato in una puntata su PHP in cui a un certo punto si diceva "eh, a un certo punto la comunità di PHP voleva che PHP avesse il GoTo e allora PHP ha il GoTo".Ho capito, ma il Google è sbagliato.Quindi, cioè, lì, secondo me, ci sono due approcci estremi.Uno è quello di PHP, in cui si fa quello che la community vuole.Uno è quello, se vuoi, del benevolent dictator for life, come era Guido per Python a un certo punto, in cui, ok, puoi fare quello che vuoi, però decide lui.Come è stato a un certo punto Linux per il kernel di Linux.Hai una figura come è stato quando era lui Salvatore Perredis, hai una figura che è quella che prende le decisioni.Però come dici tu, in effetti c'è un equilibrio che è molto sottile da trovare.Poi specialmente per persone che magari hanno utilizzato uno strumento, non so, adesso io non voglio fare nomi di competitor perché non mi sembra giusto, quindi utilizzerò MongoDB come però io vi faccio un esempio ok cioè che ne so eh io ripeto non lo conosco però magari eh uno che viene da elastic search che elastic search ha una determinata funzionalità ti dice eh mi piacerebbe avere questa funzionalità su Mongo DB ma Leonardo dice ma guarda che il Mongo DB fa una cosa diversa rispetto ai la siamma e frega niente la voglio poi rientra un altro dice ah hai messo sta issue la voglio anch'io e poi rientra un altro e dice ma perché io devo mettere l'astic search eccetera con cinquantamila like e dicimila commenti e tu stai lì a decidere con il team ma che facciamo questa cosa della stick search? La mettiamo dentro oppure no? Leonardo più o meno va così? No? Sì.Eh no avevo sentito di una storia in cui eh era il contrario cioè che veniva usata la stick search come eh come un database insomma c'era una situazione in cui tutto doveva essere un un log praticamente eh per farlo funzionare però non sempre i dati erano quelli perché magari erano altri tipi di dati.Diciamo forse la confusione viene dal fatto di dire "ma tanto salviamo Jason, che c'è che problema? Uno vale l'altro, no?" Tanto salviamo Byte! Ma alla fine, ma qua si sta a ragionare, ma alla fine sono tutte 0 e 1, no? Eccolo qua! Tra l'altro, rispetto a questa storia che hai detto tu Gabriele, secondo me c'è anche un tema di di misura delle metriche di utilizzo dei progetti open source.Nel senso, a me capita spesso di pensare, ok, ho x utenti che mi chiedono questa feature nel mio progetto open source, però magari ne ho altrettanti che vorrebbero una feature, ma non sono vocali, non aprono le ish su GitHub, e magari avrei uno spazio di utilizzo gigante, che però è composto da una user base di gente che, non so come dirlo in una maniera più gentile, non rompe il cazzo, non si lamenta.Quindi alla fine hai questa specie di, è brutto dirlo, una specie di dittatura di chi si lamenta di più.Vince chi si lamenta di più anziché avere delle metriche sensate rispetto a chi veramente fa cosa su quello che fai, perché poi ovviamente non è che puoi avere nessun tipo di real user monitoring, di Google Analytics che ti dice cosa ci fa la gente con i tuoi progetti open source ed è anche giusto che non sia così.Sono completamente d'accordo con te, il problema è raggiungere questo tipo di utenti, perché magari una cosa molto carina che ha fatto il team un paio di anni fa era fare un modulo una serie di domande eh aperte a tutta quanta la comunità dicendo, capito, cosa è giusto, cosa è sbagliato, cosa vorresti di qua di là, insomma una serie di check non ha non ha risposta libera perché se metti la risposta libera poi ti devi leggere centinaia di migliaia di che se li legge però per avere un'idea ma lì giriamo sempre lo stesso intorno sempre lo stesso problema tu raggiungi degli utenti che già sono che non sono le persone che hanno di per sé hanno una certa attitudine a eh a commentare io riporto il mio caso ma Leonardo con Mongo eh magari avrà la stessa cosa e c'è gente che installa Mongo ha pittichette installa Mongo mette lì funziona e finito non partecipa non non è attivo e ha finito così è finito così sì sì sì io io faccio quello ho fatto brew install, mora, bitmq, ho tirato sul container di Mongo, basta.Ho fatto veramente poca roba con entrambi.Sono l'utente standard.Anche io, perché poi sono in un altro team, non lavoro sul database, per cui la mia conoscenza è quella.Guardavo l'orario e diciamo che i buoni propositi dell'anno sono già sfumati, visto che siamo a 1 ora e 9 minuti però noi ci appropinchiamo verso il momento chiamato il paese dei balocchi, il momento in cui il nostro ospite ma anche i nostri host condividono di librerie, video cose, rom, insomma qualunque cosa hanno insomma spottato e hanno reputato interessante per la loro carriera.Quindi la mia domanda è Gabriele cosa porti alla nostra community in dono? Mi conduco nel paese dei balocchi.Ah il paese dei balocchi.Allora io vi invito a a provare un vino che si chiama Franciacorta Saten che è di una bontà assoluta spero che vi piaccia il vino, poi vi invito a provare il Montepulciano d'Abruzzo perché io sono abruzzese, è un rosso un po' pesantino quindi dovete accompagnare io non so se ci sono dei vegetariani, vegani eccetera, spero di no ma se ci sono mi spiace per loro, vi salutiamo, vi vogliamo molto bene il Montepulciano da accompagnare con gli Arosticini Abruzzesi, non so se conoscete gli Arosticini Abruzzesi che sono veramente buoni, perché il Saten Franciacorta è già un vino un po' raffinato mentre il Montepulciano già comincia a diventare un vino un po' più pesante però anche una serata con l'Ambrusco fatto per bene delle nostre parti è gradevole perché l'hambrus come sapete si può mettere in frigo.Spero che volevate consigli di questo tipo giusto.Io direi che hai preso alla lettera il nome del nostro podcast.[Musica] sono le 7 e 17 di sera come diceva Leo io inizio anche a sentire del appetito quindi ci sta benissimo, gli supermercati sono aperti ancora esatto esatto quindi io vi consiglio insomma poi se vogliamo ancora se vi posso dare un consiglio è giusto così non so se siete appassionati di cucina romana però una buonissima una buonissima carbonara con un lambrusco so che sono due cose perché sono due regioni diverse però ragazzi bisogna anche essere aperti un po' di mentalità su questa cosa una buona carbonara fatta per bene quando fanno a Roma adesso c'è l'acquolina qui che fortuna che un podcast e non si vede niente è anche una cosa molto molto buona.Poi se andiamo sul pesce però ci vuole un bel vino bianco frizzantino anche un pignoletto una cosa del genere secondo me può andare anche bene.Io ho questa voglia di incontrare Gabriele di persona per esplorare meglio tutti questi ballon.va discussa meglio in presenza.Informatica ce visco poco, non c'è pepe, ragà, quando volete.Benissimo, benissimo.E questo fa di te uno di noi.Allora, se volete metto io il mio balocco, che tanto non c'entra niente con la puntata, come mio solito.Allora, io vi suggerisco un podcast che si chiama "Fucking Genius", è stato rinominato da poco in "Fottuti Geni", dove ogni tanto non è molto regolare, però viene raccontata una storia di persone che, come dice la sigla, hanno cambiato la traiettoria dell'evoluzione della specie umana.Io, per dirmi, sono ascoltato due volte, a mesi di distanza, la puntata su Albert Einstein, perché poi chi lo racconta è Massimo Temporelli, che è un divulgatore scientifico bravissimo, molto piacevole, super ispirazione, raccontate un po' di storia, le puntate non sono lunghissime.Questo è il mio suggerimento.Grazie.Poi inizi tutti i link nelle note dell'episodio.Grazie.Grazie.Gabriele, ma tu, scusa Mattia, ma tu hai anche un altro balocco per noi, giusto? Allora, io in realtà ho un libro che secondo me tutti quanti devono leggere, data intensive punto net che è un libro, questo però seriamente, ma anche quello prima, questo qui è un libro bellissimo che assolutamente da leggere, ma bello bello bello bello bello.Io ho scritto anche all'autore, gli ho detto guarda sei riuscito a rendere una cosa estremamente complessa in un modo, una cosa così complessa, l'hai raccontata in un modo così semplice che quasi imbarazzante.Su Unseable c'è l'audiolibro? Io mi sono ascoltato l'audiolibro e ti giuro non ho avuto bisogno di leggere il libro.Da quanto era chiaro, preciso, un capolavoro.Un capolavoro assolutamente, veramente un capolavoro.Mattia? Allora io invece lo sto leggendo, io ho questo viziaccio di consigliare i libri mentre li sto leggendo quindi magari gli ultimi cinque capitoli fanno schifo e negherò di aver mai consigliato questo libro, ma è piuttosto interessante.È di un tizio che si chiama Adam Grant, che è uno di quelli che scrivono i libri, quelli numero uno del New York Times, bestseller, fighissimi, che vendono mille copie.È della stessa nicchia di tipo Malcolm Gladwell, quella gente lì.È uno di quelli che, se tu vai sul sito del libro, l'headline è Daniel Kahneman, che ha vinto un Nobel che dice "questo libro non è niente male".Quindi fa parte di quel giro lì grosso grosso e scrive appunto saggi su cose.L'ultimo che ha scritto si chiama "Think Again" ed è praticamente un libro sugli unconscious bias che hai quando devi prendere decisioni e sui processi che portano te, i tuoi interlocutori e il resto del mondo, anche volendo, a riconsiderare i pregiudizi che potresti avere.È molto interessante, per esempio c'è un capitolo intero sull'irrazionalità del tifo sportivo e delle rivalità sportive, messe come paragone, come esempio di conflitti irrazionali a cui spesso siamo sottoposti e come fare a disarmare questo tipo di pregiudizi che sono ovviamente non solo sportivi.Per esempio potrebbe capitare anche, non lo so, che ci sia un linguaggio di programmazione che non a tutti piace e con cui però ci siamo guadagnati da vivere a un certo punto.Si vede che sei gobbo.Sono assolutamente gobbo.Il mio balocco.Io ne ho due.Allora il primo è un podcast giusto per seguire la linea che ha dettato Leo e si chiama Bitcoin Italia Podcast.al di là di tutto l'hype nel mondo crypto consiglio questo podcast perché in realtà è abbastanza equilibrato in alcuni tratti e soprattutto la cosa carina è che si parla tanto della parte tecnica quindi non ci sono consigli sugli investimenti o robe da schema ponzi o proposte di shitcoin e cose di questo tipo, ma per esempio se vuoi scoprire come funziona il lightning network o come funziona sotto il cofano più di una volta all'interno del podcast Guybrush che è uno degli host, dei due host, si mette a spiegare proprio tecnicamente come funzionano gli algoritmi.È questa roba per noi che comunque siamo un po' nerdozzi e divertente e piacevole da ascoltare.Avevo anche un secondo balocco che però in questo preciso momento mi sta passando dalla mente...Ah no, è ritornato! La community sa della qualità del mio inglese che è excelsa, altissima, no? Come ben sapete.Scherzo, fa proprio cagare.Quindi siccome un altro obiettivo del 2022 è migliorare l'inglese, ho beccato un'applicazione che è una figata assurda e la sto usando sia per migliorare l'inglese che per migliorare il francese.Faccio schifo in entrambi, quindi sono perfetto da quel punto di vista.Si chiama Buzu, con due U, ed è fatta veramente bene, ci sono degli esercizi, c'è la grammatica spiegata in modo assurdo, e soprattutto c'è un sistema di gratificazione continua e una community sotto che rende l'applicazione veramente veramente interessante.C'è una free trial, il prezzo è abbastanza accessibile, adesso non ricordo quale sia il prezzo perché ho comprato l'abbonamento annuale quindi l'ho pagato una volta, mi sono anche dimenticato, ma era qualcosa di veramente accessibile e devo dire che è fatta veramente bene, quindi complimenti e niente, io la uso tutti i giorni, sia mezz'ora per l'inglese che mezz'ora per il francese.nel 2045 forse, no scherzi a parte tra l'altro aggiungo questa cosa perché stavo perdendo una cagata, ci sono i vari livelli quindi A1, A2, C1 e lui stima, l'applicazione stima la data di raggiungimento di quel livello in funzione del piano di studi che ti organizzi, quindi tu dici io ho 20 minuti al giorno, un'ora al giorno da dedicare e lui automaticamente ti dice a giugno sei a livello C1 ed è veramente veramente figa.Interessante.Bello, forse ho trovato un replacement per TikTok la mattina.Quindi ti ringrazio molto.Anch'io con i con i vini di Gabriele.Due modi diversi.Leonardo, dove siete collocati fisicamente? diciamo.Il mio accento mi tradisce tanto.Io ora sono in questo momento in una location segreta al mare ma il resto sono di Firenze.Ah ok.Beh Firenze e Bologna si può fare.E uno la prima.Ah ma sta a Bologna.Sì sì.Ah io sto poco fuori Milano quindi l'autostrada da qua a Bologna è tutta dritta non c'è neanche rischio di prendere delle curve al ritorno è super facile.Dai.Raga io faccio qualche chilometro allora.Perché sto a quindi un po' di strada la devo fare però per bere la farei volentieri ecco abbiamo visto ho guardato l'orario insomma ormai l'obiettivo di stare dentro l'ora è sfumato appuntamente visto che ci stiamo avvicinando all'ora e mezza ma secondo me è fisiologica questa cosa che Gitbar deve durare un'ora e mezza e basta cioè non c'è storia intanto io ringrazio davvero Gabriele per aver accettato il nostro invito e per essere venuto a farsi una chiacchierata che è stata super piacevole qua su github.Abbiamo detto gruppo telegram oggi? No, no, no.Un problema, che facciamo? Lo diciamo? Dobbiamo rifare tutta la puntata.Diciamolo allora che abbiamo un gruppo Telegram che trovate scrivendo Gitbar e come dice Luca trovate la faccia di Brain Repo sul sfondo giallo è quello è quello è l'unico che esce fuori.Difidate dalle imitazioni.E ci trovate tutti lì con anche gli ospiti.C'è tutto siamo 627 l'ultima volta te l'ho visto.Insomma puntiamo ai 700 chiaramente.Due.Detto questo io direi che intanto voglio ricordare a Gabriele che da oggi Gitbar è un po' anche casa tua per cui quando ti va di berti un vino e ti sappiamo intenditore ormai in compagnia.No intenditore no bevo.Bravo bravo il vino buono è quello che piace.Hai paura di far arrabbiare gli enologi all'ascolto tranquilla noi ci salutiamo che ci ascoltano sempre gli enologi che gli vogliamo molto bene se voleste farci delle donazioni in vino comunque noi li accettiamo anche se non sono perpetual volevo dire una postilla avete notato che gli enologi non trovano mai l'uva quando assaggiano il vino? sì sì infatti era quello che volevo dire cari enologi io il sapore e l'odore di sella orientale spero di non trovarla mai la sella orientale cinese io non l'ho mai sentita però è buono lo stile.Sì sì siamo noi, siamo a livello base.Tutto qua scusatemi la...bellissimo no questa puntata è fantastica e iniziamo alla grande quest'anno.Ti dicevo Gabriele qualora ti venga in mente qualche argomento carino da condividere o hai piacere di venirci a ritrovare sai dove trovarci.Quindi grazie.Quando vuoi.Questa è anche casa tua.Noi ti ti ringraziamo a nome nostro e a nome di tutta la community e di tutti gli ascoltatori di Gnit Bar e quindi un sincero un sincero grazie grazie a voi a presto.Detto questo io e i miei compagni di viaggio Mattia e Leonardo ci avviciniamo all'uscita dobbiamo pure abbassare la clare di questo bar no? certo pulendo il bancone svuotiamo le spine della birra ovviamente esatto non sul pavimento si detto questo ragazzi noi ci diamo appuntamento alla prossima settimana con una nuova puntata di github facciamo una nuova chiusa ci diamo appuntamento alla prossima settimana qua sempre su github mi raccomando se non avete ancora fatto aprite la vostra app di podcast, possibilmente non Spotify, e iscrivetevi, fate la subscription, mi raccomando questo vi permetterà di ricevere ogni settimana la nuova puntata bella fresca.Se non vi siete iscritti nel gruppo Telegram iscrivetevi e se poi proprio proprio vi fa piacere Apple Podcast entrateci e andate a cercare il nostro podcast e potete metterci la stellina con il bel messaggio alla prossima ciao salute gitbar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con re repo parliamo di linguaggi e tecniche di sviluppo web di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei full stack dev [Musica]
