Bene e benvenuti su GITBAR, nuova settimana e nuovo episodio qua sul nostro bar degli sviluppatori.Oggi abbiamo Luca e Carmine.Ciao ragazzi, com'è? Ciao Mauro, ciao a tutti.Bene, bene, benissimo.Era un po' che non venivate qua a sbevazzare nel nostro GITBAR.E' vero, è vero, è vero e quindi oggi esageriamo si si, birre a fiumi oggi oggi un sacco di birre in realtà oggi abbiamo anche un ospite super speciale, ma non ve lo sveliamo almeno prima di aver detto la solita pappardella che un po' vi stressa ma noi la diciamo lo stesso potete contattarci scrivendo un'e-mail a info@github.it o nel nostro bellissimo sito nuovo, nuovo vecchio, potete contattarci su Twitter @brainrepo, vi rispondiamo sempre o quasi sempre e potete anche in realtà Luca? C'è il nostro ormai famoso se non famigerato gruppo Telegram che potete trovare cercando di farvi la podcast, vi darà il benvenuto, un piccolo bot giusto per previsare che dei bot vengano a romperci le scatole e a parte quello vi verrà offerta una birra, quella non è fatta dal bot noi baristi saremo a darvela molto volentieri quindi, clipbar podcast, telegram e ci siamo ottimo, ottimo, ottimo allora io penso che abbiamo detto tutto quindi possiamo spegnere sta musichetta fastidiosissima aiuto iniziamo bene mi si sta già torcigliando la lingua namo bene e partire benvenuti su github il podcast dedicato al mondo dei full stack developer i mezzo artigiani mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo [Musica] Molti hanno parlato di lui in questi ultimi giorni.In realtà è un principal software engineer a Red Hat è un Java Champions, uno degli uomini Java italiani...l'uomo Java italiano, posso dire almeno quello che si vede dappertutto e anche il project lead di Drulls abbiamo con noi a Gitbar a bere una birra con noi appunto Mario Fusco ciao Mario come stai? Ciao ragazzi grazie mille di avermi invitato è tutto ok siamo super super felici di averti qua con noi anche perché in realtà il topic di cui parleremo oggi è un topic che proprio personalmente mi interessa Strettamente legato a doppio filo alla natura etica del nostro lavoro e voi sapete quanto mi gasano questi argomenti no? Immagino anche anche luca sia di quella pasta E quindi oggi parleremo di una cosa molto interessante con mario parleremo di reinventare la ruota però ancora prima mario io ho una domanda tu lavori a Druul's, è un rule engine in tutta sincerità che cos'è un rule engine? allora diciamo che il rule engine è il modo per implementare il terzo paradigma di programmazione che forse viene un po' trascurato ma che invece è importante.Voglio dire che di solito, va bene, io sono uno sviluppatore in Java, quindi da quanto programmo ho sempre programmato in Object Orientation, ho fatto anche un po' di Functional Programming, ho lavorato in scala in passato e poi ovviamente da quando ci sono le LAMP Expressions in Java si tende a mischiare sia la parte di Object Orientation che la parte di Functional Programming la terza gamba di cui ti parlavo è la programmazione dichiarativa quella che facciamo in prolog, tanto per capirci se avete mai fatto prolog per dichiarare in maniera dichiarativa il risultato che si vuole ottenere, ma non gli step per ottenerlo.La cosa più vicina che mi viene in mente è una query SQL, il SQL è il tipico esempio di linguaggio dichiarativo nel senso che tu dici al database cosa vuoi ottenere ma non dici al database come mettere in join le tabelle o come ottenere i risultati.Quello che fai invece con un rule engine è quello di dichiarare delle regole di business in maniera… praticamente una regola di business è fatta di due parti, la parte in cui dichiari le condizioni che devono soddisfare i tuoi oggetti di dominio e nella seconda parte invece quando questi oggetti vengono trovati, quale azione eseguire a fronte di quegli oggetti.Quindi, in realtà, se vogliamo fare un'analogia con un metodo Java, quando il motore di regole fa pattern matching, ovvero sta trovando gli oggetti che fanno matching delle condizioni, sta trovando gli argomenti del metodo, mentre il body del metodo è la seconda parte che ti dicevo, con la differenza che tu non passi esplicitamente argomenti alla regola si ritrova da solo e non invochi tu la regola ma la regola viene invocata dall'engine, prima è scatolata e poi invocata dall'engine quando quegli oggetti vengono trovati.L'altra domanda è che ci faccio con questo e ovviamente cerco di modellare le regole del business in un modo che sia intelligibile agli esperti del business domain stesso, perché tipicamente alcuni dei progetti che ho visto fallire in realtà li ho visti fallire perché c'erano delle incomprensioni tra gli sviluppatori e chi descriveva le regole del business, perché i secondi dicevano una cosa, i primi ne implementavano un'altra, ma poi i domain expert non sanno leggere java, quindi non riescono a capire se l'implementazione corrisponde alla regola di dominio o no, e quindi le cose funzionano male.Quindi l'idea è che questo linguaggio dichiarativo sia più facile per i domain expert, se non scrivere regole di BISTIS o almeno validarle.Queste regole di BISTIS possono spaziare davvero in tantissimi settori.In campo medico, per esempio, è molto utilizzato, è una delle più grosse installazioni che abbiamo, al centro oncologico più grande del mondo che in Minnesota e lì c'è un'equipe di esperti di quel dominio, di medici opologisti che hanno codificato circa in 200.000 regole la loro conoscenza su quel dominio e praticamente loro danno in pasto al Rulanchin la prognosi e il Rulanchin dice "ok, qui c'è un tumore, e di che tipo è il tumore, utilizzando le regole che hanno dato i medici.Viene usato per esempio per fraud detection, nel senso che una banca può dare delle regole di business per decidere quando c'è un comportamento che è potenzialmente fraudolento su una carta di credito.Viene usato per il marketing, visto che le regole di business al marketing sono abbastanza fantasiosi e cambiano parecchio spesso, quindi quello è un altro campo di applicazione.In generale, è anche l'altro aspetto che secondo me in maniera erronea viene drascurato un poco, dell'intelligenza artificiale.L'altro errore che viene fatto è che si utilizzano come sinonimi i termini intelligenza artificiale e machine learning, ma non sono sinonimi, nel senso che il secondo è un sottinsieme del primo.Nel machine learning sono quegli algoritmi di intelligenza artificiale in cui la macchina impara da solo attraverso metodi statistici, fondamentalmente pensiamo alla rete neurale.L'artificial intelligence invece è qualcosa di più largo, è appunto intelligenza artificiale dove la macchina può imparare da solo, magari no.Il problema secondo me è che si abusa troppo di machine learning e certe volte però facendo così fai a scoprire in maniera statistica il tuo dominio di business, quando alcune regole di business invece le sai già e le puoi codificare tu nel tuo codice, non devi scoprirle da zero.Se riuscissimo a far cooperare questi due mondi, a far parlare di più questi due mondi, che è uno degli sforzi che stiamo facendo ultimamente, forse ne avremmo qualche vantaggio.ti faccio un esempio, non so se hai mai provato a comprare, a cercare poi a comprare una lavatrice su Amazon, da quel momento in poi Amazon ti propone una tonnellata di lavatrici perché sono statisticamente correlate, il machine learning ha deciso così, sono statisticamente collinate fra di loro e quindi per un po' di giorni o di settimane vedrai i proposti di lavatrici che però a quel punto lì probabilmente non ti interessano a meno che non hai deciso di aprire lavanderia.E' lì però puoi mettere una regola di business per dire ok se tizio ha comprato una lavatrice molto probabilmente sarà interessata a qualsiasi cosa nei prossimi giorni ma non a una seconda lavatrice.Questa è la disculsa.Sacro santa cosa Mario, tra l'altro fun fact, proprio oggi mi è arrivata l'asciugatrice, perché col break friday, gli sconti, allora ho deciso di prendere l'asciugatrice e Amazon ha iniziato a propormi stendini.Ma Cribbio, se sto comprando un'asciugatrice! Però davvero, domanda, come questi due mondi, quindi il mondo delle regole di dominio, delle regole di business e il mondo statistico di analisi si possono incontrare dal tuo punto di vista? Quali sono le azioni che in un sistema così ampio si possono fare per far sposare questi due approcci che sono antitetici, possiamo dirlo? Si, li chiamerei complementari più che antitetici ma dobbiamo ancora dobbiamo trovare il modo per per complementarli bene insomma e ci vedo almeno due modi che sono bidirezionali in un caso una una regola potrebbe invocare un pezzo di neuronector per farsi dare uno score per esempio uno score di affidabilità di un utente di una carta di credito, quello potrebbe essere valutato da un neural network, ma quello score potrebbe rientrare come valore all'interno della regola e la regola di business a quel punto dice "ok, al di sopra di questo score ti voglio dare delle cose, al di sotto non te le voglio dare più, però quella è una regola di business".Oppure potrebbe succedere il contrario, nel senso che a palle della valutazione, facciamo tornando all'esempio di Amazon, a palla della valutazione della correlazione statistica con Machine Learning nell'esempio dell'asciugatrice e della lavatrice, si potrebbe dire che l'algoritmo di Machine Learning ha proposto questi ulteriori prodotti a cui potresti essere interessato, però mettiamoci una regola di PSTIS che faccia da filtro applicando le regole di dominio prima di far arrivare con gli oggetti all'utente finale.Quindi ci sono dei modi per complementare le due tecniche e secondo me potrebbe essere molto interessante.Mi sento di dire che è anche il modo, dal mio punto di vista, ne parliamo in una puntata con Frate Paolo Benanti che è un eticista dell'intelligenza artificiale, quindi si occupa dello studio della natura etica, dell'intelligenza artificiale, utilizzare questo tipo di sistema, quindi i rule engine, a valle del processo permette in qualche modo di controllare anche la natura non solo pragmaticamente fattiva della cosa ma anche la natura di impatto di una cosa che è fuori dal controllo dell'uomo quindi è un po' come rimpossessarsi del controllo della tecnologia e non esserne.Questo è un altro problema enorme l'etica perché tipicamente di machine learning sono delle black box, però prendono delle decisioni che potrebbero essere anche non eticamente accettabili, l'esempio classico è decidere di concedere o meno mutui bancari, però l'algoritmo potrebbe imparare che le persone di colori sono statisticamente peggiori pagatori dei bianchi e penalizzare persone in base alla razza, che ovviamente non è eticamente accettabile e questo neanche puoi riuscirlo a capire perché tipicamente questi oggetti funzionano come delle black box, quindi lui agisce in quel modo ma non L'altro aspetto in questo esempio è che ancora una volta ti serve una spiegazione comprensibile dagli esseri umani quando rifiuti il mutuo, perché pure lì colore della pelle a parte probabilmente non è etico dire "il mutuo non te lo do perché la neural network ha detto di no", magari ci vuole una spiegazione un po' più intelligibile per un essere umano.E poi anche il risultato secondo me di una neural network come abbiamo detto prima è figlio di una serie di pattern che magari ai nostri occhi non si vedono ma che in qualche modo vengono riconosciuti.Ma se noi vogliamo rompere i pattern a livello fattivo, proprio di azione, beh a quel punto dobbiamo forzare una serie di regole al di là del risultato statistico che ci arriva da un percorso più o meno complesso, più o meno nascosto.Voglio ritornare per un attimo al Rule Engine perché qualche tempo fa ho letto un libro molto interessante.Era un libro su functional domain driven design dove si diceva che l'interfaccia, la definizione dei tipi, poteva essere un linguaggio franco tra il business, se fatto in un certo modo, tra il business e la parte più ingegneristica comunicazione.Ecco quanto un rule engine utilizza, quanto i due mondi, il functional DDD e l'utilizzo dei rule engine si differenziano? Allora, sì, col functional DDD o col DDD in generale, perché poi il functional è solo una possibile implementazione, appunto stai esprimendo le regole ma le stai stai comunque esprimendo nel linguaggio, a meno che non ti sei fatto il tuo DSL esterno, che però tipicamente richiede un bello sforzo, lo stai comunque esprimendo nel linguaggio di programmazione, magari ti sei fatto un DSL interno carino, però pure lì è abbastanza poco probabile che un esperto di dominio che non conosce quel linguaggio di programmazione sia in grado di leggere e validare la regola di business che hai messo dentro usando quel domino.E questo è un aspetto.L'altro aspetto è anche che con il DDD stai comunque codificando le regole di business insieme a tutto il resto del tuo software.Quindi in quel software, in quell'applicativo ci stanno sia concern architetturali e concern di business mischiati insieme.Se tu invece codifichi le regole con i rule engine, le regole di business stanno in un altro posto, codificate in un altro linguaggio, sono nettamente separate dalla parte architetturale del software e questo è vantaggioso perché tipicamente se ci pensi queste due cose hanno anche dei cicli di vita molto diversi, nel senso che se scrivi la parte architetturale del tuo software probabilmente ci farai piccole modifiche, una volta stabilizzata resterà quasi invariata per anni, mentre le regole di business variano potenzialmente ogni giorno, penso che ne so, un'altra applicazione del mio Rulancin è quella di un'agenzia di viaggi di cui non faccio il nome, che nessuno conosce, ma che in realtà controlla il prezzo del 90% dei bigliettieri che vengono venduti e se vedete la follia di come cambiano i prezzi, rendete conto che ci sono delle regole di marketing dietro e quelle regole di marketing sono implementate con Drulls e cambiano letteralmente ogni giorno ma sono totalmente separate ancora, ripeto, dalla parte architetturale di software.Questa è un'altra cosa importante secondo me.Ti faccio l'ultima domanda su Drulls perché sono super curioso, devi avere pazienza e sopportarmi.hai detto che Drulls è un tool, possiamo definirlo tool? Sì, sì.È uno strumento che permette la definizione di una serie di regole di dominio per domeni diversi.Hai parlato di campo medico, hai parlato di agenze di viaggi.Adesso la mia domanda è se chi scrive le regole è un esperto del dominio.Il Rule Engine espone una lingua franca su tutti i domini o c'è un modo per farlo? C'è un linguaggio di programmazione, insomma, che però come diceva è programmazione dichiarativa e che però è molto più semplice da ragionarci su per chi non è un programmatore, perché c'è un match uno a uno tra le regole che ti possono venire in mente e come le scrivi, mentre quelle regole se ci pensi e le scrivi in programmazione procedurale, sarebbero un mischione di branch.Ti faccio un altro esempio, c'è un'azienda di Torino, loro fanno sentiment analysis, Quindi, quando viene lanciato un prodotto, per esempio, raccolgono tutti i tweet, i post su Facebook, sui social network che vengono fatti relativi a quel prodotto e c'è un software basato su Druums che fa natural language processing e che cerca di capire il sentiment nei confronti di quel prodotto dai post rapporti.Questo set di regole che fanno questa analisi di natural language processing è stato scritto da un linguista, da un esperto della lingua italiana, quindi non da un programmatore, che ha scritto le regole di base per tokenizzare la lingua italiana, per dire questo è un verbo, perché se ci pensi pure quello non è banale, capito? Quando una parola è un verbo, quando una parola è soprattutto l'italiana che è bello complicato, quando è un aggettivo e se quell'aggettivo ha un'accezione positiva o negativa e quindi questa è la base dell'analisi linguistica e poi on top di questa analisi linguistica ci stanno altri insieme di regole, credo che ne abbiano una sessantinete adesso, divisi per categorie merceologiche che fanno un'analisi relativa a quella categoria merceologica.Quindi ci stanno questi due insieme di regole, uno generico che fa l'analisi della frase in italiano, che genera dei token.Questi token vengono passati all'analizzatore relativo alla specifica categoria merceologica e da lì riesce a dedurre il sentimento analisis, a fare sentimento-analisi sul prodotto da analizzare oppure per esempio viene utilizzato pure sai adesso su Twitter vengono un sacco commentati i programmi televisivi mentre vanno in onda ecco la RAI è un cliente di questa azienda per cui mentre va in onda il programma televisivo loro cercano di capire qual è il giudizio del pubblico su quel programma.Ripeto, quella parte di natural language processing è stata scritta da un linguista, non è stata scritta da un programmatore.Chiarissimo, ho una domanda per Carmine e e Luca avete qualche domanda curiosità? No pensavo più che altro che insomma mentre parlava assolutamente interessante infatti ci volevo dare anche un'occhiata è bello che la cosa principale che risolve risolve se vogliamo anche la comunicazione che c'è tra le varie le varie parti di un'azienda, riguarda sempre le persone.Insomma noi siamo il problema, adesso non voglio dire, ma noi persone siamo il problema ed è veramente interessante solverlo, cioè il modo in cui viene risolto e sono anche assolutamente d'accordo sulla questione della black box e di mettere l'intelligenza artificiale, il machine learning lì dove in teoria non dovrebbe esserci, non che se ne potrebbe fare meno, proprio non dovrebbe esserci, perché molte cose, molte scelte magari sono tutto deterministiche.No, ci voglio dare sicuramente un'occhiata, è scritto in Java? Scritto in Java, certo sì.Però, ripeto, il modo in cui scrivi le regole poi non è Java, c'è un linguaggio di programmazione dichiarativo che dovrebbe essere relativamente semplice da imparare.È bello ricco, quindi poi, insomma, se vuoi andare più nel dettaglio di tutte le funzionalità c'è tanto da imparare, però per iniziare dovrebbe essere relativamente eccessivo.Esatto, lo faccio volentieri anche perché stiamo proprio anche già definendo un dizionario comune nell'azienda dove lavoro e mi sembra proprio anche un bel momento dove darci la piatta.Perfetto, grazie a te.Ci sta.Però Mario, tu qualche tempo fa hai fatto, a Zurigo se ricordo bene, hai fatto un intervento dove parlavi di reinventare la ruota e devi sapere che nel nostro gruppo Telegram questo topic è tipo uno dei più caldi in assoluto perché come ben sai, ormai facendo parte del mondo delle community da ormai tanto tempo sai che è uno di quegli argomenti che un po riscalda gli animi no? Il tuo talk era abbastanza chiaro sul reinventare la ruota quindi quello che io voglio chiederti è proprio come primo passo proviamo a definire cosa intendiamo reinventare la ruota perché sentendo più campane spesso il reinventare la ruota è diverso a seconda della persona che lo definisce quindi proviamo insieme tutti e quattro a definire una versione non necessariamente quella giusta o la verità infusa dall'alto no però la nostra versione comune oggi del reinventare la ruota.Quindi per te Mario, che cosa è il reinventare la ruota? Allora sì, come dicevi tu, probabilmente ognuno gli dà una definizione diversa e quella che io portavo nel talk di cui parlavi è la mia definizione che ovviamente, e ne facevo alcuni esempi, che ovviamente è basata sulla mia esperienza personale, sulle cose che ho notato lavorando nell'ultimo quarto di secolo, 25 anni di programmazione, si iniziano a sentire e si iniziano anche facendo un po' di analisi retrospettiva a vedere dei cicli che si ripetono.Il mio reinventare la ruota è questo, ogni tanto mi capita che viene lanciata la nuova buzzword, perché poi il nostro mondo lavorativo è tanto basato su su su su seguire alcune mode e sul reinventarsi cose che esistevano prima semplicemente con un nome diverso che abbiamo provato a fare poi non funzionavano e le abbiamo abbandonate e poi abbiamo deciso che dopo dieci anni ce le siamo scordate gli diamo un altro nome e ci riproviamo.Questo è quello che intendevo io.Non so se posso fare uno dei primi esempi che facevo nel mio talk, è che più di 20 anni fa ormai lavoravo per un'azienda italiana che si chiamava SoftwareAgain, non so se ne avete mai sentito parlare, ma il software che è l'azienda che tra la fine degli anni '70 e l'inizio degli anni '80 combatte la battaglia dei database, tipicamente contro ora, con l'epoca la battaglia dei database non era un brand piuttosto che un altro, ma un paradigma piuttosto che un nel senso che c'era il paradigma relazionale di cui ora colla all'epoca e anche adesso era il proponente più importante, poi c'era il paradigma gerarchico che era quello invece proposto da Software Hacker, sappiamo tutti com'è andata, i database relazionali hanno vinto per un buon motivo.Poi quello che è successo però è che nell'inizio degli anni 2000 andò tanto di moda l'XML, non so chi è vecchio come me se lo ricorda, e quindi database XML e indovina un XML è un albero quindi è da gerarchia e quindi loro pensarono ok, allora facciamo un database gerarchico riutilizzando il nostro engine di storage di dati gerarchico per stavolta piccarci dentro un XML.Non aveva funzionato all'inizio degli anni 80, vent'anni dopo non ha funzionato bene.Quindi quando una idea è cattiva, resta cattiva pure dopo che l'hai riflettizzata.Ti faccio una domanda, o almeno mi piacerebbe provare a inserire questo elemento nella riflessione.Allora, posto che questi cicli storici di "fai, ritorna, fai, ritorna" sono chiari, io mi chiedo, in quest'ultimo periodo, mi sto chiedendo se in realtà il concetto di ciclo o come l'hai definito tu nel bellissimo talk che metto nelle note degli episodi di pendolo, non sia condizionato dal modo nel quale osserviamo l'evoluzione della tecnologia.Ripeto, non è la verità, è una domanda alla quale non ho risposta.Contestualizzo, quando noi osserviamo il mondo della tecnologia e proviamo a interpretare una certa evoluzione di un tool, di un paradigma, noi questa interpretazione la facciamo analizzando una serie di attributi, per esempio come hai appena detto un sistema di archiviazione gerarchico o un sistema relazionale.Stiamo valutando quel ciclo storico guardando un attributo, ma di attributi all'interno di quel processo evolutivo ce ne sono degli altri.Quindi mi chiedo, quanto, e non ho una risposta, quindi proprio una mega domanda aperta, la giro anche alla community, quanto invece questo ciclo dei corsi e ricorsi storici sia legato al modo in cui guardiamo le cose più che alle cose stesse? Allora, io come te non ho proprio una risposta e credo che o meglio ce l'ho, è simile a quello che ti ho raccontato prima e la risposta dipende esclusivamente sulla mia esperienza.Quindi come dicono gli inglesi "your mileage may vary", ognuno può aver fatto diverse esperienze, aver visto ricorsi storici diversi nel proprio settore di expertise e aver tratto conclusioni anche diverse.Non saprei come risponderti meglio di così.Guarda, puoi dirlo che sono un maledetto relativista, mia moglie me lo dice tutti i giorni, quindi forse è un modo ponziopilatesco per lavarmi le mani di una discussione scottante.Non lo so però è comunque una domanda che mi faccio e che in qualche modo mi porta anche a guardare l'interpretazione di questa cosa.Però vero è che comunque il nostro mercato è drogato, no? È drogato di stimoli autoindotti, è drogato di una serie di elementi.Quindi In realtà, secondo te, quanto il reinventare la ruota è legato a quello concetto che io chiamo "Hype Driven Development"? Ah sì, tantissimo, tantissimo.Guarda per esempio i microservices adesso, e prima si chiamavano SOA e non ci piacevano, chissà perché, adesso invece i microservices mi piacciono e io non capisco qual è la differenza adesso gli abbiamo dato un altro nome, tantissimo, è basato su queste ondate di hype, per me alle volte è difficile da giustificare, diciamoci la verità, non è vero che non si fa innovazione, ognuna di queste andate qualche cosina di nuovo si cerca di portare o di capire dove si è sbagliato e di rifarlo meglio.Questo va benissimo, però venderlo come una cosa totalmente nuova che mai nessuno si era sognato prima, ecco, quella è la cosa che mi fastidisce un po', mi fa saltare sulla sede, perché poi con un po' di anni di esperienza ti guardi indietro e c'è quell'effetto spiacevole di déjà vu, non so se riesco a spiegarmi, e dici "cavolo, sta cosa non funzionava prima, boh, magari adesso abbiamo imparato dei nostri errori, riusciamo a farlo funzionare, però andiamoci copiti di più.A livello di marketing però uno può anche capire che non venga sul mercato dicendo "ho un nuovo prodotto", sì è vecchio di 20 anni, però questo è l'anno giusto, quindi diciamo che ci sta.Poi del resto io ho dei dubbi sul fatto che se una cosa 20 anni fa non andava bene, oggi continuerà a non andar bene.Il contesto cambia, cambieranno anche soprattutto le persone, magari le persone rispetto a vent'anni fa hanno un nuovo approccio, delle nuove teste, un modo nuovo.Semplicemente non funzionava perché non si era capito come usarlo, adesso invece si sono fatti dei progressi in quella direzione.Poi l'altra cosa che mi piace poco è l'estremizzazione di certi concetti, nel senso che siamo passati c'è questo effetto pendolo tra il serverone e poi la risoluzione del suo e poi siamo tornati al monolite e poi adesso invece facciamo i microservizi e poi e però non solo facciamo questo pendolo avanti e indietro ma quando lo facciamo il pendolo ha un'elongazione molto più lunga di quello che dovrebbe avere nel senso che ci andiamo dentro all'in, prima un monolite enorme, adesso il microservizio fa l'addizione e abbiamo 250 microservizi, uno per fare l'addizione, un altro per fare la sottrazione, un altro per fare la divisione.Ecco, cioè si passa da un eccessivo estremo ad un altro e si fa fatica a trovare la giusta altro aspetto che mi sembra abbastanza ricorrente.Però credo che, non lo so, correggetemi se sbaglio, questo è un pensiero a ruota libera, ma questo tipo d'approccio sia in qualche modo correlato in realtà con il mondo sempre più polarizzato che stiamo vivendo.Nella tecnologia stiamo ormai sviluppando, c'era già da prima, però stiamo sviluppando in modo più forte il concetto di polarizzazione.Io lo chiamo il concetto del tifo calcistico.Mi sentite? Sì, sì, di sentiremi sono d'accordo.In realtà io ho provato a darmi una risposta a questa credo che in realtà la nostra industria ha avuto montagne di soldi sopra la testa negli ultimi vent'anni e dobbiamo ammetterlo.Ok? Questa montagna di soldi ha drogato, sto sparando la bomba quindi fermatevi, ha drogato un'industria che non era ancora matura che ha sviluppato una dinamica autoreferenziale di creazione della complessità.Sto facendo un giro gigante per arrivare a dire abbiamo creato talmente tanta complessità che oggi come uomini e come industrie non possiamo più controllarla.Questo fa sì che ci sia una polarizzazione estrema come gesto di protezione.Di protezione vuol dire di protezione del job securing? Anche di protezione individuale dal carico cognitivo, oltre che di protezione economica, di protezione della propria carriera.Appunto, quella che io chiamo job securing, sì, è sicuramente una lettura, sì.Questa è la cosa che più mi convince e quindi da una parte tu devi entrare in questa dinamica, dall'altra abbiamo una cosa che voglio provare a interpretare con voi, specie perché comunque sia tu Mario che Carmine hai lavorato in un mondo dove c'è tanto open source e quindi mi chiedo qual è il ruolo delle dinamiche open source e dell'evoluzione di come interpretiamo l'open source oggi che è cambiato drasticamente negli ultimi vent'anni, mi potrete confermare? Diciamo con l'open source quantomeno è un po' più di possibilità di fare il peer review, che è quella la cosa che mi piace di più di quel modo di lavorare e quindi diciamo c'è una discussione un po' più aperta e può venire chiunque a dirti "questa roba appunto ti stai reinventando la ruota" o "non funziona perché ci ho già provato io e lo so che non funziona" o "sì sei sulla strada giusta ma magari ti do un consiglio per migliorare perché ho fatto gli stessi errori che stai facendo tu e ti posso aiutare a risolverli.L'open source mitica, secondo me, un po' tanto questo problema.Io stesso mi trovo quotidianamente in meeting of fiume dove si discute di tutto e del contrario di tutto, e infatti è difficile trovare l'accordo, trovare la quadra.Siamo tutti quanti strongly opinioniti, io non mi salvo assolutamente da questo, ho le mie opinioni forti su certe cose e le difendo anche al di là del ragionevole, quindi non mi chiamo fuori da questa situazione.Io la penso esattamente come Mario e credo che l'open source abbia anche un altro effetto, che nel 99.9% è meraviglioso.C'è quell'1% che spesso porta a drogare ancora di più tutto, che è il concetto dell'alternativa.Perfetto.Avete presente l'alternativa? Io lo sto vedendo, credo, nell'ultimo anno e mezzo sul mondo front-end.esce una cosa nuova ogni x settimana.Noi stiamo parlando ora, c'è questa persona...C'è un framework javascript che sta nascendo mentre parliamo.C'è uno che sta morendo e c'è una startup che sta facendo layoff di persone che lavoravano con quella cosa lì.Ecco, il concetto di alternativa secondo me spesso si incrocia tanto con quello di reinventare la ruota, perché spesso nascono delle...è giusto che ci sia l'alternativa a qualunque cosa, solo per il pluralismo di qualunque cosa, figuriamoci il front-end.Spesso però il fatto di sforzarsi di creare queste alternative, anche quando non ce n'è effettivamente bisogno, è quella proprio la miccia su live driven development.Nel senso, Dio, è nata questa nuova cosa, concentriamoci qui, facciamolo qui, eccetera, eccetera.E spesso sono quelle tecnologie che sono anche supportate da un'ottima campagna di marketing nelle community come le stesse.Io credo che...cioè, anche noi abbiamo fatto la stessa cosa.Il sito prima di Gitbar era fatto con Gatsby.anche noi ci siamo lasciati, io per primo ho provato Gatsby che mi sembrava la soluzione a tutti i miei problemi e poi mi sono ritrovato con il sito che non compitava più, che è strano, ora stiamo parlando tra quattro persone che fanno questo lavoro e io dico il sito non compita più, che non significa niente, però siamo sostanzialmente arrivati a questa in cui la build di produzione del silo, io su diversi clienti, ho diversi progetti, ho visto questo, si rompeva.Quindi che cos'è? Quindi non va più bene Gatsby, allora si va su Next, però Next poi diventa tutto, il contairo di tutto, ci facciamo il frontend, ci facciamo il backend, perché no? Tanto si fa tutto.Poi viene, insomma, Astro.Astro effettivamente qualche concetto nuovo lo porta, proprio architetturale.anche noi di Gitbar ci siamo cascati dentro l'Astro, vediamo per quanti altri mesi dura prima che si spacchi e si ritorni a farlo insomma con Jekyll.Però ecco, apro una parentese e la chiudo coi c***i se io non rifaccio più quel sito.Il fatto è che spesso vengono proposte delle alternative che sono sacrosante, il più delle volte però le vedo come delle cose senza una precisa razza dietro, o è blazing fast però non si sa su quale benchmark o è più...io ho letto delle cose che non ho capito che che cosa significa? È più community oriented, stessa licenza, stessa cosa, dell'alternativa insomma che voleva.Quindi, come posso dire, ci sono tante cose che non ho capito e credo che questa mentalità di voler necessariamente trovare l'alternativa, ci sono aziende che foraggiano marketing per far spazzare queste alternative, e qui poi ci toglie veramente, o meglio, diciamo che lascia l'onere e l'onore a pochi di fare reale innovazione, anche in quei tempi che di innovazione, di cose nuove ne avrebbe effettivamente bisogno.Ho fatto questo discorso come tipo il vecchio che grida verso il cielo, che fa tutto schifo, però in realtà ecco è una cosa che stavo effettivamente notando.Tantissime community, ma anche se vi fate un giro su Reddit, in diversi subreddit, ci sono aziende che sponsorizzano con fiori e fiori di euro, dollari o quello che sia, una tecnologia emergente piuttosto che un'altra.Ovviamente si può dire "eh, ma lo fa e lo faceva anche ora con Microsoft Red Hat, Suse, lo facciamo, nel senso è giusto promuovere un proprio prodotto, quello che non capisco è il voler promuovere a tutti i costi un'alternativa a qualcosa che non ne aveva reale bisogno di questa alternativa.Beh, scusa vai Luca.No, volevo dire una cosa su questo, perché comunque noi siamo sviluppatori o quel che siamo, se aspettiamo di avere l'idea che nessun altro ha avuto, stiamo freschi, cioè non dovremmo fare niente davanti al computer, sennò drag and drop di elementi già fatti da altri.ma a parte questo e quindi diciamo magari un po' anche per roba personale per per spasso personale ogni tanto ci sta pure un reinventare questo nel singolo, poi ovviamente dipende da chi ti paga, cioè se ci sta qualcuno che ti sta pagando per fare quello che stai facendo magari non è proprio il massimo reinventare la ruota senza motivazioni plausibili Invece per quanto riguarda tutto il discorso dei servizi o cose che esistevano e che magari non funzionano.Mi chiedo quanto sbaglia chi fa e quanto chi decide di usare la ruota reinventata.Nella maggior parte dei casi si accusa quello che sta facendo quando in realtà io faccio quello che voglio, poi se tu mi vuoi usare usami altrimenti non ti costringo mica ad usarmi.Cerca di avere la testa, di capire se è il caso di usarmi oppure no.Certo se io sono la mega company che spingi un prodotto là è già un po' più difficile credo per tutta una serie di ragioni che sempre riguardano le persone, è la voglia delle persone di non avere responsabilità delle scelte che fanno.Poi c'è un altro aspetto che mi chiedo è se chi "accusa" di reinventare la ruota sta capendo quale ruota sto reinventando.Perché è successo più di una volta che io sono un fan del reinventare la ruota, ovviamente nel piccolo per motivi di learning, per tante altre cose, un sacco di volte che propongo una libreria o un qualcosa e mi dicono "eh ma c'è già" mi dici "ok fammi vedere cosa c'è già" "eh no c'è questo" "sì ma non è questo quello che sto facendo, ma perché sei così prevenuto?" cioè sto facendo un'altra cosa, sto risolvendo un altro problema di quello che tu pensi.È un po' smorsa l'intusione e magari sta lì, rimane lì.Ho spaziato un po' tra il personale e le big company.Il discorso personale per tutti quanti, come dicevo, è tutto basato sull'esperienza personale, ognuno ne ha una diversa.Sì, secondo me hai tirato fuori un buon punto che io sento molto nel senso per citare due miei colleghi, la cosa che pensa, io voglio programmare un ciabatte al mare comodo pensando solo a quello che effettivamente mi serve e pensando solo a scrivere e a pensare a quello che mi porta realmente valore.Io sono dall'altra proprio sponda, nel senso che a me non piace reinventare la ruota, a me piace prendere quello che c'è già, se non c'è lo faccio e lo metto a disposizione degli altri.Sono sempre stato un po' contrario a questo reinventare la ruota.Spesso però mi sono ritrovato a parlare con persone e diciamo "No, guarda, che erano convinte di star reinventando la ruota, in realtà stanno facendo una cosa completamente diversa".Il fatto che tu abbia delle esigenze di performance, di dominio, di compliance, di qualunque cosa che ti porta a scrivere qualcosa da zero invece di usare come foundation qualcosa che c'è già, non significa stare inventando la ruota.Per me, in questo caso di cui stiamo parlando, reinventare la ruota significa, e l'ho visto, No, stiamo facendo l'ennesimo microservizio crudingo, non utilizziamo Chia o un'altra libreria per fare rooting, ce lo facciamo a mano con la libreria standard e le RedEx, per me questo è reinventare la ruta, rifarsi il sistema di...- Qui vuole il "not invented here" più che reinventare la ruta, insomma.- Sì, nel senso, ci sono opposti e ci sono anche diverse comunità che spingono verso una cosa e verso un'altra cosa.Insomma, questa ovviamente è una cosa personale che non c'entra niente, ma poi è inevitabile che, ritornando al discorso di prima, il mercato si droghi inevitabilmente.Se ho la nuova tecnologia che sta prendendo piede, tutti ci vanno dietro e vogliono imparare con la tecnologia, è più o meno ovvio che l'azienda cerchi personale specializzato in quella cosa lì, perché ora va, perché può prendere fondi, perché può sentirsi di nuovo.Ci sono tante cose che vanno in mezzo, insomma.E alla fine, parliamo, parliamo, sta ancora di mezzo Java, sta ancora di mezzo Erlang, in una definizione diversa, è comunque quello, e sono ancora diciamo pochi i veri pilastri che poi si usano in certi ambienti.Non me ne vogliono più puristi di linguaggio più nuovi.Io ragionavo su una cosa, proviamo a vederla così.La tecnologia si evolve sotto forma di piccoli salti quantici, quindi non c'è una graduale evoluzione, ma ci sono degli step.Io non ho ancora individuato il momento preciso in cui c'è il salto, però mi immagino che se noi dovessimo analizzare localmente, provare a visualizzare localmente questi step, sia una crescita quasi logaritmica, quindi che tende a stabilizzarsi.Parlo di evoluzione.poi c'è lo step successivo che fa l'altro jump e quando tende a stabilizzarsi c'è un continuo reiterare.Quindi questo è più o meno come potrei visualizzarla.Però allo stesso tempo mi chiedo se cerchiamo di limitare questi sforzi perché spesso sono alimentati da da da da da marketing spesso sono alimentati da focus e qua lancio un'altra bomba autocritica focus sulla developer experience.Oggi noi siamo degli sviluppatori noi siamo degli ingegneri abbiamo un impatto fondamentale e parlo da sviluppatore che agisce opera anche in ambito pensoso Abbiamo un impatto fondamentale nel mondo che ci circonda e quello di cui parliamo ai tavoli è come miglioriamo la dev experience del tool che stiamo facendo.Ma siamo sicuri che il focus è quello fondamentale perché molto del reinventare la ruota che vedo tutti i giorni ha proprio questo focus.Va bene che voglio un cavolo di sedile nella macchina in pelle super comodo, ma se non ho le ruote io quel sedile me lo giro in el collo.Scusate il rant, però secondo me questo è un elemento importante da prendere in considerazione dal punto di vista autocritico.Che ne dite di questa visione? Io non ho una risposta, insomma vedo il punto, Il mio problema sono le motivazioni, cosa voglio ottenere, se voglio "vendere" il prodotto devo fare delle cose che probabilmente ti sembrano un po' balzane, ma in un certo senso ce le hanno.Cerco di essere… capisco il tuo punto di vista, insomma, cerco di essere un po'… passami il termine… equilibrato, insomma, nel senso che tante cose si fanno perché si devono fare.chiaro, chiarissimo.In realtà, e con questo io vorrei provare a passare a un altro argomento, però talvolta spesso si prova a reinventare la ruota super autocritica personale perché non si è capita la ruota.C'è un principio che si chiama il Chesterton fence, che cosa dice? C'è un cancello in mezzo alla strada e un riformatore, un innovatore dice togliamo sto cancello non ne vedo l'utilità, eliminiamolo.Poi arriva il riformatore, l'innovatore intelligente che dice non vedi l'utilità? Ok allora tu quel cancello da là non lo togli, te ne torni a casa, quando ne vedi l'utilità tu torna e ne discutiamo e possiamo anche toglierlo se vedi l'utilità.Se non vedi l'utilità quel cancello sta là.Probabilmente dovremmo essere o dovrei essere, lo butto su me stesso, un innovatore, un riformatore più intelligente piuttosto che un "cambiamo tutto perché non mi sembra utile".Tieni presente però che se il cancello davvero non ha un'utilità rimane lì.Se qualcuno l'ha messo ha avuto un'utilità in un qualche tempo quindi devi capirla e poi a quel punto puoi decidere di eliminarlo, puoi decidere di innovarlo.Cioè il fatto di essere ritornati con l'XML come dice Mario probabilmente viene da quel cioè non si è capito dell'impatto importante del relazionale di quell'utilità non si è capita fino in fondo e si è provato a eliminare.Chiudo qua.Tutte le decisioni dovrebbero avere una data di scadenza quella è la verità.Quando io scrivo un "to do" nel mio codice ci metto pure la data di quando ce l'ho messo insomma perché poi se no se non faccio così, trovo DuDu che sta da otto anni e se per otto anni non l'ho fatto, forse quello non lo posso togliere, perché effettivamente non c'era davvero il bisogno di tenerlo lì.Ho lo stesso vale per i ticket sull'issotracking, se il ticket sta aperto lì da sei anni e nessuno ci ha messo le mani, c'è qualcosa che non va, per il cancello quel cancello lì si può toglierlo.Darsi delle scadenze ragionevole e ripetere le proprie decisioni.Secondo me l'unica domanda è una, questo cancello è fatto in rast o no? Alla ruggine o no? No, no, no, no.Per realtà, e cico, mi ricordo qualche anno fa il trend era "lo rifacciamo in Go".Ora è "lo ho fatto in Go, lo rifaccio in Rust".Sì, hai ragione.Tra due o tre anni sarà "lo rifaccio in Zig".Tra tre o quattro anni "lo rifaccio in Java".Cioè, non lo so, ormai è ciclica come economia.E poi...Ricordo veramente che due anni, due o tre anni fa si andava su GitHub e scriveva, non il nome di qualunque tool tra Tino Go usciva.Ho rivisto AVK, SED, Datamesh, le cose veramente storie scritte in Go, senza il senso.Era veramente divertente.E lo sto rivedendo anche in tasto.E poi trovi le cose che sono state fatte, che lo stanno facendo e che continueranno a farlo in php e stanno lì, cioè, eterno, costanti.Mi voglio però portare a questo punto, visto che il tempo vola, la discussione su un altro elemento.Abbiamo un po' tutti visto il post di Mario di ieri, quando è avanti? Credo l'altro è ieri, sì.sui pattern ed è una critica che ha le sue radici e ci piacerebbe approfondirla un attimo con te e soprattutto ti chiedo come si lega quella critica al concetto o meno di reinventare la ruota? Credo che reinventare la ruota lì c'entri poco, anzi tu vuoi definire dei design pattern proprio per evitare quello, hai un problema, hai una soluzione codificata e non ti inventi da zero la soluzione e ce l'hai lì.Il motivo per cui ho fatto quella critica al Gengofor, ho scritto che è invecchiato male, ma nel senso che il problema di quel libro, e ho cercato di spiegarlo, è che ha un solo unico punto di vista che è quello dell'object orientation e quindi praticamente partendo da lì tutto tutto tutto diventa un oggetto e quindi invece di fare una funzione di passare in giro una funzione devo fare uno strategy pattern invece di usare i pattern matching devo usare il visitor e invece di usare la function composition devo fare un decorator e invece di usare sia ancora la function composition devo fare una chain of responsibility.Insomma quello che volevo dire è che il difetto di quel libro è che c'è solo il punto di vista degli oggetti e quindi tutto diventa un oggetto, una funzione deve diventare un oggetto, tipo un command, per esempio, ma quella in effetti è solo una funzione, gli stai mettendo attorno una infrastruttura d'oggetto, stai trasformando un verbo in un nome, solo per motivi di paradigma di programmazione, ma non per motivi veri, e quello che poteva essere ragionevole quando quel libro è stato scritto, oppure qualche anno dopo quando Java è nato è iniziato a diffondersi, o altri programmi che erano pure object oriented, che avevano senso all'epoca, quei concetti là, non ce l'hanno proprio più, perché adesso un libro di design pattern non è che non dovrebbe esserci, ma dovrebbe tener conto del contesto nuovo, ma neanche tanto nuovo, visto che la Lambda e Java per dirne una sono state introdotte otto anni e mezzo fa, non ieri, del contesto nuovo che c'è.Il problema di quel libro è che non è un libro rivolto a nessun programmatore che usa linguaggi di programmazione moderna, che nessun linguaggio di programmazione moderna è puramente oggetti.Non era contro il concetto di design pattern, ma contro il concetto di design pattern esclusivamente orientati al al mondo degli oggetti, come viene proposto in quel libro.L'altro aspetto che ho accennato e che ho visto qualche anno fa, adesso per fortuna non è più così, ma forse più che altro per quel libro non è più tanto così mainstream o forse online, quello che vedevo che la gente buttava dentro questi pattern, dentro il proprio codice in maniera compulsiva, senza un vero motivo, giusto per metterci il check box su "ok, lo strategia l'ho usato, visitore l'ho usato, il command l'ho usato, il template l'ho usato.Usandolo ti sto dimostrando che lo so.Nella mia vita lavorativa ho visto più danni che vantaggi fatti in nome di quei pattern.Quello che è positivo che ci ha dato quel libro, e l'ho scritto, l'ho ammesso, è che ci ha dato un vocabolario comune.Quando un programmatore dice "ho usato uno strategy", ti sta dicendo una cosa che dovresti sapere, che c'ha un nome.Il merito è stato quello di dare nomi a quei modi di implementare una soluzione.Il punto è che quelle soluzioni avevano senso in un mondo puramente oggetti e adesso non è più il caso.L'altra cosa che ho fatto, ma ripeto, è un discorso che va avanti da diversi anni, almeno da quando è stato introdotto la lambda expression in java, quindi 8 anni fa.Sei anni fa feci un progettino in cui prendevo degli esempi così come erano scritti nel libro del Gang of Four di Object Orientation e li scrivevo con quei concetti di programmazione funzionale che vi dicevo.se andate sul mio GitHub sicuramente lo ritrovate, quel progettino che si chiama "From Gof to Lambda" e c'è anche linkato il video di un talk in cui facevo quelle trasformazioni in una sessione di programmazione funzionale, credo che fosse DevOx, non mi ricordo se fu quella in Belgio o quella di Newgator, in entrambi i posti.In più, pure da lì è nato un trend, nel senso che qualcuno ha fatto lo stesso esercizio in altre linguaggi di programmazione, tipo Swift e Kotlin, ho cercato di linkare anche quegli altri esperimenti nei ritmi del mio progetto.Ecco, questa è la motivazione da cui è partita la discussione e in realtà è partita per caso perché domenica sera l'amico di un amico ha scritto "io mi leggo il golf, ce l'ho sul comodino, è il mio libro di programmazione preferito" e mi ha fatto saltare un po' dalla sedia e da lì è partita la discussione.Poi per come è stata presa, devo dire la verità, ho ricevuto delle critiche ovviamente, ma mi sembra che la maggior parte siano più commenti di consenso, diciamo che i commenti di consenso hanno largamente sovrastato le critiche, quindi evidentemente non sono solo a pensarla così.Esatto, questo ragionamento che mi abituo qui è un ragionamento, quello che si ha su Twitter, specialmente negli ultimi giorni, è terribile.Io ho letto alcuni commenti critici anche su altri account legati a QTT ed erano terribili.Guarda, io a un certo punto l'ho mollato perché per me era impossibile stare appresso a tutti commenti, insomma, nemmeno me l'aspettavo, è vero che ho scritto un piccolo thread per cercare di chiarire la mia posizione, raccontare in maniera succinta quello che ho cercato di spiegarvi adesso poi in maniera un po' più estesa, però poi lo mollate, voglio dire, se no la mia giornata lavorativo basta rispondere ai twitter non mi pare il caso.Io però quando ho visto la risposta del vecchietto scappato dalla casa di riposo che dice cose deliranti e continua a farlo...Stai parlando di Uncle Bob? Aspetta però perché secondo me quella cosa mi ha fatto capire un un elemento importantissimo, che fa parte del nostro approccio.Noi trattiamo i testi, io in primis, come il libro, come se fosse il Vangelo secondo Uncle Bob, il Vangelo secondo Goff, ed è sbagliato.Ma quel libro in particolare è stato "Il Vangelo" e me lo ricordo benissimo, spero che non sia più così, ripeto.O spero che il mio tweet sia un piccolissimo contributo ad evitare che sia così in futuro.Ma quel libro è stato il vancello per generazioni di programmatori ed è stato anche il motivo per cui quando si è iniziato a parlare di programmazione funzionale, per esempio Java è arrivato dopo degli altri, oggettivamente, ma anche in altri linguaggi, la gente ha fatto una fatica bestiale, ripeto, soprattutto in Java, perché in Java poi era diventato davvero avambibbio, come dici tu quel libro lì, la gente ha fatto una fatica bestiale a iniziare a usare bene le funzioni, proprio perché venendo da quella prospettiva lì non ci si ritrovava più.A semplificare il codice tra l'altro.E tra l'altro c'è un altro elemento che voglio aggiungere alla discussione perché in realtà veramente proprio quella risposta della qualità che vi faccio vedere andatevelo a vedere e lo capite da soli però quella risposta poi mi ha in questa riflessione personale mi ha fatto pensare pensare a un'altra cosa e io c'ero cascato in pieno.Abbiamo considerato la conoscenza dei pattern della Gang of Four come la discriminante per dire io sono un senior, so programmare e tu no.Sì, non solo quella roba lì è stata usata, ripeto, pure questo spero non succede più ma è stata usata per fare un casino di interviste di lavoro insomma crede che migliaia di sviluppatori nel mondo se non milioni sono stati assunti o non assunti in base alla conoscenza dei pattern di quelli pratichi è ancora così e nelle università è ancora così I professori che insegnano la parte Java, la programmazione ad oggetti così, lo considerano ancora come la Bibbia e osteggiano la programmazione funzionale nello stesso modo in cui tu stai raccontando.Ma sai, io come ti dicevo, non è che osteggio niente, non è che osteggio l'object orientation, ci sono diversi paradigmi di programmazione, io te ne parlavo di un terzo quando parlavamo del mio rule engine, c'è l'object oriented, c'è la functional programming, c'è la programmazione dichiarativa.Un'altra cosa che ho cercato di dire nei miei tweet è questo, che vedo un sacco di persone che si vantano di conoscere 10 linguaggi di programmazione diversa, ma li usano tutti e 10 nello stesso identico modo.E allora perché ne devi usare 10? Perché devi fare Java, Scala, Kotlin e usarli tutti e 10, tutti in uno stesso modo, non in maniera idiomatica.Quello che invece è meglio è magari usare uno solo, ma usalo in maniera non deve essere necessariamente poliglot, ma deve essere poliparadigmatico, deve conoscere più paradigmi di programmazione, quanto più è possibile, perché quella è la tua cassettina degli attrezzi.E poi molto probabilmente tutti quei paradigmi di programmazione, se usi un linguaggio di programmazione moderno, li puoi usare con lo stesso singolo linguaggio e questa è l'altra cosa importante.Vi ripeto, ho visto scrivere Scala come se fosse Java vecchio prima delle Lambda, però è scritto Scala, e allora che cavolo di senso ha? Ho visto Scala con Spring scrivere come se fosse Java, è quello che devo capire.Però vi faccio una domanda e con questa chiudiamo perché ho visto l'orologio e siamo super super oltre.Se mettiamo sul tavolo i pattern, siano essi funzionali o a oggetti, e gli algoritmi, possiamo fare una distinzione in termini di impatto e di entità? Per algoritmi, intenze, strutture e dati? Esatto, algoritmi, strutture e dati.Diciamo che siamo su due livelli di astrazioni un po' diverse, secondo me, due livelli di complessità pure diversi.Alla fine quel libro, il Game of Four tra l'altro, è molto verboso, nel senso che è un concetto tutto sommato banale, tipo uno strategy, ci mette 25 pagine di testa per spiegarli, col con diagrammi OML, con sequence diagram e che cavolo altro ne so.Però se ci pensi quello è un concetto banale, se devi spiegare una struttura adatti tipo BlackTree, che è tutto sommato semplice, ma siamo su un livello di complessità che non ha paragoni.Stiamo parlando di due cose su due piani un po' troppo diverse.Ho visto l'orologio e ahimè io rimarrei, non so Scarmini e Luca, ma io rimarrei ore a parlare con Mario ma dobbiamo lasciarlo andare a cena e quindi lanciamo rapidamente il nostro momento tipico e topico che è il Paese dei Balocchi.E conduco nel paese dei balocchi.Ah, il paese dei balocchi.Allora Mario, la mia domanda è, hai qualcosa da condividere con la nostra community? Allora, sì, mi hai detto di questo format subito prima della nostra call, un po' mi divertito, devo ammettere, mi ha spiazzato perché stavo ripensando a cosa "portarvi il regalo".Credo che vorrei portarvi il regalo il mio libro preferito, io ce l'ho lì, è un libro vecchio, sono lì da quando avevo forse meno di 18 anni e ogni 10 me lo rileggo, non è il Gengoforro.Il libro si chiama in italiano "Un'eterna ghirlanda brillante", non so se ne avete mai sentito parlare.L'autore si chiama Douglas Hobstater, è un pensatore, filosofo americano, credo morto proprio da pochissimo.Il libro è del fine anni '80, inizio anni '90 e parla di logica, del teorema di Codell, di Escher, di come Bach componeva la musica e di come queste cose si sono influenzate fra di loro e in che correlazione stanno.Il titolo completo è "Gode lescher back un eterna girlande abbrillante".Vi consiglio davvero di leggerlo.Io ce l'ho lì, ogni dieci anni lo rileggo, mi faccio più vecchi di dieci anni e scopro cose che la lettura precedente non avevo capito e scoperto bene, quindi regalatemelo per Natale.Bellissimo, hai aggiunto l'ennesimo libro alla pila di libri che io dovrò leggere, tenendo presente che ho solo pochi giorni per le ferie di Natale, ahimè dovrò trovare il tempo per farlo.Carmine, Luca? Vado io? Sì, io ho un consiglio e un libro tanto per cambiare.Il libro si chiama "Design Pattern" no scusate era un altro, no, un libro è un testo narrativo, un romanzo che anch'io stavo cercando qualcosa da balloccare ormai, credo di aver balloccato quasi tutto.Il libro l'ho letto ho letto, forse 15-18 anni fa, si chiama "Improbable" di Adam Fowler.Mi sono reso conto che tante cose che so di statistica lo devo a questo romanzo e credo anche gli devo un 29 in calcolo di probabilità statistica dell'università e quindi ce l'avevo in mente e ve lo consiglio.Credo che è lì che ho imparato il paradosso del compleanno.Credevo di averlo fatto l'università, invece l'ho imparato proprio questo libro.Il secondo balocco è un consiglio.Io da qualche mese sto dando ripetizione di matematica a una mia vicina di casa che fa la terza media.Non so perché è una cosa che mi piace e soprattutto mi piace il fatto che insomma, sto contribuendo a diciamo, non voglio dire rendere migliore una persona, però ci siamo, quindi magari invece di stare la sera a casa a reinventarvi la solita ruota potete uscire e fare del bene.Fare un po' di mentoring, il mentoring è importante perché è anche bidirezionale, si impara a mentire, impara ovviamente, ma anche a metterlo… c'è una comunicazione bidirezionale.LM: esatto, impari tanto, impari anche a comunicare, impari a far capire, perché tu dici "ma io te l'ho spiegato, perché non stai capendo?" Evidentemente non hai spiegato bene e se non hai spiegato bene forse non l'hai capita bene la cosa e sto parlando di matematica di terza media.Quindi questo è quanto, vai Carmelo.Allora, io in realtà ho due libri, uno tech che ho finito di leggere un po' di tempo fa, che probabilmente non fecherà a nessuno, ma si chiama "Testing Elixir" e insomma diciamo per chi stesse cominciando con Elixir, insomma, se volessi affacciare questo mondo qui, non è assolutamente...non mi viene da dire in italiano, direi "straightforward", ma non so come dirlo in italiano.Non è proprio semplice, ecco, approcciarsi al testing quando, insomma, si va nel mondo dei processi della concorrenza di Erlang con OTP, e proprio così, è un bel libro fatto bene.Vi dà effettivamente un insight utile e pratico su come testare il vostro codice in questo caso.E l'altro invece il libro è profilo di leggere qualche giorno fa, profilo di rileggere, mi è piaciuto come la prima volta ed è "Sostiene Pereira" di Davuk, insomma.Se vi capita di vederlo in libreria, è un bel libro.Io è difficile perché in realtà le ho finiti tutti però guardando qua a fianco al mio computer ho un libro che ho già portato ma siccome è veramente figo ve lo porto per la seconda volta è un libro che è dedicato ed è indirizzato ai manager quindi ai tech lead piuttosto che agli engineering manager ma secondo me da sviluppatore assume una lettura completamente diversa che va fatta.Il libro è The Manager's Path e secondo me per ciò che riguarda le soft skill può essere un punto di riferimento che però mi piacerebbe mettere in discussione tra dieci anni per vedere se è ancora attuale e se i contenuti sono invecchiati bene o male.Detto questo io direi che il momento della sigletta è e dei saluti.Bene Mario, io sono super super super felice di averti avuto qua con noi.Grazie a voi.La chiacchierata è stata veramente figa, io non posso aggiungere altro.Assolutamente.È così che ci divertiamo.Come diciamo di solito, da oggi GIT BAR è un po' il tuo bar sotto l'angolo, nel senso che quando è qualcosa di bello che ti fa piacere condividere con noi, noi abbiamo sempre una birra fresca da invitarti per farci una chiacchierata e passare del tempo insieme.Detto questo io ti ringrazio nuovamente Mario, vi ricordo rapidamente i nostri contatti info@gitbar.it @brainrepo su Twitter e il gruppo Telegram di Gitbar prego prego che siamo più di...vai vai lo diciamo insieme 1, 2, 3 gruppo Telegram di Gitbar siamo lì si, dovete andare sul gruppo Telegram siamo più di 1300 una varietà di...siamo 1138 Carmine Hai invertito il 3.Ah sì, scusate.Mi scalponiate.Vabbè ma Carmine è avanti.È avanti.A parte che non so quando esce questa puntata, quindi va bene, vedete che siamo a 1300, si parla di tanti argomenti diversi e se vi volete le licenze trovate anche qui.Detto questo io ringrazio nuovamente Mario e alla prossima.Ciao! Ciao! Ciao, grazie! 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 e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.(Sottotitoli a cura di QTSS)
