Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori Ho dato un'occhiata all'orologio, sono già le 9.20 della sera, naturalmente voi lo state ascoltando la mattina e noi siamo anche un po' bolliti Uso il "noi" perché non sono solo, ma prima di svelarvi il nostro ospite Vi devo ricordare un po di cosettine anzi lo voglio fare insieme a mattia ciao mattia come Ciao, ciao mauro ciao ospite di cui non abbiamo ancora fatto il nome Io sono in modalità smr perché ho mio figlio che dorme nella stanza di fianco quindi oggi avrò questa voce molto sexy Che figo tra un po github farà il suo canale twitch dove mattia sventolerà e soffierà sul microfono per far venire la pelle d'oca a tutti gli ascoltatori di Gitbar.No scherzi a parte ciao Mattia grazie per averci raggiunto Naturalmente vi devo ricordare i contatti info@gitbar.it e la nostra email @brainrepo e il nostro handle twitter e poi forse vuoi dire gruppo telegram? è il momento in cui con voce sua dente ricordo a tutti gli ascoltatori che abbiamo un gruppo telegram ebbene si abbiamo un gruppo telegram di oltre 500 arzilli giovani e giovanotte che si incontrano tutti i giorni a parlare del più e del meno dove appunto non si parla mai di RAL e dove questi giorni non si sono condivisi dei pseudo fake green pass lasciamo però questo argomento che prima o poi mi piacerebbe approfondire per presentare il nostro ospite 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.Ma devo fare l'accento svedese? Consumeran fantozzi? Così non si capisce di solo.Non l'avrete ancora capito allora lascio a Mattia lo stage per presentare il nostro super ospite di oggi.Ok il segreto di Pulcinella è che il super ospite di oggi oltre a essere un mio ex collega è un ospite di sicuro valore, ricco di argomenti interessanti e anche un mio amico.Si chiama Fabio Mora e appunto noi abbiamo lavorato insieme quando io lavoravo in eBay ormai 5-6 anni fa, può darsi, sbariati anni fa.Lui sa così tante cose, ha così tanti argomenti interessanti che anche adesso che non lavoriamo insieme ci vediamo e ci sentiamo spesso.Siamo usciti a cena la settimana scorsa, facciamo cena anche domani.Per cui io ammetto di essere un po' biased nei confronti di Fabio perché appunto ci sentiamo spesso, siamo amiconi.Però è anche per il fatto che lui ha scritto un libro super interessante che si chiama in cui compare anche il mio nome perché io l'ho letto in anteprima e gli ho fatto la tecnica al reviewer ma non per questo, non grazie al mio scarsissimo intervento, è un libro strafigo.Basta, in realtà questo è probabilmente quello che ha senso dire di Fabio rispetto alla puntata di oggi.Fabio, tu vuoi dire qualcos'altro di te? Ciao, ciao, grazie.Sono lusingato ovviamente, no, nel senso che ero contento quando mi hai presentato come Fabio, mio collega, perché ho detto "almeno non è tuo amico", invece poi lei ha detto "no, sto scherzando, va bene, al di là di queste battutine, Mattia è un mio grande amico e quindi sono contento di essere qui, ma sono qui col cappello di, posso dire, lo sviluppatore o almeno appassionato sviluppatore, appassionato dell'informatica e di tutto quello che ci ruota attorno.Quindi dell'invito prima di tutto Mauro e Mattia.Grazie a te di essere venuto ed è un po' in realtà che mi ero appuntato, ne parlavo a lungo con Mattia, dobbiamo avere Fabio, dobbiamo avere Fabio, dobbiamo parlare di The Vops come Dio comanda ed eccoci qua.Sì in effetti la storia è che quando Quando noi sveliamo questo backstage di Githubar, quando di solito viene un ospite, poi Mauro a fari spenti e dietro le quinte chiede sempre a tutti "Mai un ospite da consigliarmi? Dimmi qualcuno che sarebbe figo avere su Githubar" che è il modo in cui io sono arrivato su Githubar, nel senso che l'eccellente Alessio ha fatto il mio nome e nella primissima puntata di Githubar in cui c'ero io, in cui abbiamo parlato di Code Review, la primissima cosa che ho detto quando Mauro mi ha chiesto questa cosa, ho detto no assolutamente dobbiamo avere Fabio su YouTube.LM: e così finisce.DL: subentra volevi parlare bene di The Vox e hai invitato me e hai sbagliato credo.No beh no sto scherzando sono davvero contento è un po' che ci rincorriamo lo posso confermare ci siamo sentiti un sacco di tempo fa e sono passati dei mesi ma ce l'abbiamo fatta siamo carichi quindi.Sì, e sono super felice.Allora io ho già subito una domanda per te.Vai, spara tutto quello che vuoi.Tu oggi sei un professionista del mondo dell'IT.Come sei entrato nel tunnel? Oddio, stiamo andando… quante ore abbiamo? No, allora, allora, allora.Io sono una di quelle persone che si definiscono fortunate in questo senso, perché la cosa che mi piaceva da piccolo era poi, a parte i treni, perché i treni quelli piacciono quasi a tutti gli informatici.Ma anche a mio figlio che informatico ancora non è.Sì, ma io sono ancora piccolo e ancora mi piacciono i treni dentro.No, quindi ho iniziato a programmare veramente da molto molto piccolo e avvicinandomi al computer perché mio papà lavorava in falegnameria e c'erano delle macchine a controllo numerico e a me affascinavano molto questi laptop che erano con questi cristalli che si aggiornavano una volta ogni morte di papa e da lì vedevo che lui scriveva delle cose e succedeva che venivano fuori dei labirinti di legno perché era un pantografo, una macchina a controllo numerico e dentro questi labirinti scavati nel legno io giocavo con le biglie e forse questa cosa mi ha fatto venire in mente che con l'informatica si potevano fare delle cose da zero, praticamente dal niente, senza impiegare troppo sforzo e costruire qualcosa.Era una specie di superpotere.Quindi ho iniziato di lì, ho iniziato da molto piccolo, avevo una decina d'anni, credo, mi ricordo che già smanettavo su tutti i prodotti che erano legati al tempo, al mondo Microsoft, perché Linux era all'inizio.Stiamo parlando degli anni zero, quindi nel 2000.Sono arrivato al 2000 che smanettavo un po' sui cloud.LM: Ricordiamo che il 2000 era già l'anno di Linux sul desktop.sì sì sì era l'anno lì, si compilava il kernel, c'era il cd di suze in edicola, queste cose qui e ho iniziato di lì, ho iniziato perché l'informatica mi è sempre piaciuta, è la mia passione e quindi mi dava anche poi soddisfazione e poi ho avuto un periodo della vita in cui diciamo che sono dovuto per limiti esterni stare chiuso in casa e quindi avevo un computer e da lì ho cercato di usarlo nel modo più profondo che potessi fare, tirare fuori anche il sangue dalle rape di quel Celeron.Anche tu hai deployato qualche sito su Geocity, sì io lo so, io lo so, io lo so.credo di sì, credo di sì, io sono classe 90, libero, altervista, che aveva il php dentro, altervista, ho detto php, Raybaz non è morto, quindi sono sereno.E poi c'è stato il Lube Linux User Group, quindi che ho fondato, città che in realtà è un paese, ai tempi era un paese, poi è passato ad essere città, 15 mila abitanti, è pazzesco.Linux User Group, due ingegneri dieci anni più grandi di me, che già erano fuori dall'università e inseriti nel mondo del lavoro.Io ero molto affascinato da quello che facevano e da lì poi diciamo che Microsoft l'ho vista per, credo, un anno, perché non sapevo che esistesse Linux, ho iniziato a programmare in C e poi a scuola, in parola delle medie, andavo alle medie e facevo il LOOG, il Linux User Group poi il pomeriggio con loro, quindi argomenti tosti e io li apprendevo da loro, da questi due ragazzi, quindi sto parlando di C, sto parlando di facciamo la rete con NIST, YellowPage, il laboratorio, perché poi nel laboratorio cosa facevamo i corsi stile CDL, al tempo c'era le CDL open, si poteva fare con Microsoft ma anche con il mondo open, allora ho iniziato così e lì sono stati tanti anni belli nel quale sono cresciuto facendo un istituto tecnico-industriale, sono un periodo informatico e già lì, prima della fine del percorso, lavoravo perché ho iniziato a lavorare facendo stagio insomma e mi è piaciuto e ho continuato a farlo.Vabbè poi in realtà non è finita lì la mia formazione, non finisce mai la formazione.Diciamo che il primo contatto con il mondo del lavoro ce l'ho avuto appunto a 16 anni.Un po' come molti di noi.Hai parlato del pantografo e delle macchine a controllo numerico e parlando appunto della falegnameria un po' devo dire mi hai portato in quella situazione no? E da osservatore mi sono subito fatto una domanda, anzi questa ambientazione che hai ricostruito mi ha risollevato una domanda che è da un po' che gira sulla mia testa ed è quello che facciamo tutti i giorni è la fisicità delle cose.L'altro giorno parlavo con mio fratello che fa l'architetto e lui mi diceva "Mauro noi facciamo grosso modo un lavoro molto simile, sai però perché io non potrei mai fare il tuo lavoro perché le cose che tu vai a realizzare difficilmente o almeno quello che fai proprio tu io lavoro nel web non ha una materialità una fisicità e quindi sarei insoddisfatto nel non vedere la fisicità hai mai sofferto questo questo limite Sino… e quale può essere l'antidoto per questo tipo di… Ti direi… beh sì, di sì, ovvero in vari modi, in maniera più o meno diluita, succede, a me succede quando faccio qualcosa che poi non ha un impatto sulla realtà, ovvero fai quel genere di software che non risolve un problema che effettivamente era un problema che valeva la pena risolvere.Ricordiamoci che l'informatica poi è a valle della risoluzione dei problemi.Si può anche usare per imparare a risolverli, certo, però il risultato finale è che in qualche modo abbiamo risolto un problema una volta sola e poi l'abbiamo automatizzato.Quindi la prima cosa che ti risponderei è questa, se il problema che risolviamo non vale la pena di essere risolto, la questione, il valore che vogliamo generare non arriva, valore poi nei metodi agile è una roba un po' abusata, ma magari questo ce lo teniamo per più tardi.L'altra cosa rispetto al poter toccare le cose, quello io non lo sento tanto perché credo che l'informatica sia diluita in mille e mille risvolti e nel mio caso ad esempio, sì è vero, io ho fatto web, faccio web, lo faccio oggigiorno, la weekend, ma in tanti anni l'informatica l'ho declinata in tanti aspetti e in questi c'è stato anche fare elettronica prima di fare proprio informatica pura, quindi che so, sto sparando, mi facevo i pedalini della chitarra da piccolo, mi mettevo lì e saldavo e sopra lì magari poi si evolvevano queste cose, dal pedalino della chitarra fai il sistema di controllo della porta blindata, avevamo una sala prove con i turni, avevamo fatto il codice d'accesso con le porte blindate, sempre in quell'anno lì che ti dicevo, per far accedere le persone su uno schedule.C'era una seriale che andava poi a confluire in rete, c'era un sacco di software che faceva aprire quella porta e quindi per me quella era una cosa fisica, così come lo sono i pedalini della chitarra, così come lo è il software che c'è dentro uno smart.Non sono tanto d'accordo che l'informatica non si possa toccare, però posso capire… LM: è così come lo è anche il metallo delle macchine, so che tu sei un grande appassionato anche di amministrazione e configurazione dei server, del metallo e anche quello è una cosa che puoi toccare.LM: del basso livello? Sì, ovviamente, si dice i cloud, i cloud sono le nuvole, ma poi la fine del carattere… Io ho un ricordo di Matt che andiamo a smontare dei server da un ufficio di eBay per spostarli da un'altra parte e quelli pesavano, quindi mi ricordo che comunque un peso di informatica lì ce l'aveva.L'altra cosa che forse mi fa un po' più soffrire è che c'è molta fatica, faccio molta fatica, a come credo la maggior parte di noi, a raccontare quello che faccio nel momento in cui non è finito.questo è un po' il crucio di tutti quei lavori in cui si fa qualcosa di immateriale, non so se è il termine giusto, lavoro immateriale, credo ci siano delle sfumature, perdonatemi se non è quello super corretto, ma tutti quei lavori in cui fai delle cose che non si possono toccare ed è vero, qui soffriamo molto, ogni software che non è finito rimane nel nostro computer e nessuno lo vedrà mai.Io potrei lavorare 10 giorni una cosa bellissima, ma se poi non lo faccio vedere a nessuno rimane lì, è un semilavorato finito.Però il punto è che anche comunicare fuori quello che hai fatto è una forma di arte, è un certo punto di comunicare fuori.Si rischia un po' l'effetto Olimpiadi nel quale vedi l'artista, scusatemi l'artista Lapsus.Vedi lo sportivo che si è allenato, che arriva a prendere una medaglia d'oro e tu dici sì, vabbè, si è allenato, vedi un movimento che dura dieci secondi, che ti sembra fattilissimo, di un'eleganza spaventosa e dici vabbè, posso farlo anch'io.In realtà ci sono ultimi magari vent'anni per arrivare lì, no? E tu stai dall'altra parte dici cavolo io sto facendo questo movimento, ho vinto magari anche questa medaglia, come faccio però a far capire che ci ho impiegato 20 anni a arrivare qui a questo risultato? Quindi forse questo è un po' il rammarico che c'è nell'informatica, la difficoltà di dover comunicare fuori qualche cosa nel momento in cui ancora il software non funziona.Ma con gli sviluppatori Rockstar però un po' questa tendenza si sta invertendo, cioè ci sono persone che sono diventate gli uomini più importanti del mondo partendo dalle righe di codice, questa cosa non ha aiutato? Sì sì sì credo però che, in un parere personale, In quei casi, Rockstar, quindi immagino che ti riferisca ai vari imprenditori a partire da Elon Musk, a Bezos, a Gates e via dicendo, credo eh, ho capito bene.Sì, a Zucco.Sì, lì l'informatica è importante, è una parte però, l'informatica sta in un contesto di risoluzione di un'esigenza.Loro sono stati bravi anche a intercettare qual era quell'esigenza, è una parte della torta l'informatica in quel caso, ma c'è da dire che in quel caso c'è la brillantezza di riuscire a capire che questo è un problema interessante e riesco a battere tutti i costi marginali che ci sono in quel modo di fare vendita di libri per Besos e poi evoluzioni successive, c'è l'intuizione dell'abbattere un costo marginale e di portare a termine con un atteggiamento da imprenditore, quindi con una forte vena imprenditoriale che prescinde la sola conoscenza informatica.Si può essere dei bravissimi programmatori, ma se si è inserito in un contesto che è una bolla in cui si risolvono più o meno sempre gli stessi problemi e magari quei problemi sono inutili, è tutta un'ottimizzazione locale per dirlo un po' al sistema engineering, vado a lavorare su qualcosa che nel contesto generale non importa ed è un grande spreco ovviamente.Cambiamo per un attimo argomento, in realtà è collegato, però voglio un po' farmi fatti i tuoi.Guardando nel tuo LinkedIn ho visto che nel tuo percorso professionale hai fatto un passaggio particolare che in realtà non mi sarei aspettato generalmente non ci si aspetta è il passaggio da lavorare in una grande società una dot com con una sua credibilità una sua dimensione delle sfide anche con una portata in termini di valore importante al passare al mondo del freelance facendosi carico poi di una serie di altre problematiche e tu hai fatto questo passaggio, questa metamorfosi, allora ti chiedo, se naturalmente ce lo puoi dire, cosa è che ti ha portato a fare questo cambiamento e soprattutto quali sono gli elementi, le differenze sostanziali dell'approccio al lavoro in questi due ambienti? Tosta, tosta questa, questa.Dunque sì è vero, ho fatto quel passato.Quanto tempo hai per la risposta? Possiamo parlare di alcuni momenti? Provo ad essere interattivo incrementale, così vediamo, posso aggiungere dettagli.La prima versione in cui ti posso raccontare questa cosa è che non era la prima volta e quindi per me è stato più facile, perché fuori dalle superiori, come ti dicevo, io ho iniziato da freelance, ho iniziato da freelance e poi ho fatto di nuovo il dipendente perché volevo studiare, nel frattempo avevo fatto un'azienda, un'SRL, di quelle che oggi si chiamerebbero start up, solo che ci avevo messo i soldi miei con dei soci e poi l'abbiamo venduta e poi da lì sono arrivato in quell'azienda, in quella dot com che tu hai visto sul mio LinkedIn e questo dove c'era Mattia, dove ci siamo conosciuti.Abbiamo detto era ebay, no? Sì, sì.E cosa è successo? È successo che a un certo punto, io ho fatto quell'esperienza perché io volevo essere più bravo tecnicamente e pensavo che andare a lavorare in un contesto di quel genere mi avrebbe dato la possibilità di imparare, di essere come si dice in altri contesti, l'uomo più, la persona più stupida nella stanza.Purtroppo per te però c'ero io il più stupido nella stanza.E quindi questa cosa ha avuto una validità piuttosto longeva, fin tanto che questa cosa è venuta un po' meno per dei motivi che non sono legati all'azienda, sono principalmente legati a me, avevo voglia di cambiare, avevo voglia di fare altre cose, perché appunto la mia natura è quella di essere un po' più freelance.Sono nato così, mi sento un po' costretto nell'essere dipendente, oddio l'ho detto, non mi assumerà mai nessuno nella vita adesso.In realtà ci sono alcuni modi di lavorare che secondo me oggi giorno sono un pochino antieconomici, mi vanno stretti e volevo provare delle cose nuove.Se lì programmavo molto, sono andato a lavorare in una situazione in cui avevo molto da imparare, sono andato a fare il coach, quindi il coach XP, extreme programming o agile, poi ho fatto anche Scrum, altre cose e di lato ho continuato a programmare, ho continuato a programmare per altri clienti in maniera minore, programmavo sempre, mi sono sempre tenuto l'attività di lato e questo è stato il passo, però la spinta è stata che io volevo fare qualcosa di diverso, era il mio desiderio, quindi mi sono dimesso, non era la prima volta che mi mi dimettevo nella vita, mi sono dimesso da almeno tre contratti a tempo indeterminato, almeno sì.Spero di non aver detto delle cose irrispettose.Assolutamente, tra l'altro io ho fatto il percorso inverso, quindi capisco bene la ricerca di quell'equilibrio tra la libertà individuale, lo stimolo, il contesto, è un gioco con una serie di pedine per cui suona assolutamente logico.Dipende sempre dalle persone, no? Entrambi i contesti mi hanno reso felice dal punto vista sia professionale che poi di connessioni, cose imparate, persone conosciute, sono due approcci proprio alla vita direi, molto diversi.Però se sei in una dot com diciamo che ci sono dei sistemi anche nelle dot com per stare, diciamo, galleggiare, dove più dove meno, però la cosa bella di stare in aziende così grosse e con quel genere di cultura è che tu puoi chiedere quello che vuoi a chiunque, quindi se vuoi…fisicamente noi eravamo in Italia, per carità, sì fisicamente abbiamo lavorato tantissimo in Italia, però nel momento in cui c'era un'esigenza di avere conoscenza più verticale o un confronto, tu avevi ingegner che stavano sparsi un po' per il globo con un background un po' diverso da quello che potresti trovare diciamo in un'azienda che non ha come mission il software, l'ho detta Nessuna azienda fa soldi con il software, potremmo non scrivere il codice, saremmo più contenti di non scrivere, però l'idea è quella, aziende che hanno un core tecnologico molto molto forte.LM: Si si, concordo.LM: E aggiungo, oltre a essere una tech company, che è un fattore che fa una differenza secondo me a quello che volevi dire ma che non hai detto è, che era una fucking billion dollar company, quote unquote.Sì però se no sporo.Allora visto che comunque il tempo sta correndo e io avrei tonnellate di domande da farti e visto che parli in lungo e in largo di Agile e di DevOps allora apriamo lo sto argomento.La prima domanda che ti faccio è come sei arrivato a scoprire il mondo di DevOps e che cos'è questa metodologia, chiamiamola così? Ma se ti va chiamiamola metodologia.Dunque, la definizione che mi piace di più di DevOps si può andare.No, non ce n'è una in particolare.Ormai so che sta… c'è una parola che si si chiama un epiteto che è diffusione semantica, di Martin Fuller, un termine che si diffonde nell'ambiente talmente tanto da diluirne il significato e a quel punto perde varore.Diciamo che per me DevOps è la naturale prosecuzione di quello che già erano i metodi agili per lo sviluppo di software e se lì c'erano dei problemi, sono nati in un contesto ben specifico e risolvevano in quel periodo storico, davano delle risposte ai problemi che le aziende avevano, soprattutto quelle private e in contesti specifici bastavano alcune cose che ci hanno fatto lavorare per tanto tempo, detta male, dicendo ok, facciamo le cose iterative, incrementali, applichiamo metodi agili perché lavorare bene, lavorare con crisi, ma lavorare in modo curato paga, lavoro bene perché lavorare bene paga.Questo era un po' quel tanto che ci bastava per essere motivati ad andare in quella direzione e ha sempre funzionato, nel senso che i risultati credo che oggigiorno nessuno possa etichettarci un più come gli hippie che fanno Agile al posto del Waterfall, sono un po' andati coi tempi, io credo personalmente, almeno per quanto riguarda l'approccio, se una persona oggi giorno parli di Agile, puoi parlare di agile addirittura alle grandi società di consulenza, anzi sono loro oggi che si ergono in cattedra.DevOps è la naturale prosecuzione di questo modo di fare software che già era una buona idea, che a me piace molto nella formulazione di Xtreme Programming, ma ci sono moltissimi modi di fare bene software in maniera agile, quindi interattiva incrementale.DevOps dice ok, passiamo dal campo qualitativo, facciamo bene, al campo quantitativo, quindi mettiamoci attaccati dei numeri.E da lì i numeri che trovate in DevOps vengono spesso e volentieri da quello che è il Lean, il Lean che era già qualcosa che veniva utilizzato, il Lean che esiste anche nei metodi agili, è uno dei metodi Lean for software development di Pop and Dick, però il Lean per la produzione discreta, quella di oggetti fisici viene da una casa automobilistica che era Toyota, che aveva appunto dei problemi.Quindi ci sono un sacco di nuove in questa cosa, perché il Lean è passato anche attraverso un altro punto di svolta in questi anni, che è un libro che probabilmente avete già sentito che è The Product Development Flow di Don Reinerstern, poi lo linkhiamo perché non ci siamo provati niente, quindi sto andando tutto a memoria stasera.E' questo libro che è un po' la svolta dell'in e del product development porta assolutamente in campo quantitativo tutte queste tre cose che ho detto, quindi metodi agili, il lean per la produzione in realtà di prodotti, qualunque genere siano, e se aprite questo libro trovate teoria delle code, trovate formule, dispersioni, integrali, grafici, trovate la storia di come sono stati inventati i protocolli di rete, come sono di rete e come questi possono aiutare nel dimensionare dei centri di elaborazione di qualche genere di unità di flusso e quindi questo è, secondo me il DevOps è un agile in campo quantitativo prima di tutto.Andando a livello pratico però, quali sono i problemi che DevOps va a risolvere, i problemi ideali, quelli da tutti i giorni? Allora, qui mischio un po' le cose, nel senso che per me DevOps nasce una conferenza di metodi agili, ne parlo in modo un pochino indistinto, perché secondo me già li risolvevano un sacco di formulazioni agili quei problemi.DevOps diciamo che è un, come dire, a un A un certo punto il mondo esterno, soprattutto quello dell'hardware, è cambiato, il modo in cui veniva consegnata la potenza di calcolo, mettiamola così, la capacità di elaborazione, di fare networking alle aziende è cambiata, è arrivato appunto il cloud che si svegava da dei limiti fisici e quindi abbiamo potuto fare una cosa molto semplice che è applicare informatica all'informatica, quindi gestire i sistemi con l'informatica, che è una cosa un po'… dovrebbe essere naturale, se è un informatico invece di dare i nomi ai server dei Pokémon oppure di Dragon Ball, quelli sono server, per cui sono macchine, si potrebbero gestire con l'informatica.A un certo punto la tecnologia ha permesso di fare questa cosa e noi l'abbiamo fatta.E quindi il sistema engineering è diventato di fatto a pieno titolo software engineering, così come software engineering del prodotto.Io non vedo grosse differenze nel senso che sono cose che chi poteva farle le ha sempre fatte, si è scoperchiato il vaso di Pandora.Non so se sia risposto bene.Quindi praticamente il compito di DevOps è quello di utilizzare le tecniche, gli strumenti che utilizziamo tutti i giorni per lo sviluppo di software legati al prodotto, nell'ambito appunto dei sistemi? Se ci mettiamo il cappellino da software engineer, quindi da tecnici in generale da tecnici sì sì dai mi sembra una buona approssimazione.Poi potremmo andarsi a vedere sul Dora, il DevOps report, se la definizione è giusta, potremmo anche farlo.Io in questo momento momento voglio chiacchierare più volentieri con voi, quindi non lo sto facendo.Però c'è un sacco di business, dall'altra parte c'è un sacco di business.Si.Assolutamente, è un prato di un pezzo.Se posso inserirmi un attimo, a me è piaciuta molto una cosa che hai detto rispetto al fatto che è una cosa che è emersa nel momento in cui c'era la tecnologia per farlo, quindi nel momento in cui fare Systems Engineering era una cosa che si poteva fare scrivendo del codice ed è venuta fuori a un certo punto perché qualcuno ha detto "beh noi facciamo questa cosa fondamentalmente perché possiamo" perché molte delle cose fighe dell'informatica sono venute fuori anche in questo modo.Sì, sì, sono super d'accordo.Poi sai, dipende dal periodo storico in cui lo dici, ogni tanto ci sono delle situazioni in cui sento "eh, però noi da aziende o organizzazioni in generale, noi non riusciamo a deploiare una volta a settimana, non riusciamo a deploiare una volta al giorno.E non lo so, io quando sento queste cose nel 2021 penso un po' che non c'è motivazione, non c'è voglia di sbattersi per far funzionare queste cose, la motivazione è a monte di questo compendio di discipline che è l'evops, si può applicare in mille gradi, si può giocare a pallone così come si può giocare a pallone per divertirsi, si può giocare in serie A e in mezzo ci sono migliaia di sfumature e la stessa cosa, se vuoi fare quello che fanno le dot com e quello che fa ad esempio Google, cito Google perché SRE, Site Reliability Engineering, di fatto è una versione, un'implementazione di DevOps, anzi è precedente se proprio vogliamo dirla correttamente, però certo per fare Google per arrivare a quei risultati devi comportarsi in una certa maniera, devi veramente studiare tutti i giorni, avere un team che ha voglia di farlo, una motivazione alla base.Abbiamo parlato di DevOps come metodologia, naturalmente DevOps dietro di sé nasconde anche dei nuovi framework di comunicazioni tra ruoli nella definizione del processo.Però la mia domanda è un po' diversa.Con l'Agile abbiamo visto che strumenti e tecniche alle volte sono state usate oltremisura generando dei danni o comunque provando ad attaccare tecniche in dei contesti dove a) non si erano capite bene b) dove probabilmente non fittavano abbastanza.La mia domanda è, nell'ambito dei sistemi esistono, questa è più una curiosità, dei contesti dove DevOps potrebbe essere inutile o controproducente? Assolutamente sì, come tutte le soluzioni, come tutti questi modi di fare informatica, queste metodologie hanno a che fare purtroppo per fortuna con i sistemi complessi dove tu prelevi qualche cosa e non lo puoi prendere e spostare in un altro contesto, perché quella soluzione lì smette di funzionare.Mi riferisco tutta alla questione del Canadian framework, di Snowden o Sinefim, come ne si fa lo spelling in Italia.Diciamo che già con i metodi agili valeva il fatto che se tu hai una cosa che butti domani non ha senso mettersi a imbastire tutta una serie di pratiche e procedure che garantiscano che la curva del costo del cambiamento rimanga piatta.Quello è il motivo per cui sono interessanti sia i metodi agili sia DevOps, dal punto di vista business, di cui non abbiamo parlato prima.Perché non vorrei che vedessi "ah Fabio ha detto solo che DevOps riguarda i tecnici".No, attenzione, non abbiamo finito.Quindi, primo caso che mi viene in mente è quando tu hai una cosa e butti il giorno dopo.La seconda cosa, ti direi tutte quelle volte in cui sia i metodi agili sia DevOps vengono applicati come "ah ok, ho preso il libro, nel libro c'è scritto CALMS che sta per Cultural In Automazione S-Sharing M-Metrics" che è l'acronimo con cui spesso viene popolarizzato DevOps, divulgato DevOps.Ok, facciamo tutto, via, qui c'è il playbook, ok, siamo agili, sono ottimi punti di inizio, tante volte si va a giocare con gli stati d'animi delle persone, con la pazienza delle persone, la richiesta loro di fare degli sforzi molto grandi per smettere di imparare qualcosa che fanno bene, insomma sono cose molto delicate, quindi prendere queste cose con la cargo culture, credo fosse Steve McConnell che diceva, che che diceva, c'era questa storia per cui il culto del cargo, credo fossero i polinesiani che vedevano le navi cargo passare all'orizzonte nell'oceano e si chiedevano che cosa fossero, no? Aiutami Mattia perché non mi ricordo poi tutta la storia, però fatto sta che vedevano delle cose di cui non capivano, vedevano gli aerei nel cielo ad esempio e loro emulavano ciò che facevano le culture più avanzate che osservavano e quindi speravano che solo facendo una pista di terra con una torretta e una bandierina, ok, quello è un aeroporto.Purtroppo non funziona tanto così.Lì si rischia di fare un po' più danno, quando vuole fare la trasformazione agile a tutti i costi, senza avere la giusta motivazione alla base, ci si mette in pericolo.Sto cercando un ultimo esempio per arrivare a tre, forse diciamo dove questa me la gioco da Weinberg, che è un autore super prolifico, se vi interessa andatelo a googolare.Lui descriveva vari modi in cui si può sviluppare software, credo che fossero cinque, però in questi ce n'era uno che, vi ripeto, siccome non abbiamo preparato quasi niente, non ho appunti, in cui c'è un momento nello sviluppo del software in cui c'è un cliente, c'è un programmatore e c'è un utente, o utente una persona che lo usa, il software.Quindi non sempre questa situazione avviene, nel senso che se io sono in un ufficio e so un po' programmare, faccio il commercialista, sto scrivendo una cosa su Google Scripts che mi è attaccata a Google Drive, ecco quello è fare software engineering in un certo senso, solo che il cliente sono io per me, quindi non c'è una separazione, non c'è un utente.Lì non lo so, ha senso fare DevOps? Sicuramente ha senso in queste situazioni in cui il contesto è molto piccolo, non c'è un team o magari il team sono due o tre persone, oppure c'è un gruppo di persone e non c'è un team, e prendere le pratiche tecniche senza esagerare troppo con il resto.Lì credo che...Pratiche tecniche quindi continuous delivery, continuous integration, test e via dicendo.La mia domanda adesso però per un attimo vuole spostarsi al mondo del business perché ne abbiamo accennato e quindi prima di parlare di pratiche e di parlare delle cose che un ci emozionano e che usiamo tutti i giorni.Getty container, quindi kubernetes vari.La mia domanda è quali sono gli strumenti che possiamo utilizzare per misurare l'impatto di di queste pratiche nel business.Come possiamo renderci conto che sta roba funziona nel nostro contesto? Beh ci sono ovviamente… la risposta diciamo da libro o da blog post è che ci sono ovviamente delle metriche comuni che hanno a che fare con il lead time, il process time, le SLA quindi quanto service level agreement, quanto siamo up, quanto siamo bravi a recuperare dopo un incidente, quanto va dritto un deploy quando lo facciamo, complete and accurate ad esempio.Ci sono un sacco di metriche, quindi diciamo che le metriche in base al problema che dovete risolvere potrebbero essere un metodo, come dice un mio amico ex coinquilino collega Jacopo Romei un metodo per salire sulla bilancia.Quando ho lavorato tantissimo con Jacopo e ho imparato un sacco da lui, mi ha sempre raccontato che se tu vuoi dimagrire puoi andare dal dietologo, però lui non farà il lavoro per te, tu lo pagherai.Il punto è se poi ti fai la pasta a mezzanotte, 100 grammi di pasta, ecco forse devi fare un po' pace con te stesso, perché forse è meglio che o smetti di pagare il dietologo oppure approcci il problema in un altro modo.LM: Credo che lui abbia detto esattamente queste parole quando è stato ospite a Geek Battle.è una cosa che è molto famosa, non mi stupisce, è una storia che racconta spesso e che funziona molto, quindi i credits sono suoi ovviamente, io ho un report speech.Tornando alla nostra domanda, quindi sceglierei una metrica e cercavi di capire se queste pratiche tecniche ci fanno avvicinare, quindi misurarci in qualche maniera.La seconda cosa è cercare di capire, di nuovo se si è in un contesto in cui quello che stiamo cercando di risolvere è rilevante davvero, cioè stiamo generando un, uso questo termine, un pochino abusato, magari poi lo spieghiamo in un altro momento, valore per quello che sto andando a automatizzare, quindi automatizzare con l'informatica.Quindi se io sto facendo un software per la radioterapia e sono un biomedico, probabilmente ci sarà un significato se sto facendo ed un impatto, e di conseguenza dovrò attrezzarmi per muovermi in un perimetro di rischi, di forecast, di budget di stakeholder che ha un determinato genere, cioè che ha determinati requisiti.Dall'altra parte se faccio software, faccio dei videogame, potrei permettermi di scrivere facendo esperimenti molto rischiosi perché alla fine al massimo è una partita che si interrompe.Certo mi verrebbe da dirti dillo a quella società polacca era che ha fatto… come si chiama il gioco? Project Red, quelli di Cyberpunk.Esatto, quelli di Cyberpunk.No vabbè adesso ovviamente sappiamo che il gaming è una roba molto seria ma ovviamente tutte le cose hanno valore.No no no capivo era solo una battuta lanciata la Fabio tranquillo.Non voglio ovviamente offendere nessuno.Dalla parte ci sono le persone che potrebbero morire dall'altra è un po' più difficile.Era chiaro quello che volevi dire, ero io che avevo solo voglia di cazzeggiare un po'.Hai tirato fuori un argomento molto interessante, ne hai parlato già in un talk che hai fatto per Code Emotion, però io ci voglio ritornare anche qua su Gitbar perché secondo me è importante cioè tutte queste queste tecniche ma le tecniche separate dall'approccio complessivo e della vision generale secondo me non portano lontano quindi proprio quest'approccio al modo di automatizzare tutto quello che è il processo di creazione e di rilascio del prodotto.Hanno un impatto anche sui rischi che in questo percorso si possono, sui pericoli che in questo percorso si possono presentare? Sì, allora il talk che ho fatto a CodeMotion, diciamo che se quello che hai visto che ho chiamato Human Factor, allora quella era un'idea che mi è venuta perché di fatto negli ultimi mesi ho cercato di riavvicinarmi a una cosa che mi piace molto che è fare on call, che è fare incident management, quindi fare proprio in un certo senso l'SRE, site reliability engineer, e mi sono accorto che studiando queste cose ci sono delle similarità, ho lavorato anche con clienti che appunto avevano quel genere di problemi che ti dicevo prima da risolvere, quindi non semplicemente più il sito web su quale vendi qualcosa, ma magari più delicato, biomedico, sanitario, cose del genere.Quindi mi sono chiesto chi già facesse meglio di noi, noi informatici, questo genere di gestione delle procedure.Alla fine anche noi abbiamo un'unità di flusso nei nostri flussi di produzione, produce il software, il software deve essere funzionante.Quindi ho detto associamo chi già fa bene e quindi i contesti sono due, l'aeronautica nel quale una fatalità ha un costo molto elevato, ma nello stesso tempo statisticamente avvengono degli incidenti, avvengono anche nei nostri sistemi gli incidenti, lì però la differenza è che l'esito degli incidenti generalmente è soddisfacente, ovvero l'errore non si propaga.Quindi già lì ho detto, va bene, vediamo cosa fanno in aeronautica e ho scoperto che c'è proprio tutto uno studio, una disciplina che si chiama Human Factor, che l'informatica sì, magari c'è in qualche ISO forse, in qualche CMMI, però c'è mai venuto in mente forse, o magari sono io che sono ignorante e che questa cosa non l'ho mai sentita.L'altra roba che invece secondo me si mappa più su delle cose divertenti è la medicina di emergenza, cioè se voi guardate un pronto soccorso o chi veramente fa incident management di quel genere, fa tutta una serie di cose che hanno sempre a che fare con il human factor, la disciplina, l'area di studio è la stessa, declinata da una parte in aeronautica e dall'altra parte in medicina.Poi ovviamente quello che fanno come pratiche sono declinate in modi diversi, così come in Lean, cioè del Lean di Toyota puoi salvare il modo di pensare, ma non le pratiche che diventano extreme programming, quindi un'altra cosa.Lì puoi salvare il modo di pensare, di fare human factor, di capire come ragiona chi fa, chi considera l'elemento umano nell'informatica e andare scopiazzare quello che fanno e così scopri che come noi diciamo standardizing the environment, quindi Git, gli stessi strumenti, lo stesso modo di fare test, le stesse pipeline con quel flusso, loro dicono ad esempio la stessa planimetria e le stesse macchine di pronto soccorso e tutte dello stesso modello di fianco ai letti di ospedale, oppure ci sono delle procedure nell'area un'africa come il cabin crew cross check, cabin crew cross check non che lo fanno perché si divertono, lo fanno perché ci sono le procedure che in post mortem, e anche noi facciamo i post mortem, vanno ad aggiustare tutta una serie di processi che prendono l'essere umano e dicono ok, siamo fallibili, facciamoci qualcosa e non continuiamo a lamentarci perché questo è un vincolo che non possiamo… cioè siamo umani, sbaglieremo sempre, le macchine sono meglio di noi, dal punto di vista della precisione, almeno e quindi ho fatto questa analogia tra le due cose.È una roba ancora che mi sta frullando in testa, non so se avrà una forma ancora più definita però questo è un po' l'idea.Io credo di sì, sai, questo tipo di approccio io per per tanto tempo ho definito l'approccio all'informatica in genere come un approccio di tipo artigianale con una buona dose di critica evidenziando proprio il lato meno buono dell'artigianalità cioè non vedevo almeno in molte realtà italiane un approccio industriale all'informatica.Se tu vai nel mondo dell'automobile per rilasciare un automobile tu devi superare una serie di certificazioni.Questo rende tutta l'industria, tutto il comparto molto più rigido, molto più rigido ma nel contempo lo rende molto più resiliente molto più tra virgolette industriale molto più sicuro molto più standardizzato.Il mondo dell'informatica oggi attraverso questi approcci attraverso una certa attenzione sulla qualità del software che però è una tensione di tipo processo non l'artigiano che vede bene che il suo software sia bello e funzioni bene.Questo forse è il momento giusto questo parlo in Italia probabilmente nel contesto globale questo passaggio è già avvenuto però nel nostro contesto nazionale è forse il momento giusto e sono una serie di elementi che si stanno andando a unire per portare proprio un comparto da un approccio un po' più artigianale a un approccio un po' più industriale.Perderemo forse un po' di agilità nel senso lato, nel senso delle metodologie? Non lo so però probabilmente ne guadagneremo in qualità del software ed essendo oggi il software così importante nelle nostre vita e per cui è sbagliato dire "ma che impatto avrà un Facebook? Non è come un ecografo".Eh, parliamone! Perché se i medici di pronto soccorso, come ho visto io, comunicano con i propri colleghi per avere ulteriori informazioni attraverso le chat di Facebook, sbagliato per quanto può essere, l'importanza di quello strumento è altissima.E' pervasivo.Eh sì, l'abbiamo visto quando è andato giù qualche settimana fa Facebook e tra i seggi elettorali non riuscivano a comunicare.Ma Cristo santo puoi utilizzare Facebook per comunicare in questo tipo di situazioni? Va bene, però questo ne delinea un'importanza e una pervasività, come dicevi tu, del software nelle nostre vite.Per cui software non si può più permettere o almeno una parte di software non si può più permettere di essere artigianale specie perché l'importanza del software nella vita delle persone non la sceglie chi fa il software la sceglie l'utilizzatore.Ti ho perso un attimino sull'ultima l'importanza la scegli l'utilizzatore? Cioè con che grado io voglio farmi coinvolgere a questo ti riferisci? Allora io sono uno sviluppatore.Allora io credo quanto quanto ti viene male quando va giù Facebook.Ah ok.No nel senso che se io uso Facebook come unico mezzo per comunicare con la mia famiglia in una condizione d'emergenza, forse ho un problema.Ledo: guarda, sì, non so se questa cosa ha a che fare con l'informatica, però, o meglio, sono d'accordo che questa sensibilità debba esistere.Mattia tante volte io faccio questo ragionamento con lui e mi dice "però siamo nel 2021".Ed è vero, a tutti piace una novità, a tutti piace usare giocattoli nuovi, soprattutto non informatici e è la consapevolezza che c'è di mezzo, c'è uno strumento per ciascuna esigenza.Nel momento in cui viene mancare, soprattutto in contesti critici, la capacità di vedere cosa c'è sotto il cofano di alcune soluzioni software e lì si può generare un problema, una disfunzione, un uso improprio.Sono temi che secondo me hanno a che fare con altri punti dell'informatica da cui siamo già passati, ad esempio prima citavo Pop&Dick con il Lean Software Development In realtà la signora Popendic ha qualche decade più di me, ha una grafica e già lei parlava di Responsible Software Engineer negli anni '70 addirittura, lì forse mancava il mercato, lì forse mancava il coinvolgimento, però gli informatici sono anni che dicono queste cose, così come probabilmente lo dicono i biologi, gli ecologisti che stiamo andando gli ecologisti che stiamo andando in una situazione che sarà molto calda, piena di anidride carbonica, ma nessuno ne frega niente di fatto.Ci sarà un momento in cui l'urgenza ci farà quelle robe, ci porterà a dover adottare delle soluzioni che sono tipo, sarà il paragone informatico con "andiamo a mettere i teloni sul ghiacciaio, perché così non si scioglie".È una cosa vera, Google ha trattato.Quindi la nostra bravura forse sta da divulgatori, se vogliamo provare a raccontare fuori l'informatica e far capire alle persone, dare degli strumenti le persone più che altro, insegnarle a pescare, non dare il pesce nella cesta, per capire, per fare in modo che quando tu parli con un adolescente e gli chiedi cosa succede quando tu mandi un messaggio su WhatsApp o su Telegram a un tuo amico che è dall'altra parte dell'Italia o dell'Europa e lui ti riguarda e ti dice "scena accaduta, va al satellite, va a va al satellite e scende.Ecco, nel momento in cui stai guidando una Ferrari, ma non sai bene se ci sono i freni o no, però sei lanciato a 300 all'ora sulla quattro.È un conto che tu quella cosa lì la fai perché vuoi, perché ti vuoi divertire, perché sei in un contesto sicuro dove puoi sbagliare, è un conto che la fai mentre scrivi il software di controllo di un aeroplano e dici deliberatamente "ok, ci sono delle ISO, ci sono dei test, ci sono tutta una serie di checklist, però vabbè siamo in ritardo, questa suite di test la disattiviamo e anche questa è una cosa che purtroppo è successa e lo dice l'ICAO, non lo dico io, in dei documenti, ad una nota compagnia aerea.LM: Tra l'altro io vorrei aggiungere una cosa rispetto a questa cosa che è vero e mi piace tantissimo il tema di cui parli tu rispetto alla divulgazione dell'importanza di avere un po' di alfabetizzazione informatica e di capire un po' cosa c'è sotto il cofano, almeno un'idea generale tra chi appunto è utilizzatore.Ma secondo me c'è un tema gigante anche di far capire l'importanza di quello che facciamo e di com'è importante farlo bene anche per chi fa il nostro mestiere.Un momento in cui noi siamo parte volentieri o nolenti di una scena, di una comunità di sviluppatori che ha un impatto gigante sulla sua età, nel senso che comunque Andersen, che non è esattamente l'ultimo degli stronzi, ha detto che software si è mangiato il mondo ormai un discreto quantitativo di anni fa.Quindi quello che facciamo noi di mestiere ha risvolti in diverse, praticamente tutte le pieghe della società in cui viviamo.Mi piace un sacco dire "viviamo in una società" quando parliamo di questa cosa.Io sono tendenzialmente contrario all'argomento che comunque in realtà è molto comune, di dire "beh, se io faccio il mio sviluppatore web non salvo le vite", che è vero, nel suo...in the small è vero, è assolutamente vero.Però è vero anche che io faccio software e io quindi lavoro in un campo che ha impatto su potenzialmente tutto.Io, nel mio piccolo di carriera, lunga ma nemmeno troppo, perché lavoro da 15 anni, ho fatto, oltre a lavorare per una dot com, quando lavoravamo insieme ho fatto il motore di calcolo dell'energia elettrica, ho fatto software di logistica, adesso faccio software di commerce, ho lavorato a software per le pubblicità sull'internet di un'altra dot com, ho fatto software di automotive per i concessionari auto, In nessuno di questi casi probabilmente ho salvato delle vite, non escludo però di essere incontrato in contatto con persone che adesso probabilmente salvano le vite, o generano posti di lavoro, o fanno cose comunque ad un impatto rilevante per la vita delle persone.Dire "io faccio sviluppo web, non salvo vite" secondo me è una brochia in window.È una cosa in cui lasci una finestra aperta o comunque lasci uno spiraglio per dire "sì, ok, allora posso fare il mio lavoro male, posso spegnere una su wiki test, posso come si dice in italiano "cut the corners", posso prendere delle scorciatoie perché tanto sto facendo un lavoro che non salva vite.Sì ok, però penso che Mauro su questa cosa ci tiene un sacco sul tema della qualità del software.In realtà è importante anche quando sembra che non salviamo delle vite.anche perché in modo incidentale comunque come dici tu abbiamo un impatto ed ecco perché tutta la mia sega mentale la passeggiata che ho fatto in mezzo a tutti questi concetti per arrivare qua partendo da DevOps mi diceva beh ma allora queste metodologie in qualche modo aiutano un comparto che sta cambiando da artigianale e industriale proprio nell'ottica di dare quella sicurezza, quelle procedure, quegli strumenti che aiutano a strutturarsi in modo da ridurre i rischi.Sì, anche perché poi c'è… io condivido quello che dice Mattia, ovviamente, non sono il teoria delle finestre rotte e continuare a lavorare male.C'è un tema un po' più ampio secondo me, di cui si potrebbe parlare, che ha a che fare con il fatto che è molto lontano l'impatto del tuo lavoro, quindi di difficile percezione, ma soprattutto che alcune cose che potresti fare sono gratis, cioè una serie di cose che potrebbero vi condurre a delle checklist, non sono diffuse nell'ambiente, cioè ci sono proprio delle cattive pratiche che si continuano a fare, cioè si continuano a lavorare così, però nessuno si accorge del danno che fanno.Sto pensando un esempio intanto, non mi viene però, per dire tutto quello che si categorizzerebbe sotto Nermis, quindi un incidente mancato, no? Cioè se io sono costretto a fare un'operazione manuale su un server e prendo la faccia dentro faccio ssh dentro il container, lascio sporco, quindi crea una divergenza, non è successo niente, l'ho fatto, magari potevo non farlo, nel senso che quella cosa lì l'ho fatta, è un incidente per me, nel senso che è un incidente senza impatto, però è un incidente, è qualcosa a cui posso imparare, nel momento in cui questa cosa la categorizzo come è successo qualche cosa che poteva provocare un incidente e ci penso a quella cosa lì, magari nel corso di anni, nel corso di conferenze, fare parlare, insegnare, apprendere, provare, probabilmente si diffonderanno delle buone pratiche, così come oggi giorno credo che nessuno si sieda e prima di iniziare a fare coding non faccia git init, git init e poi inizi a scrivere il codice.Un tempo, io quando ero piccolo ho perso dei file perché non ho fatto un get in it, però perché quella roba lì è gratis, ha un costo piccolissimo, non lo sapevo.In tutto questo ho perso il filo.LM: In tutto questo ho io una domanda da fare a te e al resto del… GZ: Ah no, ce l'ho, poi vai.LM: Di quanto di questo secondo te, secondo Mauro e secondo Luca che ci ha raggiunto e salutiamo, sono dolori di crescita di un'industria che comunque è relativamente giovane o comunque lo è molto di più, per esempio, dell'anemicimento del discorso o dell'area autica.Nel senso quanto di questo è perché siamo stronzi noi e quanto di questo è perché facciamo un lavoro che tutto sommato esiste da relativamente poco tempo e fa parte del naturale processo di crescita dell'industria.A Monte c'è una cosa che si collega anche con la domanda di prima, che è che non puoi comprare il lavoro che facciamo, un lavoro che ha una certa simmetria informativa, cioè tu puoi imparare un pochino a programmare in diversi paradigmi, puoi sapere se sei un ingegnere qual è il metodo ingegneristico e applicarlo nella maniera migliore possibile, poi il software presenta un certo grado di il software quando vai in un'azienda, in una organizzazione, quando prendi un software open source, non è che basta che tu hai studiato tanto l'informatica per poter manovrare quel codice, no? C'è quella che si dice "assimetria informativa" che è quella distanza che sono tutte le cose che invece chi ha scritto quella code base sa e tu invece no.E quindi per te quel software è immanovrabile perché ti manca quella parte di informazione che esterno.Motivo per cui, perché questo vi pone, perché questo fa in modo che tu oltre a non poter comprare 10, 100 programmatori, tutto allo stesso skill level, allo stesso livello sul mercato, hai in più questo problema, cioè tu hai comprato dei programmatori, poniamo che siano tutti bravi, allo stesso livello, c'è un costo nell'acquisire dell'informazione sistema che ti manca e quindi questo già è un casino rispetto a tante altre industrie.Si sono trovate le soluzioni dirompenti per questo problema, tipo Akerlof con un saggio che si chiama Market of Lemons, ha risolto questa simmetria che c'era, ma i Lemons nel mercato americano sono le auto usate, perché sapete che quando vado a comprare un pacco si dice una volta che esci dal concessionario, anche se nuova, vale la metà.Questo perché non sai il proprietario che cosa ci ha fatto con quell'auto, quindi sotto il cofano, cioè la macchina è quella, tutti sanno che la macchina è quella, però sotto il cofano se tu non sai che problemi hai avuto con la guidata, con tutta una serie di cose che riguardano una vita di quell'auto usata, non puoi attribuire un valore a priori, benché tu conosca quel modello di auto.Questa cosa succede anche un po' con il software, no? E lì c'è tutta una questione proprio economica, proprio anche filosofica, no? Si va a parlare di garanzie e assicurazioni, quindi è complicata questa roba, cioè è proprio complessa.E poi in più, oltre a tutta sta roba, oltre alle cose che hai detto, siamo un settore giovane che nasce in un contesto dove adesso io non c'ero, però quando l'informatica è nata, l'informatica è nata da tre discipline, cioè TLC, telecomunicazioni come elettronica e qual è la terza? Aiutate, mi aiuto? Niente, mi prenderò degli insulti perché non mi ricordo questa cosa, però La parola scottolineare nasce in NASA, credo che fosse per lanciare i missili nel periodo della guerra fredda, quindi c'era un traino che era molto diverso da oggi, nello scrivere software, nell'esigenza del software.Poi c'è stata la crisi del software, un periodo proprio storico chiamato crisi del software, nel quale tutti volevano software, le aziende avevano i PC, i microcomputer ancora prima, le infrastrutture cambiavano, si popolarizzava l'informatica e tutti volevano software chiaramente perché era una novità tecnologica, un asset competitivo per qualsiasi tipo di azienda che accedesse a quelle tecnologie.LM: un po' come tutti vogliono cloud oggi no? GZ: in un certo senso sì, e il fatto che in quel periodo è stato fatto in un modo un po' roccambolesco, no? Cioè, vai, si fa, c'è il waterfall, è giusto, continuiamo così.Sì, era la soluzione migliore a quel tempo, poi però, oggi giorno ancora vediamo che alcune cose sono sedimentate e difficili da smontare e rimontare in una maniera un po' più, passatemi il termine, sensata, economica, diciamo economica, che forse toglie meno l'impiccio del fare le cose bene, la soggettività.E poi cos'altro? Sì, non lo so, rispetto a quello che dici, siamo noi che ci chiudiamo, non sono tanto d'accordo perché nel contesto dell'accademia, ad esempio, non sono tanto esperto su questa cosa, però è una statistica mia, molto locale, gli amici ricercatori che ho mi raccontano di invece una verticalizzazione, ma anche gli amici medici con cui parlo, insomma che hanno percorsi accademici molto profondi e lunghi in altre industrie diverse da questo, mi raccontano che lì invece forse si è ancora più verticali, se uno fa per dire, un amico chimico fa il cristallografo, lui fa solo la cristallografia dei materiali di quel genere, adesso non mi viene neanche un esempio, non sono un cristallografo.E quindi se io gli dico "guarda questa roba qui che tu hai fatto si può risolvere facile con R, con uno script e una random forest, facciamo modelli di predizione" cioè quella roba lì è come gettare una bomba nell'Ateneo perché stai contaminando tutta una serie di...stai oltre l'Accademia.L'Accademia non è tanto...il mondo in generale è fatto a silos, c'è questa idea.E invece noi nell'informatica forse no, dai, questa almeno secondo me non ce l'abbiamo più tanto.Abbiamo fatto ammenda e almeno i team cross funzionali ce li abbiamo.Perché siamo un po' tutologi.Altrimenti stavamo qui a parlare.Esatto, infatti siamo tutologi per natura noi informati.No bellissimo quando hai detto che il tuo amico era cristallografo per un attimo l'ho immaginato programmare in crystal.No, i cristalli quelli materiali, quelli della droga.No, lui fa il report con cristal repertory.Cos'hai risuscitato? No, giusto perché per per dire la mia e chiudere su questo argomento e poi passare per per gli strumenti pratici del DevOps rapidamente, quello che secondo me manca a questo tipo di industry per essere un industry a tutti gli effetti non lo so non mi viene da dire stabile, riconosciuta ma è sbagliato.Matura.Matura bravo grazie.È un contratto nazionale.No.Oltre a quello perché il video terminalista metal meccanico.L'hanno prima che mi usi.Abbiamo lanciato un nuovo flame all'interno della community.No secondo me è un concetto diverso di responsabilità.Per un attimo vi porto a guardare quello che sta succedendo con i dati personali.Gradualmente, in modo molto lento, ma a forza di calci nel sedere, di legge e soprattutto di punizioni, l'industria si sta adeguando.Quindi, dai dati personali in chiaro, alcune società, molte società stanno iniziando a sviluppare quella consapevolezza.Io non so quanto sia multa driven o quanto sia una consapevolezza sviluppata però sta entrando nei flow, nei processi.Se io guardo l'industria aeronautica oggi se tu fai un errore come quello che ha fatto la Boeing visto che l'hai citata tu Fabio e ti mangiano esattamente come è successo.Tutte le certificazioni, tutte le autorizzazioni ci può essere la vulnerabilità però sono ben definite, schematizzate e la responsabilità di quello che si fa è importante.Oggi se Google School, la suite di school va giù e le scuole per due giorni non possono fare lezioni.Di chi è la responsabilità? Leggiti le polizie contrattuali che però scaricano tutte le responsabilità.Quindi...Guarda, sfondi una porta aperta, sfondi una porta aperta e ti chiedo però se questo problema informatico, ovvero è un problema dell'impatto che l'informatica ha, ma è molto più ampio, non so, è la questione del "hai inventato l'energia nucleare, poi se ci fai la bomba atomica e un altro paio di maniche.Per un certo periodo è stato così, oggi forse l'informatica… è un discorso veramente ampio, però in due parole, secondo me questi meccanismi correttivi multadriven si accendono quando c'è un'urgenza, cioè in quei settori che abbiamo citato, l'errore ha un impatto, ha un impatto sulle vite, ha un impatto sulla borsa, ha un impatto sul plus valore che un manager non riesce più a far saltare fuori da qualche parte.La percezione, i dati personali, l'istruzione, forse oggi abbiamo una spinta del legislatore molto forte, ma anche lì la spinta del legislatore è molte.Non so se poi questa è una cosa che proprio interessi a tutti, tutte le persone.Non so quanto sia percepita l'idea di avere dati personali trattati in un certo modo.Sono più io che faccio la domanda, ma le altre industrie nella storia abbiamo visto dei pattern diversi, perché in realtà se io ci penso l'informatica è nata tipo ieri, 10 anni fa, 20 anni fa, abbiamo iniziato un'oretta fa dicendo che io andavo in edicola a comprare il CD di Suse.L'informatica secondo me ha il pro di essere qualcosa che impara, di essere un'industria che evolve molto velocemente, in termini storici, se fate zoom out, se mettete il grand'angolo, è una roba giovane l'informatica, che in 20 anni, Stuart l'informatica di 20 anni fa, il modo, magari non l'informatica, l'informatica nei suoi concetti essenziali magari no, però il modo di fare il mestiere.Siamo molto bravi a insegnare l'informatica, poco a insegnare il mestiere, diceva, credo, Gabriele Lana, credo.Non vorrei dare… andiamo avanti, credo che lo dicesse lui.È una cosa molto, la Gabriele Lana.Ecco, è la stessa cosa qui, no? L'informatica evolve, anche altri mestieri sono evoluti, gli altri hanno imparato un po' meno velocemente di noi, forse.Se tu guardi un pronto soccorso di 30 anni fa, non so ma secondo me 20 anni fa, non dico più o meno uguale, però se tu guardi un'azienda che faceva software 20 anni fa, è, è, è.In tutto questo, appunto, c'è una grande voglia da parte del mercato, da parte delle persone di tecnologia e quindi ci sono veramente mille sfumature, ci sono veramente mille, mille sfumature, potremmo parlarne ora, ne riparliamo se vuoi.No però facciamo sì, ci ritorniamo su questo argomento e come Luca e Mattia sanno mi sta super super a cuore, mi prende malissimo questa cosa.Posso dire solo una cosa, già che ero stato chiamato altrimenti la gente può pensare che non ci sono per davvero.No, forse anche il raggio di azione dell'informatica.Adesso l'industria automobilistica fa motori, fa macchine e per 100 anni ha fatto macchine, per 100 anni abbiamo messo la benzina nelle macchine.Meno male, non è cambiato più di tanto.Un'automobile ovviamente è cambiata, si è evoluta.Il problema è che secondo bene l'informatica proprio cambia, si arravota e si rigira, come si dice non a Bolzano ma in un'altra città, di continuo, a volte si involve anche, io vedo magari ogni tanto si ritorna indietro a concetti che andavano vent'anni fa per poi ritornare di nuovo davanti, ma poi soprattutto anche il raggio d'azione, l'informatica la troviamo e nell'industria automobilistica e nell'industria farmaceutica, è un'industria, non lo so, nella medicina, insomma, dappertutto e questo crea, come si fa? Questi non sono dolori di crescita, sono dolori di crescita che ci porteremo all'infinito, è un frattale di crescita, ci porteremo proprio all'infinito.Credo che, non so, forse è una visione pessimista, ma non vedo la soluzione in questo, anche perché poi magari la troviamo e poi escono fuori con il computer quantistico e sarà tutto da rifare perché ci saranno nuovi approcci, nuovi programmi, nuovi problemi e nuove soluzioni.LM: sicuramente, sicuramente tra dieci anni saremo qui a fare delle altre chiacchere, guarderemo questi talk dicendo "ah guarda".O magari no, o magari saremo ancora qui a dire che forse se scriviamo il software per gli aerei serve fare del testing automatico.Non lo so, non lo so.Intanto… No perché poi vabbè, human factor, ma il fattore umano esiste, no? E persone, cioè ti ripeto, prima voi dicevate, l'ha detto anche Jacopo, no? è veramente tanto, tanto tempo che io sento queste cose e poi è una questione di volontà, non è che non si sa, la ricetta per scrivere software bene, oggigiorno non è più segreta, secondo me almeno.Ci sono dei problemi che hanno a che fare, cioè ci sono delle difficoltà che hanno a che fare con il decidere, i rapporti umani, però a prescindere dal problema, lo metto fuori, no? Quale problema risolvere non in questa sede, ma c'è ci sono i modi per fare bene software, non prendiamoci in giro.Allora a questo punto vorrei usare un altro concetto di cui parla spesso Jacopo, secondo me visto che la ricetta per fare bene software ormai la sappiamo, se non lo fai probabilmente stai usando degli alibi.O magari non si serve, magari non è che tutti devono giocare in serie, non tutti hanno il desiderio, se tu sei un'azienda che fa gestionali per un sistema normato, dei commercialisti, dei non lo so, gli avvocati, boh, non lo so, magari ti serve di lasciare 100 volte al giorno, magari no.Qual è il cuore del tuo business model qual è il problema che ti pagano le persone? Sono contente di vedervi solto, sai, poi rilasciare 100 volte al giorno, fare DevOps ha un impatto sicuramente sulla frequenza dell'apprendimento, puoi apprendere più velocemente perché puoi fare più esperimenti, però poi mi chiedo ti serve? Dai 100 feature da rilasciare.Non lo so, quanto vuoi muoverti veloci, quello lo decidi tu insomma.LM: Però secondo me quanto vuoi muoverti veloce e quanto vuoi rilasciare veloce va bene, hai un margine di scelta e di dire che magari per te non è importante, ma quanto vuoi imparare veloce avendo un feedback più estretto secondo me non è una cosa su cui hai davvero troppa scelta.Quello è un alibi, però di nuovo è richiesto a tutti fare l'informatica a un livello così alto? Non lo so, è una domanda aperta, io sento molto questa cosa, a me piace scrivere software, io scriverai software anche se non mi pagassero.Anzi, molte persone di giorno scrivono del software che non gli piace e di notte scrivono il software che mettono su GitHub, su GitHub open source, quindi faccio parte di quella categoria.Oddio, non magari in questi termini, però mi piace, mi piace fare quella cosa lì, però non tutti sono come me.Esiste anche il contesto e oggi giorno più che mai, in versione dell'informatica, del fatto che abbiamo l'informatica, siamo tipo una delle prime generazioni che potrebbe permettersi per assurdo di non lavorare.Potrebbe anche dire "ok io faccio l'informatica perché voglio un lavoro dove guadagno discretamente".discretamente.E qua si apre il film sull'orale.Diciamo che ho un lavoro che nel mercato italiano o nel mercato internazionale, se vi volete porre sul mercato internazionale è un po' meno difficile viverci.Ok dai, semplifichiamola così.Poi il merito è questo in un'altra non apriamolo, ti prego.Però diciamo che persone che magari hanno studiato otto anni per fare la psicologa clinica guadagnano molto meno di persone che hanno fatto il corso da 90 giorni web developer full stack.No, no, no, guadagnano sicuramente di più.Poi, è giusto? Non è giusto? Ne parlo qui come si dice, Mattia aiutami, Cineera è studio, quindi senza prendere parte, è un reported speech.No, è vero, tra l'altro secondo me tu hai un punto interessante nel dire che in effetti noi probabilmente che siamo qua tra di noi, come parliamo e abbiamo un background simile, siamo tutti persone che piace fare software, software abbiamo in effetti un bias rispetto a questa cosa rispetto a dirci quando io ti dico "eh mica non hai scuse rispetto alla possibilità di non fare software bene" noi abbiamo questo bias perché noi probabilmente a noi piace farlo bene però è vero che in effetti potrebbe esistere chi non ne ha bisogno su questo hai assolutamente ragione.Sai se noi ritorniamo a quello che dicevamo prima che in modo incidentale abbiamo un effetto comunque nelle vite di tante persone anche se non diretto ma abbiamo un effetto non è solo passione secondo me c'è anche quel pelo di consapevolezza che alimenta tutto non lo so mi piace pensare che siamo importanti.Anche per il panettiere vale anche per la cassiera, per mille lavori, anche se tu servi un pasto hai un impatto nelle vite delle persone, di gioia, di sussistenza, insomma, quindi non lo so se io… sicuramente sento che siccome faccio questo mestiere, il mio contributo dal punto di vista di raccontare queste cose e cercare di rendere le persone più consapevoli, che poi consapevoli, una volta che una persona è consapevole è meno condizionabile, quindi quello è un pochino il mio obiettivo, raccontare delle cose per cui le altre persone sono più libere.Se io poi cerco di venderti qualcosa, quello è un altro discorso, io ti racconto qualche cosa e poi ti do la soluzione e ti do la mia soluzione, invece sto facendo qualche cosa che è molto diverso.Però io lo faccio per l'informatica, ma non ti saprei dire se ci si ha questo genere di preoccupazione e consapevolezza nel resto del mercato del lavoro e non in tutti i settori.Se tu fai cold calling, quindi chiami le persone, che responsabilità hai? È un discorso veramente, veramente, veramente tosto.Consiglio un libro che si chiama Bullshit di David Gerber, credo.Adesso lo googolo.Sì, hai consigliato tipo 70.000 cose e io non ho fatto tempo a scriverle tutte, quindi ti prego almeno per questi qua riesci a mandare i link? Sì, sì, sì, certo, certo, va bene.Graeber, scusate.Ho visto il tempo di registrazione, realtà siamo già un'ora e mezzo io pensavo...e vi dico di più potrei rimanere a chiacchierare ora anzi ci tengo ad aggiungere il fatto siccome poi l'argomento ha preso una piega che mi piace da tantissimo vi confido che sono un paio di mesi che sto cercando sto corteggiando un sociologo e e un antropologo per venire a Gitbar a parlare proprio di queste cose perché secondo me serve.Serve, serve, serve.Secondo me serve.Poi c'è sempre il paradosso che stiamo sempre facendo Gitbar o stiamo facendo sociologia, stiamo facendo politica non lo so è sempre noi abbiamo questa questa passione nell'andare oltre.Ragazzi Gitbar è un bar noi potremo parlare del prossimo sindaco o dell'ultima partita di campionato sempre parlando di informatica no? No secondo me secondo me è comunque importante da approfondire questo argomento e bisognerebbe parlarne di più.Io tu prima hai...[Musica] Sì, sai resta una cosa sulla scuola prima.Sì, effettivamente, quasi le 11.Sono stanco.Vabbè, detto questo io direi che è arrivato il momento del Paese dei dei pallonchi.Aspetta, Mauro è cotto, è cotto.Tu hai detto una cosa, mentre Mauro vide, così lo recuperiamo, ha detto una cosa sulla scuola molto interessante prima, cioè quando una piattaforma pagamento smette di funzionare perché c'è uno scarico di responsabilità, succede e io ti dico qui, Mauro, quando inviti il sociologo e l'antropologo facciamo la stessa cosa che mi è venuta in mente a me mentre pensavo all'esempio che tu mi hai fatto, perché io ho detto, mentre tu ne parlavi, questa cosa nel 2008, nel 2006 era il tema credo del Linux Day, che era tre giorni fa.Il Linux Day esiste ancora, solo che forse non esiste più quel mondo attorno, però i temi erano gli stessi, ti parlava di scuola la Libra si parlava di… giusto, è l'anno di Linus, tutti sono gli anni… è come l'anno del podcast, tutto è sempre l'anno del podcast.Quindi si parlava di quei temi lì, è giusto che la scuola adotti software, però lì non era il momento giusto.Il tema è lo stesso di adesso, se tu lo prendi è lo stesso, potresti andarti a vedere la commissione cosa scriveva, lo stesso.C'è una roba che si amacca appunto, andiamo a vederla, però mi credo che Pop and Dick con The Responsible Engineer potremmo trovare un sacco di spunti interessanti di gente che l'ha già studiata molto più di noi questa roba e ricaricare questo argomento con antropologi, sociologi, tutti quelli che vuoi, economisti.Io sto prendendo appunti.È registrato però prendi appunti, è meraviglioso.Qui è dove svegliamo che Mauro non riascolta le puntate di Gatto.Però ha ripreso fiato, ha ripreso fiato.Prima era proprio perché noi siamo in webcam, infatti io mi sono pettinato.Vi sveglio il segreto.La bambina ha pianto tutta la notte.Io poi alle 9 ho iniziato a lavorare, mi sono alzato dalla sedia poco fa per iniziare a registrare.Pizza congelata al volo, questa è la triste vita mia.Quindi abbiate pazienza di me.Io direi che vista l'ora e viste le mie poche energie possiamo anche chiudere.Prima di chiudere, il paese dei balocchi.Che cos'è il paese dei balocchi? è quel momento dove condividiamo un libro, un talk, qualunque cosa abbia catturato la nostra attenzione insomma che vogliamo condividere.Siccome abbiamo nominato pochi libri oggi.Community.Per cui chiedo subito a Fabio qualcosa da condividere con la community sotto le 250 pagine please e conduco nel paese dei balocchi aaaah il paese dei balocchi ok un libro un libro un touch uno due in italiano vai scuola in inglese allora il primo super tecnico perché ne abbiamo parlato di art of phoenix programming di Raymond questo è irrinunciabile.Sì, sono fatto così, mi spiace, mi spiace, a me Unix piace.L'altra cosa che è un po' più legata a, invece, la parte un po' più di divagazione di cui abbiamo parlato è Geek Sublim di Vikram Chandra, non so se l'avete mai sentito, Mattia fa Signoristi con la testa, è la storia di un informatico che ha fatto l'informatico per un sacco di anni della sua vita e a un certo punto si mette a scrivere, invece scrive di letteratura e parla di software e arte e fa un sacco di riflessioni.È un libro veramente pieno di idee, è forse uno dei libri sull'informatica che preferisco a livello di divulgazione.Divulgazione vuol dire che potrei darlo anche a un parente da leggere, un parente che non si intende di informatica.Il sottotitolo è "The beauty of code, the code of beauty".Sì, è proprio lui.Credo sia stato anche tradotto in italiano ultimamente da qualcuno.Non so poi… ma guardate, io poi non ho remore a leggere anche in italiano quando si tratta di… Anche perché hai scritto un libro in italiano.sì ho scritto un libro in italiano perché la commessa era quella, la richiesta era quella, però per rilassarmi un po', questo è un libro che si può leggere anche senza l'ansia di avere la penna in mano per sottolinearlo.Devo dire un altro perché mi guardate, non No, no, tocca a me se volete.Io ho un balocco molto bello che non è strettamente un libro tecnico ma più lo leggo e più mi rendo conto che invece forse è tutto sommato un po' sì.Abbiamo parlato un sacco di human factor e di quanto in realtà le persone abbiano una componente importantissima nel lavoro che stiamo facendo.Io, come sapete, ho anche questo secondo lavoro parallelo che svolgo gratuitamente, che è fare il padre.Sto leggendo un libro che si chiama "The self-driven child"."The science and science of giving your kids more control over their lives".Praticamente l'idea, al fondo, è che molti degli problemi che generano incazzature nei bambini derivano dal fatto che loro non si sentono in controllo di quello che stanno facendo, perché sono piccoli e l'istinto di qualunque genitore è di dire "no, questa cosa la faccio io" oppure "no, ti spiego io come fare questa cosa" oppure "no, adesso devi fare come ti dico io" e questa cosa nei bambini crea incazzatura, sconforto e potenzialmente effetti anche a lungo termine.Ora, se voi questa cosa la traslate in un rapporto tra senior developer e junior developer o tra informatico che spiega come si fanno le cose a una persona che non capisce niente dell'informatica, probabilmente vale esattamente la stessa cosa.O anche tra uno sviluppatore qualunque e la sua azienda, che probabilmente si sente molto frustrato perché si sente poco in controllo di quello che sta facendo e fa fatica a valutare quali sono le conseguenze di quello che fa.Quindi, ok, non è un libro tecnico.e poi ci sto trovando molti paralleli con quello che faccio tutti i giorni.- Bello, bello, bello.Grazie, perché in realtà è fighissimo il concetto.- Tra l'altro, scusami, parte da basi scientifiche solidissime, nel senso che racconta per primo i motivi fisiologici e neurologici, per cui la mancanza di anche solo di sensazione di controllo anche senza ma anche senza averlo veramente controllo fai ma avere la sensazione di essere in controllo attiva delle aree del cervello che bla bla bla che sono legate a quella dell'ansia della depressione e co a tanti.Quindi è molto grande l'inferso.No ma poi è un po come il dare un senso al "lasciami sbagliare" che tutti abbiamo urlato verso i nostri genitori, verso i nostri senior, verso le nostre mogli.Stavo pensando a quello perché proprio oggi con la bimba è successo quello.No, bello grazie, grazie Mattia.Luca? Sì, io ho finito un po' tutti i balocchi.In realtà ce ce n'era uno ma mi sono reso conto di averlo già consigliato che era appunto la caffettiera del masochista dove tra il design degli oggetti quotidiani c'è anche un accenno, qualche capitolo sui processi e sulle procedure che riguardano le interazioni e le persone.Ma visto che non voglio fare l'ennesimo libro consiglio un'app che è Algorithm Explained è free e a pagamento si sbloccano nuovi algoritmi, puoi vedere la maggior parte degli algoritmi spiegati quasi per bambini, quindi con delle animazioni per vedere cosa succede e cosa non succede.E' carino.Quanto si vede la paternità degli abutinati, mamma! Io invece ho un libro, il titolo è DevOps guida per integrare development e operation e produrre software di qualità l'autore è una persona super interessante è il nostro buon Fabio quindi se non l'avete ancora letto leggetelo perché intanto è in italiano e poi perché parla di DevOps senza essere troppo pressante sulle tecniche ma non lo so, leggetelo, vi dico solo questo grazie Mauro anche sull'italiano poi Raybaz ci scherzava potrei raccontarvi tutta la retroscena di questa cosa, di quanto sia difficile poi in realtà scrivere un libro in italiano sarebbe stato forse molto più semplice scriverlo in inglese Non faccio difficoltà a crederti.Naturalmente io a questo punto ti devo dire che ce lo verrei a raccontare un'altra volta, sappilo, dove parleremo magari di tecniche, quindi di tutta la parte tattica del DevOps.Del processo editoriale, perché quello è Waterfall.E poi parleremo del...in realtà davvero abbiamo avuto tantissimi autori di libri e pochi ci hanno raccontato cosa succede a scrivere un libro tecnico.Io ci ho provato una volta a chi è che l'avevo chiesto? A Luca Mezzalira forse, però in realtà nessuno scende nel dettaglio.Forse è una cosa che sarebbe figa andare ad approfondire.Che ne dite? E allora… Sì, a disposizione.Rinnoviamo… Un editore diciamo che ha un flusso editoriale vero nel senso che l'editore è quello lì grosso che vedete.E possiamo anche dirlo a Poggeo, tanto non siamo sponsorizzati da nessuno.Quindi non abbiamo… cioè noi i marchi possiamo dirgli se l'obiettivo non è fare pubblicità ma condividere possiamo dire tutto quello che vogliamo.è il bello di essere podcast indipendenti.Quindi ripeto io Fabio a nome mio ma anche a nome di tutti di Mattia di Luca di tutta la community rinnovo il nostro invito.Siete d'accordo ragazzi? Si un'altra birra con Fabio ci sta? Assolutamente.No io no, io basta Fabio lo vedo pure noi.Facciamo decidere che ci ascolta.Vabbè ce la suoniamo, ce cantiamo non vale, non vale assolutamente così.Prima di chiudere la puntata di oggi dobbiamo ringraziare Erichitato che ci ha offerto 5 birre e ci sta aiutando per raggiungere in modo veloce l'obiettivo che ci siamo posti che è quello di riuscire ad acquistare in questo Black Friday i microfoni o almeno iniziare ad acquistarli per gli ammutinati in modo da migliorare la qualità audio del nostro podcast e renderla insomma in qualche modo all'altezza di quelli che sono i nostri desideri fondamentalmente.Detto questo ringrazio nuovamente richitato e sollevo il bicchiere per blindare alla sua salute quindi grazie grazie di cuore e vi ricordo che potete sostenere gitbar entrando nel nostro sito www.gitbar.it nel menu in alto a destra trovate il link supporta gitbar cliccando ci avete la possibilità di darci una mano per raggiungere questo nostro obiettivo.Io rinnovo quindi l'invito a Fabio.Grazie per essere venuto a farci compagnia oggi, a condividere le tue esperienze e insomma i contenuti che hai portato.È stata una puntata super interessante, io mi sono divertito tantissimo.Vorrei e continuare a farla per altre due ore e mezza ma ormai il mio livello di stamina è praticamente zero Adesso mettiamo stop e registriamo un'altra no? Sì sì sì tant'è, io mi accordo che quando abbiamo spostato la registrazione a stasera Fabio ci siamo detto "Sì sì va bene facciamo pure le nove basta che non andiamo oltre le 11 sono le 23.02 quindi adesso questa la chiudiamo e poi iniziamo a registrare un'altra dopo" Siamo appe.Fino alle 11 del mattino.Maratona mentana maratona murru reinone tommadone.Ok ragazzi grazie di nuovo Fabio alla prossima.Grazie a voi dell'invito ciao ciao a tutti grazie per avermi ascoltato e aver ascoltato i miei deliri.Io prima però di lasciarvi insieme a Mattia e a Luca vi devo ricordare che abbiamo un obiettivo stiamo raccogliendo le donazioni per acquistare i nuovi microfoni di Geekbar quindi se non l'avete ancora fatto mi raccomando fatelo perché potrebbe essere la volta buona che Geekbar avrà una qualità audio spettacolare e altra cosa vi ricordo i nostri contatti info@gitbar.it brainrepo sono i classici quelli che non usa mai nessuno e poi...- Mattia? - Ah sì scusate devo dire gruppo telegram giusto? è il momento in cui vengo pagato approssimativamente per dire gruppo telegram - Il doppio dell'anno scorso - Gruppo telegram @gitbar lo riconoscete con il simbolino giallo con il faccione del nostro brainrepo? si se non l'avete ancora fatto mi raccomando iscrivetevi e io lo so che molti di voi non l'hanno ancora fatto perché guardando i numeri degli ascolti del podcast in realtà vedo che una grande fetta non si è ancora iscritto quindi facetelo, facetelo, è il posto più bello del nostro podcast anche il posto dove in realtà potete trovare anche i nostri ospiti per chiacchierare di persona detto questo io vi do appuntamento alla prossima settimana e vedo che Fabio ce l'ha aperto io vi do appuntamento alla prossima settimana e nulla ciao ciao ciao GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con BrainRepo parliamo di linguaggi e tecniche di sviluppo web, di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dead.
