*musica* Siamo noi quelli che leggendo il codice cercano lo stronzo che ha scritto quello schifo Ma ahimè, lo stronzo è mai medesimo, ma l'ho scritto giusto ieri *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 codebase 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 comment message prima di tutto, e dentro ce l'appella tutti i santi.- Non bestemmio, 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, ma hai 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, la CIA rossa, il business incazzato, ci troviamo al Gitbar e davanti a una birra tutto ci sembra un po' meno grave.Bene bene bene benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Nuova settimana che inizia, in realtà è giovedì, quindi la nuova settimana è già in porto, anzi si appropinqua verso l'uscita, ma nuovo episodio di Geekbar registrato di mattina, non è vero, non è mattina, anche se sembra che ci sia un sole fortissimo, non è vero, sono tipo le nove e mezza di sera, ma con noi ho due co-host, due baristi, due amici, Andrea e Leo, ciao ragazzi! Ciao! Io non vedo nulla con questi occhiali, adesso me li levo eh! Tra l'altro è...Voliamo fa' sta roba, voliamo fa' sta roba, capito? Sta intro un po' così...È memissimo! Presentiamo l'ospite e poi ce li possiamo levare anch'io, brancolo, nel...Nel buio! Nel sole! Nel buio! Nel buio! Però con tutto questo arancione di Gitbar gli occhiali da sole ci stanno! Io sono mezzo disconnesso perché sto provando a convincere Carmine e Luca a unirsi a noi, così facciamo proprio una mucchiata grandiginosa.Che bello! Speriamo si uniscano.Io ho già il fiattone e tipo stiamo registrando da tre minuti esatti, quindi non so come arriveremo a fine dell'episodio.Però, ditemi voi, Leo e Andre, cosa mi raccontate di bello? No news, good news.Niente di bello, niente di brutto, tutto normale, tutto procede.Se eravamo felici prima siamo felici ora.Non ve l'ora di iniziare.Allora iniziamo, parte la sigletta di presentazione del nostro ospite e poi Andrea ce lo presenta Per chi ci guarda in video su youtube e altri schemi è già stato spoilerato il nome no? Però che ci sta ascoltando invece ancora non lo sa.Quindi vado a presentare l'ospite di oggi, a gran richiesta.Come posso descrivere l'ospite di oggi? È quello che io chiamo un po' il mio pupillo.L'ho visto un po' sbocciare, no? Ex collega, grande compagno di bevute, ride e spalla di snowboarder, amante dell'A.S.Roma e sempre perché ci vede in video capirà perché a breve, dal muro del nostro ospite.Vivi a Lisbona, direttamente dal Grafana Labs, oggi con noi on stage Giordano Ricci.GZ: buonasera, buonasera, grazie Andrea.LM: intanto è un super piacere averti qua.Devo dire che io di calcio me ne intendo poco.Ragazzi però perdonatemi, io questi occhiali li devo togliere, sembro veramente un cecco.Da finale sarò malo, grazie.Andava bene ma è già passato un quarto d'ora.Ah, finalmente ho riacquisito la vista.Salute.Salute al bar.E dicevo, ho diversi amici che mi parlano di vivere, abitare fuori.Tra l'altro qualcuno me ne ha parlato anche da poco.Io conosco quel qualcuno, Leo tu lo conosci? No, a me non vado a vivere, vado a fare un'esperienza alle Canarie per tre settimane per fare veramente il remote worker.Volevo andare a prendere delle temperature un pochino più alte, però anche qui a Firenze adesso comunque il giorno ci sono 20 gradi, però vado a fare il surf, va beh, quello non lo posso fare a Firenze.Però una cosa di tre settimane, poi torno alla base.Ah, e vabbè, insomma, è un modo per… Si, si ha piccoli passi, piccoli passi.Esatto.Non per fare il nome digitale, diciamo.Invece voglio andare a provare un co-living e andare a vedere cosa fanno i nomadi digitali e soprattutto dove pagano le tasse.Figo.Quando lo scopri dimmelo, perché dove si pagano le tasse è sempre interessante.E soprattutto il co-living da nomad e digitale mi sembra tanto Erasmus 2.0, non so se è veramente così.Sì, sì, quello è uno dei motivi anche per vedere come fare l'Erasmus a 40 anni.LM: tu vuoi andare a fare surf lì, ovviamente anche la patria dove attualmente il nostro Giordano risiede è super fan e popolosa di surfisti, quindi direi rompiamo un po' il ghiaccio.Giordi, raccontaci un po' com'è Lisbona, Grafana Labs, nello specifico di che ti occupi quotidianamente.Ah, intanto, Lisbona, surf, primo, c'ho porra dell'acqua, quindi, padia del surf, quello che volete, no, assolutamente no.E poi è freddo, fa freddo.In acqua, in oceano, fa freddissimo.Però, 20°C, adesso ne fanno 18°C, quindi bomba.In realtà Lisbona non c'entra niente con Grafana.Io mi sono spostato qua cinque anni e mezzo fa ormai per motivi totalmente differenti.L'opportunità di venersi dopo sei mesi è svanita.Però era giugno e mi hanno detto "ancora non me la so fatta un'estate in Portogallo, perché no? non so, magari altri due o tre mesi e cinque anni dopo sto ancora qua.Poi si, poi sono venuto a Grafana, ormai sono tre anni e mezzo che sto a Grafana e lì mi occupo di...faccio sviluppo software.In realtà ho iniziato come sviluppatore front-end e poi in realtà, poi penso che questa cosa vale per un po' tutti quanti, inizi come front-end poi il giorno dopo fai sia i quello dopo ancora fai documentazione quello dopo ancora automazione ma poi pulisci l'ufficio porti caffè insomma quello che quello che capita quindi sì adesso sì diciamo front-end non proprio non non più da un pochetto che abbiamo perso.Ma principalmente dentro.Scusate? Hai laggato? Sì sì ma no problem.Sei tornato però.No problem, no problem.I grandi strumenti tecnologici che utilizziamo hanno permesso di recuperare il pezzo di lag che noi non abbiamo sentito ma voi avete appena sentito.volevo chiederti rispetto proprio alle grandi aziende e il fatto che tu entri con un ruolo e poi una volta che sei dentro fai quello che serve nel team/nei team.È capitato anche a me, io ho fatto un interview di React e adesso sto facendo microservizi da un anno, insomma, che capita.Ecco, secondo te in quest'ottica e in un'ottica di seniorship medio-alta, ha ancora senso il concetto di verticalizzarsi per un ingegnere? Guarda, secondo me è un po' un discorso che ogni tanto spunta fuori con...almeno per me è spuntato fuori mille altre volte.Allora io parto dal primo posto, io non credo nel full stack di Pelover.Non c'è un'opinione personalissima, so che mi odieranno tantissimi.Non ci credo molto, nel senso che...Sì, poi parlo di me.Io ho fatto, in realtà, ho nato come backhand quando ho 16 anni, 17 anni, quando ho cominciato.Poi ho espulsato perché lo trovo più interessante.Dopo adesso faccio un po' observability, backhand, sto in fissa telemetry e ti dirò sì magari riesco pure a essere abbastanza forse bravino in alcuni aspetti però non potrò mai essere bravo in tutto perché io penso sinceramente che va però io penso che va bene conoscere un po' le basi di qualsiasi cosa quindi a livello di di io penso che a un certo punto una persona debba conoscere un po' di tutto al meno capire quando si parla di un di un nuovo progetto di un di qualcosa di cosa si stia parlando però essere orizzontali completamente penso che sia boh una una una carta non potrai mai...troppo dispersivo...troppo dispersivo...sei un...ma più che altro probabilmente il rischio è che è un miraggio, è una cosa che non riuscirai mai a raggiungere...sì...io invece su questo ho una mezza bold opinion...Ok, la mia bold opinion è questa.Io credo che invece un software ingegnero, un software developer che ha raggiunto una certa maturità professionale, possa essere un full stack.dove i confini del full stack sono anche abbastanza diciamo sfumati.Perché può essere un full stack abbastanza bravo con una signorship abbastanza alta? Perché se tu hai un livello di competenza in quello che fai, di un certo livello, un buon livello di esperienza quindi non una settimana, tu sei in grado di masterare le tue abilità di apprendimento.Per cui per esempio da senior a me capita domani mattina di essere buttato in una tecnologia che non conosco a risolvere un problema che non conosco e da senior full stack definiamolo come ci pari ossia del culo sulla sedia cioè i miei metodi d'apprendimento e io il problema te lo risolvo perché? Perché so andare a cercarmi le informazioni, so come chiedere, so come gestire le informazioni su una base, un humus di conoscenza e quindi alla fine secondo me il full stack ci può essere ma puoi essere full stack a partire da un certo livello dove la capacità non viene misurata il numero di concetti che tu conosci ma in rapidità nella quale tu apprendi questi concetti.Io ho un modo di dire no? Senior staff, principal engineer non è chi sa una cosa o chi sa tante cose, ma chi trasforma in modo rapido, agile e veloce la unknown un un in un anno poi le cose che non conosci ma che sai di non conoscere te le smazzi veloce e apri un libro ti leggi la documentazione ti siedi il culo sulla sedia e risolvi il problema però alla fine c'è quella competenza e tra l'altro vogliamo anche dire che per quanto noi ci verticalizziamo spesso quando le coi giochi si fanno duri e non stiamo facendo il crudino della chiesa come direbbe Carmine, alla fine i problemi sui quali sbattiamo il muso sono diversi ogni giorno e non sappiamo spesso come risolverli, al di là del fatto che siamo anche verticali.Quindi, cioè alla fine questa verticalità va bene se devi essere un Ghostbuster che fa solo quello e solo quel problema risolve, ma in contesti dove i problemi sono vari e bubble up ogni giorno e hanno forme molto diverse ecco secondo me ha senso vi ho tirato un pippone senza fine bisogna capire quali sono i limiti del full stack perché il full stack potrebbe voler dire che ti occupi anche di fare UI/UX perché sei veramente proprio a stra il front end perché non parli di codice E esempio di oggi in palestra un mio amico mi ha detto "mi piacerebbe fare informatico se gli facevo il cablaggio della rete in casa nuova" perché ho studiato informatica da un po' da elettricista.O per andare un pochino più nell'informatica, la cyber security.Quelli sono argomenti complessi perché una UI/UX buona ti fa convertire di più e una cyber security buona ti fa non perdere soldi.diciamo il discorso che fai te mi puoi trovare d'accordo però dobbiamo restringere quanto al mondo dello sviluppo software per esempio posso posso dire che secondo me invece sei un un junior molto veloce invece nel senso cioè quello che la skill che descrivi te che poi sono d'accordo io quando penso un signore penso a una persona che ha un problema e lo risolve Ok, non penso al fatto che questa persona programmi in Go o Java a occhi chiusi, perché io sì, il titolo mio è Senior, sono il primo che va su Google e cerca come si fa Trim e Translating in JavaScript, cioè primo, primissimo.E secondo me Signoriti non è quella.Signoriti, come dici te, è sapere risolvere problemi e sapere applicare conoscenze per crescere a ha problemi nuovi.Quello che dici tu, essere veloci nel risolvere un problema, o nel trovare il modo di risolvere un problema, quindi essere veloci nell'apprendere, nel leggere documentazione, secondo me ti rende un segno nel modo in cui tu sai dove cercare informazioni e come applicare quell'informazione.Però quando la applichi sei forse un junior o un mid-level molto veloce.Per esempio, adesso sto facendo Go molto, io non so come funziona il management di Go e questo non mi rende un sviluppatore senior in Go.Sono forse un senior perché so come risolvere un problema, perché applico le conoscenze che ho avuto facendo 10 anni di front-end a un problema nuovo.però poi mi dici boh fai cioè questo performa meglio di quest'altro perché x o y boh aspetta fammi fammi aggiungere perché forse non sono stato non mi sono spiegato bene naturalmente sul fatto di risolvere il problema è uno degli elementi però tu ti porti appresso un bagaglio di fondations che tiri fuori per farti le domande non per darti le risposte io volevo arrivare a questo punto nel senso tu stai scrivendo Go, già il fatto già il fatto che ti stai chiedendo "oh ma quello che sto scrivendo rispetto a quello che sto scrivendo il memory management o il garbage collector di Go come lavora? quanto inficia? a quel punto cosa fai? la domanda te la sei fatta vai a cercare non è necessario che tu abbia quella risposta ma quanto che tu ti sia fatto quella domanda è quello che ti rende senior, non il nozionismo di dire "ok c'è questo problema facciamolo così" senza andare a cercare, a documentarsi, a studiare, anche perché il nostro mondo è vastissimo quindi alla fine comunque puoi essere il giga ninja di un topic specifico, comunque vai a leggerti qualcosa nella documentazione o ti apri il codice per vedere come sta facendo quella cosa, perché la vastità e il carico cognitivo legata a quello che facciamo è incontrollabile.Per cui cioè alla fine al posto di limitare il carico cognitivo a una verticalità specifica, io il carico cognitivo potrei dire che potremmo limitarlo a un'orizzontalità legata a un contesto specifico di business, di dominio che può essere che ne so al posto di System Programming in Rust, noi stiamo usando Rust e io automaticamente ti faccio abbastanza bene la parte in Rust, abbastanza bene la parte frontend perché noi stiamo usando Rust come back end.La sto buttando così e allora non sono senior perché non sono sceso in quella verticalità.No, beh, c'è una orizzontalità che mi rende tale perché utilizzo questi due strumenti.forse stiamo entrando in una galleria senza via di cì.Per uscirne da questo tema dico però è corretto nei tuoi panni secondo te questo atteggiamento? Cioè io datore di lavoro è giusto che ti devo mettere nella condizione che oggi devi risolvere un problema in RUST, domani in GO, dopo domani devi gestirmi di storage su openstack, dopo domani mi devi fare la network di rete per far parlare diciamo sta roba in cloud, dopo domani ancora rifammi la build con webpack per questo software frontend.Io sono capito tranquillamente se ognuno di noi che è senior si mette lì se lo studia, risolve il problema, applica le metodologie eccetera eccetera, ma è giusto che ti si venga chiesto questo? E quindi ecco perché io torno a dire che sono un po' d'accordo sul discorso.Sì, può esistere questa figura, ma io preferisco che non esista, ma perché esista un concetto di verticalità e di vera conoscenza approfondita sulle diverse tematiche.Poi possono essere anche due o tre, non deve essere per forza soltanto un pilone unico e basta tecnologico.Intanto oggi siamo fortunati e abbiamo la fortuna di poter scegliere, quindi abbiamo la fortuna di poter sfanculare il dattore di lavoro quando ci dice "sì vabbè adesso mi fai anche le pulizie".Ecco, io non sto parlando di questo tipo di contesti, io sto parlando di tipo di contesti sani dove lo scope ha un'ampiezza grande che può passare dal front end al back end alla parte un po' più let's call it DevOps, però alla fine con l'anzianità e portandomi a presso un'esperienza da imprenditore mi viene anche da dire "ma cazzo noi siamo pagati non per conoscere javascript Go, Python, Rust, Ruby...ne siamo pagati per generare valore! Per cui se il mio ruolo in quel contesto e io mi sono ritagliato il contesto di super specialista in...chiamiamo performance di Node.js, a quel punto non ha senso che il mio datore di lavoro mi dica "no ma scusa mi fai anche la configurazione cloud agisce un po' nell'ambito del DevOps probabilmente non avrebbe senso ma se io invece ho come obiettivo quello di risolvere un'ampiezza di problemi un po' più larga quindi un po' più legata al sistema engineering, ma perché no? Cioè secondo me dobbiamo toglierci dalla testa questa puzza sotto il naso che abbiamo di dire io faccio solo quello? Basta, no, io genero valore.Guarda io sono molto d'accordo però stiamo dicendo la stessa cosa cioè in realtà stiamo dicendo la stessa cosa perché io non dico che mi rifiuto di fare javascript se faccio, se sono astuto per fare il backhand o l'opposto.Quello che dico è che la tua seniority o la mia seniority o quella di Andrea o chiunque deriva dal fatto che tu sappia prendere delle decisioni e quello ti rende un senior.Poi il fatto che tu voglia chiamarti non è che tu devi fare un progetto e farti full stack o o no quello secondo me è un discorso completamente diverso.Quello che dico io è che eh la tua signorita deriva dal fatto che tu sappi a prendere quelle decisioni e sappi a come applicarle in vari contesti.Poi si posso prendere una una decisione su come organizza boh su come fare un'architettura di un software X che fa che c'ha uno span da da immenso però poi è chiaro che se devo momento in cui tu scrivi un'applicazione che ha un servizio che critico dal punto di vista di performance o memory management la mia seniority mi dice "ok, non lo fa, lascia a verde, fallo fare a qualcun altro che a verde cuoce, capisce?" Certo, infatti stiamo parlando, quando ci confrontiamo in quel modo, stiamo parlando di due seniority diverse.Il primo è la seniority come ingegnere o come software developer.La seconda è la seniority in un ambito specifico.Il problema è che se a te manca la seniority in quell'ambito specifico, ciò non toglie che tu non sia senior come developer.E io parlo perché sto shiftando, io ho shiftato da un po' al mio punto di vista più architetturale.Nel senso che l'architetto sa tutto e niente.È bellissimo, no? Perché c'è un libro che si chiama software architecture introduction, qualcosa di introduction software architecture, che parla proprio di technical breadth e technical depth, quindi la profondità tecnica e l'ampiezza tecnica e spesso quando ci sono questi discorsi, la mia era una provocazione, però spesso quando ci sono questi discorsi noi ci concentriamo sul misurare la senioriship con una misura tipo verticale quando invece secondo me anche un minimo di misura orizzontale dobbiamo cioè va bene che mi sai tutto javascript ma se non mi sai che cos'è una una una una lambda function di AWS e che non mi conosci almeno un minimo di architettura del mondo serverless probabilmente insomma.Accordissimo.Se sull'orizzontalità che sia un negozio per essere veramente, da un certo punto di vista, considerato senior, sono d'accordissimo.Su questo sì.Volevo passare però, sono passati tipo 20 minuti su un argomento che era completamente...Volevo dire una cosa.Scusa, volevo dire una cosa.Perdonami.Qui siamo tutti senior e Gitbar.it ha un errore di SSL a questo momento, quindi sappiamo come risolverlo, però non è che siamo dei geni perché queste cose non succedono.In realtà vi do qualche informazione in più, devo risolvere un problema perché ho dovuto spostare il DNS di Gitbar, l'ho spostato su Aruba e mai decisione fu così sbagliata, quindi non riceviamo l'email, come ho detto nella precedente puntata, non sono riuscito a far rigenerare il certificato da Netlify e quindi devo fermarmi.Questo è un podcast che invecchierà malissimo perché nella data di uscita tutto questo sarà già risolto.però però ecco a questo punto io devo dire che in realtà abbiamo bisogno del vostro aiuto quindi se avete del tempo da dedicare contattatemi e datemi una mano a risolvere questa cosa perché ho tempo ne ho praticamente zero quindi se volete che il sito rifunzioni, pingatemi.Quali sono i contatti? Perché forse abbiamo dimenticato una cosa all'inizio.Hai ragione.Bravo Leo! Comunque su Telegram cercate Gitbar.Sì, anche perché info@gitbar.it non sta funzionando.Gitbar.it non è trusted.Non funziona.Solo su Telegram.Vediamo se riusciamo a indirizzare la gente solo su Telegram.Tra l'altro non è trusted come tutto il podcast.Non fidatevi di noi.No, e quindi insomma contribuite, dateci una mano a far funzionare le cose.A proposito di contribuzioni, parliamo di open source.Tu lavori in una società che in realtà fa tanto open source.Sì, praticamente 90%, 95% di quello che facciamo è open source.Grafana nasce come prodotto completamente open source, siamo in una società penso a distanza di anni da quando Grafana è stato creato e comunque Grafana rimane open source come Locke, come Tempo, come vari altri progetti resi open source.Quindi sì, la società è quasi totalmente open source.Ecco e qua viene la domanda.Noi abbiamo visto tante di licenze cambiare, di situazioni complicate con le community.La mia domanda è come, dal punto di vista di un dipendente della società, una società, un'entità di quel tipo riesca a bilanciare la parte open source con la parte un po' più commerciale, più per profit? Eh, se lo sapevo c'era la società mia penso che faceva open source sinceramente, se avevo la risposta non forse non ero non ero un ingegnere è difficile difficile cioè non è non so come darte una risposta c'è ci sono tanti modi cioè se ne parla tantissimo posso che se te stai a posto del mese scorso e anche lì se ne parlò tantissimo di come bilanciare open source e revenue perché poi open source sì, bello però tutti dobbiamo mangiare bilanciare? secondo me c'è una differenza fra...il punto è sapere dove creare i valori per l'utente poi quello che abbiamo fatto nel tempo è stato fare revenue dove c'era denaro da spendere anche oggi Grafana ha open source, il software open source e abbiamo un'offerta enterprise, una versione di Grafana con una parte di codice closed, che fondamentalmente serve a chi già spende, ha una bill 100k l'anno su AWS, quindi non alla persona che usa Grafana a casa, l'aziendina che monitora tre servizi.Un'azienda che spende un milione su AWS l'anno, allora una parte la voglio pure io.Quindi quello è la monetizzazione su quel tipo di feature, magari closed.Avere un'offerta cloud nostra che è differente rispetto a Amazon o a Google o a a Microsoft o a chiunque offre Grafana on Cloud.Perché? Perché è offerta da chi Grafana lo fa.Quindi da cliente io andrei a...a parte Grafana, ma qualsiasi altro software, andrei a comprare da chi lo fa il software, non solo dal rivenditore.Ovviamente varie spazio stature sta affermazione, però quello è un differenziatore secondo me.Anche alcuni plugin, se non sbaglio, hanno delle fee? Sono closed oppure è tutto open? No, ma molti plugin sono open.Ci sono alcuni plugin che sono closed, cioè plugin enterprise, che è un po' come il modello che molti altri software utilizzano.per esempio penso che sia forse il plugin per Oracle sia un plugin Enterprise perché nell'open source o nella community hobbyst pochissima gente usa Oracle.Se usi Oracle è perché hai una licenza da milioni di euro e me ne dai un po' anche a me.Se ti vuoi permettere di pagare la licenza Oracle dammi una piccola fianca a me.Esatto.Se ti vuoi mantenere il plugin per Grafana, chiaro.Il concetto è quello.Ha molto senso.Ti volevo chiedere, a questo punto c'è una parte di Codebase open source, quindi anche una parte di Codebase aperta alle contribuzioni della comunità.Come funziona questa cosa? Perché per esempio ci sono modelli differenti, ci sono modelli molto più aperti, oppure modelli veramente rigidi e chiusi, mi viene in mente che ne so la Codebase di React, no, che prima di andare a fare una contribuzione su React probabilmente tu sei invecchiato, React è diventato obsoleto e c'è il nuovo framework JavaScript per fare front-end super brillucicoso.Da voi invece come funziona questo modello? Cioè, come è gestito? Ogni contribuzione è vista indistintamente dal fatto che sia fatta da un dipendente o da un contributore esterno, bisogna essere invitati a diventare contributor, dimostrare interesse, c'è un flusso, un hater? No, assolutamente no.Nel senso, PR sono welcome, quindi trovi un baghetto che, non so, qualche parte di Afana che un baghino o una figure che vorresti avere.Ovviamente, issue first.questa è una cosa che probabilmente non verrà mai ripetuta abbastanza nell'open source quindi sì, prima se crea una issue, perché almeno si discute anche un pochino il cosa che deve essere fatto e soprattutto questo vale per nuove funzionalità, perché ovviamente io posso aprire una issue su Grafana dicendo, o una via sulla Grafana dicendo "vorrei che il tema fosse rosa" che va bene, tu lo vuoi, però lo fai te su 900 milioni di persone, utenti, possibili utenti e poi lo mantieni te però, perché tu magari lo mergi, però poi va pure mantenuto.Quindi, discorso di nuove feature, ci hanno senso e vengono accettate di base se c'ha senso per Grafana come prodotto, come software.Però l'Iter non c'è, l'Iter c'è una issue.interessati se lavoro su questa? Sì, bomba, vai, PR, review, mergiata.Mi viene in mente però un'altra domanda a questo punto e l'apro anche a Leo che so che anche anche loro praticamente sono una società open source first, no? E questo, allora, sul fatto di proporre una feature va bene ci sta diciamo che va bene ai maintainer però alla fine Grafana è anche un prodotto, Trattformatic è anche un prodotto e quindi c'è un minimo di lavoro da product manager uno degli elementi di questo di questo lavoro è la priorizzazione delle cose adesso se io ho un contributor che mi butta sul tavolo una feature mettiamo che la feature sia anche bella fatta e finita ma quello è un single contributor affinché quella feature prenda a piede ha bisogno di review, ha bisogno di additional integration, cose particolari cioè alla fine come si gestisce la contribuzione libera e la creazione di feature esterne fuori dalla scaletta, diciamo così, con le risorse che tu hai, magari paid, che sono i maintainer, e la scaletta, il backlog che tu hai per il prodotto.Oggi ho difficoltà a parlare italiano.Io se vuoi ti dico brevemente visto che siamo otto persone e abbiamo delle label su GitHub dove quello che i lead chiedono hanno priorità e non ci lavoro io.Quello che viene dall'esterno è poco come nuove feature perché semmai si sono, vengono fixati dei bug quindi vengono emergati più velocemente, però sì c'è quella cosa, cioè diamo priorità a chi potenzialmente poi potrebbe diventare un client.Poi su un'enterprise più grossa annuisce Giordano, quindi forse è una cosa simile.Eh no, in realtà è questo.Cioè ovviamente, a parte della storia di Grafana, stava anche a fare, come si dice, mi fugge il termine, però fondamentalmente Grafana la prima reva non la faceva facendo roadmap assurance.Quindi cliente Enterprise X pagava per far sì che Feature Y venisse sviluppata a un certo punto.Quando si tratta di open source nel senso che una persona vorrebbe Feature X che se fa parte del contesto Grafana, se c'è senso nel prodotto, sì.Se non c'è senso perché è solo un problema che è solamente di quell'utente, no.poi comunque questa è anche la cosa bella dell'open source nel senso che Grafana è a GPL quindi non ti piace Grafana perché vuoi una feature diversa? Fork? Bomba! Poi te lo mantieni! No, quello è il punto, poi te lo mantieni! Allora io non voglio scoraggiare la persona che fa la feature perché anzi, a milioni ne vorrei vedere queste persone qua! è una cosa bellissima nell'open source però c'è anche un concetto che un software va mantenuto quindi una feature dà tanto al prodotto ma poi vuole anche tanto indietro, vuole manutenzione, vuole...è un investimento intera una feature in un prodotto.Quindi se quella feature la vuole anche DevRel, quella feature la devi comunicare, la devi spiegare, la devi documentare, la dei vende.Esatto, va aggiornata, vanno fixati i bug se compaiono, va messa in considerazione quando verrà fatta una feature diversa che deve interagire con quella.Quindi è un investimento, c'è un ritorno di investimento? Sì, allora la feature va bene nel prodotto, se no forse non è la feature giusta, forse non è il prodotto giusto per quella feature.Low priority.Nella Xunt Leones del backlog dove nessuno mai è andato e neanche col macete riesce a penetrare.Il giorno del mai.Volevo fare un'altra domanda sempre rispetto a questo contesto.A questo punto noi abbiamo parlato di feature enterprise e feature nella versione open source.Come fai coesistere questi due elementi, uno aperto e uno chiuso, in un'unica codebase ibrida a questo punto? Come gestisci la codebase in questo contesto quando hai queste due entità? Ah, guarda, fortunatamente dal punto di vista di Grafana la cosa che funziona bene è il sistema di plugin perché poi fondamentalmente qualsiasi cosa che è esterna, che non è nel codice open source, nel 90% dei casi è un plugin.Quindi una volta che c'è un sistema di plugin che funziona, fa feature che siano closed source indipendenti diventa fondamentalmente facile perché non è che devi lavorare su Grafana.Poi per l'estensione di Grafana, che è tutta un'altra storia, tecnicamente quello che facciamo è fondamentalmente simlinking, quindi due repo, uno simlinkato dentro l'altro in fase di sviluppo e va avanti così.Dal punto di vista di prodotto è là la cosa interessante secondo me, la cosa difficile anche perché poi è decidere se una cosa appartiene alla versione OSS o alla versione Enterprise e secondo me è quella la parte difficile, non il codice.il codice, Simlink o non so, ci saranno mille altri modi per fare questo tipo di submodules, qualsiasi altra cosa.La parte difficile è capire se c'ha senso nella versione open source o nella versione enterprise.Quello che ho detto prima ancora vale, poi quando ci trovi.Sì anche perché poi alla fine quelle sono gestioni manageriali e insomma è veramente complesso capirlo.Ultima cosa rispetto all'open source.Cavolo, molti di voi sono pagati, di noi sono pagati per lavorare su pezzi di software open source.Ed essere pagato per lavorare su pezzi di codici open source ha un peso e un valore diverso rispetto al farlo nel tempo libero.Probabilmente perché il giudizio non ti arriva solo dai peers e dai tuoi manager ma ti arriva dalla community che talvolta è brava altre volte ci va con l'accetta per cui come si vive come si gestisce il peso del fare working in public? Tremore degli hater? eh ma guarda no il primo retegliere no no non penso che sia ah c'è c'è il codice scrivi in pubblico quindi scrivi codice de schifo quello vedono tutti e e forse è una arma a doppio taglio no nel senso che che spesso è è bello è figo perché tu scrivi codice lib c'è apertamente e buon fare un interview fra un anno però io non ho scritto del brutto codice eh ma pure Grafano non è che che faccia finta di no.Cioè penso che chiunque l'abbia fatto.Eh cioè nessun progetto è c'è sta solo bel codice dentro.Se no ci avremmo Babi se no saremmo tutti non staremo nessuna parte di questo progetto.Sì.E quindi io non ho scritto del brutto codice.Io non ho scritto del brutto codice.Io non ho scritto del brutto codice.Io non ho scritto del brutto codice.Io non ho scritto del brutto codice.Io non ho scritto del brutto codice.Io non ho scritto del brutto codice.Io non ho scritto non sarebbe un problema produzionale, perché no.Saremmo tutti non staremo nessuno di noi sarebbe sarebbe un call, nessuno di noi sarebbe eh Paige eh al Red Notte per risolvere un problema produzione.Se scriviamo tutti quanti il bel codice.Eh però guarda sinceramente veramente poche persone vanno a leggere il codice scritto da altri per per sputtanarli, scusatemi il francese.Eh dei basi quando si trova un un problema è la "Boh, sta cosa qua si potrebbe migliorare per X, Y e Z" L'ho sempre trovata costruttiva, sinceramente Almeno nel codice Nelle issue, secondo me, invece è un discorso diverso Non so se mi avrebbe chidato, insomma, la issue che dice "Oh, l'ho aperta due anni fa, ancora navide fixata, siete dei perdenti" "Siete, non lo so, siete che schifo di società, o che schifo di progetto" La Leo potrebbe testimoniare le risposte di Matteo Collina, che sono fantastiche che fanno scuola dovrebbe farci un libro, no? LM: sì.LM: riguarda questo, volete qualche altra domanda su questo tema? O se non andiamo avanti? LM: no, io direi che possiamo andare avanti.FB: mi piace un po' rimbalocco per dopo.LM: ottimo.allora proporrei di entrare un po' nel vivo del tema del perché abbiamo diciamo oggi qua Giordano che diciamo un po' parte tutto da una parola che è observability e quindi direi cominciamo con che cos'è? Che dite? Qualcuno vuole dare una definizione o vado io? Se è arrivato tu sei apposta non è che non è che non è proprio questa cosa.Ma magari quando provare facciamo definisce un bingo e chi ci arrivava più vicino vinceva.Diciamo possiamo tradurre dall'inglese che è lo scelgibilità di quello che succede in in una cosa che probabilmente.Famo i guardoni del software.Sì.Esatto.In realtà è quello.In realtà è secondo me esattamente quello.Eh.Ma io dico da una dimensione un po' un po' un po' diversa dal dal dal punto di vista storico.Eh poi girava poi se si rompeva toccava capire perché si rompeva dopo un po' si è capito che che andare a cercare di capire perché qualcosa si rompe dopo che si è rotto non funziona.Tutto avrai di come una macchina, una macchina ce l'ha adesso centralino che ti dicono guarda che la temperatura del motore è troppo alta o via dicendo e secondo il software funziona allo stesso modo cioè da ingegnere da persona che fa girare un software quindi non solo lo scrive ma lo opera anche per operarlo al meglio devo capire effettivamente quello che sta succedendo in quello che che che che gira su in produzione ma anche in realtà anche prima e quindi observability è quel quel quel processo quel tool quel quella best practice.Metodologia? Metodologia, non lo so come definirla per cui io instrumento il mio codice, il mio prodotto, il mio il mio software per sapere in ogni dato momento quello che sta succedendo con quel prodotto, con quel codice.Quindi capire il consumo di memoria oppure capire quante richieste al minuto il mio servizio riesce a gestire o fare tracing del mio servizio per capire dov'è che qualcosa va lento o va storto o continuous logging per capire esattamente dove è successo nel lifecycle di una richiesta.Quindi effettivamente è smettere di vedere il software che gira come una black box e aprirlo, quindi fondamentalmente quasi una white box ed essere in ogni istante capaci di capire cosa sta succedendo.però è molto più veloce.È come insomma se tutti noi sui quaranta vedevamo la Formula Uno prima cioè era la telemetria che da fuori è una macchina va va più veloce va più lenta e invece anche quando uno si giocava a GP due o questo cioè era il consumo della ruota che era più quella a destra allora e adesso siamo a a quei livelli siamo molto in profondità quindi si perché la cosa è più in un giro dice la cosa è da cosa è difeso da dalla gomma però se non hai dati puoi solo supporre.Ma non solo.Eh.Ma non solo perché se tu non sai se tu non sapessi che la ruota è consumata e tu prima che la cambi magari vai a sbatte perché.Esatto.Lungo.Invece così magari la cambi prima che vai a sbatte.O magari la cambi prima che che perdi tempo in un giro per cui perché la ruota è troppo consumata.Esatto.E fortunatamente il software non ha la psicologia può anche essere, so, presumare una curva allora rallenta un po' perché si è caccato addosso, invece il software va sempre a diritto quindi è un po' più facile.Però si tratta di quello, ecco, guardare i dati live e capire come mai...Sì.Però a questo punto la domanda mi viene un immediata e la faccio partendo dalla prima mia esperienza con un sistema di APM, di Application Performance Monitoring, cioè la prima volta che ho visto o ho collegato un sistema di APM e ho iniziato a vedere la CPU quando andava a tappo, la la RAM, vedere cosa girava del mio web server, le chiamate al database.Ricordo ancora la prima volta che usai One Relic.One Relic, New Relic.One era il prodotto, però One era il prodotto più moderno, ovvero.va beh, New Relic si, era mindblowing quella cosa, perché pur avendo una semplice o due semplici virtual machine io avevo tutto sotto occhio e quello era venduto come monitoring.Oggi si parla però di observability.E che cos'è l'observability? Un modo nuovo per rinfiochettare il monitoring, è una provocazione la mia eh, per rinfiochettare il monitoring e vendercelo meglio o è veramente qualcosa di diverso? No, perché secondo me in realtà è diverso perché monitoring effettivamente è monitoring.Cioè io la vedo come una black box monitoring, no? Quindi come quello che diceva Leonardo prima.C'è una macchina che fa un giro in 40 secondi, quindi che fa monitoring sul tempo che ci mette la macchina a fare 40 secondi.Però poi perché ha fatto 40 secondi e non non è che tu vedi quello che succede con trentanove e allora fai observability allora cerchi di capire quello che sta succedendo dentro la macchina cioè tu attivamente vedi quello che succede eh dal consumo del carburante dal lo stato dei freni da passando non lo so per o qualsiasi altra cosa cioè monitoring è è è fare monitoraggio di quello che è un po' la parola stessa no? Eh monitoring.Possibilmente poi ovviamente reagisci, però è quasi passivo.LM: la definizione che mi sono sempre dato io riguardo a questa differenza è "fare monitoring è quando tu osservi una sola cosa".Cioè, osservi soltanto "sto monitorando questo dato", "sto monitorando quest'altro dato", che ne so, su dashboard differenti.Invece per me fare observabiliti e averle tutte davanti, capire come i numeri che variano da uno impattano sull'altro.Io non so giusta o sbagliata che sia, ma mi sono sempre data questa definizione internamente.No, ma è giustissima perché in realtà il monitoring è...De base si applica solamente a metriche.Quando observabiliti in realtà c'ha dietro log, c'ha dietro trace, c'ha dietro continuous profiling, c'ha mille altre cose.Quindi in realtà non è che guardi solamente il tempo.Guardi anche il log del motore che ti dice "alerting".Ah fai alerting.Alerting è una parte importante di Observability.Quindi si è log, tracing, profiling, metriche.Observability è tutto questo messo insieme.A me piace un sacco la definizione di Observability come più che una parte attiva, anche se trigger l'attività, mi piace proprio vederla come una caratteristica del sistema.Observability è il livello di trasparenza che ha il mio sistema affinché possa essere guardato da me e compreso profondamente.Magari con l'observability poi diciamo, cioè che il monitoring io la vedo come una cosa passiva per noi umani, mentre con l'observability puoi avere anche azioni automatiche tipo l'alerting che è un'azione automatica che deriva da un dato che comunque poi...Però quello ce lo puoi avere anche nel monitoring.io quando le richieste iniziavano a fallire, avevo l'alerting.Quello era monitoring o observability.Si, quello dicevo fa parte dell'observability.Se te vedi come monitoring solo errori e non prendi azioni, cioè quello è un monitor che ti fa vedere, questo è il monitor degli errori.Mentre magari nell'observability ci puoi anche mettere un'automazione.non è un'idea di che cosa succede? Non so, tiro a caso eh il la differenzione è nell' approccio io ho visto monitor come come un c'ho le mie dashboard, c'ho il mio so quanti quanti errori c'ho al giorno boh c'ho il report bomba ho fatto monitoring sto monitorando quanti errori c'ho al giorno observabili invece è è è quell'approccio per cui io indago quello che succede nel mio servizio quindi trasparenza quindi essere capaci di entrare dentro di però come observability è l'approccio in cui che mi permette di di capire di di di intracciare il perché di un errore non di capire di di sapere che è successo ma di sapere perché è successo e questo e questo credo che sia secondo me veramente la la la chiave di volta per darne una definizione.Un altro modo per comprendere eh l'observability di volta per darne una definizione.Un altro modo per comprendere l'observability può anche essere quello di andare a vedere le sue componenti, no? Perché rispetto al monitoring è un pochino più articolato e offre delle prospettive differenti.Allora la mia domanda è quali sono le componenti dell'observabile.Ad oggi si parla tantissimo di tre pilastri che sono metriche, log e tracing.Tracce? Tracce, però diciamo ormai hanno cognato questo tema di linguaggio comune.Metriche, log e trace.Metriche, ok, sono forse le prime che...anni 80 che forse si fanno metriche che sono servizi ma forse anche prima.Log, quindi in realtà è col collezionare log per poi vederli dopo.E trace sì, che forse è una cosa che magari è un po' più nuova per tutti quanti, che diciamo che è la traccia di quello che succede dentro il nostro software.Quindi la traccia intesa come, per esempio, se c'è un programma che composta di tre funzioni, esattamente la il tempo di esecuzione e quello che succede in ognuna di queste tre funzioni o tra micro servizi o tra micro servizi o anche tra front end e poi il servizio che viene chiamato è distributa distribuita distributa distribuita e capire nel complesso quello che è successo tra l'altro è molto figo perché per esempio io adesso sto lavorando in ambiente distribuito con un gozzilione di microservizi a layer N, un microservizio che chiamo microservizio, che chiamo microservizio, che chiamo microservizio, che chiamo microservizio in Java, che chiamo microservizio in COBOL, che chiama il suo database DB2 o quello che è.No, e alla fine tu vedi, vabbè COBOL lo tagliamo fuori però, che ne so, chiama il suo database Postgre e tu vedi tutto il percorso, vedi dove fallisce, come l'errore si propaga seguendo le traces e cioè fare debugging.Esatto.I giorni in cui facciamo qualcosa come quattro servizi, quattro incroci veramente e uno falliva e poi manualmente andata a capire perché, da dove veniva l'errore, se era un errore che veniva da una risposta o da una chiamata.Quindi poi "va a temerlo e te quello l'altro.Cioè, se c'hai una traccia di quello che è successo, boh, lo vedi subito.Molto spesso da, diciamo, sviluppatori software, noi ci concentriamo anche su software.Anche se abbiamo sistemi di allarmistica su quel software X, ma va a finire che il problema non è lì, ma è su un componente architetturale che sta vicino al nostro software.Quindi noi perderemo anche tantissimo tempo a indagare sul perché quel software non sta funzionando bene ma va a finire che è colpa che il bilanciatore, il proxy che gli sta davanti sta a tappo o non riesce più a fare io il database che sta sotto.Cioè sta roba è fuori di test.E poi sì, poi c'è stata un'altra cosa nuova, cioè nuova, non è nuova però forse un po' più nuova rispetto alle altre che è profiling.Adesso si comincia a parlare molto di continuous profiling, quindi non fare solo profiling in tempo a tempo di di sviluppo ma ma farlo eh continuamente.Quanto? Dovremmo tenere acceso XDebug in produzione.No, non è esattamente non è esattamente però in realtà sì, in realtà forse la puoi vedere come la puoi vedere così.Tenere acceso XDebug in produzione e raccogliere output live.E spendiamo un po' più in server a quel punto che tutto diventa un chiodo con XDebug.Non lo so, io sono fermo a tipo sei anni fa, no tre anni fa.No è ancora così, è un mattone ancora oggi.No no però ecco mi chiedo davvero l'impatto delle performance nel fare observability.Adesso la domanda sul profiling che hai detto mi ha aperto una domanda, cioè che impatto però non si ha mai avuto rispetto a eh questa cosa in termini di performance e quando è dove fare e overkill guarda a termini di performance eh secondo me dipende tanto se quello è lavoro tuo tra virgolette nel senso che che io diciamo che una volta non se non se faceva tanto non se colzionavano tantissimi log perché si diceva che costava perché c'avevi bisogno di perché era un problema che un servizio manda log da qualche parte perché se ogni volta che devo scrivere qualcosa da qualche in un qualche log devo anche occuparmi di di spedirlo che ne so a elastic eh è è un costo cioè faccio chiamate extra chiamate di rete extra e in realtà che è un è un po' un po' un falso mito nel senso che ad oggi io devo avere i prodotti come come Loki ma in realtà l' non è che si sta muovendo verso quale direzione? Eh il costo dello storage è diventato praticamente con S3 quasi nullo.No nullo no però è è molto ridotto rispetto a bo dieci anni fa.Immensamente ridotto.E quindi salvare log su S3 è fondamentalmente viene quasi gratis.E quindi quel problema se se vuoi è anche risolto.Secondo me.Eh dal punto di vista di performance però se tu fai un blog in maniera bloccante e fa l'upload su S3 per ogni chiamata che fai beh forse non sei signore forse forse forse non sei un uomo esatto.Esatto.Tu un blog lo scrivi, lo mandi su standard output, che sì c'ha un costo standard output, perché non è che è gratis.Però poi c'è un altro che se che te guarda lo standard output, li quindi se tu scrivi su S3 eh diventa diventa il costo non c'è quasi più.Se scrivi su file e poi c'è un altro processo che che legge quei quei file e rimanda allora sì eh il costo non non diventa più nel processo tuo.Però poi poi ci arriviamo eh scusa a me è venuta in mente una riminescenza di di di qualche lezione di fisica tra la scuola superiore e le università che diceva quando uno osserva un inevitabilmente modificato.Parlavano di quando vai a vedere fasce di luce e te per vederlo devi metterci le fasce di luce, le cambi, però non puoi fare altrimenti.Cioè è l'unico modo e dice ok accettiamo e stimiamo un errore e quindi, però altrimenti non possiamo non possiamo farlo.Quindi probabilmente i vantaggi che porta l'osservabilità li paghiamo con dei piccoli pezzi di performance se la roba è scritta bene.e questo mi dà un perfetto gancio a un'altra cosa che facevi l'esempio dei log però anche sul tracing, cioè instrumentare il concetto di tracing sulla mia architettura ha un costo, cioè devo andare ad aggiungere una logica in tutti i miei pezzi di software, che ne so se se ti arriva l'header "trace ID", "span ID" o "correlation ID" in base a come si chiama, prendilo e ribaltalo a quello dopo.Se non arriva, crealo.Questa è logica.E quindi, diciamo, questo è un po' l'approccio probabilmente anche un po' datato, che si cerca un po' di evitare se non utilizzarlo per casi specifici.e quindi voglio sfruttare il gancio per dire esiste qualcosa per automatizzare tutto questo per fare in modo che sia un po' agnostico il nostro software non abbia questa dipendenza forte con questo concetto? Guarda, intanto ci sono tantissimi libri e tantissimi linguaggi programmatici.Se vogliamo parlare di OpenTelemetry perché in realtà io penso che poi è diventata l'evoluzione naturale del dell'observability perché perché è una soluzione unica che poi permette di esportare in in lo so vuoi loghi vuoi per il log vuoi tempo per trace oppure vuoi stato elastic vuoi andare su snowflake vuoi andare su non lo so quello che ti pare a te veramente quindi permette di farlo c'è il tuo back end che ti pare a te in più ci hanno delle tantissime libri per tantissimi linguaggi di programmazione e framework che fanno auto-instrumentazione del codice.Cioè dal punto di vista stupido aggiungo uno span di una trace per ogni chiamata a funzione.Ma magari questa è esagerata perché magari non fai così.Però questo tipo di auto-instrumentazione c'è sta.Oppure il driver per database di base ha il fatto che se tu gli passi X quello genera tracce con con quell'X36D.In realtà molto spesso è built-in e se non è built-in ci stanno librerie che questa cosa qua la rendono molto facile.Sì per esempio con Node lui monca i patch come se non ci fosse un domani e poi alla fine ce l'hai praticamente built in.Ma se proprio non vuoi far così e utilizzi, anche se non dovreste, una libreria tipo Axios, giusto perché le sto usando OpenTelemetry in produzione proprio adesso, con Axios c'è gli strumenti datore di Axios stesso oppure eh installi Open Telemetry su Node ed è praticamente out of the box la cosa sì ma l'altra cosa potrebbe essere scrivere un middleware per Fastify che ogni richiesta genera una traccia e e tra l'altro ho visto una cosa fighissima al Fosdem proprio rispetto a a questo, che sono andati in brodo di giugiole rispetto sempre all'instrumentazione, che però non riguarda OpenTelemetry stessa, è Baila, che utilizza eBPF, uccandosi praticamente a il kernel e auto-instrumentando proprio il nodo completo.C'è una figata, mind blowing.LM: è quello che fa Dynatrace.DL: l'approccio è stato da tantissime persone adesso.LM: in molti ora stanno applicando questa logica che tu metti un agent sulla tua macchina e qualsiasi cosa gira in quella macchina o processo lui spacchetta tutto e ti permette di osservarlo.Sì, e poi è quello che facciamo con Grafana e OpenTelemetry.Grafana Agent, che adesso è stato rinominato, mi perdono a solo quelli da Grafana, non mi ricordo il nome perché è successo due settimane fa, una volta si chiamava Grafana Agent, che non c'entra niente con Grafana in realtà.Grafana Agent è una distribuzione di OpenTelemetry Collector, quindi può funzionare anche quella stick volendo cioè non c'entra niente con grafana per sé.Sì, è fondamentalmente un agente che gira su una macchina che colleziona log metriche.E come li prende queste queste informazioni? Li prende tramite i BPF o esistono anche altre fonti? No, le fonti le scrivi te.Guarda, io a Fosdeme questo anno ho fatto un talk, anzi in realtà due talk, su CI/CD observability, quindi l'observability prima che il software giri, quindi in CI/CD.La sorgente in quel caso qual è? È il tuo sistema di CI? Quindi è l'evento che magari GitHub ti manda con un webbook quando la tua che la tua build è completa.Ehm il il sorgente di di quelle metode, di quel log, può essere in realtà qualsiasi cosa.Può essere che tu leggi da un file, può essere che stai in ascolto su standard in, può essere che stai non lo so, cioè veramente io l'ho scritto un per una stupidezza che mi sto a fare un un agent che che prende le metriche dalle nano Leaf che che c'ho qua.Che mi fa metri, quindi in base alla luminosità dei dei Ranolif quindi in realtà può essere qualsiasi cosa lo puoi lo puoi posare per IoT quindi via Bluetooth pushi eh mediche su questa gente che gira su un Raspberry e puscia su Prometheus.eh il sorgente per se quello che ti pare se tu vai a vedere per esempio Open Telemetry Collector eh Contrib che è un repositorio di una distribuzione di Open Telemetry eh mantenuta dalla sorgenti quindi Receiver per S3 per Log file per MySQL per mille cose.Facciamo che noi siamo andati a palla su OpenTelemetry secondo me e ci siamo presi benissimo dalla cosa ma secondo me ha senso fare step back.Proviamo a inquadrare OpenTelemetry.Ok, allora OpenTelemetry è soltante cosa OpenTelemetry.OpenTelemetry è un progetto che che che cerca di definire quello fa tante cose, definisce uno standard, definisce eh il il wire format del del dato che passa sulla sulla rete, definisce tante cose, definisce anche dei dei nomi, dei della nomenclatura per per metriche e log ma di base a questo strumento che che vuole standardizzare, democratizzare la gestione dei log di di profile in futuro probabilmente anche no scusa profile adesso magari no però in futuro magari anche profile o migliaia altre cose è un tool è un progetto enorme che comprende varie varie cose tra cui un agente un agent questo per tre metri di collector comprende uno standard quindi definizioni su nomenclatura dei degli attributi di un log o degli attributi che vanno messi in una trace se si parla di database o la definizione di log trace o metrica.È un progetto che c'è un po' all hand compassing su cui vuoi definire uno standard, che poi sarà l'ennesimo standard ma in realtà questo sembra che sia effettivamente lo standard a quanto pare andando avanti.Per dare a noi sviluppatori fondamentalmente una cosa che ci dice lo di fà una volta e quello è e tu sai che se hai una traccia che genera il servizio tuo, se oggi usi Tempo, la vedi su Tempo, se domani vuoi ripassare elastico o splank o quello che è, la vedi su Splank.La stessa, non devi cambiare codice, devi cambiare la configurazione della gente.La Prometheus, quello che è.Prima hai citato un altro tema che suoniamo dopo in maniera approfondita che è quello dell'observer build sulle CICD.Ho letto un po' diciamo di articoli che sono usciti da Grafana, gli interventi che ha fatto al FOSDEM eccetera eccetera.Andando a lavorare diciamo in quest'ottica di Observe Partiti e con OpenTelemetry, ho capito che state cercando anche di creare una specie di working group per tirare su uno standard pensato ad hoc per le metriche di CICD.Ho capito bene? Sta andando avanti e così? Come funziona? Ah bomba, l'ultima volta che ci siamo parlati io e te, il working group è stato accettato e adesso ufficialmente fa parte Dopem Telemetry, è un working group ufficiale Dopem Telemetry.Wow, grande! Quindi non è stato proposto da noi, cioè noi come Grafana siamo stati tra i primi a far parte di questo gruppo pre-working group per definire questa cosa e c'è altra gente da tantissime altre altre aziende che sono interessatissime a questo a questo topic e e ad oggi il working group è stato ufficialmente accettato, quindi adesso stiamo lavorando sul definire questo standard e per standard intendo convenzioni semantiche, si chiamano in OpenTelemetry che sono queste convenzioni su attributi o nomenclatura da dare a metriche, log o tracce che nel contesto di CICD hanno un significato particolare che sarebbero dei contratti delle strutture dati? più che struttura data è proprio un ubiquitous language del domino.Esatto, è una convenzione semantica.Tu sai che se tu cerchi l'utilizzo della CPU, tu oggi sai che cerchi CPU usage.CPU usage è così in Prometheus, è così in Elastic, è così in altre parti.E quello che stiamo facendo noi è cercare di definire uno standard, un set di attributi, o di nomenclature, per cui Build Time è Build Time sia che viene fuori da GitHub, sia che viene fuori da GitLab, sia che viene fuori da CircleCI.E immagino che la vera guerra sarà su Job Time o Action Time.Esatto.Immagino che lì ci sarà una vera guerra per capire dove far andare a confinire la la nomenclatura? Eh potrebbe potrebbe in realtà non non non non non secondo me non ci sarà una tantissima guerra da quel punto di vista perché in realtà è molto è tutto molto molto astratto.Eh c'è build time e build time sia che sei in GitHub sia che sei in GitLab perché è la tua build, non è il tuo workflow, non è il tuo la tua action.Quindi è molto generica.Eh poi ovviamente la cosa interessante poi là è che eh ogni ogni quindi quindi che sarà nominata come punto sarà specifica perché non ci avrà senso solamente se usi GitHub.Eh poi eh GitLab ci avrà le sue.Però il standard di base è definito.Ancora no.Sarà definito.Grazie.Bocca al lupo.Per chiudere un po' il discorso OpenTelemetry, mi è parso di capire che ci stanno anche un sacco di SDK per qualsiasi linguaggio per andare poi a utilizzare questi standard? sì sì vabbè fondamentalmente sono quelle librerie di autostrumentazione che di cui di cui parlavo prima o autostrumentazione o strumentazione quindi c'hai SDK per PHP per Node per Java per C# e e fondamentalmente ci sono librerie che ti permettono di generare di scrivere queste metriche in maniera opportuna quindi magari metriche o logo o attributi di una traccia perché magari esportano funzioni che ti permettono di creare uno span o funzioni che ti permettono di creare un log o un connettore per Pino, un transport per Pino che butta fuori roba in OTLP, e pusha su un endpoint OTLP.Insomma, sono librerie che ti permettono di di strumentare il tuo codice.Prima di andare avanti Giordano puoi farci un esempio bello fatto e finito di applicazione per quanto semplice magari con un backend, un frontend, un database di un'instrumentation completa usando OpenTelemetry e nel nostro caso Grafana.Quali sono le componenti che entrano in gioco? Allora, in realtà poi, molto dipende dall'approccio, secondo me Però, diciamo che tu hai un servizio scritto in linguaggio, diciamo Go Facciamo butta su Go Che scrive log Su file Metriche E trace, perché deve fare tracing è solamente un servizio, quindi c'è solo un API, solo un back-end, partiamo dalla parte più semplice quindi l'idea di un'instrumentazione completa è che questo servizio generi dei log con dei grismi quindi che possono essere non troppi, non troppo pochi, quindi dove è giusto con un livello, con degli attributi tra cui il livello del log stesso quindi un log di debug, giusto attributo di level debug e qui sono la parte di logging Metriche, ci sono vari modi per esporre metriche, io sono un grandissimo fan dei Prometheus che ha un approccio un po' differente alla metrica che è pull based invece che push based è un approccio lì, in Google è facilissimo, anche in JavaScript, anche in Node, è semplicissimo esporre un endpoint che ritorna tutte quante le metriche per quel servizio.Quindi ProMedius può andare a fare pull da quel servizio.E sulle tracce è fare tracing.Quindi ovviamente con una libreria di strumentazione per Go o per Node, nel nostro caso per Go, è scrivere dal punto di partenza di una richiesta, generare una trace con un trace ID, e dopo generare span all'interno del servizio per tutta la durata del servizio.Poi se il nostro servizio ovviamente chiama altri servizi, si genera uno span per la chiamata a servizio 2, servizio 2 riceverà come header HTTP per esempio, span ID, e saprà già che span ID mettere nella sua traccia per far sì che poi, quando il nostro servizio di tracing, su back end ricostruisce il la traccia collega tutte le le gli span tutti i pezzettini come se fosse un puzzle e quindi a quel punto c'è un aggregazione un aggregatore che ti che ti fa vedere il servizio completo e come farlo sì ci sono librerie per farlo è una cosa può essere set up pare questa gente che fa che piano piano si va a vedere i log su quel file o su standard in o standard out scusa o su continuamente magari richiama quel endpoint e le manda poi da un'altra parte e via dicendo.Poi direi sinceramente non sono un espertissimo nel nel fa' ste cose.Io più che altro lavoro sulla parte opposta che è quella poi dello standard, delle definizioni su pentelemetri.Eh sì, in base a quello.Non so se te l'ha Sì sì assolutamente, tra l'altro mentre parlavi io stavo pensando a come fare tracing dentro l'applicazione React dove i componenti vengono rigenerati, richiamati come funzioni quindi stavo pensando siccome non l'ho mai fatto frontend, l'ho solo fatto a livello di microservizi mi chiedevo se come era possibile.Non l'ho mai fatto con frontend.non lo avevo mai fatto su frontend, nonostante io abbia fatto frontend da tanto tempo adesso a Grafana pure non l'ho mai fatto su frontend.Però abbiamo un nostro prodotto, non è che fa una marchettata qua, però c'è un prodotto nostro che fa esattamente questo, fa obessorabiliti su frontend.Anche perché poi là si apre tutto un discorso enorme che è il real user monitorings e ci sarebbe da parlare per ore.Prima di passare di nuovo all'altra parte, volevo chiederti una cosa riguardo agli eventi.Mi è capitato di incrociare delle discussioni in termini di observability, nel caso specifico era con OpenTelemetry, dove si parlava di utilizzare o non utilizzare dei domain events, di utilizzare l'observability per monitorare dei domain events.Qual è la tua opinione? Perché là la community è un po' bipolarizzata.guarda in realtà sono sincero io non l'ho mai visto sto problema quindi mi sono un po' nuovo se ti chiedo ti chiedo la mia opinione oggi che la che la sento per la prima volta se vuoi secondo me l'observabilità risolve un problema se tu secondo me ti senti che fa che monitorare degli eventi quel tipo di eventi ti può forse risolvere un problema, fallo.Cioè, secondo me è giusto che tu lo faccia.Quindi l'observability di un sistema può anche non essere strettamente tecnica, può anche essere di dominio o di business.Beh, quel progetto di cui parlavo al FOSDEM, in realtà che si chiama CDObservability, non è tecnico l'observability, è un tema...Infatti era una provocazione per portarci a parlare là.esatto esatto.Io sono d'accordo, secondo me è sacrosanto che tu risolva il tuo problema con l'observability.Sì no perché ho visto delle battaglie pesanti sull'argomento quindi ho detto.Quindi diciamo che possiamo affermare che non è soltanto una metodologia che va a servare a livello architetturale o applicativa ma anche a livello ad esempio, con il discorso appunto di sia il CD di un team.Domanda retorica, no? Perché possiamo dire che è importante prendersi cura anche delle telemetrie, delle proprie pipeline per migliorare la developer experience del team che lavora su quel software? Secondo me assolutamente sì.Da qui mi viene anche la domanda, C'è il fantastico lavoro fatto da te e i tuoi colleghi, che problema voleva risolvere? In realtà tanti.Esatto, perché siccome è molto interessante quello e poi ovviamente con un dev ex come me mi triggera un sacco questo tema e quindi volevo portarlo sul tavolo.Quindi vai, sono super curioso.Ok, allora, guarda, tutto è nato...Stavo...Umbriachi, io ho questo collega mio a Nizza, è nato là, davanti a...Già mi piace.È nata così, un anno fa.Si dè nata così un anno fa.E...allora, il discorso è questo, secondo me, che log, metriche, tracce, sono strumenti, ok? Quindi poi sono nate perché sono nate per il monitoraggio del software che gira.però secondo noi a quel punto c'era un gap cioè tu fai monitoring delle observabilità del tuo servizio in produzione però tu non hai cognizione di quello che succede prima dal deployment alla fase di test alla CI e ti dico una cosa secondo me tu fai monitoring del tuo servizio in produzione ma la CI quello che ti permette di fare il deploy poi in realtà è uno dei tuoi servizi di produzione perché senza di quello tu non vai in produzione tu non rilasci se per rilasciare un servizio che sei rotto ci metti 40 minuti non è il tuo CI system che è rotto è il tuo servizio che è rotto il tuo CI system è un prerequisito la tua per il tuo production.Quindi tu dici puoi avere il sistema di allarmistica più figo del mondo che dopo 30 secondi riceve la notifica, hai capito il bug, lo risolvi proprio se c'è un sistema di sia idea merda che ci metti tre ore a portarlo in produzione e non hai risolto niente.Esatto esatto lo sai e poi lo sai e poi ti metti a crociere le mani e stai a posto perché non lo puoi risolvere.E guardi la pipeline.Esatto e sta cosa è andata là perché noi abbiamo non c'erano.C'erano.C'erano.C'abbiamo.Eh adesso magari abbiamo migliorato molto la situazione.Eh anche grazie a sta cosa.C'abbiamo magari test, fleghi test ovunque perché poi c'è i fleghi test sono sotto i buglizzi antipatici a Natale.Ci avevamo tutti.E ci sono sempre non solo a Natale.Esatto.Esatto.e niente eh ci abbiamo fleghi spesso capitava che facevi una PR, i test passavano, abbiamo una branch da cui facciamo deploy e quella build su quella branch non passava.Perché? Il test è lo stesso, il codice è lo stesso.E era a quel punto poi che succedeva che l'ingegnere che stava di turno a dove fa il deploy passava tre ore a cercare di capire perché quel test falliva, chiami l'altro team, disabilita il test test se non si ha e perché perché non non passa sulla branch dell'introduzione.La rilascio invece che dura 20 minuti che dovrebbe essere fondamentalmente yarn build e go package diciamese tre ore e non funzionava.E quello che volevamo fare noi era avere un sistema per cui quando una build falliva, un test falliva, devi saperlo nel momento in cui fallisse, non nel momento in cui dovevi fare il rilascio e ti accorgevi che quel test falliva.Quindi non è la visibilità, è quel tipo di è invece la visibilità nel tuo nel tuo processo di sviluppo.Eh ma il test è un esempio, potrebbe essere come il test, potrebbe essere la la performance delle delle delle dove si hai.Perché magari oggi aggiungi un test che fa hm fa in crisi, fa aumentare il tempo de build eh di cinque secondi.Domani altri cinque.Tra tre settimane so, venti per esempio se tu hai due macchine per settimane tu invece che che fanno un rilascio in venti minuti ce ne metti quaranta.Ok? Oppure semplicemente anche il discorso di che macchina utilizzi per far per far la tua build.Magari ti accorgi che se passi da una micro a una small su eh AVS invece che che metteci venti minuti ce ne metti dieci e e magari la bolletta invece che costate un però se tu fai un'ottanta centesimi perché perché utilizzi in totale meno risorse perché è anche quello è anche il il prezzo che paghi per fare quelle build o di rida dal tempo che che che ci mette o sì Dora Matrix eh infatti stavo per dire sento proprio puzza di di Dora di Dora.Eh Dora è un'altra decanta decanta.Quanto ci che è che è cascato che che si è rotto.E se tu non lo sai quanto ci metti non non lo potrai mai sapere.Cioè lo devi andare a vedere a mano.Vedi se c'è un sistema per cui fai osservabilità sulla tua sul tuo processo di rilascio o il tuo processo di sviluppo tu sai anche quanto ci metti da momenti in cui ti crei un incidente a momenti in cui il servizio è ristorato e quindi puoi garantire c'è c'è visibilità sulle tue eh sla o su S SLO.SLO.Esatto.Quindi su quello sai quello che può promettergli enti che certo che spesso fa differenza fra fa un contatto da milioni o non chiude l'affatto gli amici che ci ascoltano vuol dire un po' quale sono le queste quattro tore le raccontate con il discorso che è molto bello però diciamo maniera più puntuale allora io non è che mi ricordo tutte le pensioni perfetta però però eh aiutatemi se se se se se mi rimentico qualcuno.Vai.Una è la median time to recovery che è il tempo la media il tempo medio per ristorare un servizio che che corretto.Che che cascato.Grazie.Un'altra ehm ehm quindi il tempo che ci per un commit da essere fatto a arrivare in produzione.Un'alta deployment rate, deployment frequency, quindi ogni quanto riesce a fare il deploy.E l'ultima è failure rate.Madonna quanto sono bravo.Applausi.E quindi Feliorezzi, quanti deploy risultano in un servizio fallito? Quanti rollback sono stati costretti a fare o quanti incidenti? Esatto quanti incidenti sono stati segnalati.Ragazzi pensavo una cosa mentre Giordano parlava, ma magari può essere un'idea per il prossimo progetto legato a questa cosa andrà a finire nel quadernino dei site project abortiti in quasi tutti i casi d'uso di cui abbiamo parlato parliamo di monitorare delle esecuzioni che sono prevalentemente automatiche vedasi la pipeline, vedasi l'esecuzione dei microservizi qualcosa che noi osserviamo e mentre tu parlavi di pipeline a me è venuto in mente proiettare lo stesso, di proiettare la stessa osservazione su quella che è la nostra attività nei repository che ne so immagino monitorare il tempo per le review oppure monitorare il tempo da review eseguita a rilascio o a attivazione o merge ok monitorare la lunghezza delle conversazioni e quanto il numero di post di messaggi per tempo incide sul tempo di rilascio ma ragazzi non non siamo nel mondo del business analytics, ok? Siamo in quel mondo...io vivo in una famiglia dove mia moglie è una big data engineer ieri ho fatto le pizze e in casa c'erano due business intelligence, un altro paio di ragazzi che fanno dashboard su Qlik e Tableau quindi alla fine lo respiro fondamentalmente non è quello che l'industria già fa e che noi già facciamo con l'industria e che solo adesso ci stiamo fermando a dire "Ehi, forse il caso che ci fermiamo un attimo è come il calzolaio che ha sempre le scarpe bucate, esci che ce le ripariamo".Esatto, secondo me è impossibile.Non sono così convinto perché sono diversi punti di osservazione con diversi fini.Qual è il problema che vogliamo risolvere? Vogliamo realizzare qualcosa a partire da dei numeri? vogliamo migliorare un flusso, vogliamo essere più produttivi e quindi diciamo cambia il goal, cambia il goal secondo me.Il goal è prendere delle decisioni per il miglioramento continuo.Esatto.Fondamentalmente possiamo generalizzarlo in quel modo perché per esempio il progetto di di cui parlava Giordano, no? Delle delle del monitoraggio della CI ha un approccio o comunque l'informazione che lui tira fuori sono informazioni di tipo ingegneristico però molte di quelle informazioni che vengono da quell'osservabilità sono anche di tipo manageriale.Guarda secondo me il discorso cioè le Dona Matrix sono molto ingegneristiche tra virgolette ma specialmente lì Time for Changes quindi il tempo che ci mette un commit arrivare in produzione.Quello sì è un è ingegneristico perché dipende anche da quanto ci mette la CI ai test a passare, quanto ci mette la build a essere eseguita, quanto ci mette il deploy a essere effettuato.Non ci mette la review perché ci sta anche il tempo di di review.Esatto, include la review, include se vuoi la velocity dello sviluppatore che dopo aver mai reviewato deve fare dei fix e pusharli.E fa parte della review in realtà.Quindi sì, secondo me è un tool per migliorare.E ti dirò una cosa in più.C'è una cosa che ho parlato con un ragazzo riguardo a questo, un collega, che mi diceva "Ma in un coincidente pericoloso cioè io dal momento in cui comincio a essere monitorato effettivamente sulla mia velocity perché andiamo a finire su quel settore cioè adesso c'è un tool che misura quanto codice scrivo quasi, quanti deploy faccio a settimana io sviluppatore o quante PR ho fatto in un mese le posso comparare facilmente con gli altri del team mio.Non comincia a diventare uno strumento pericoloso per cui io comincio a dialogare con lo strumento.E qui c'è sta c'è sta una discorsione da aprire perché se secondo me se tu ti senti in pericolo da sto strumento secondo me c'è già qualcosa di sbagliato a prescindere.Perché dovresti avere più paura.Esatto, c'è già una red flag in azienda.No, semplicemente il valore che stai generando o ne stai generando poco o il management non l'apprezza per cui già sei fortunato, cambia lavoro, cambia azienda.No, però questa cosa è una cosa che spesso sento, è un sistema di monitoring per il lavoro che faccio.In realtà no, è un sistema per far sì che il lavoro che fai è ottimizzato.Cioè io preferisco che tu, dipendente mio, spendi venti minuti a guardare video su YouTube che quaranta a guardare una pipeline.Perché se quella pipeline non è ottimizzata ce la fai a mettere cinque.L'altro di quindici, vai a tappare dei video su YouTube perché dopo sei più produttivo.Certo, va a dare un talk, che ne so.Sì sì.E tra l'altro io vi posso dire una mezza giornata spesa a fare il rerun delle pipeline mi stanca più, mi stanca più che un'intera giornata a scrivere del codice.Io credo che, non lo so, quando non faccio un cazzo perché sto dietro alle pipeline, sono molto più stanco che quando faccio le cose.Anche perché poi se sei uno con un po di adhd come me La pipeline ti runna tu prendi un filone poi ci ritorni dopo un'ora la pipeline magari aveva già finito a un quarto d'ora Perché poi secondo me penso che 90% dei sviluppatori quando fanno la serie dicono "no la guardi" cioè il pulsante auto merge quante volte lo premete voi? spesso il più possibile Però poi non lo vai a guardare comunque.Io magari non lo premo, no? Però quando lo premo, io comunque sto a guardare se poi viene emergiato o no.Quello sì.Quello sì.No, io per quanto riguarda la pipeline, qualche tempo fa mi feci proprio un'estensione del browser che se la pipeline falliva ricliccava il pulsantino.E' arrivato.Sinceramente io lo faccio soltanto per ricevere l'email di notifica che è stata mergiata, perché quando devi mettere la cosa auto-merda arriva l'email.E poi basta con queste email di notifica che ne devo cancellare 700.000, la pagassa di GitLab! Vabbè io ho proprio la cosa sul cance fisso, il picchio proprio.se ti dovessi scrivere un plugin per browser che ti facesse ripartire i test, forse è il caso che...è il processo che è sbagliato, non è...magari si può essere risolto al monto il problema, cioè magari risolto no, però magari non ti portava a scrivere un plugin per browser che...no, bastava marcare come fallibili quei test, è fine, cioè alla fine...oppure toglierli, se sono flechi non devono star là, punto.Lo zio antipatico alla cena di Natale, è difficile a togliere, specie perché è il grande amico di tuo padre e metterlo alla porta è un po' un casino.E quindi dobbiamo talvolta essere democristiani nel contesto nel quale ci troviamo a lavorare.Io guardavo l'orologio e siamo già a un'ora e mezza e per me stiamo iniziando l'episodio di oggi quindi facciamo un giro rapido a questo punto.Andrea e Leo se avete qualche altra domanda? Io no.Ma io lancerei il momento donatori intervallo per spezzare così ci viene in mente una cosina e poi rigiochiamo dai.Allora allora sì allora a questo punto mi hai preso in realtà in contropiede perché non ero pronto però eccomi.*musica* Ecco la nuova sigletta del momento donatori ringraziamo chi ci sostiene chi fa sì che appunto questo episodio possa arrivare alle vostre orecchie.Io sto temporeggiando perché sto provando ad aprire la dashboard dei donatori che si è appena aperta perché in realtà oggi...Donatori che ci aiuteranno a pagare Fastlane per il certificato SSL, Aruba...merda...per la gestione del hosting di questi servizi, più ovviamente altri mille servizi dove c'è il billing.Mauro potrei parlare a dirotto? Io sto soltanto aspettando che trovi la dashboard.No, è aperta.Perfetto, via.No, è vero.Allora, facciamo questa cosa, chiariamo questa cosa.Io ho spostato su Aruba non perché sono coglione, anzi sì, un po' sì.Se c'è qualcuno che lavora ad Aruba aiutatemi per favore, perché non mi fa settare i namespace di Netlify, quindi non lo so.Però detto questo, le ho spostati perché Namecheap, che era il mio provider, non mi faceva registrare i puntui.Non so perché prima utilizzavo Toppost, però con Toppost ho fatto un casino praticamente, avevo un account a nome di un cliente mio di 15 anni fa dove c'era la mia mail, le mie informazioni, la mia carta di credito, però il nome, il cognome e la partita erano di questo cliente che nel frattempo è deceduto e mi sono cagato addosso, ho paura di perdere tutti i domini quindi ho detto aspetta che gli sposto però top post non mi faceva registrare un nuovo account con l'email che era già registrato un'odissea detto questo detto questo io vi ricordo che potete sostenere github direttamente dal sito www.github.it non trustable ma tanto vi rimanda col pulsante di donatore una pagina trustable dove potete farci dove potete supportarci cosa che ha fatto Livio per l'ennesima volta tra l'altro Livio è uno dei nostri supporter affezionati.Grazie Livio.Tre birre, ben tre birre, scrivendo "ciao ragazzi messaggio breve ho finito di ascoltare tutte le puntate e ora sono in pari contenuti veramente preziosi continuate così" cioè tutte le puntate tu hai ascoltato 191 puntate? L'ho fatto anch'io e ammetto di sentire anche le puntate che registro, perché voglio sentire come suona due e mezzo per.Papirino, no Livio davvero grazie perché con questo piccolo contributo comunque ci aiuti a sostenere le spese che sono tante.Se voi sapete Gitbar è gratis ma non senza costi e il vostro contributo ci aiuta a sostenere le spese di abbonamenti ce ne sono un gozzi di io non voglio, mi sono imposto di non voler fare il recap delle spese annuali di Gitbar perché il giorno che io lo faccio probabilmente smettiamo di registrare Gitbar.E in una puntata dove si parla di observability questa affermazione suona strano.Non voglio farlo, per adesso molte di queste spese sono ancora sulla carta di credito di mia moglie.Ma detto questo...Lei non lo sa! Non parla italiano! Detto questo vi ricordo il modo per sostenerci come vi ho detto direttamente dal sito supportaci o con i modi del podcasting 2.0 quindi se avete un'applicazione moderna di podcasting 2.0 come Castamatic, come Fontan, avete la possibilità di inviarci dei Satoshi, Satoshi una frazione di bitcoin che ci permette da una certa prospettiva di supportarci, dall'altra attraverso il Satoshi Stream potete fare in modo che ogni minuto di episodio possa donare 1, 4, 10, 20 Satoshi per minuto ascoltato che sono veramente una frazione di centesimo ma ma che ci aiutano a capire quanto state apprezzando il podcast perché vediamo che parte insomma degli episodi ascoltate e poi se c'è un momento clutopico che vi piace particolarmente o che vi fa incazzare tantissimo potete fare un boost e allegare il messaggio e in quel caso lo leggeremo negli episodi successivi.Detto questo però supportarci non è solo darci soldi.Sentivo un episodio di un podcast, del podcast di podcast index, no forse pod news, vabbè, dove si parlava di supporto a un podcast attraverso le 3T e voglio portarlo su Gitbar perché è molto molto importante.le 3 t sono time, talent e treasure voi potete...che cos'è questa cosa? è la telecamera del mac che mette le emoji mette le emoji quando? ma sì, ma mi ha bloccato tutto non è abbastanza ram per farlo Vabbè, dicevo...Ma vaffanculo! No, tra l'altro non sto usando la cam, sto usando la telecamera, quindi boh...Non ti preoccupare, vai avanti Mauro, mentre giochiamo...Io non me ne ricordo...Con le reaction...Allora, introduco io, bitcoin è andato all time high questa settimana, ma i satoshi sono un centomilionesimo, ma i satoshi sono un centomilionesimo quindi nel senso non potete donare senza non influiranno sul vostro portafoglio.Specialmente se avete azioni della invidia ora siete ricchi e quindi potete donare a Gitbar per risolvere tutti questi problemi che abbiamo.Esatto e se investivate in Amazon nel 94 adesso sareste milionari e sicuramente non ascoltate Gitbar.Poi se invece vi siete persi le password della vostra chain piangete insieme a noi e fine.Stai parlando di me? No, di chiunque si sente a feeling con tutto questo.Io sono stato uno dei pochi coglioni che ha creduto in Mountain Gox.Hai cambiato camera nel mental brain? No, ho dovuto riavviare la camera perché Mac ha fatto crashare tutto con quel cazzo di simbolo.Vabbè, fammi mettere un marker che questo pezzo lo taglio.No, no, poi se ti vai a vedere il montato è bellissimo.E dicevo, cosa sta? Ah, Time, Talent e Treasure.potete o donare come vi ho appena detto oppure regalarci il vostro tempo e il vostro talento.Due cose rapide.Il problema del dns che dobbiamo risolvere ci farebbe piacere avere una mano per farlo.Qualche bug fix all'interno del sito ci farebbe un piacere...minchia non ce la faccia farcela oggi, ci farebbe piacere riceverlo.E non ultimo, io sto terminando la trascrizione di tutti gli episodi di Geekbar.Questa è una cosa interessante, perché se c'è qualcuno che si diverte con gli LLM, io probabilmente farò un piccolo scriptino per calcolare gli di praticamente tutto quello che abbiamo detto, è fare un sistema di ricerca un po' più evoluto della ricerca per parola.Quindi se qualcuno ha voglia di metterci un po' di effort, noi siamo qua, contattateci, non vi è email che non funziona, ma contattateci.Non andate sul sito HTTPS, scriveteci sul gruppo Telegram, cercate Gitbard.it su Telegram e ci trovate, c'è il bel faccione di mauro trovate giallo arancione la picchia entri vai no vi faccio una domanda a questo punto tiro via il sito da da roba dove lo metto mi serve solo un dns versi al free ovh no ma il sito è già su netlify mi serve proprio il dominio punto hit godetti mi sa che facciamo godetti Ma ci stanno mille! E potremmo continuare la lista e nessuno di questi ci vorrà dire "vate la do gratis!" Non ci sponsorizza nessuno! "Faccio io l'hosting!" Hai svelato la cosa! No, detto questo io direi che a questo punto vi chiedo se avete qualche altra domanda.Sì, vorrei chiedere a Giordano, c'è qualcosa in tutto questo macro tema che non abbiamo toccato al tavolo e che invece volevi toccare? Per le serie hai tu una domanda? però non è una domanda o un tema.Chiara la stessa domanda volevo farli io ora eh.Guarda sai che c'è in realtà sto discorso open telemetry è talmente ampio che che ce ne stanno de cose che non abbiamo toccato eh ma tante eh quindi dittene una eh diventa pure difficile però E rimandiamo alla prossima puntata, ci riaggiorniamo in futuro quando questa tecnologia magari sarà andata avanti o quando sarà davvero uno standard.Questo è tipo un tema no? Secondo te, visto che stai in mezzo alle commissioni e ti sei seduto a qualche tavolo di qualche working group, quali sono i sentimenti? Alla CNCF, ok, se fa qualcosa, se si ha una data di previsione, cioè già il fatto che tutto questo, sta dentro la CNCF, fa ben sperare.Però diciamo, anche lì ci stanno diversi stage di livelli, se non sbaglio, prima di entrare, poi approvazione, poi davvero ufficiale, poi di… non so se rientra in qualcosa tutto questo, la lentezza che possa diventare stata, o è perché la industria, ci sta talmente tanta competizione e quindi deve sfondare spallate i competitor per diventare lui il leader dello standard.Guarda in realtà proprio oggi o ieri, ma comunque questa settimana, è stata aperta come proposta quella di far diventare OpenTelemetry un progetto graduated della CNCF.Prima era in incubating, cioè fino a praticamente oggi era in incubating.questo significa che a livello di progetti cncf è avanti perché il 90% sono incubating o sperimentali e questa è tanta roba dove siamo noi col working group per sia cd è ancora molto presto perché siamo stati approvati come come come working group per per questo due due massimo che facciamo per Altana, che facciamo tre settimane fa.E ancora molto presto.Sì.Il lavoro che facciamo per Altana è è il lavoro che de base è da parte della community.Cioè io faccio sta cosa con con Grafana lavoro con Grafana e però a Granada faccio altro.Questo non è lavoro mio.E il discorso qual è? Che sta cosa ci serve a Grafana e e un po' di tempo di Grafana lo dedico anche a questo.Eh però ecco è il una cosa è se avete problemi se ci avete idee se ci avete se volete partecipare perché poi open source quindi c'è chiunque ma anche solamente per capire quello che stiamo facendo per capire dove stiamo andando cf c'ha uno un gruppo slack cercate canale il canale che si chiama hotel che è il nostro email trattino CICD e oh benvenuti.Se c'avete problemi.Metteremo link nelle note dell'episodio a voglia.Sì se c'è qualsiasi cosa che dubbio idee accettatissime stiamo veramente all'inizio stiamo definendo le prime cose stiamo lavorando sui primi delle prime integrazioni con GitHub, GitLab, eccetera e drone quindi qualsiasi cosa se volete iscrivervi voi il vostro collector che si interpreta per Jenkins che c'è un plugin in realtà ma è prima di questo working group venite, dateci una mano, ci farebbe molto molto comodo ma ancora, anche se lo sentite quello che ci ha l'età di, è il problema vostro c'è che dovete definire lo scope del problema Sì, io volevo...mi sono dimenticato cosa volevo dire in realtà, cazzo oggi non è Zeku 1? Boh, me ne sono dimenticato.Ah! Volevo dire...No, volevo dire una cosa riguardo gli standard, che secondo me ha senso che non si corra quando si fanno gli standard.Ha proprio senso prendersi il tempo, ragionarci per bene sulle cose, anche perché gli standard poi devono diventare qualcosa di ossificato, qualcosa di difficilmente cambiabile e per arrivare a quel livello c'è bisogno di un percorso lungo e questo è l'unico modo per non arrivare nella condizione di dover rilasciare un altro standard perché ci sono troppi standard.Vero? A questo punto il paese dei balocchi, il momento nel quale i nostri host e i nostri guest condividono con noi un libro, un film, un video, un giocattolo qualunque cosa abbia catturato la loro attenzione pensino sia utile da condividere con la nostra community.quindi Giordano la mia domanda è hai qualcosa da condividere con noi? e conduco nel paese dei balocchi ah il paese dei balocchi vai pure ok ci pensavo che proprio parlavamo in realtà visto che poi siamo andati su OpenTelemetry forse la intro migliore OpenTelemetry e perché l'observabilità è importante e perché sarà il futuro è un libro di Ted Young che è uno dei co-founder del progetto che si chiama "The future of observability with open telemetry" poi penso che metteremo anche il link il link eh certo ovviamente sì mettiamo il link nelle note dell'episodio.Sì eh il libro in realtà dà un un un primer su su cosa e perché observability grandi linee e in realtà risponde alla domanda che mi hai fatto prima tu Mauro eh che fondamentalmente è come una funziona.Una pipeline moderna, come funziona end to end.Questo indipendentemente poi dal tool di osservabilità che utilizzi o dal linguaggio.Quindi se siete interessati a quel mondo, che è un mondo enorme, questo libro sì, è tanta roba.Un innesimo libro raggiunto al mio backlog delle vacanze io credo che dovrò prendere tipo tre anni di sabbatical per leggere tutto.Vai tu Luca? Sì, vado io.Allora io ne ho due, uno è anche in tema, quindi rispetto a quello che propongo di solito.Allora parto dal primo.Il primo non è in tema, è un tool che ho scoperto nell'ultima settimana, è un'applicazione per App Store, per iOS, ma si può trovare delle cose analoghe anche su Android, si chiama Web Proxy Tool, praticamente è un man in the middle per sniffare le richieste HTTPS che fanno le vostre applicazioni verso i vostri server.A cosa mi ha servito? Mi sta servendo per fare un reverse engineering dell'app della palestra per automatizzare la prenotazione dei corsi e delle sale perché non riesco mai arrivare in tempo e non mi voglio mettere i reminder.Alcune applicazioni si accorgono che c'è un proxy nel mezzo quindi non funziona con tutte però con questa che sto usando funziona e ti permette di vedere le richieste HTTP con tutto il payload, le risposte e da lì uno si può creare la propria comandata di attrazione per chiamare API remote e anche vedere quante canale di altri servizi vengono chiamati da una semplice applicazione di una palestra.L'altro che mi è venuto in mente durante la registrazione di questa puntata è un talk che è stato fatto all'Open Source Day a Firenze la settimana scorsa su come monetizzare un progetto open source e abbiamo toccato alcuni argomenti anche perché questo speaker internazionale lavora per Grafana Labas e quindi ha parlato proprio del modello di Grafana, quindi mi sembrava molto in tema.Vi metterò un link alla live che dura 8 ore e 40, ma ve lo metto appena inizia la presentazione di quel talk, così non mi faccio imparare.Questi sono i miei valori.Andre? Allora io, come sapete da grande amante di Developer Experience, diciamo abbiamo toccato l'Edora, abbiamo toccato e parlato di Grafana, non posso non citare una delle piattaforme alle quali mi sono avvicinato di recente che è DevLake.DevLake è un progetto open source di apacito.org è bellissimo lo stiamo studiando a fondo ci stiamo tenendo su un poch internamente abbiamo contribuito anche al software open source non è altro che semplicissimo come archettura un pezzo di demone che fa gathering e screpi da tutte le piattaforme che hai in azienda e poi ovviamente ti mette davanti un bel grafana che ti permette di andare a leggere tutte queste metriche che vengono storate in un database.Ovviamente è già predisposto per attaccarsi a Jira, GitHub, GitLab, Bitbucket, tira fuori già informazioni sulla qualunque basso livello di amministrazione, dìgli quali sono i repository e poi ovviamente è onere tuo andarti a graficare appunto tutto quello che tu vuoi osservare.Il discorso che facevamo prima non soltanto riguardo a Ledora ma appunto il discorso anche di CI/CD, capire i flussi e capire appunto dove andare a tensionare e intervenire per poter migliorare il livello di produttività del proprio team, osservando tutto dall'alto.Questo è il mio.Mauro? Figo se riuscissi a sbloccare il microfono potrei anche parlare.No, bello! Tra l'altro ricorda un po' probabilmente Lake viene proprio da Data Lake ed è un approccio alla gestione di di quei big data.Figo! Ci butto un occhio.Io ne ho due.Allora, il primo è il podcast di Hussein Nasr.Backend Engineering.È un podcast, in realtà, Hussein Nasr non ha questa voce spigliatissima, è freschissima, quindi rischia di far addormentare talvolta.Ha un bellissimo corso su Udemy sul back-end development che proprio tocca le basi di quello che è il back-end development da come funzionano i database fino a una chiamata HTTP.Quindi è molto molto bello.Però oggi voglio parlarvi dell'ultimo episodio che ho sentito sabato mentre facevo la spesa e che parlava di come si è riusciti a migliorare la performance delle chiamate dirette, chiamate dirette in generale, non voglio addentrarmi sui tecnicismi perché non sarei in grado di spiegarlo nel dettaglio, insomma di come è aumentata la performance delle chiamate dirette cambiando solo la disposizione dei valori all'interno, dei nomi dei valori all'interno di uno struct, di una struct di C.Cioè mettendo un nome prima dell'altro, una proprietà prima dell'altra, ok, in quella struct si riusciva a bustare la performance e si riesce a bustare la performance del 40 per cento.Lessi un articolo simile su un improve di performance su javascript sulle proprietà degli oggetti tantissimi anni fa quindi non sono nemmeno trovare i link però ero così a dirlo ma davvero si è una di quelle cose mind blowing quindi vi metto il link nelle note dell'episodio...a parte quello voglio condividervi un altro podcast di un italianissimo si chiama Marco Ieni e ha un podcast bellissimo che si chiama Rust Ship.Se non l'avete seguito e vi interessa Rust mi raccomando seguitelo perché l'ultima sua puntata dove parlava di Rust Nation, che è la più grande secondo me conferenza su Rust al mondo, ci sono un sacco di cose interessanti proprio sul concetto delle conferenze, dei talk, quindi seguite il podcast di Marco che tra l'altro saluto.E nulla questi sono i miei due Balocchi di oggi.- Nani? - Siamo arrivati alla fine.Sono due ore esatte.Naturalmente qualche pezzo lo tagliamo.Andrea! Facci vedere, parla così così almeno la telecamera cambia l'inquadratura.- Allora, volevo parlare così da poter inquadrare questa fantastica t-shirt per commettere l'ultima marchettata dell'episodio e poi chiudiamo ragazzi andate nello store di Gitbar andandoci in HTTP anche lì poi ovviamente il click vi porterà su un'altra piattaforma che sarà Trusted per poter acquistare questa fantastica t-shirt in due colori questa blu e rossa se non sbaglio Offerta speciale come direbbe Roberto Il Baffo.No, abbiamo il nostro store con le magliette, per ora ce n'è solo una, quella di video terminalista metal meccanico, per chi ci stesse ascoltando solo audio.Come diceva Andrea, ce n'è una rossa e una blu.Rossa con la faccia al martello forse non è il periodo storico per poterla mettere.potreste donare delle grafiche che noi validiamo e mettiamo nello store e quello è il talent dell'E3T no? esatto esatto dita t-shirt tra l'altro quindi il collegamento è proprio...c'è un movimento da 4 in un attimo esatto come la t-shape di cui abbiamo parlato all'inizio ragazzi dobbiamo fare un puntatone tutto collegato E' a quest'ora che si iniziano a vedere i mostri, quindi dobbiamo chiudere ragazzi.E infatti sì, ci avviciniamo in chiusura.Io ringrazio Giordano per essere venuto oggi a trovarci qua nel nostro bar.Gitbar come diciamo sempre è tipo un po' il circolo del dopolavoro postale degli anni '70, '60-'70.Tu lavoravi tutto il giorno alle poste o alle ferrovie, finivi di lavorare e ti schiantavi nel circolo a bere i Knus o per ovvio la '66.Tra l'altro circolo dove per entrare serviva una tessera e tu la prima volta che entravi entravi, ti facevano la tessera e quella tessera la utilizzavi tutte le volte che entravi, ecco perché diventavi in parte, in piccola parte, proprietario di quel circo.E oggi tu sei in piccola parte proprietario proprio di Gitbar, per cui quando c'è qualcosa nuova, qualcosa che ti fa piacere condividere con la nostra community, bussaci ping Andrea, ping me, ping Leo, ping chi vuoi e Gitbar è anche casa tua.Perfetto, ma sicuramente qualche qualche aggiornamento su quello che stiamo facendo arriverà presto.E sono sarei super super felice averti qua proprio per parlare di brindare e festeggiare il nuovo standard.Bomba! Grazie mille! Grazie mille Giorno, abbraccio! Grazie Giordano! Un abbraccio grandissimo! A voi! Ciao! Andre, Leo, come è andata? Io vi ho già salutato! C'è sempre questo siparietto intimo che si saluta l'ospite Per me siamo live su Twitch per esempio E' una cosa di stand up, una roba così Voi avete già utilizzato sistemi di telemetria di questo tipo e di observability? Noi ce l'abbiamo integrata nella nostra piattaforma core per l'enterprise, ce l'abbiamo per Intermetric, ma più perché c'è stata richiesta, la vogliamo, noi non la utilizziamo al momento insomma, non guardiamo le metriche.Capito, Andre? Andre? Il discorso di Amp mi ha sempre interessato, sempre osservato, sempre attenzionato alla cosa, con grande interesse li abbiamo avuti, però i tre pillar, tutti e tre, visti nella stessa medesima piattaforma, ancora no, ma ci stiamo arrivando, è in corso un po' che per motivi di NDA, non posso citare, altrimenti poi ci riempiono di soldi perché gli facciamo pubblicità, quindi preferire non farlo, visto che ne hanno abbastanza già di milioni di euro, basta così.Però è un mondo davvero che quando lo vedi ti esplode il cervello perché capisci di avere un potere in mano di osservazione incredibile che in un attimo ti mette...se ti fai le giuste domande, comprendi bene le cose, hai un posto dove puoi osservare tutto e in tempi davvero brevi comprendere le problematiche e intervenire a colpo sicuro e non andare più a tentoni e aprire quelle call di sette ore dove tutti "ma forse è questo, forse è quell'altro" e tentativi, esatto, mille cose.È un bellissimo mondo, sono davvero contento che ci siamo arrivati da diversi anni ed è qualcosa di consigliabile a tutti a livello psicologico, lavorativo.Proprio accampionando tutto il rumore trovi il segnale perché lo seguo non sono più...Bellissima, potremmo chiudere qua proprio, grande Leo.Io ci sono due cose che mi porta a casa da quello che ci ha detto Giordano.La prima è quella di capire bene come progettare il monitoring delle nostre applicazioni, non prendere, scrapare tutto alla vichinga e poi come va va.Questa è una cosa che mi sono portato, lui l'ha detta in due volte questa cosa ed è una cosa che mi porto a casa perché alla fine deve essere una cosa progettata, non buttiamo tutto in pancia poi chi si è visto, se viste quei dati non li leggerai, non sono fatti per essere letti, strutturati per essere letti, organizzati per essere letti.LM: Banalmente è lo stesso discorso delle metriche, metriche soltanto applicative.E' nudito che tu metti le metriche ovunque se poi non le vai a guardare e quindi non le osservi col passare del tempo.È la stessa filosofia che si applica, diciamo, si continua ad applicare anche a tutte le osservabilità che è arrivata.Sì esattamente quello e questa è una cosa che mi porta appresso come diciamo la morale dell'episodio che Giordano mi ha regalato oggi quindi molto molto figo per il resto io lo uso tutti i giorni in realtà non saprei come fare senza e vi lascio con una bold opinion probabilmente avere un sistema di di observability ben strutturato ci mette in condizioni di non essere in rota per la riproducibilità.Qualunque cosa noi ci dicono "Mauro non funziona sta cosa! La prima cosa che è...ok, dov'eri? Cosa stavi facendo? Come posso riprodurla? Perché se non posso riprodurlo quel problema non esiste!" E no cazzo! L'observability mi fa vedere che quel problema c'è stato e queste erano le condizioni quindi io non sono più dipendente dal dalla riproducibilità che talvolta c'è e talvolta no perché noi ogni giorno lavoriamo in sistemi complessi e dobbiamo essere consapevoli che sono sistemi complessi e che le variabili che entrano in gioco sono un gozzilioni e riprodurre tutto non è poi così semplice.Io mi riscaldo, mi si gonfia la vena sempre qua, probabilmente mi dovrò ricoverare.Detto questo io ringrazio nuovamente Giordano, Andrea e Leo per essere venuti qua da noi, noi ci sentiamo la prossima settimana con un nuovo episodio di GITBAR.Grazie Giordi, grazie...Ciao a tutti! Siamo noi che nonostante il deploy fallito, l'Aziai rossa, il business incazzato, ci troviamo al GITBAR e davanti a una birra tutto ci sembra un po' meno grave.Ah, dimenticavo, rapido rapido! Ssss...abbiamo anche il canale YouTube, se non l'avete ancora fatto, iscrivetevi e cliccate sulla campanella o sul campanaccio è veramente veramente importante ciao ciao Ciao!
