Nel nostro bar degli sviluppatori.Bar degli sviluppatori che ha una bellissima bellissima o almeno per me una bellissima sigla che naturalmente essendo io invecchiato parecchio non riesco a vedere a leggere nel pulsante quindi facciamo la solita la figuraccia del del boomerissimo.Avviciniamo gli occhi allo schermo.Eccola qua.Cioè, questa cosa è vergognosa.Io credo che mi si piglierà per il culo a vita perché sta cosa è "facciamo partire la sigla".Siamo noi quelli che leggendo il codice cercano lo stronzo che ha scritto quello schifo.Ma ahimè lo stronzo è me medesimo, l'ho scritto giusto ieri And I'm sorry Siamo quelli che santificano il nuovo framework javascript preferendo segretamente jQuery Gli stessi per il quale il testing è importante, infatti la nostra code base ha solo due test e flakey pure Siamo noi quelli che il tuo linguaggio fa cagare, ma il mio è peggio Quelli che la chiarezza nei commit message prima di tutto, e dentro ce l'appella tutti i santi E' no bestemmia guarda quelli che in call parlano per 5 minuti prima di accorgersi che il mic è muto quelli che non si può fare di default diventa velocemente un tutto e possibile se hai le risorse, tempo e budget illimitato siamo noi quelli che l'AI va regolamentata mai visto questo nuovo modello che disegna gatti di funambuli? quelli che il dipende e unisci gratis la prigione e quelli che la RAL...no vabbè, fa già ridere così Siamo quelli che fanno lo slalom tra le specifiche che cambiano costantemente, ormai rassegnati che la definition of ready è solo una pia illusione.Quelli che si sentano dire "ho un'idea per un'app" ed è subito l'ennesimo social come Instagram, ma meglio.Siamo noi che nonostante il deploy fallito, l'Asia in rossa, il business incazzato, ci troviamo al github e davanti a una birra tutto ci sembra un po' meno grave.Davanti a una birra tutto ci può sembrare un po' meno grave, ma è gra...in realtà che di avere qua oggi a darmi una mano in questa chiacchierata con un ospite che vi svelerò tra qualche secondo, di aver Luca perché in realtà non ha ricevuto l'evento nel calendario.Ecco ecco ecco stavo appunto debagando cercando di capire perché per questo ho fatto un minuto di ritardo ma ci sono ci sono questo è l'importante.Grazie di cuore Grazie di cuore, iniziamo subito con il momento dei rant.Oggi iniziamo perché sono incazzatissimo.Problema numero uno.Orange Telecom ha deciso che oggi, primo maggio, festa dei lavoratori anche qua in Francia, non doveva funzionare e quindi sono da stamattina che non ho internet e sto andando col telefonino che ormai è diventato una pietra rovente e quindi non so quanto può durare se esploda o meno però io credo che ce la farà a farcela.A parte Orange Telecom, che si merita tutto il mio odio, ho un altro rant da fare.Credo di aver capito dov'è il problema del calendario, Luca.La settimana scorsa credo di avervi di un balocco super figo che sono le app di Moleskine create da Bonobo.Adesso non ricordo se ve ne ho parlato.Sono delle app bellissime con una UI super innovativa, con un sacco di micro...come si chiamano? Micro animazioni, micro interazioni...veramente molto ergonomiche direi.E' peccato che non mandano gli inviti.Quindi alla fine cercherò adesso...No, ma adesso...Dai, dai! Ma sì, potrei anche farmela da solo la puntata, visto che ci sono...No, però il fatto è che ci auto-invitiamo, così...Beh, come tutti i bar, le porte sono aperte, ovvio.Esatto, esatto.No, comunque adesso magari debago ancora un po' e scriverò una mail, perché sono delle app veramente fighe, ma se non funzionano rimangono dei pezzi di applicazione che non funziona, quindi non ce ne facciamo niente.Luca com'è? Come te la passi? Bene, bene, bene, tante novità, tante cose per personale e lavorative, ma bene.Diciamo che il lavoro cambia e cambia proprio di primo maggio, che è una data molto simbolica per cambiare posizione lavorativa.Allora in tutta sincerezza come direbbe il vecchio saggio io ti do i più grandi in bocca al lupo a nome mio anzi a nome di mio e a nome di Gitbar ti do i bocca al lupolo perché insomma ci sta sempre.Quello molto molto bene anzi quasi quasi Mi assento un attimo e ti dai all'alcol.Mi do all'alcol.No in realtà perdonate se dico delle cose inenarrabili o delle cazzate super fredde ma è come dicevo al nostro ospite in pretrasmissione sono completamente bollito.Quindi sopportatemi.Ma lo annunciamo allora il nostro super ospite di oggi.Subito dopo la sigla specifica dell'ospite adesso mi sono già posizionato il mouse sul pulsante in modo che non mi debba avvicinare.Abbiamo con noi Mauro Servienti che oltre ad avere un bellissimo nome e anche software architect a Particular Software e uno dei creatori di N Service Bus.Dico bene Mauro? Abbastanza bene, sì.Tutto giusto, a parte il fatto che non sono proprio uno dei creatori ma lavoro per l'azienda che produce Service Bus.Sono arrivato dopo che Uno dei...io ho letto nella tua bio così no? "One of the makers" di Anservice Bus.Ho tradotto letteralmente "mea culpa" però a questo punto ci racconti che cos'è Anservice Bus? Anservice Bus è un framework di messaggistica fondamentalmente.Se avete mai avuto a che fare con sistemi distribuiti e code o semplicemente con code quindi la necessità di mandare un messaggio da una parte all'altra utilizzando una coda che può essere da RabbitMQ a SQS su Amazon o Azure Service Bus su Azure o MSMQ per chi ancora usa Windows e MSMQ.Il service bus è un framework che si pone sopra l'infrastruttura code e permette di astrarre in parte la coda sottostante, quindi diciamo che un po' come potrebbe fare un ORM, ci permette di rimpiazzare la coda sottostante in maniera più o meno trasparente, non è proprio così semplice, ma diciamo che concettualmente si può fare un ruolo del genere e in più offre tutta una serie di funzionalità on top all'infrastruttura di code che l'infrastruttura di code non offrono perché non è il loro lavoro, fondamentalmente il lavoro di una coder, quello di portare un messaggio da ABI o di fare broadcasting come può fare RabbitMQ con i topic o SNS su Amazon con i sempre i topic.Ti faccio una domanda, sviluppare una libreria condivisa o comunque lavorare allo sviluppo di una libreria condivisa spesso è una sfida che va oltre il lato meramente tecnico.Certo.Quali sono dal tuo punto di vista gli elementi non tecnici che entrano in gioco in questa partita? Mi ne vengono in mente tre, di cui uno sfiora il tecnico ma non è prettamente tecnico.Ti direi, nel nostro caso e probabilmente nel caso di molti aziende che fanno software, chiamiamolo middleware in generale, noi abbiamo il colossale problema che i clienti sono molto lontane da noi.Quindi nel senso che abbiamo clienti estremamente diversi per tipologia di clienti, da dimensione a quello che fanno e soprattutto quelli grossi è molto difficile avere un ciclo di feedback.Quindi tu rilasci lo usano, non lo usano, che versione stanno usando, non sai assolutamente nulla di tutto ciò.E spesso di dire, anche contattandoli direttamente, le risposte arrivano mesi dopo, perché quando parli con aziende enormi sono abbastanza normali, cioè hanno altre priorità che rispondere a te e di conseguenza aspetti.E questo fa sì che sia molto difficile avere una sorta di, chiamiamola roadmap, cioè capire cosa facciamo adesso, perché fai molta fatica a capire che cosa vogliono questi con cui non riesci a parlare.Questa è una delle cose secondo me più complesse.La seconda è che sfiora leggermente il tecnico la documentazione.Tra i nostri clienti tutti apprezzano la quantità industriale, la qualità della documentazione su cui noi investiamo una quantità di tempo sproporzionata rispetto a quanto investiamo per scrivere codice.Il mostruosamente, c'è un ordine di grandezza probabilmente tra le due cose, tra quello che mettiamo in scrivere documentazione rispetto a lo scrivere codice, dove per documentazione intendiamo anche, che ne so, le upgrade guide.Quindi passi da una versione all'altra e hai corposa documentazione su come fare l'upgrade guide.E in quel senso, come fare l'upgrade? sfioro un pochettino il tecnico perché da quando...In Service Bus è tutto .NET, quindi è tutto C# e .NET.In .NET, qualche anno fa, Microsoft ha introdotto un nuovo compilatore che si chiama Roslyn.E Roslyn è scritto a sua volta in C#, che è curioso perché è un po' come se erano tutti i primi a volare la gallina.In C# scrivi un coso che scrive C#.E una delle cose che hanno introdotto è una sfilza di punti di estendibilità del compilatore.Quindi si chiamano Roslyn, ad esempio, si chiamano Roslyn Analyzer o Roslyn Fixer, e via dicendo.Se avete mai utilizzato, ad esempio, un IDE di Genprein o Resharper, avete tutte quelle funzionalità dell'IDE che vi suggeriscono "No, ma togli quella roba lì" oppure "Farlo così" e via dicendo.Tutte quelle robe sono Analyzer e Fixer.Una volta gli IDE si edificiano da soli, quindi devono capire da soli come era fatto il codice, e via dicendo, adesso te lo fa il compilatore, tu puoi estendere il compilatore, che è un lavorazio perché ha a che fare con un linguaggio di bassissimo livello e tutti questi expression tree che rappresentano la sintassica in davanti, ma è quello che ci permette di fare, è che ci permette di suggerire all'utente, "Cambia il tuo codice così perché sarai compatibile con una nuova versione".E quindi possiamo intervenire direttamente nell'idea dell'utente cambiare il codice senza che debba leggersi la cosiddetta "upgrade guide" e che non è niente male.C'è una terza cosa che in questo momento non ricordo più, l'età colpisce.Mi viene in mente una domanda, a posto che appunto questa la possibilità di intervenire proprio in quella fase per suggerire delle cose mi affascina particolarmente.Mi chiedo perché è una sfida che sto abbracciando adesso a lavoro? Sono sparito? Sì, non ti vediamo più, almeno io non ti vedo più.Non è che io ti vedo, però ti sentiamo messo.Però è un podcast.Esatto.Dicevo, a parte questo, una cosa interessante che mi interesserebbe sentire da te è legata al Breaking Change.Quando tu gestisci una libreria così importante, come approcci alle breaking change, perché io ho avuto una discussione da poco con alcuni architetti del progetto dove lavoro e si era quasi tutti allineati sul concetto "no breaking change", cioè che vuol dire ti porti a presso la merda, e te la continui a portare ad oltranza.Ecco, Tu, e soprattutto nel contesto di una libreria condivisa, come approccia e come approceresti ai breaking change? Ma allora, noi fino a un annetto fa, un annetto e mezzo fa, seguivamo in maniera religiosa semantic versioning.utilizzavamo il numero di versione per comunicare le breaking change.E continuiamo ad avere un approccio ai rilasci che devia moltissimo da quello che fa il resto del mondo dell'informatica e in questo senso per certi vesti dal punto di vista commerciale ci penalizza un pochettino.Che è quello che le major release sono la parte noiosa in cui togliamo roba e quindi facciamo le breaking change.Quindi immaginiamoci molto semplicemente se abbiamo un metodo che fa una certa cosa e a un certo punto lo vogliamo cambiare, quello che succede è che rilasciamo tipicamente una minor in cui in questo caso tramite i tool di .NET comunichiamo che il metodo è deprecato, quindi è obsolete, continua a funzionare senza nessun problema.Nella major successiva il metodo verrà rimosso dal punto di vista della funzionalità, quindi Il compilatore ti dà un errore perché ti dice che non lo puoi più chiamare, ma l'intelligenza lo fa vedere lo stesso.Quindi il vantaggio è che tu aggiorni la major successiva e dal tuo codice qualcosa non scompare, nel senso che l'IDE ti dice che non esiste più e quindi non sai cosa farci.L'IDE continua a dirti che c'è, ma non lo puoi più usare.Quindi hai tutti i vantaggi della documentazione in line all'interno dell'IDE che ti dice "usa questo per fare questa roba qui" oppure "vai a vedere il guide per sistemare quello lì".e nella major successiva ancora scomparire il codice.Quindi questo vuol dire che il processo per ridurre, per rinuovere un qualche cosa, nel nostro caso, siccome puntiamo a rilasciare una major circa ogni anno e mezzo, ci vuole tre anni abbondanti.Il che è un bagno di sangue, se ci pensate, perché non comporta il tenersi dietro codice legacy per un sacco di tempo.Abbiamo delle parti del codice in cui la filosofia è "no breaking changes", per cui noi distinguiamo la compatibilità tra tre cose diverse.Quindi abbiamo la compatibilità a livello di API, quindi quello che il programmatore utilizza quotidianamente.Abbiamo la compatibilità che noi chiamiamo "wire compatibility", quindi due nodi che usano in service bus che parlano tra di loro e si scambiano messaggi.Banalizziamola dicendo, il formato di serializzazione del messaggio che viaggia sul trasporto è la Quest Data Wire Compatibility, e quella da, direi oggi è il 2024, da 16 anni a questa parte non l'abbiamo mai nota.Quindi è sempre rimasta retrocompatibile.Perché quello si porta a casa il colossale problema dei Quest Data In-Flight Messages.Cioè, tu aggiorni un nodo, ma hai messaggi che sono sulla coda in quel momento lì.E quindi devi continuamente consumare roba che arriva da non hai la più pallida idea a quale versione.Perché non sai chi te l'ha mandato, fondamentalmente non lo puoi sapere.potremmo farlo sapere ma comporta altri problemi.Quindi non abbiamo mai implementato questa roba e di conseguenza siamo retto compatibili fondamentalmente all'infinito.E poi la cosiddetta schema compatibility per lo storage, delle cose di cui facciamo storage, in cui non abbiamo mai fatto...non abbiamo la stessa logica del non breaking changes come sulla wire compatibility, ma non abbiamo mai fatto breaking changes.Non abbiamo mai avuto la necessità di fare breaking changes.Quelle volte che abbiamo cambiato il formato, l'abbiamo fatto sempre in maniera retrocompatibile, per cui il nodo si auto aggiornava e man mano che consumava i dati, cambiava anche lo schema del dati che consumava.Quindi potevi trovare, analizziamo la molte, immaginiamoci che i dati stessi lo sono su un dataproceso documentale con metà dei documenti con uno schema e metà dei documenti con uno schema nuovo, e man mano che i documenti venivano consumati, che venivano aggiornati alla versione successiva.Perché un altro dei problemi che abbiamo è che tipicamente in un sistema distribuito vuoi i cosiddetti no downtime deployment.Cioè voi potete fare deploy senza avere downtime.E di conseguenza non puoi permettere di dire "Ok, ferma tutto, lancia questo script in produzione, spera che vada tutto bene, sennò fai rollback e poi fai deploy".Deve essere tutta una roba che funziona appunto.e di conseguenza le breaking changes sono un colossale problema.Abbiamo ultimamente rilassato leggermente l'uso di semantic versioning.Rilassato intendo che fino a un annetto e mezzo fa, se cambiavamo il messaggio, il testo, in uno statement di log, per noi era una breaking change."Quello non è per un rating change", abbiamo detto.Forse è un po' esagerato.Ce l'avevamo perché sappiamo che abbiamo dei clienti che hanno tool di monitoring che guardano i log e di conseguenza utilizzavano il test del log per capire se era un problema o no, che a cui dovevano dare retta.Però sono molto pochi e un pochettino..."Se c'è un type, c'è un type", non è che puoi impazzire a dire "Tirala giù una major release perché c'è un type e non un log", e quindi abbiamo detto "No, quello non va, come se fosse una patch o una minora, secondo me, quello che stiamo lasciando in quel momento.E di conseguenza così è.A questo punto mi viene da chiederti, e ci spostiamo un po' a parlare di ambienti distribuiti in modo un po' più wide, abbiamo parlato di breaking change e di aggiornamenti di versione.Quali sono secondo te, immagina un sistema distribuito, il sistema distribuito spesso ha senso in una logica di business che è abbastanza grande da poter giustificare degli ambiti, passamela in modo brutale, dei team che si occupano di un pezzo del dominio ben definito o di un pezzo di sistema, bisogna immaginare il microservizio che si occupa dell'invio delle mail, sto banalizzando.Capita che uno di questi ambiti, cerchiamo di rimanere più generici, uno di questi ambiti deve evolversi, debba aggiornarsi, per cui debba rilasciare una major, salire di versione e aggiornandosi va, deve andare a cambiare magari l'interfaccia, ok? Per interfaccia intendo l'insieme di API, chiamate col protocollo che più vi piace, che può essere attraverso messaggi, HTTP o piccioni viaggiatori, ma comunque cambia il protocollo.Come funziona? Secondo te, dalla tua esperienza, qual è il modo più semplice, ma allo stesso tempo effettivo per poter fare questa evoluzione? Non c'è e dipende dalla modifica.Faccio un passo indietro e vi attacco una cosa che ho detto all'inizio, che il mio motto di solito è, parafrasando un pochettino quelli di Fight Club, la prima regola dei sistemi distribuiti è che non ti serve un sistema distribuito, cioè devi avere motivi e problemi ben precisi per accettare i problemi che ti porti a casa con il sistema distribuito.I vantaggi devono essere tali che deve valere la pena far lo sforzo di andare in quella direzione.Uno dei problemi che ti porti a casa è esattamente quello che hai appena descritto, cioè il fatto che tu hai uno o più pezzi che in qualche modo non possono essere deploiati insieme, perché non vuoi, perché non puoi, perché ci sono team diversi, perché un team non è pronto, quello che tu hai pensato non è un problema particolare, perché magari non hai nessun controllo sull'altro pezzo e devi in qualche modo rompere il contratto tra i due.Diciamo che il problema colossale ce l'ha il momento in cui togli roba dal contratto, quindi finché vai in aggiunta è un problema molto relativo, per cui tu puoi aggiungere roba e devi gestire il fatto che ci sarà qualcuno che ti manda meno roba di quella che tu vorresti, quindi diciamo che quella retrocompatibilità è relativamente semplice.Facciamo un esempio banale, io ho il mio classico contratto che si spieta un username oppure una person, il first name e il last name e a un certo punto voglio anche aggiungere sempre utilizzando un esempio banalissimo il full name.In quel caso lì c'era qualcuno che continuava a mandarmi first name e last name e io full name mi devo attaccare e dire ok non ce l'ho perché questo tizio non me l'ha ancora non si è ancora aggiornato per mandarmelo ma diciamo che il contratto non si è spaccato tecnicamente perché andando in aggiunta se la pensiamo dal punto di vista di qualcuno che serializza quel payload, il serializzatore è in grado di deserializzare con un pezzo di più.Allo stesso modo il serializzatore sarebbe in grado di serializzare con un pezzo di più.Quindi io ti mando first name, last name e full name, tu conosci soltanto first name e last name, il full name lo perdi, ma a te diciamo che non te ne frega niente, perché se non ce l'avevi prima, non sai che ti arriva, non l'hai mai usato e quindi il tuo processo di business non lo usa e di conseguenza chi se ne frega.Il problema è quando facessi un esempio contrario, a un certo punto tu hai il tuo contratto che è solo full name, a un certo punto tu dici "no, adesso lo voglio far diventare first name e last name e tolgo full name".E' quella roba lì, non si può fare.Quindi è fondamentalmente "io ti sto mandando full name oppure accetto full name", in entrambe le direzioni funziona in questo modo.Ti devo dire, vorrei anche first name e last name e per sei mesi accetto di entrambi.Sei mesi, un anno, un mese, quello che vuoi.Per cui c'è un lungo periodo di tempo in cui il mio contratto è doppio e quindi tutti sono in grado di parlare con me con una o più versioni.E se la pensate in maniera un po' più estesa potresti avere una situazione in cui chiunque è in grado di parlare con me con cinque, sei o sette versioni diverse, perché nel frattempo un altro pezzettino di me è cambiato, c'è tantissima altra roba, quindi anche comunque qualcuno, magari tre versioni con cui stanno parlando con me.E a un certo punto posso dire, per io è una policy, a un certo punto dirò ok, la spiri in basso, perché quella roba non la voglio più.Non ti sei aggiornato in tempo, non ti sei aggiornato in tempo.Poi a seconda della complessità di gestirsi diciamo più versioni dello stesso processo di business uno può decidere che quella versione 1 la supporta per sempre, quindi supporterà per sempre la versione 1 e la versione 2.Perché è un non problema, diciamo che da un punto di vista tecnico tu dici è un non problema supportarla entrambe, le supportiamo entrambe.Oppure dà un codice, basta.Il codice della versione 1 non ha più senso ottenerlo lì perché non c'è più nessuno che manda payload in versione 1 e quindi lo possiamo falciare.Il problema diventa il sapere che nessuno manda più pre-payload in versione 1 è un problema irrisorbibile, è un po' come anche di nuovo siamo di nuovo all'uovo alla gallina, è molto difficile sapere che non ci sono più in giro versioni 1.Sante parole, guarda è esattamente quello che sto facendo, che ho fatto stamattina, cioè nel senso cosa ho fatto stamattina? Ho ho messo una linea nel log che mi dice quando uno sta chiamando un certo endpoint con un certo payload schema ok e sto loggando e identificando i team naturalmente i team sono già stati notificati sei mesi fa che si sarebbe dovuto spegnere quello schema chiamiamolo così no quel endpoint avrebbe dovuto smettere di accettare quello schema.La deadline era data cinque mesi fa che poi è shiftata quattro mesi fa che nella vita reale poi shifta tre mesi fa e siamo arrivati a oggi che sono ancora entrambi supportati.Allora prima di sentire il mio ennesimo sfogo su questa questione come il vecchio brontolone no? Mi chiedo come comuni, perché quando si parla di sistemi distribuiti spesso si parla anche a livello aziendale, di struttura aziendale no? Come gestisci la comunicazione di una dismissione o di un cambiamento inter team? Ci sono fondamentalmente due modi per farlo.Uno è parlarsi molto banalmente, quindi avere dei protocolli all'interno dell'azienda che permettono ai team di comunicare, quindi chiamare una documentazione in generale.Ovviamente fa affidamento sul fatto che tutti i team siano scrupolosi nell'usare la propria documentazione.Il secondo, secondo me, quello che funziona meglio, è Semantic Versioning un'altra volta.Quindi a questo punto diventa vantaggioso l'uso di messaggistica.Perché? Perché supponiamo che noi tre stiamo scambiando in qualche modo payload su una coda e supponiamo che utilizziamo un linguaggio di alto livello tipo C#.Quindi quello che facciamo è che sulla coda viaggia un payload string a JSON, ok, o protobuf o quello che volete, qualcosa di serializzato, e quando lo consumiamo viene deserializzato in un tipo del linguaggio che stiamo utilizzando, quindi può essere Java, C#, quello che volete.Quindi io ho nella mia codebase una classe che rappresenta il messaggio che Luca mi manda.Come faccio ad avere quella classe? Perché è un pacchetto che Luca ha pubblicato.Quindi quello che succede è che abbiamo un sistema tipo npm per Node, in cui Luca può pubblicare pacchetti, NuGet per il mondo dell'internet, ma Aven e via dicendo su questi, in cui Luca può pubblicare pacchetti e a un certo punto pubblicherà una versione nuova dei suoi contatti con una major release, che comunica una breaking change.A questo punto il problema mio è capire cosa è la breaking change ovviamente.Mi aspetto che nel pacchetto ci sia anche la documentazione che mi spiega cosa è la breaking change.Ma fondamentalmente se io non rispetto la breaking change divento il problema mio.Sono io che non sto seguendo la semantica di semantic rationing.Questo è il sistema migliore.In aggiunta a questo una cosa che si può fare è costruire nell'infrastruttura del sistema una sorta di control messages, nel momento in cui Luca diceva da me un messaggio che è vecchio, il sistema automaticamente mi manda un messaggio indietro che mi dice "guarda, quella roba lì è vecchia, hai ancora 50 giorni per sistemarla".Insomma gli spammiamo lo slack.Esattamente, esattamente.Quindi i miei log si riempiranno di roba perché io sto mandando messaggi sbagliati a Luca.Ok? E di conseguenza, però l'infrastruttura stessa lo fa.E quindi uno dei concetti fondamentali di questi mistri buiti è che mai far diventare un problema del destinatario quello che è un problema del vittime.Quindi in questo caso, se io mando roba vecchia a Luca, sto facendo diventare un mio problema, perché non ho rispettato il suo specifico, lo sto facendo diventare il suo.Perché gli mando roba.Lui in realtà me lo rimbalza indietro.Gli dice, io te la sto continuando a consumare, però stai attento che la deadline si avvicina sempre di più.Io ho la mia tecnica Mauro, dimmi se ti piace.Nel contesto dove sto lavorando adesso in realtà ci sono davvero tanti microservizi, sono diverse centinaia, quindi inizia a essere veramente complicato.Anche se non hai un sistema di Devex fatto bene, non hai un portale come Backstage che ti dice l'ownership e ti chiarisci insomma chi è responsabile di cosa su questo poi ci torniamo, diventa veramente difficile avere il feedback che il messaggio è recepito.Allora io la mia strategia da mini local prof? La strategia è, siccome ogni microservizio è, almeno in alcuni contesti, testi è deploiato, mettiamo Kubernetes ok, è deploiato con più pod che sostengono l'immagine, e sarebbe bello ecco, deploiare due microservizi e direzionare il traffico e decidere che il 5% del traffico questa settimana arriva al nuovo e quindi fallisce, la settimana dopo lo porti al 10% questa è la mia strategia, la settimana dopo ancora il 15% e arrivare a un 50% che più o meno nel momento in cui il team più distratto si accorge che qualcosa non sta funzionando, ok, perché poi se hanno una buona interfaccia e un sistema di alerting è più facile, però arrivano e ti scrivono "ma che cazzo sta succedendo, non funziona niente" e tu gli rispondi "se seguivi le tue informazioni, insomma se seguivi gli aggiornamenti ti saresti reso conto che ti ho contattato tale data, tale data, tale data, sappi che dalla prossima settimana automaticamente poi al 60, poi al 70, all'80, al 100, poi al 100 e tutte le chiamate ti saranno rimbalzate.Questo è un modo, è un modo brutale, brutale, in realtà è anche un modo per misurare quanto responsive è il team che ha l'ownership del dispositivo.Però è un modo in realtà per immediatamente rendere proattivo il team utilizzatore e per dire il problema è del team utilizzatore.Naturalmente questo deve essere supportato da un developer portal che ti permette di avere una visione di insieme, da un buon sistema di comunicazione e quanto meno da un team responsabile del team e un team controparte.Sveglio.Quella cosa viene fatta in produzione, chiamiamola "arm time", utilizzando a seconda del linguaggio, del framework o dello stack che stai usando, una cosa che si può fare è farla anche a compile time.Utilizzando l'esempio che facevamo prima all'inizio, parlando del compilatore, in questo caso di .NET, e del fatto che giocando con Semantic Versioning puoi fare obsolution di certe cose, noi internamente, per esempio, cosa facciamo per noi stessi? Cioè, ci facciamo del male a noi stessi? Abbiamo un'infrastruttura che ci siamo costruiti su GitHub per distribuire su tutti i repository che abbiamo tutta una serie di file che rappresentano gli standard interni.Nel mondo .NET c'è una roba che si chiama Editor Config che ad esempio serve per configurare il compilatore e di conseguenza dirgli cosa vuoi che succeda, cosa vuoi che non succeda, le regole che devi rispettare e via dicendo.dicendo, tutta una serie di cose di questo genere che ci permetterebbero di fare che cosa? Che se Luca mi manda ad un certo punto, tornando all'esempio di prima, un pacchetto con una versione aggiornata del contratto, la versione precedente del contratto con l'obsolete, il mio codice non può più e quindi non c'è mai zona di andare in produzione, perché appena cerco con CI di andare in produzione, CI mi rimbalza e quindi mi dice "no, no, no, perché stai usando una roba che non si può più usare" e di conseguenza scordatelo che quando è in produzione, lavoratore e modifiche.Quindi puoi tenere in produzione quello vecchio e a quel punto il tuo sistema entra in gioco perché mi ricorda che devo mettere a posto quella roba lì perché nel frattempo Luca va a deployato, ma io non posso tenere in produzione nulla, finché non sistemo quella roba.E questo aiuta a seguire quelle policy e tenersi aggiornati il più possibile.È noioso ovviamente perché tu stai cercando di fissare un bug e ti ritrovi in mezzo ai maroni con la roba e dici "perché devo fare se questa, però è così.Luca, io ho una domandina che in parte mi è risposta una bella soluzione, però abbiamo parlato di una domandina che sfiora il tecnico, non è prettamente tecnico, e la faccio a tutti e due.Allora abbiamo parlato di breaking changes, di semplici modifiche che magari correggi un typo nel log, bella c'è questa consapevolezza che possiamo spaccare qualcosa da qualche altra parte, ma potremmo anche fare dei piccoli errori.Noi sappiamo che quando deployiamo su un sistema normale bene o male siamo un po' tranquilli con i test automatici atomici che facciamo, test a volte anche manuali, e così...se non hai test va bene, hai la stessa ansia ma a quel punto sei un po' te la cerchi e quindi sei un pazzo, e va bene così.Però nei sistemi distribuiti, parleremo sicuramente di test nei sistemi distribuiti, quindi è così, però ovviamente non penso si possa testare tutto, ci sono corner case praticamente ovunque.Quindi domanda è come si gestisce l'ansia da sistema da deploy? Cioè noi, almeno io anche, ogni volta che c'è da fare un deploy, anche abbastanza importante, e siamo ancora in un finto sistema distribuito per quanto mi riguarda, l'ansia c'è.Cioè l'ansia di non aver considerato una cosa, ok sì test passano, quello che possiamo testare funziona però c'è l'ansia e tendenzialmente si cerca anche ogni tanto di rinviare un pochino, no non siamo pronti, no ok rimandiamo a fra un'ora, aspetta c'è c'è un problema.Nel sistema distribuito penso che quando lavori su un servizio o su una libreria o con quello che vuoi che sai che va a impattare un sistema, dei sistemi così grandi e distribuiti che tirano giù tanta di quella complessità particolarmente difficile da gestire, immagino che quest'ansia sia a livelli molto più alti.Come si tiene sotto controllo? Ovviamente vale per tutti i sistemi, ma in particolare? Ti direi in un paio di modi.Il primo è il testing ovviamente, dove una delle cose molto complesse nei strim distribuiti è quello che che a me piace chiamare "choreography testing".Quindi diciamo che tu potresti avere quattro livelli di test, parte dello "unit test", "integration testing", in cui hai più componenti, ma sempre, diciamo, nello stesso processo, che parlano tra di loro.Una sorta di "acceptant testing", quindi hai più componenti che potrebbero essere distribuiti, ma che metti nello stesso processo e poi parli tra di loro.E poi quello che io chiamo "choreography testing", in cui hai effettivamente più end point che parlano tra di loro.Quindi il test sta facendo girare un pezzo del sistema distribuito.Ovviamente hai il problema che è un pezzo soltanto.Quindi tu stai dicendo "sto testando la fine del processo di checkout".Quindi gli do come input il simolo che sono arrivato allo step 4 e sto testando dalla scelta della carta di credito alla scelta della tipologia di spedizione e del checkout.Quindi diciamo che ho tre nodi con cui sto parlando e si mandano messaggi tra di loro e via dicendo.Questa tipologia di testing è quella che mi permette di verificare che nell'HPPAT le cose funzionino come mi aspetto che funzionino.Che è il problema, giustamente, sottolineato tu, però i corner case sono un milione, perché dovrei pensare quanti possibili messaggi in formato vecchio in giro che possono arrivare a questa cosa.Boh! E non è che posso scrivermi tutti i test possibili per pensare a quegli scenario.Uno dei vantaggi, in questo caso, secondo me è più uguale il vantaggio un sistema distribuito basato su messaggistica.Ed è che, da un lato, pensiamo all'evoluzione dei messaggi che abbiamo parlato prima.Ora, diciamo che abbiamo due macro tipologie di messaggi, comandi e eventi.Rimettiamoci a questi.Nel caso di ownership, nel caso di un comando, il ricevente è l'owner del comando.Quindi io che ricevo un comando da un altro endpoint, io che sono owner del comando, quindi sono io che posso dettare modifiche sul comando, solo io appunto.Di conseguenza so quando cambierà e tendenzialmente saprò anche gestire le varie versioni che stanno arrivando.Nel caso degli eventi, il publisher è l'owner, perché non ha più pari idee di chi sono i subscriber, quindi non possono essere loro gli owner.Nel caso degli eventi la cosa è ancora più facile, "facile" è sempre tre virgolette in questi casi, è ancora più facile perché io publisher, nel momento in voglio evolvere il mio contratto, potrei potenzialmente pubblicare all'infinito tutte le versioni vecchie, per tutta la storia.Nel senso, ho la versione 1, continuo a pubblicare la versione 1, mentre pubblico anche la 2, la 3, la 4.Potrebbe non fregare niente il fatto che la gente sia aggiornata a usare l'ultima versione del contratto.Quindi questo rilassa molto i problemi eventualmente di compatibilità tra i vari pezzi.La cosa che però dal mio punto di vista rilassa moltissimo che ci permette di fare test di produzione, fondamentalmente quindi di lanciare il cuore oltre l'ostacolo e dire "Deploy, chi se ne è visto?" "È venerdì sera?" "Ma sì, deploy, non è un problema." È quello che nel mondo della messaggistica vede le Poison Q.Quindi cosa può succedere? Io mando un messaggio a Mauro, Mauro non è in grado di gestirlo perché c'è un bug su lui, perché non ha gestito la breaking change, perché ho sbagliato di mandargli una roba, chi se ne frega.Lui scoppia, il suo messaggio finisce nella Poison Q, Lunedì mattina guardiamo il problema, fissiamo il bug, rideployiamo e ricominciamo.Prendiamo quel messaggio, ne facciamo replay di dov'era.Il vantaggio è che quella roba succederà prima o poi.Ovvio che ci aspettavamo che succedesse nel giro di pochi secondi da quando io ho mandato il messaggio.In realtà succede due giorni dopo e qui potrebbe entrare in gioco tutto il discorso del "ha ancora senso che succeda due giorni dopo".però questo è un problema di business che deve essere incastrato nel sistema, ma prima o poi succederà.Mentre se avessimo una comunicazione HTTP e c'è una break in change che uno dei due non ha gestito correttamente, ritorniamo al problema di cui parlavamo prima, che l'eventuale problema di Mauro, come destinatario della mia richiesta, si ribalta su di me, perché a questo punto il errore ce l'ho io.E dico "Ma che faccio? Non ho più quale idea".E è molto facile che il dato venga perso, perché ovviamente siamo tutti in memoria a quel punto lì, no? Mentre se abbiamo un messaggio su una coda, il contenuto del messaggio per suonatore dovrebbe essere atomico, cioè contenere tutto quello che serve al destinatario per poter andare avanti nel suo processo di business, finisce nella Poison Q.Prima o poi ci guarderemo, eh.Giusto per darvi un aneddoto, nel...Boh, era tipo il 2012, io e un altro breciano Lavoravamo in Svizzera per una famosa azienda di abbigliamento.Una mattina arriviamo in ufficio e praticamente erano tipo le nove e 700 negozi di tutta Europa non avevano potuto aprire.E direi comunque niente, perché c'erano tipo 5.400 messaggi falliti nelle codine di lavoro per un bug deployato la sera prima.In quel caso lì è stato una panacea avere un sistema di distribuito fatto in quel modo, perché c'è basto capire, guardando i log, i contenuti dei messaggi stessi, cos'è il problema.Adesso facilissimo ovviamente, cos'è il problema? Deployar la FIX, fare il replay di tutti i messaggi, che in automatico sono stati fatti i replay nelle code dove erano fallito e il sistema si è ripreso.Il negozio è stato aperto con un'ora e mezza di ritardo, ci hanno fatto una capa tanta, però se ne sono persi i dati, se ne sono persi molto peggio.Guarda hai detto tante parole Luca, mi piacerebbe aggiungere giusto due cosine che un amico mi ha detto.Intanto mi è venuto mentre parlavi sia tu Luca che Mauro, mi è venuto in mente un articolo che l'essi tanti anni fa che parlava di alcuni approcci dentro Google dove si diceva no guarda ci sono degli ambiti dove noi non testiamo e testiamo in produzione perché tanto la nostra audience è scaffata se c'è un bug casi suoi al massimo ci scrive e magari essendo una audience evoluta ci suggerisce anche una potenziale fix dal loro punto di vista.Credo fosse Google però non vorrei sbagliarmi.Io ho un amico e questo amico mi ha detto che in ambiti enterprise il test che tu puoi fare ti porta fino a pagina 2, quando nel libro le pagine sono 2000.Perché? Perché magari dei layers sostanti non sono reliable o gli schemi e contratti che hai sono outdated e il mock data che tu hai non toccano quegli edge case, cosa che questo amico mi ha detto succede praticamente tutti i giorni in ambienti di aziende molto grosse e a quel punto tu hai il tuo sistema bello testato, bello perfetto, che però poi lo metti in produzione e scoppia.E allora qua sempre questo amico mi ha detto guarda che hai una strategia che puoi utilizzare che specie quando hai dei sistemi che arrivano in fretta under quindi hanno un carico pesante, hai una manopolina volendo che tu puoi dire ok io faccio la nuova release e con un API Gateway quello che solo Dio sa ci metti sopra, poi digli ok redirezionami il 5% del traffico.A quel punto ci vai giù di observability fatta bene, se ce l'hai fatta bene, se no cambia lavoro perché in ambienti distribuiti poi ne parleremo con Mauro, senza observability è tipo suicidarsi, ok? Se hai un'observability fatta bene a quel punto tu guardi ok quali errori ho, quanti 404 mi stanno arrivando, perché mi stanno arrivando tutti questi 404 è normale che la gente metta cosa ne so il codice utente sbagliato però tutti questi su questo insieme di domande non è che c'è qualcosa magari spotti un bug che il team di front end non aveva visto non è il tuo team allora gli scrivi quindi testare in produzione specie in ambienti ad alto carico e in ambienti enterprise con doppia n ok è l'unica cosa affattibile almeno non è da sola non risolve il problema se devi avere un minimo di testing che ti fa arrivare al testaggio in produzione in modo più tranquillo perché se tu arrivi senza una base di test solida a tutti i livelli arrivi in produzione anche con il 2% del carico e ti floddano e non sai più cosa fare dove sbattere la testa quindi se sei abbastanza solido se casa tua, il tuo microservizio, il tuo ambito è solido, vai in produzione, tanto qualcosa fallisce, perché l'entropia in un sistema distribuito è enorme, ok? È incalcolabile.A quel punto te ti capisci e agisci.Certo.Questa secondo me è un modo per poterlo fare.Me l'ha detto un amico, eh, non è farina del mio site.Esattamente quello che fai, nel senso se hai un sistema dove la comunicazione o diciamo il pezzo che sto deployando, la comunicazione su HTTP puoi fare il giochetto con il gateway o un load balancer davanti che ti dice x per cento del traffico lo mandi là in modo da fare il test.Se hai messaggistica puoi utilizzare la stessa politica sui nodi, quindi la messaggistica ti dà una funzionalità che si chiama competing consumer, quindi tu hai una coda di input e uno o più nodi che guardano quella coda di input.Suoniamo e siano quattro.Sono quattro nodi, tutti alla versione 1, a un certo punto tiri giù uno dei quattro alla versione 1 e metti dentro la versione 2, la versione 1.1.Quindi vuol dire che, non è proprio matematicamente così, però più o meno il 25% dei messaggi se li becca alla versione nuova.E a quel punto li puoi osservare la percentuale di fallimenti e nel caso una messaggistica potresti direttamente osservare la percentuale di retry, quindi quanto volte uno stesso messaggio è stato riprovato da una certa istanza, perché tenendo in conto che tre istanze non falliscono mai, la terza o quarta istanza che è appena deploiata perché riesca a fare quello che deve fare, che ne so, ci deve riprovare cinque volte, e potresti scoprire che sta facendo una roba strana sul database per cui ci mette un sacco di tempo e la transazione continua ad andare in timeout, perché abbiamo scritto una cazzata.Se ci pensiamo, e in tutto e lo raccontavi, pensavo alla complessità di fare questa roba, perché immaginiamoci in cui quel nodo in più che abbiamo deployato ha una breaking change.Torniamo all'esempio di prima, first name, last name e full name.O meglio, mettiamoci first name, last name e birth date, quindi la data di nascita.A questo punto, quel nodo in più usa anche la data di nascita.È plausibile pensare che sì, che possa pensare di mettere quella data di nascita da qualche parte, quindi sul database.Quindi vuol dire che quello schema del database è cambiato, ma a questo punto devo trovare un modo per fare quello schema del database che sia retrocompatibile con gli altri tre nodi del cluster, perché con gli altri tre la colonna in più non sanno che cos'è, e di conseguenza devo capire come fare a far funzionare 'sta roba.Il che ci comporta tutte quelle erogne, pensando database razionale, in cui, ok, aggiungo la quarta colonna, ad esempio, ma la metto in "unallable" anche se dal punto di vista del business non sarebbe in "unallable", ma finché tutti non sono aggiornati non possono fare altro che metterlo in "unallable" perché se no il quarto non può, gli altri tre non possono mettere dentro dati perché non possono riempire quella colonna.Finché tutti non sono deploiati e tutto sia in opposta a questo punto posso fare un'ulteriore modifica allo schema per cambiare la schema da "unallable" a "non non ha la propria clacon.Quindi gli step sono tanti, quindi mentre noi siamo abituati quando deploy un monolite che dici ok qui c'è lo script di update di schema, qui c'è l'eseguibile nuovo, oppure se non hai neanche, se l'eseguibile è in grado di farsi gli update per i fatti suoi, li fa, e tutto va in un colpo solo, nel caso di stream distribuito hai spesso in piedi tantissimi step.Deploy un pezzettino in più che mi prepara per il deploy successivo, che preparerà per quello successivo e la breaking change magari arriva dopo quattro dei plog.E quindi c'è questa sorta di forward looking, quindi di guardare il futuro e dire, "Ok, come faccio ad arrivare là?" E questi sono tutti gli step che bisogna fare in produzione per riuscire ad arrivare là e fare il giochetto.E parte di questo è il test, quindi dici, "Ok, ci provo.Tanto se va male, finiscono le cose di errore.In qualche modo lo metterò a posto." Se l'ho dimenticato un corner case strano che non avevo assolutamente pensato.Ci sta.Quindi mi pare di aver capito, una buona pratica è programmare sin dall'inizio il modo di fare recovery degli errori del sistema e questa è una cosa che va fatta prima di tutto in modo tale che ok c'è un messaggio che ho scartato che non mi piace, lo metto da parte in questa pass on queue e poi si vede, si analizza e si vede se ha senso rimandarla o riplayarla.Io ne approfitto per fare un piccolo rimando all'episodio che abbiamo registrato con Carmine e Alessio sul CQRS che un po' si collega con questo topic in realtà.Domanda, proprio due giorni fa leggevo un bellissimo paper, ve ne parlo tra un po', che parlava di, in quel caso, di divisione in microservizi.Noi stiamo parlando in un ambito un po' più alto, quindi possono essere micro macro quello che più ci pare.Sistemi? Sì.Ok, ma mi chiedo come disegni i boundaries del sistema, degli elementi del sistema? Come disegni i confini e dici questa roba deve andare in questa parte del sistema, in questo attore del sistema, in quest'elemento del sistema e quest'altra parte è un'altra.Mi vengono in mente tre cose fondamentali.Non dare nomi alle cose, usare una roba che si chiama "anti requirements" e la terza è quello che cambia insieme e sta insieme.Quindi diciamo che, partiamo dal fondo, tutto ciò che cambia insieme, quindi che diciamo usiamo pure il termine transazionalmente, Se pensiamo a scrittura su database, tutto ciò che ha senso e che stia nella stessa transazione non può essersi fatto, quindi deve stare per forza insieme.Tutto ciò che non deve stare in quella stessa transazione non deve stare per forza lì.Poi non è detto che non stia lì, però diciamo che non ha necessità di stare lì.Quella è una buona regola Aurea.Possiamo elevare questa cosa staccandoci dal tool, dal database di tool, per dire quindi ciò che cambia insieme sta insieme.Facciamo un esempio per capirci.Se io ascolto un analista che mi parla di prodotti, uno degli errori che tipicamente lo sviluppatore fa, mi includo anche io in quello, è cominciare a immaginare nella nostra testa la classe.Hai il tuo aggregato prodotto e man mano che l'analista ti racconta cose, tu infili robe in quell'aggregato prodotto e ti ritroverai con il nome del prodotto, la descrizione del prodotto e il prezzo del prodotto.Poi la lista ti racconta anche che c'è la vendita di quel prodotto e che se si verifica una certa condizione c'è uno sconto sul prezzo del prodotto.A questo punto è un problema, quindi vuol dire che il prezzo del prodotto cambia insieme allo sconto, ma lo sconto non è parte del prodotto.Quindi vuol dire che il prezzo e lo sconto non stanno insieme.lo sprezzo e lo sconto devono stare insieme e siccome quando cambia il nome del prodotto o la descrizione del prodotto il prezzo non è in nessun modo influenzato né viceversa allora possiamo dire non devono stare insieme queste tre cose probabilmente descrizione e nome stanno insieme ma potrebbero non starlo assolutamente in questo caso perché io potrei cambiare solo la descrizione e non necessariamente il nome e via dicendo ma il prezzo è rilevante per gli altri due mentre è rilevante per il prodotto per il loro studio.Quindi ho toccato due cose del tre che ho detto.Il primo è, qualcuno mi ha detto un nome, prodotto, e io immediatamente l'ho usato come insieme.E tutto quello che mi è arrivato dopo ce l'ho messo dentro.Quindi partire dal descrivere i boundaries, dandogli dei nomi come sales, finance, shipping, e via dicendo, rischia di portarci in una direzione sbagliata, perché ovviamente quello che arriverà è La nostra conoscenza del business o l'influenza che il business ci dà ci fa mettere nelle caselline la roba che appartiene a sé.Ma dal punto di vista di sistema istituito, il taglio non è quello lì.Il taglio è quello del business.Il nostro è ciò che cambia insieme e sta insieme.E quindi le due cose viaggiano in maniera distinta.Quindi ha più senso chiamare quelle robe lì rosso, giallo, verde, i nomi dei pianeti, datevi i nomi che ci avete voglia, non è importante, ma non i nomi di business.Quindi non diamo nomi, ciò che cambia insieme sta insieme.A questo punto quello che posso ottenere è che se li separo avrò delle robe che non sono più degli aggregati, perché non rappresentano più dei concetti che mappano uno a uno con lo ubiquito slang del business.Qui è la divergenza fondamentale con domain driven design.Quello che mi ritroverò è che ho un qualche cosa che è probabilmente stupido, cioè il prodotto fatto da nome e descrizione, non c'è niente di logica, non c'è niente di strano dentro lì.Mentre la polisi di scontistica del prodotto, che è quella con prezzo e sconto, che mi butta fuori il prezzo finale che io faccio vedere al mio utente, c'è un po' di logica di business legata alle regole, che non so quali siano, per determinare quel prezzo.In questo giochetto, quello che ci può aiutare a fare questo taglio, oltre alla logica di "ciò che cambia insieme sta insieme", sono i cosiddetti "anti-requirements".Sono quelle domande che l'analista ti guarda con la faccia come se dice "ma sei scemo?".Quindi facciamo un esempio per capirci.A un analista io farei una domanda.C'è mai una casistica in cui il prezzo del prodotto è influenzato dal nome del prodotto? E lui ti dice no, punto.Non bisogna stare insieme.Però ti potrebbe dire, c'è una casistica in cui il prezzo del prodotto è influenzato se la data del tuo compleanno.E quindi tu dici, ah, allora se io metto insieme le tre cose che mi hai detto, avrò un calderone prodotto, nome e descrizione, un calderone utente, email e password, e un calderone in mezzo, policy di sconto, prezzo, percentuale di sconto, data di nascita.Che sono le tre cose che il workflow usa per sputar fuori il prezzo finale che devi farmi vedere.E se volessimo estremizzarla, portando la cosa all'estremo, potremmo dire, mi serve l'anno di nascita dentro lì? No, vi basta mese e giorno.Per cui potremmo addirittura spacchettare quello.Cioè, cosa cambia insieme? Sta insieme, l'anno non ci interessa.Poi, arrivare a quell'estremo non ha nessun senso.Però è per capire il livello di dettaglio a cui potremmo arrivare.È ovvio che se la guardiamo, quella roba lì in mezzo non ha un nome.Ma è proprio probabilmente una discount policy.Non è un aggregato, è un robot che fa calcoli.Pum.guarda Mauro se non fossi molto lontano io verrei là a rinunciarti, dai gesti che ti facevo credo che non so, l'abbia capito.Per quanto riguarda lo scambio dei dati poi voglio voglio arrivarci, nel senso vorrei parlare di sicurezza di dati, di cosa e quanto gli elementi di un sistema distribuito possono vedere, di accesso ai dati di questa belle di queste belle bestie però ancora prima voglio estendere e portare all'estremo quello che hai detto con un esercizio allora io vengo da un mondo che ha abbracciato il domain driven design ok e insieme al domain driven design mi sono innamorato della union architecture quindi per per me c'era la logica di business, le porte e gli adapter e quindi mi connettevo i pezzi terzi.Questo funziona bene concettualmente dal punto di vista teorico, quando però metti le mani nel fango può funzionare bene, adesso super super super bold opinion, può funzionare bene in un contesto dove c'ho un monolita per cui c'ho il mio dominio bello astratto, le mie classi o elementi del codice, componenti del codice che si occupano di astrarmi tutta la parte platform chiamiamola così e così viaggio.Nella mia esperienza ho visto che quando ci si spinge in un sistema distribuito e quando si va verso i microservizi talvolta questo approccio di purista, come dicevi tu, mal si sposa.E io mi sono ritrovato ad avere dei microservizi dove il libro ci diceva "creati il tuo bel il Boundary Contest, Usa l'Ubiquitous Language per mappare tutto.Sì, e poi mi sono ritrovato come un coglione ad avere un microservizio che faceva solo parte platform.Perché può capitare, perché nella vita reale...E quindi mi son detto "Ma allora nella vita reale ci sono delle casistiche specifiche dove non esiste il dominio che mi dice questo deve stare qua".E come faccio? Tu hai dato un insight importante, quello che cambia insieme lo mettiamo insieme, però là c'è anche il rischio che tutto cambia insieme, perché in un qualche modo tutto è collegato.Quindi dove ci vai con l'accetta e dici "ok qua io taglio, basta".Il legame è talmente flebile che mi posso permettere di tagliare? Sì, chiaro.Faccio un passo indietro.Service oriented architecture, microservizi e domain driven design sono, diciamo, tre architetture di alto livello.Io personalmente quella microservizi è quella che mi piace meno, per un motivo di fondo, che la teoria di microservices confonde, mischia, senza dare una spiegazione ben precisa, la vista logica con la vista fisica.Quindi un microservizio logico è anche un microservizio fisico, c'è un rapporto umano, quindi quello che scrive un codice è quello che dettoria.Mentre in realtà il mondo è più complesso di così, purtroppo, sarebbe bello se fosse tutto così semplice.Quindi guardiamo semplicemente domain driven design e service architecture.Diciamo che nascono per risolvere due problemi molto diversi.Domain driven design nasce come tool o come framework, chiamiamolo così, per comprendere la complessità del mondo di business.Purtroppo, nella stragrande maggioranza dei casi, quando vedi qualcuno che parla di domain driven design, lo fa utilizzando il codice.Ma è l'ultima cosa che dovremmo fare.Nel senso, il fatto che io abbia una classe che deriva da una classe aggregate non serve assolutamente a niente a nessuno.È l'ultimo dei problemi, è l'ultimo 5% del mio lavoro quando implemento un'architettura come quella di Doom2020.Doom2020 è principalmente un tool di analisi del mondo che sto cercando di risolvere.E di conseguenza i bounded contexts, i pandories, gli aggregati, poi come li implementerò tagliati tra di loro, è un problema di layout, il che mi permette di introdurre un concetto che è quello della cosiddetta 4+1 architecture.Quindi, una delle cose importanti quando guardiamo le architetture distribuite è che abbiamo varie viste dell'architettura, quindi potremmo avere una vista logica molto ad alto livello, che è quella data da Service Oriented Architecture o domain driven design, che ci dice questi sono i nostri macro blocchi.Questo rappresenta sales, questo rappresenta shipping, questo rappresenta finance e via dicendo.Quando guardiamo dentro lì, quello che possiamo guardare è una vista fisica dei blocchi e quindi dirò che come comunicare tra di loro, come sono fatti dentro, questo parla con questo con HTTP, questo parla con questo con messaggistica, "Questo usa un database fatto cosa? Questo usa FTP per mandare dati a quel robot?" E via dicendo, quello che ci viene in mente.Un terzo punto di vista è come sono strutturati dal punto di vista dello sviluppatore.Già banalizziamola, quanti repository Git è quella roba lì? È un mono repo con dentro tante folder o sono 200 repository Git, ognuno con la sua CI, ognuno che produce pacchetti separati? E via dicendo.E la quarta è come li deploio.Quando vengono deploiati, finiscono tutti sulla macchina sola come monolite, perché si è buttato fuori un robo singolo che viene deployato, oppure finiscono dentro in un cluster Kubernetes fatto di centinaia di pod.Benissimo, questa è la quarta vista.In questo gioco, la vista logica, la prima di cui avevamo parlato, è quella che ci permette di tagliare.Cioè ci dice, queste due cose cambiano insieme, quindi stanno insieme.è vero che quando pigio il bottoncino "checkout" allora farò anche la debito della carta di credito, ma quelle due cose non cambiano insieme, non sono transazionalmente insieme.Quindi torno all'esempio di cui siamo partiti con non c'era una transazione tra i due, no, di transazione ACID in questo caso, ok? Ma lì avrò un messaggio che viaggia, un evento in questo caso, quindi "order checked out", che mi permette di dire a chiunque interessato quella roba lì, ok, io adesso lo farò pagare, Io comincio ad andare in magazzino a pescare i dati, io ho i pacchetti da mettere nel pacco, io contatterò il corriere.È ovvio che questi tre che abbiamo citato stanno cambiando, quindi Finance, Shipping e Warehouse, stanno cambiando in funzione del fatto che sono cambiato io, che sono chi ha fatto fare il check out, cioè il carrello, mettiamola così.Ma non c'è transazionalità tra i tre.La transazionalità mi è data dalla consistenza eventuale della messaggistica.quindi la differenza sta lì fondamentalmente, quindi non hanno bisogno di stare insieme dal punto di vista della stare nello stesso processo o nello stesso database, mettiamo così.Ho risposto? Sì, sì, e a questo punto la mia domanda è, in questo tipo di contesti, ci troviamo davanti, essendo fortemente disaccopiati, che ne sono a parte il pagamento con la parte dell'ordine, ha una consistenza eventuale.Quali sono le strategie che possiamo avere per un eventuale allineamento dei "da" a "altra cosa impossibile"? Non dirmi "non si può fare", ti prego dimmi cosa si può fare per avvicinarsi a una potenziale soluzione.Però in realtà quali sono le strategie secondo te utili per poter cercare di avere dei dati non dico consistenti ma che ci si avvicinino.Allora sono tutti trucchi per gestire questo problema.Allora Diciamo che la guarderei da tre punti di vista.Il primo è focalizzarsi sull'infrastruttura in modo che le robe falliscano praticamente mai.Cioè, devo eliminare, ridurre all'osso il fatto che mi scoppino in faccia tutti i nodi che fanno una certa cosa.Pensate a Amazon.com.Quante volte vede la pagina con i cagnolini? Rarissimamente.Si vede ogni tanto, ok? ma è estremamente raro che le cose vadano talmente male che scoppi tutto.Il che si radice lungo sulla nostra pubblica amministrazione, ma questo è un altro...Esattamente.La seconda cosa importante dal mio punto di vista è una cosa molto difficile da fare, ma fondamentalmente si può riassumere in un motto che è "comenza, never fail".Cioè non ci deve essere...facciamo un altro esempio, un esempio diverso per capirci.Siamo abbastanza abituati al concetto di invarianti.Vuoi perché ce l'hanno insegnato a scuola, vuoi perché è una cosa che va...è molto presente in domain driven design, anche se secondo me non è vero che lo è, ma quando ne parlano, ne parlano come se fosse una cosa fondamentale.Siamo abituati a quegli esempi di codice in cui aggiungi un prodotto al carrello.If product is not in stock, allora eccezione.No, commands never fail.Aggiungi un prodotto al carrello, va bene, ce l'ho, non ce l'ho, non ti preoccupare.me la trarangio dopo, cioè riduco all'osso tutte le possibilità di fallimento di business.Quindi è, aggiungo, perché se noi chiedessimo a qualcuno del business che fa sales, ma se non ce l'ho in stock, non glielo vendo, lui ti dice ma tu vendiglielo lo stesso, portiamo a casa i soldi, poi ci arrangiamo a seccare e capire come fare l'altro.Che è esattamente quello che fa Amazon.Quante volte a me è capitato che su un ordine di 5 cose mi direste 3 te lo spedite, 2 te rispetto di tutti i nostri altri.Perché non ce li hanno.Perché è normale che più aumenti la dimensione del sistema, più è facile che se noi tre stiamo comprando la stessa roba, uno dei tre probabilmente non ce l'avrà, se ce ne sono solo due.Perché qualcuno arriva prima.E per riuscire a garantire quella roba lì, l'unica cosa che possiamo fare è avere una transazione con un lock pessimistico in un sig.3.Perché se no, ci dobbiamo serializzare il nostro accesso la base dati per garantire che il prodotto ci sia disponibile per tutti.Quindi lì ho il concetto di "i comandi non falliscono mai, ma il codice parte sempre dal presupposto che deve gestire tutti quei casi del "non ce l'ho, va bene, lo aggiungo e carrerò lo stesso, in fase di check out cercherò di capire come farlo".La terza cosa sono tutti quei trucchi di user experience, quindi di UX, nelle applicazioni, per farmi credere che certe cose stiano funzionando, anche se in realtà non lo hanno ancora fatto.Usando sempre Amazon come esempio, quando aggiungete un qualche cosa al carrello, Amazon mette una pagina intermedia che vi dice "I clienti che hanno messo questa roba nel carrello hanno anche comperato queste 32 cose".Il nostro cervello si focalizza sulle 32 cose.Quella roba lì, insieme a "spendono un sacco di soldi in infrastruttura", fa sì che il mio messaggio per mettere la roba nel carrello sulle code abbia fatto il tempo di essere processato e rasservano il carrello.E a quel punto lì, quando arriverò sul carrello, la mia roba c'è.Allo stessa strego, quando vedete quei sistemi per cui aggiungi il carrello e immediatamente in alto a destra li concede il carrello 2, 3, 4, 5, 6, con una varia fake.La posso fare fake? Parto dal presupposto che funzionerà, la aggiungo, quindi via javas che ti faccio comparire quella roba, e se poi non funziona l'altro sistema, io metto Ridiventa uno, è come i cuoricini, no? Il cuoricino dopo due secondi ti scompare e ti dice "no, non hai più un cuore".Io ricordo ancora quando avevo una fan su Facebook che fattevo tutte queste prove.Se tu provavi, e proprio lui si è ancora così, avevo la mia macchina virtuale negli Stati Uniti che guardava lo stesso wall che guardavo io.Mettevi il like dal mio browser e di là ci metteva tipo 5 minuti a comparire.Ma da me compariva immediatamente.Ma non è che il mio, ma il mio ha finto.Per cui lo mettevano, il JavaScript lo faceva comparire, punto.E nel frattempo loro dietro processano il messaggio.A quel punto lì il gioco si chiude.Sì, là poi ci sono anche dei livelli aggiuntivi.Esattamente, c'è il mondo di sopra di quello che può succedere.Ci sono esatto, ci sono dei modelli aggiuntivi.Leggevo da poco un paper su come funziona a livello architetturale Blue Sky, il social network, e in realtà la complessità quando poi si hanno sistemi distribuiti e magari anche decentralizzati esplode, per cui c'hai un optimistic data.Ragazzi adesso facciamo girare della logica on the edge quindi in qualche modo se qualcuno è collegato a un altro nodo di un'altra cdn quella roba la vedrà dopo x tempo quando è arrivata al server centrale che ha propagato l'eventuale aggiornamento quindi in realtà si ha e poi transazioni ACID pensavo a una cosa mentre parlavi e noi che veniamo dagli anni 80 siamo tanto innamorati delle transazioni ACID e il mio amico mi diceva ormai le banche sono credo una delle poche a utilizzare transazioni ACID e la mia risposta è neanche loro perché gli ho fatto l'altro giorno un esempio, a questo sempre questo fantomatico mi amico, sempre lui, gli ho fatto un esempio e gli ho detto "scusa quando sei in aereo dove non c'è connessione e tu paghi la tua Fanta con la carta di credito, e che è quello? Perché la debito della carta di credito talvolta non è immediato.Quindi in realtà sì hai ragione, quello che insomma è difficile è poi tenere gli eventuali read replica che utilizzano altri elementi della rete allineati in un modo migliore possibile.È ovvio che, vi raccancio così dicendo, se ci pensiamo ci sono sistemi per cui questo modello fa molta fatica a funzionare.Cioè se io penso a sistemi di contabilità in cui hai il classico inserimento massivo di roba, c'è poco da fare.Cioè il tizio e la tizia che inseriscono centinaia di fatture al giorno non ce la vogliono aspettare.Quindi questa roba fa molta fatica a funzionare con la logica del uso di tutti questi trucchetti che mi fanno funzionare le cose di tra le quinte.Per cui c'è anche da calare nella user experience del prodotto che sto facendo le problematiche derivanti dal "ho scelto un sistema eventualmente consistente".E quindi devo capire come fare in ogni use case a dire "ok, dietro di là ho un messaggio su una coda che potrebbe non arrivare mai potenzialmente, perché potrebbe finire una una cosa in più.Come faccio a spiegarlo all'utente da questa parte? Senza mettergli uno spinner davanti che gli blocchi la UI finché non ha finito, perché fondamentalmente è quello che stiamo parlando, e gli dice la cosa si complica, sono casistica per casistica.Vero, io ricordo e saluto il mio compadre Gianni, ne abbiamo parlato a lungo di questo, sviluppammo un sistema di booking abbastanza complesso che faceva dei pacchetti distribuiva la deduzione della disponibilità tra più servizi server differenti mille casini e ci sedemmo attorno a un tavolo e io arrivai là con ero molto giovane con la mia discotta arrivai là con la transazione ACID in testa per me è un booking deve essere ACID perché c'è la disponibilità andiamo in overbooking e Gianni mi guardò e mi disse ma secondo te le compagnie aeree come funzionano? Ti è mai capitato di vedere persone arrivare in aeroporto e dirgli non c'è posto per te? No perché è una prassi abbastanza comune, poi l'ho vissuta, però in realtà è abbastanza comune.Allora là abbiamo fatto tutto un percorso nel team di riflessione, di ragionamento su cosa doveva essere immediato e su cosa no e fondamentalmente ci siamo resi conto che per quello che stavamo facendo in realtà non c'era praticamente nulla di immediato, c'era l'operatore che metteva un biglietto.Posto che la persona stava nell'ufficio, prendiamo l'agenzia di viaggi, quanto sta una persona che sta prenotando qualcosa dentro l'agenzia di viaggi? Minuti.Ci sta? 15 minuti? 10 minuti? Se c'è fila? Di solito i clienti della mia amica Giannina ci stanno almeno mezz'ora e magari Giannina le offre anche il caffè, no? Contesto reale, vita reale, no? A quel punto cosa succede? In mezz'ora, cazzo! Un messaggio di una cazzo di più! Non riesci a processare, anche se hai il carico e puoi scalare, quella cosa riesci a processare.Se non riesci in mezz'ora, a quel punto basta una linea così sottile nel foglio che dice hai tre ore per ricevere la conferma o l'annullamento di quest'eventuale prenotazione.Nel caso dell'annullamento ti verrà rimborsato senza alcun costo il prezzo del biglietto oppure questo se vuoi stare a garanzia dell'agente di viaggio o del fornitore oppure semplicemente tra tre ore ci sarà l'addebitamento del costo.Quando tu vai a pagare con la carta di credito di solito c'è una preautorizzazione e poi c'è lo scarico, ma anche quando tu paghi con lo strate della situazione funziona così.Quindi alla fine secondo me spesso ci facciamo la testa che vogliamo tutto in sync quando non siamo neanche un ospedale che deve avere tutto in sync, o un aeroplano.ecco in quel caso forse sì che deve essere insomma in questo modo.Ti faccio una domanda e poi passo la palla a Luca se ha qualche altra domanda.Sembra quel mio amico famoso che gestiva la manopola del traffico in quelle situazioni un po' strane di enterprise in questo Parliamo di ambienti distribuiti ok e parliamo di codice che noi scriviamo in ambiti ben contenuti.Spesso questa cosa ritorna anche quando si parla di micro servizi, quando si parla di aiuto aiuto i micro servizi nel front end? tipo? no aiuto questo è la vecchiaia micro front end questa cosa è veramente preoccupante quando si parla di micro front end che c'è sempre la cosa che si dice no vabbè ogni team decide la chiave inglese da usare, il linguaggio da usare, il framework da usare, le robe da usare e poi insomma ognuno si gestisce posto che non è così e non funziona così e se lo fai ti fai male.Come secondo te può essere un modo sano per cercare di tenere un equilibrio e non andare a finire in un bagno di sangue dove ognuno usa qualunque cosa e nel contempo lasciare abbastanza libertà ai team per utilizzare lo strumento giusto per fare quello che fanno.Ti direi policy aziendale, non ci girerei molto intorno.Se io penso ai nostri clienti, Ne ho visti di clienti che hanno provato ad avere team poliglotti, una sorta di "fate quello che volete, che tecnologia che volete, sono tutti fatti male".Nel senso che il problema diventava che questi team diventavano dei silo estremamente impenetrabili, perché a quel punto lì se io uso, facciamo esempio, tutto .NET e tu usi tutto Python e tu non senti .NET e io non sento Python, io e te non saremmo in grado mai di parlare.Quindi quando diventiamo aziende diverse, fondamentalmente, perché tu hai bisogno di fare le tue assunzioni, hai bisogno di fare il tuo percorso di onboarding, hai bisogno di fare tutta la parte di skilling delle persone, è completamente diversa dalla mia.Diventa un problema aziendale notevole, che probabilmente può essere digeribile per aziende enormi, per cui penso alla dimensione di Google, dove a quel punto è un problema molto relativo.Si perché se l'azienda è di centinaia di migliaia di persone, è impensabile dire a tutti "tutti usate Python".Quello non è assolutamente pensabile, ma su dimensioni umane, togliendo quelli 5 o 6 che vengono in mente a tutti, che sono gigantesche, tutti gli altri probabilmente hanno molto senso, che contengano il più possibile gli stack tecnologici.Questo non vuol dire però non lasciare libertà di sperimentazione, quindi mi aspetterei che ognuno possa sperimentare più o meno all'interno del suo orticello, chiamiamolo, all'interno del suo bandwidth context, del suo service boundary, sperimentare più o meno all'interno di un limite o di una serie di cose che abbiamo scelto insieme quello che si voglia utilizzare.Per cui se tu vuoi utilizzare un database documentale e noi e non rilazionare, andiamo per i fatti nostri, perché tanto siamo completamente disgiunti.Il problema diventa l'interfaccia utente.Per cui nel momento in cui i nostri dati, di entrambi, di tutti e tre i service, lo andres, devono affinire sulla stessa interfaccia utente, è vero che ci sono strumenti, metodi per utilizzare un po' Vue.js, un po' React, un po' Angular sulla stessa interfaccia, ma c'è da farsi veramente.E non trovo abbia senso.Quindi lì l'interfaccia diventa un po' il monolite tutti insieme inevitabilmente.Anche lì io taglierei la cosa in due.Abbiamo due ordini di problemi.Uno sono i dati che arrivano da parti diverse e la seconda è la visualizzazione di quei dati.Quindi Microfrontend si occupa della visualizzazione di quei dati, ma come i dati arrivano insieme verso quell'interfaccia è quella che io chiamo in gergo "view model Quindi torniamo all'esempio da cui siamo partiti quando abbiamo parlato di tagliare i nostri service boundaries.Se noi abbiamo il prodotto che non è più nome prodotto, descrizione e prezzo, ma è nome prodotto e descrizione e il prezzo sta da un'altra parte, ma io sulla pagina voglio vedere nome e descrizione e prezzo, quindi su un pezzo solo perché non voglio andare su due pagine diverse, quindi dobbiamo trovare un modo per cui quei dati vengano insieme prima di arrivare Quindi se ci immaginiamo una pagina web, quindi la classica richiesta HTTP, io arriverò su /products/id/prodotto, avrò quindi quella richiesta HTTP che arriva verso il, chiamiamolo, gateway, o il back-end for front-end di turno.Lì dietro c'è qualche cosa che è in grado di dire, ok, io sono in grado di servirti nome e descrizione, per quella richiesta, io sono in grado di servirti prezzo, il JSON della risposta HTTP viene messo insieme di dietro e torna indietro la singola risposta HTTP.Con tutto il payload in mente.A questo punto possiamo metterci dentro tutto quello che vogliamo.Cioè, data quella richiesta, evidente ci sarà qualcuno che avrà messo dentro le offerte, qualcuno che avrà messo dentro le recensioni, qualcuno che avrà messo dentro le staff, qualcuno che avrà messo dentro il contenuto corrente del carrello, perché quella richiesta HTTP si deve portare dietro tutto, supponiamo.il front-end a questo punto ha in mano la responsa HTTP.Qui entra in gioco Micro Front-end.Io che ho fatto il prodotto, tirerò sui miei pezzi di HTML che è in grado di consumare da quella responsa HTTP nome e cognome, nome e descrizione e prezzo, supponiamo.Tu che hai fatto il carrello, le parti del carrello, Luca che ha fatto tutta la parte di recensioni, si viene in grado di tirarsi su le reviews e le star.E il fan da vedere.E a questo punto il front-end è, diciamo, disaccoppiato dal punto di vista del fatto che ognuno di noi tre guarda dati diversi, all'interno dello stesso globone che è arrivato indietro.Ma noi tre non facciamo tre richieste HTTP diverse, perché sono gente che è un mattino.Perché se in mezzo su quella pagina ci sono 40 widget, abbiamo 40 richieste HTTP, quella pagina diventa la cosa più rentri di questa terra.E tra l'altro possono fare più volte la stessa richiesta con gli stessi dati.L'altro giorno mi è capitato per sbaglio di buttare un occhio a X, a Twitter, ho visto un post di Tommaso Deorama che appunto si lamentava di quel problema nel sito di NAN faceva cinque volte la richiesta allo stesso endpoint nello stesso istante con le dovute problematiche.Certo è che in molti casi, in molti di questi casi, il centralizzatore, il punto centrale è un perno intermedio della Clessidra che è l'API gateway che tanto più o meno in buona parte delle casistiche che io ho visto, insomma centralizza tutto.Spesso nel mio caso era un api graphql.Graphql è uno dei tanti modi per risolvere quel problema, di orchestrare questa roba.Poi ovvio che ci sono, uso un esempio un po' strano per parlare di una casistica, delle classiche casistiche particolari.Se provate a guardare la home page di un repository su github e prendete un repository bello corposo, tipo uno di quelli di Microsoft, dove c'è dentro il mondo, cioè quando le scariche in locale sono giga e giga di roba.La home page di GitHub, del repository, vi fa vedere i file che stanno nella nuova, fino al numero 1000, fino a un tot, esatto, e poi per ogni file o cartella di fianco, nella colonna di fianco c'è il commit message dell'ultimo commit di quell'elemento, che ovviamente non sono tutti uguali, perché ogni file potrebbe essere committato in momenti diversi.Se provate a fare sulla connessione relativamente lenta e su un repository grosso, a fare F5 o Command + R, secondo il sistema operativo, su quelle pagine vedrete che arriva tutto in una singola risposta HTTP, tranne i commit message.Perché probabilmente per ricostruirli là dietro, quelli giusti, è un bagnissato capire quali dati per ogni roba che si stanno facendo vedere.E quindi arrivano asincroni che li pushano tipo con WebSocket.Quindi la pagina si è creata e poi li devi comparire.E immagino che vengano da una cache e che non si debba iterare tra tutti i comment per decidere cosa...Te lo dico io, ho guardato un po' di cose su Git in questo periodo, sull'API Hub in realtà si monte...è molto facile, con GitLab è facilissimo, perché guardi l'API, l'API rest e tu sai esattamente, vedi esattamente la sequenza con cui gettano le robe.Te ne rendi conto? Io facevo, proprio l'altro giorno dovevo, mi sono fatto un piccolo tool a linea di comando per avere, fa ridere però ci sono dei, in quel contesto non avevo un developer portal e volevo sapere quale versione era deployato in stage dev e dovevo risalire alle pipeline che stavano rannando perché non avevo accesso al cluster quindi dal log della pipeline sapevo che versione del codice stava nel pod, dal log dell'ultima pipeline in prod.Insomma, morale della favola dovevo fare una sequenza di chiamate per ottenere quelle informazioni, quindi ti rendi conto dei vari passaggi.Mi chiedo Luca hai qualche altra domanda? perché vedo l'orologio stiamo...In realtà una, perché insomma si parlava di come architettare, di come accopiare, disaccopiare, fare analisi molto attente, ma quando poi ti trovi ad aver fatto uno schifo, quando ti trovi, quando ti rendi conto che tutte le tue assunzioni vengono sbagliate.Che è sbagliato anche tu perché...LM: quando la merda colpisce il ventilatore.SB: praticamente sì.Perché appunto il problema di quando si va anche tanto nel dettaglio è quello di poter sbagliare.Magari fare tutto giusto ma su assunzioni o su informazioni sbagliate.E e quindi ti ritrovi un casino da sistemare.Che strategia ci si può adottare se esistono dei tool di analisi o qualcosa? O si cambia lavoro? Non so, cioè qualcosa tu dici "ok, mi guardo indietro, guardo quello che ho fatto, qualcosa non funziona".Allora finché qualcosa funziona magari con il, insomma, con qualche breaking changes nelle versioni successive ci sono, ma proprio quando è un macello.Sì, lo so che è difficile, dipenderà sicuramente da progetto a progetto, però magari se c'è stata un'esperienza o qualcosa per cui, o magari c'è anche qualche tool o qualche framework o qualche strategia che si può trovare.mi viene in mente quello che facciamo noi per imposizione dall'alto, che è arrivata una decina di anni fa più o meno, ed è stato che ci siamo, ci è stato imposto e alla fine ci siamo autoimposti.Da noi non si può riscrivere da zero nulla.Hai scritto una merdata, te la porti a casa e ti chiedi di capire come farla sistemare senza poterla riscrivere.Lo diceva anche Italo Calvino.Anche perché non funziona riscriverla.Esattamente, perché il problema che tu hai è che cosa ti garantirà che se la riscrivi non finisci in una situazione simile.Quindi il problema è se ce l'hai, come fai a evolverla per portarla a essere migliore di quello che era prima.E qui noi facciamo due cose fondamentalmente.È tutta una questione di analisi, è tutto una questione di capire dove vuoi andare e quindi capire che è là che voglio andare, adesso capire come faccio ad arrivarci, quindi costruire un percorso per riuscire ad arrivare là, potenzialmente senza rilasciare neanche una breaking change, nel nostro caso.Potenzialmente perché non è detto che sia facile, ci sono dei casi che potrebbe non essere possibile, anche perché magari dipendi dai librerii di terze parti che hanno delle vecchie incendie, quindi noi siamo un po' fattuti in quel caso, quindi non è che ci puoi fare molto.Ma se non tu non puoi descrivere, fondamentalmente ti devi un pochettino arrabbattare lì in mezzo a cercare di andare là in fondo.E noi abbiamo un'iniziativa interna che da noi si chiama "Componentization Release", che è fondamentalmente, immaginiamoci come tu hai davanti il tuo, immaginiamoci il tuo con la tua Big Ball of Mud schifosa che dice che quella roba è una schifezza.Immaginiamoci che quello che facciamo noi è approcciarla in un primo giro da pura analisi e dire "Vogliamo arrivare là? Questi sono i macro step che possiamo fare per arrivare là".In questo modo, quei macro step funzionano un pochettino come se fosse una roadmap, che non è scritta sulla pietra, perché tu potresti scoprire che al terzo macro step dici che al quarto non vale più, perché abbiamo capito che non vale più così, quindi cambia tutto quello che viene dopo.Una volta in elettrico di macro step, quello che noi facciamo è che abbiamo gruppi di persone che in maniera cittelica arrivano e spendono del tempo per migliorare il codice o cambiarlo per arrivare a completare uno di questi step.E quindi ci vuole un sacco di tempo, ovviamente, però pian pianino ti porti via e migliora, migliora, sposti, togli, sposti, togli, metti a posto, fai questo, fai quest'altro, e prima o poi ti ritrovi e dici "ok, adesso è abbissalmente diverso da come era prima".ancora abbastanza schifo, ma è meglio di come era prima.Ci vorrà un sacco di tempo per portarlo a quello che vuoi e nel frattempo hai il problema che qualcun altro sta scrivendo merda.Qui combatti anche con quella roba, però è una cosa che noi abbiamo accettato come un fatto della vita.Non riscrivere mai nulla effettivamente, ho una leggera esperienza, mi sento di avallare, di appoggiare tutto.Io voglio fare una marchetta nel dire che all'interno di Gitbar abbiamo un un episodio che tratta proprio l'argomento, ne vado fierissimo di quegli episodi, sono gasatissimo su questa cosa, ed è un episodio che racconta appunto il refactoring e il rewriting guardando, visto dagli occhi di Italo Calvino e di Sun Tzu.Sun Tzu era lo scrittore dell'arte della guerra, che in realtà ci dicono molto di più dei codici di quanto potrei dire io, secondo me è una cosa molto importante.Sul fatto di riscrivere, è vero, pensavo, quando riscrivi da capo una cosa non arriverai mai alla feature parity in modo proficuo.Poi la riscrivi anche peggio.Sai perché? Arriva quel meccanismo dove tu arrivi a Greenfield, diventa Brownfield prima o poi, perché le stagioni passano e ciò che è verde diventa marrone, perché le stagioni sono così.Seconda cosa tu parti con tutte le buone intenzioni, poi vedi la nuova moda, vedi la nuova moda e allora inizi a vedere modelli di pensiero diversi all'interno della codebase.Mettiamo che il team è anche grande, quei modelli di pensiero diversi iniziano a esserci già dal giorno zero, ma per quanto tu bravo possa essere, possa avere una brava veloce ti arriva il business che ti dice sì vabbè bello tutto quello che stai facendo, debito tecnico mi importa fino a pagina due, dobbiamo deliverare sta roba, come facciamo? Noi abbiamo alloccato queste risorse, state sprecando tempo, cosa fai? Quando costruisci un ponte, non è che distruggi il ponte perché ti hanno inventato un nuovo calcestruzzo, questa frase viene da mio fratello che fa l'architetto, dice quando io faccio una casa.Non è che perché hanno inventato un nuovo modello di parquet dico al padrone della casa "casa mia cambio il parquet".Quella roba me la tengo X anni e non è che per il parquet cambio tutta la casa.Diciamo che il bene è meglio del meglio, del perfetto, no? E il bene soprattutto è achievable.Sì, una delle cose in cui facciamo molta fatica come sviluppatori in generale è rispondere alla domanda "ma ci serve veramente questa roba?" Quindi lo scope creep diventa un problema colossale.Quello che negli anni abbiamo imparato internamente è tagliare il più possibile, quindi alla domanda "ci serve veramente questa roba?" nella strada di una giornata di case la risposta è no.Sì e soprattutto serve al team e serve al business.Serve al business cazzo! E' una domanda che nessuno si pone.Esattamente, che è la domanda qualcuno è disposto a pagare per questa roba.Perché se la risposta è no, allora non ha senso farla.Può essere che vuoi, mi spiace, ma no.Io capisco che tutto è bello per te stia annoiando a lavorare in PHP5.Però non è che butti tutto al cestino e rinizi da capo con PHP, adesso non so che versione ci sia.E scriviamo il rastro.O la riscriviamo in RAA.Non puoi farlo, la vita reale non è così.Wake up! Solo che io questa cosa l'ho compresa avvicinandomi ai 40 anni, quindi non so se è colpa mia In realtà, ripensiamo anche a quello che ha detto prima Mauro, rispetto a linguaggi diversi in team diversi.Credo che alla base.Io non sono uno di quelli che dice scriviamo tutto nello stesso linguaggio, perché ci possono essere degli edge case particolari dove, mi è capitato di vederne uno, dobbiamo scrivere tutto in Elixir perché ci serve la concorrenza in un certo modo, stiamo usando WebSocket in modo pesante e il modo più performante e più comodo in quel caso specifico era farlo con quel linguaggio.E ci sta, credo che alla base di tutto, anche dello riscrivere codice, ci sia un risk estimation ben fatto, cosa che non vedo spesso.E qua io parlo, parto con la mia subito bold opinion.- How do you know what's good for me? - That's my opinion! - Allora, la bold opinion è che in realtà buona parte dei nostri team, quando fa delle scelte tecniche, non fa cazzo di stima del rischio.E soprattutto non documenta il rischio che si abbraccia.Perché facendo una stima del rischio documentando, e questo è un problema di management più che del single contributor, ma deve essere una cosa condivisa nel team perché altrimenti appare la frustrazione.Se tu documenti il rischio e una volta che l'hai documentato lo guarnisci di tutti gli elementi necessari per fare un ADR fatto bene e non fatto fare da chat GPT, perché se l'ADR te lo stai facendo fare da chat gpt le diar non serve.Ok, nella nota dell'episodio lasceremo appunto i prompt per fare giro.No, questa cosa ci tengo particolarmente perché mi è capitato di perdere un sacco di tempo a leggere i diar che non servono un cazzo.Cioè se me lo scrivi è perché mi serve leggerlo per capire qual è il motivo per cui hai fatto questa scelta.Io un po' di tempo fa avevo fatto uno scriptino che è semplicemente l'ADR io l'avevo messo nel codice e con questo scriptino estraevo l'ADR.Se io facevo slash, doppio asterisco, spazio, ADR in capitale letter, quel blocco di commento veniva estratto su un file markdown con le referenze al file e alla linea di codice.Io ce l'avevo sempre tutto aggiornato.Questa cosa in realtà è fondamentale perché oltre a documentare ti costringe a sedere quel cavolo di sederino profumato sulla sedia e a ragionare sulle cose prima di buttarti sulla tastiera, prima di buttarmi, perché sono io il primo che parte di convice compulsivo, prima di buttarmi sulla tastiera.Internamente abbiamo processo che si chiama RFC, quindi request for comment, fondamentalmente per, di vera e vera dire, per tutte le decisioni, diciamo quasi tutte le decisioni, il microteam che la sta prendendo tendenzialmente fa un RFC.L'RFC è strutturata più o meno in quel modo, quindi descrizione, assunzioni, possibili opzioni, opzione scelta, rischi.E il resto dell'azienda ha tipicamente 48 per commentare sulla roba.È una cosa faticosissima all'inizio, perché ovviamente metti in gioco la tua stessa opinione.Tu sei convinto di dover fare una certa cosa, ma ti metti al pubblico ludilibrio a farti schiaffeggiare per dire "una cazzata, non funziona questo, hai sbagliato quest'altro" e via dicendo.Quindi all'inizio il tuo ego ne risente pastoralmente.Sul lungo periodo invece è una sorta di ancora di salvataggio notevole, perché ti rendi conto che se tu sei un un microteam di quattro persone sei probabilmente già in una piccola bolla ed è difficile, tutti hanno la stessa opinione ormai, e quindi avere qualcuno che dall'esterno ti dice "guarda che vi siete dimenticati questo, questo, questo e quest'altro" è un supporto notevole.E ti aiuta a documentare una parte, quindi torniamo all'inizio quando mi parlavi di documentazione.Hai documentato il perché una certa cosa è fatta in un certo modo e anche a proiettare nel futuro i possibili rischi e quindi prendere contromisure se serve immediatamente.Vero, tra l'altro mentre parlavi mi è venuto un'altra boldupina, un altro rant e non riesco più a contenerlo.Oggi, zio quanto mi sento un colpo, mamma mia.In termini di vecchio brontolone, non in altri termini.No, in realtà pensavo una cosa e tra l'altro il ruolo del lead in quello che hai appena detto è fondamentale, nel senso che, request for comment, il lead mette da parte tutto il suo ego per cui il team fa una valutazione più, il più oggettiva possibile, di quel più perché l'oggettività assoluta non esiste e nel caso si entri in uno stallo la democrazia non esiste.Il lead decide e sarà compito del lead lavorare affinché quella decisione non sia non c'è la decisione del lead ma la decisione del team.Sì sì funziona così anche da noi.Quel quel RFC non è un processo democratico.È semplicemente un'accolta di feedback.Mettiamola così.Però però vedi il lead in quel caso è messo davanti a tutti quei punti a quel contesto per cui quando prende una decisione che va in deve argomentare e in quel caso splitiamo i sistemi in due microsistemi, lo stiamo splittando così perché? E là il gioco è molto semplice, è un gioco che è guidato 90% dal business, se l'idea è sveglio.Per cui va bene tutti i discorsi che facciamo però alla fine perché siamo qua? Perché ci piace giocare con i nostri giocattoli.Sì, siamo fortunati e spesso giochiamo con i giocattoli che ci piacciono.Però valla a dire al calzolaio o al pizzaiolo se ha tutta questa fortuna.Poi il mio pizzaiolo sì, infatti fa pizza da Dio.Però, insomma, diciamo il nostro un dominio dove siamo abbastanza fortunati, ma non possiamo neanche scivolarci, come diciamo in Sardegna, nel senso il business is the king in questo caso specifico.Poi talvolta il business è abbastanza ideale, ma qua apriremo un altro capitolo infinito per cui rimarremo ore.Luca? Mi è venuto in mente, racconto soltanto questo aneddoto, che fino a un po' di tempo fa, durante le retrospettive che facevo con il mio team, io di default mettevo in una board chiamata "debito tecnico" tutte le cose che facevamo.Tutte.Feature, non feature, cose effettivamente a debito tecnico.Perché alla fine quello che cosa misura? La complessità o l'entropia? Ogni feature aggiuntiva comunque aumenta la complessità.Quindi la mia era, più che altro, le mettevo di default anche insomma come provocazione, dire "ma l'avete fatto bene questa cosa qua? L'abbiamo fatto bene? O fra tre mesi ce la dobbiamo piangere di nuovo, perché non ci sono test, non c'è la documentazione, non ci ricordiamo più nemmeno cosa abbiamo fatto e l'abbiamo fatto l'altro ieri e cose di questo tipo.Se non che poi ho notato che era un po' deprimente dal loro punto di vista, allora ho rinominato la Bordoga "debito tecnico" non mi ricordo cosa, ma qualcosa tipo entropia appunto del sistema.Niente, no, stavo raccontando qualcosa.Sapi che a livello narrativo è fighissima, cioè se vuoi passare un messaggio è bellissima, quindi...bella, te la rubo, sicuro.Vai tranquilla, non mi assumo responsabilità.No lies! Need money for beers! Questo è il motto del momento donatore.In realtà questa settimana non esiste un momento donatore, perché non ci sono supporter, ma ne approfitto comunque per ricordarvi che Gitbar è un qualcosa che facciamo nel nostro tempo libero, lo facciamo con estremo piacere, però se avete piacere di supportarci in questo viaggio, ecco, potete farlo attraverso il pulsante supportaci nel sito, cosa che ci piace ancora di più, col value for value, Podcasting 2.0 attraverso un'applicazione moderna potete darci dei boost quindi donarci qualche satoshi lasciandoci un messaggio oppure streammare qualche satoshi qualche frazione di euro mentre ascoltate l'episodio è ancora più bello.Comunque Gitbar non è interessata ai soldi in senso stretto ma interessata al supporto.Per cui se volete supportarci, tre sono le parole, Time, Talent e Treasure.Treasure l'abbiamo già trattato, ne rimangono altri due, Time e Talent.La nostra community è talentuosa, non so quanto tempo libero abbia, però se aveste del tempo libero e il talento ce l'avete, contattateci perché abbiamo un sito che insomma ha bisogno di aiuto e abbiamo un altro paio di contesti che hanno bisogno di aiuto quindi se vi fa piacere bussateci, veniteci a bussare, siamo ben lieti di accettare.A questo punto io direi che è il il momento del Paese dei Balocchi.Il Paese dei Balocchi, il momento in cui sia i nostri guest che i nostri host condividono con noi un libro, un talk, un video, un qualunque cosa abbia catturato la loro attenzione e e insomma gli faccia piacere essere condiviso appunto all'interno del nostro contesto.Per cui, prima domanda, Mauro hai qualcosa da condividere con noi? Due cose mi sono venute in mente, perché sono impreparato, per quanto parlavamo mi sono venute in mente.Una, parlando di sistemi distribuiti, c'è un bellissimo talk di una ragazza che si chiama Cathy McCaffrey, se ricordo bene, non chiedetemi come è scritto, Cathy è C-A-T-Y, McCaffrey, MC, qualche cosa, che lavorava per Twitter anni fa, adesso lavora per Microsoft, credo, e ha lavorato anche, se ricordo bene, a una parte dell'architettura dei server di back-end di Halo, del gioco che era di Microsoft, e il tool che è su il Saga Pattern, fondamentalmente.E ce n'è uno in particolare, che era quello che mi era chiesto di più, ne ha svariate versioni, quello in particolare che mi era chiesto di più era legato a Twitter, al lavoro pazzesco che, presumo che faccia ancora uguale Twitter, adesso, quando carichiamo le immagini in un tweet per preparare tutte le differenti risoluzioni delle immagini da far vedere nei vari contesti e per le varie tipologie di app.Quindi ho caricato tre immagini, quindi te le devo far vedere piccoline dentro il tweet, ma sull'applicazione mobile è fatta diversa, sull'applicazione web è fatta in un certo modo, sulle connessioni a bassa qualità è fatta in un altro modo, le risoluzioni sono piccole per le preview e poi ci clicco sopra e posso vedere che è un lavoraccio insomma.e però questa cosa deve essere moscurosamente veloce, è eventualmente consistente in maniera inevitabile, ma deve essere comprensibile dall'utente non tecnico quello che sta succedendo, quindi fondamentalmente deve essere più o meno sincrona, anche se in realtà non lo è, e c'è tutta la spiegazione di come fanno a fare questo lavoro che è a parte veramente affascinante.La seconda cosa che invece ho scoperto oggi, che esiste da anni, ma l'ho scoperta stamattina, e non c'entra niente, non si devono distribuire i tempi, è lo stesso, sono i notebook di Jupyter.se avete mai provato sono una figata pazzesca io ho l'estensione installata per visual studio code e praticamente per la documentazione è fenomenale perché ci permette di scrivere pezzi di codice inframmezzati da testo e quei pezzi di codice sono eseguibili quindi si può modificare, provare, far andare molto bene, bello ne avevo sempre letto ma mai provati tra l'altro ne abbiamo parlato con Alessandro quando a suo tempo era il PM del DBS Code era appena uscita la feature molto molto figa.Ti chiedo se poi a fine puntata riesci a mandarmi i link così li mettiamo con precisione nelle note.Luca! Stavo aspettando, sai che io sono timido.Arriva la vecchiaia e il nonno si blocca, ti guarda e non dice niente.Sono entrati quella fase stand by.Ho ti riscordato il mio nome dopo Microfront? No, no, no.Al massimo mi scordo il mio di nome.Finché non te lo scrivi sotto, perché sotto c'è scritto BrainRepo, capace.Comunque, ah no, allora i miei balocchi.Il primo è InTopic, del libro forse già baloccato, ma siccome è InTopic, con tutto quello di cui abbiamo abbiamo discusso oggi, quindi lo balocco, è del libro che si chiama "System Design and Interview" di Alex Ksu.Sì, è una panoramica, in realtà ti prepara a colloqui, però in realtà ci sono tanti spunti interessanti, alcune cose le abbiamo anche affrontate, abbastanza semplice e piccolino, digeribile, non dirigibile, digeribile.Il secondo invece balocco, promuovo un evento che si chiama Open Data Hub Day che si tiene qua a Bolzano il 22 maggio, sperando questa puntata arriverà prima, ma immagino di sì.Esce domani, allora ci siamo, abbiamo ben 20 giorni di tempo, sarà disponibile anche online dopo il 22 maggio su youtube da qualche parte.Il biglietto è gratuito, organizzato dal parco tecnologico di Bolzano e promuove appunto sostanzialmente l'evento di tutta una grande occasione per dire a aziende, privati, pubblici, insomma tutti quanti, di aprire i dati e mostrare il vantaggio di avere, di condividere dati.Verranno presentati progetti, presenti, passati e futuri, dove il vantaggio di condividere dati sia dal punto di vista di protocolli, protocolli di scambio, sia dal punto di vista proprio dati, ok? Un Excel che ti scariche, vabbè meglio di niente, porta a grandi vantaggi alla fine per la comunità e per tutti.Rivolto sostanzialmente a tutti il 22 maggio.Questo è tutto.Fantastico, allora mi abbalocco, abbalocco, abbalocco, abbalocco.Ok, ho ripreso a utilizzare iPad come vi ho detto nel precedente episodio, avevo bisogno di un'applicazione per monitorare i miei serverini domestici ed è un'applicazione carina e in realtà ho beccato ServerCat.ServerCat è un'applicazione per iphone e per ipad che ti permette appunto di monitorare i tuoi server.In una prima schermata ti fa vedere lo stato del server, quindi cpu, memoria, upload e download sulla rete, lettura e scrittura nel disco, temperatura della macchina stessa e ti permette di aprire una connessione ssh.Prende tutti questi dati mettendogli semplicemente una chiave per connettersi con ssh e poi lui viaggia viaggia sereno.Tra l'altro cosa molto figa, siccome io nel mio server domestico, altro ballocco, ho Umbrel, che è un'applicazione che attraverso un'interfaccia molto carina ti permette di installare dei container per fare robe come Nitcoin, piuttosto che Talescale come VPN, io cosa che ci ho messo? Ci ho messo una roba per fare i backup dei computer su due dischi esterni.Insomma, sono un botto di container e io posso vederli tranquillamente, anzi, visto che abbiamo le telecamere, ve li faccio vedere.Non vedete un cazzo, ovvio, siccome sono un genio.E vabbè, fate finta di aver visto tutto.Per gli amici del podcast è semplicemente una griglia dove vedete i container e l'utilizzo delle risorse di ogni container, molto figa che mi è tornata utile e altri due balocchi che poi fondamentalmente sono uno solo, vi dicevo che ho ridotto praticamente a nulla la mia presenza sui social e ho ripreso a leggere paper ed è bello, è bello vedere che c'è gente che dice le cose che passa contenuti con più di tre parole e quando usa più di tre parole le parole hanno senso nel senso che non è che ci sono linee vuote per l'asseo nei paper, almeno in quelli che sto incrociando io non ho trovato granché fuffa e da questi paper io ho bisogno di portarmi a casa una serie di informazioni che poi devo ricomporre sulla mia testa e che capiterà che vi racconterò anche qua, capiterà molto presto tra l'altro.E per farlo dovevo trovare un'applicazione per evidenziare del testo e mandarlo su Obsidian perché poi io me lo rielaboro, lo faccio mio, capisco che cosa vuole dire, espando e faccio tutta una serie di cose.Morale della favola, ho provato l'applicazione Books di iOS e credo che sia indietro di 50 anni, cioè credo che Windows 3.1 aveva un'applicazione per leggere PDF migliore.Ne ho provato un paio, quella di Amazon, Kindle, ho provato l'applicazione del mio Kobo, niente, nulla, non ce n'era una, grazie di dio che salvasse le evidenziazioni e mi permettesse di esportarle in modo decente.Allora ho cambiato gli ID, ho provato a cercare in giro, due sono le applicazioni, una è PDF Expert, abbastanza conosciuto in giro, mi permette anche di annotare con la penna e se io faccio delle evidenziazioni automaticamente me le esporta come fai l'HTML, io dentro Obsidian ne mando all'applicazione di Obsidian che ha un plugin che converte l'HTML in Markdown e mi crea un Markdown dentro Obsidian con le citazioni che poi mi rielaboro, ci ragiono e funziona molto bene.L'altro è un po', passiamo nel termine accademico, viene utilizzato per raccogliere, sapete chi scrive paper è costretto a fare le citazioni.Prima di scrivere un paper ti documenti, quindi leggi centinaia di documenti, ti fai la tua idea, la tua tesi e poi gli argomenti.Però le citazioni sono credo il biggest pain in the ass quando devi scrivere i paper, tenerle ordinate.E c'è un' applicazione chiamata Zotero che permette di organizzare le citazioni, taggarle e raggrupparle molto carina e che torna particolarmente utile.Ah, ho mal di gola! Mauro, Luca, come siete? Stavo vedendo il server cap, è carino, il cap c'è solo per Mac.Beh potresti scrivere un'applicazione per android non è complessa da fare in realtà lancia comandi ssh in realtà già avevo provato a farlo in go una volta quando avevo tempo libero mauro com'è stata questa puntata di github per te? molto piacevole, vi ascolto sempre solo in un podcast non ho mai visto niente sul canale YouTube.Ed è la prima volta che vedo in video tutte le varie animazioni che passa via sulle polde, o figli alle compagnie a bella e la sigla pure.Perché insomma il podcast la schifo, salto avanti di un minuto e passo a questo.LM: no, ma non si fa.Non diamo il cattivo esempio, non fatelo a casa.La sigla è un po' un rituale, però so che tutti la schifano, e va bene.Sono tanto ascoltata e tutte le volte la staccate, invece vista è molto più bella.Io pensavo a una cosa, prima di lasciarci volevo farvi una domanda.Abbiamo parlato di ambienti distribuiti, abbiamo parlato di dividere i contesti degli ambienti distribuiti.Secondo voi che ruolo ha da una parte l'algoritmica, che ruolo potrebbe avere da una parte l'algoritmica da una parte l'intelligenza artificiale nel dividere blocchi di codice, blocchi di dominio, in sistemi in un contesto distribuito.Che domanda difficile.Luca vuoi rispondere tu? No, io stavo pensando poi alla risposta alla mia domanda che avevo fatto prima, cioè mentre se tu fai merda poi te la piangi tu, se la tua intelligenza ti pizzale, ti fa merda anche se la piange.In realtà è una domanda non domanda ed è un modo per annunciarvi anche se non dovrei farlo ma sono troppo gasato, vi ho detto no che questo periodo c'è la scimmia dei paper.ho beccato un paper molto figo scritto da dei ricercatori del Politecnico di Milano che appunto spiega un modo semi-automatico di decomposizione dei monoliti.Il semi-automatico mi piace perché non siamo nel dominio dell'intelligenza artificiale ma siamo nel dominio di una classe di algoritmi, di programmazione matematica fondamentalmente che io avevo in croce città ma non ma profondamente io lo penso, Mixed Integer Linear Programming quindi è programmazione lineare ed è tanta tanta cosa cosa ho fatto? Ho appena mandato una mail a chi ha scritto questo paper e spero che risponda per venire a parlare in un episodio di Gitbar di come possiamo dividere un monolita usando gli algoritmi e di come possiamo farlo in modo da poterci a core leggero più o meno core leggero riuscire a prenderci la responsabilità senza dover dire "ho usato un LLM e quello mi ha detto così".Luca hai detto qualcosa o Mauro? No, pensando così ad altavoce una cosa che mi verrebbe in mente potrebbe essere un gran bello da avere, tornando all'argomento così di capability di cui ho parlato all'inizio è che ad oggi abbiamo un sacco di tool di analisi statica del codice, ma i tool di analisi statica del codice possono capire fino a un certo punto quello che il tuo codice fa, ma se riuscissimo a mischiare il tool di analisi statica del codice con un tool che prende l'output dell'observability e ti dice "guarda che questo pezzo di codice in realtà non ci sei mai arrivato in produzione, quindi non l'hai mai fatto.E' vero che ci sono dei pack che ci arrivano, ma in realtà in produzione non ce ne è mai passato, lo potresti spostare da un'altra parte, lo potresti togliere.Sarebbero tutte informazioni molto interessanti.Abbiamo parlato di qualcosa del genere qualche settimana fa quando abbiamo parlato di Grafana e di un po' di cose, perché al FOSDEM abbiamo seguito un bel del talk che utilizzava ebpf, che spiegava come un tool del team di Grafana utilizzava ebpf per fare observability a un livello molto basso, a un livello molto profondo, che un po' si avvicina a quello che dici tu.Se poi a tutto questo ci aggiungiamo una ricerca, un po' meglio fatta di tutta la documentazione che scriviamo, in realtà, e trovassimo il modo per mettere insieme tutte queste sorgenti di dati, probabilmente, insomma, potremmo avere un tool figo.Io ne ho individuato uno che sto usando, l'ho condiviso nel back con Luca e gli altri baristi.Prima di condividerlo nel main group voglio vedere se intanto c'è qualcosa nascosto, quindi c'è qualcosa lì che non mi convince dal punto di vista etico e cose.Quando son qua lo condividerò con voi, con estremo piacere.Siamo a due ore Sette minuti, io direi che possiamo ringraziare Mauro per esserci venuti a trovare.Prima di ringraziare però Mauro, dobbiamo ringraziare anche un'altra persona, che è Luca, il buon del puppo che ci ha fatto il nome di Mauro, che ringraziamo e abbracciamo.Luca potrebbe tranquillamente essere un balocco, perché quando guardi nel profilo, nelle robe di Luca c'è sempre qualcosa di interessante da scoprire.Lo balocchiamo! Lo salutiamo e lo abbracciamo.Mauro, grazie a te.Tra l'altro grande invidia, perché io qua lo vedo, no? Sopra la tua testa c'hai un scavatore, c'hai una gru, e poi tu la stai nascondendo, la vera chicca.Stai nascondendo, guardate che meraviglia.Cioè, verrei a casa tua di notte scassinando la finestra.A proposito, visto che ne stiamo parlando, per chi ci ascolta in podcast c'è il Millennium Falcon della LEGO dietro di me.Una curiosità, ho una foto in cui ho due scatole del Millennium Falcon sul tavolo perché il sistema distribuito di LEGO ha sbinchiato qualche cosa e me ne sono arrivati due.- E' proprio la persona giusta! - Mi hanno fatto pagare anche due, e una l'allergia.Quattro giorni dopo, per una senorea di due, ne ho ordinata una e ne ho ordinata due.Con estremo dispiacere.Esatto, più o meno.E quando ti sei seduta a tavola con la tua compagna o tua eventuale moglie, hai detto "no, non è colpa mia".Se il destino chiama è.Mauro, grazie di cuore per essere venuto a trovarci, come noi diciamo di solito, Gitbar è un po' il circolo del dopolavoro postale, quindi la porta è sempre aperta, se ti capita di avere sotto mano qualche cosa di carino che ti fa piacere condividere, può essere un'informazione, un'una nuova libreria, qualunque cosa insomma, hai piacere di condividere con noi, ecco, questo è il posto giusto per avere una birra, ahimè virtuale per ora, ma con noi.Balocco Off-Limit.Cercate su YouTube Mauro e seguite il talk che ha fatto sugli aggregati perché è fantastico.Lui sarà sempre della banana nello lo zainè.Non dico altro, guardate il Toyca.Ciao Mauro.Ciao Luthi, grazie.Ciao.Dove vai Luca? Dove vai? Come è andata? Puntata fantastica direi.Bello, bellissimo.Poi sistemi distribuiti sai uno lo vede sempre da lontano.C'è a che fare di striscio però.E poi si spaventa appena ci mette i piedi si spaventa.Io credo che dagli ultimi due progetti dove sono nel bel mezzo della giungla in realtà ho perso più capelli di quanto "Oh, mio Dio, di quanta..." Ciò, me lo sono messo in castrato.Luca, ma la mandi una scatola di pastigliette perché non ce la faccia a me? No, no, io...Cioè, ultimamente, no, l'anno scorso quando dovevo fare su Firestore, che è distribuito da sotto al sedere, no, Firestore di Google, un...estrarre un numero sequenziale, laudison ok, sistemi distribuiti non vanno bene per questo.No, come diceva Mauro, sistemi distribuiti quando servono, se no, come dice DHH, fatte al monorita nei campi centrali.No, infatti ho fatto un microservice che può benissimo morire perché c'è il fallback con un glorioso Redis, grazie Salvatore, quando avanti uno per resti, quindi non ho dovuto manco scrivere codice.Web server che gira direttamente Redis e dico ok dammi il prossimo numero e via.Sta ancora là.Dimmi una cosa ma la facciamo o non la facciamo? Sta puntata sul cambiamento di licenza di Redis e conseguente flame.La vuoi fare? Non lo so, ho paura, ho una dannata dannata paura lasciamo a voi ragazzi e ragazze della community a decidere detto questo io vado a letto perché non ce la faccio più veramente noi ci sentiamo la prossima settimana si? cosa c'è la prossima settimana? sai non mi vengono gli inviti farò in modo che tu lo sappia siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato ci troviamo al github e davanti a una birra tutto ci sembra un po' meno grave
