Siamo noi quelli che leggendo il codice cercano lo stronzo che ha scritto quello schifo, ma ahimè lo stronzo è me medesimo e l'ho scritto giusto ieri.Siamo quelli che santificano il nuovo framework javascript preferendo segretamente jQuery, 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 commit message prima di tutto, e dentro ce l'appella tutti i santi.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 ilimitato.Siamo noi quelli che l'AI va regolamentata, mai visto questo nuovo modello che disegna Gattini Funambuli? Quelli che il "dipende" e unesci 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 e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Sì oggi è giovedì e sono quasi le 10 di sera e sto registrando a quest'ora, me ne scuso, quindi probabilmente questa puntata la sentirete domani mattina presto.vorrà dire che insomma vi farà compagnia nel tragitto casa lavoro lavoro casa perché ormai il remote working è uno strano appannaggio che risale a qualche anno fa, no scherzo però comunque insomma molti di noi non lavorano più da remoto, io fortunatamente è uno dei benefici che ancora conservo però vedo che tante cose stanno cambiando da tre anni a questa parte insomma chissà cosa sarà sarà di noi tra qualche anno mentre abbiamo grandi oligarchi che raccolgono mosche nei palchi importanti col braccio insomma che va un po a destra un po a manca così ma non è questo il topic di oggi anche se lo sarà prestissimo e ne parleremo con qualche esperto siamo alla ricerca come avete già visto dal gruppo telegram di qualche esperto di geopolitica capace di capire cosa realmente sta succedendo nella Silicon Valley e soprattutto capace di dirci in faccia quello che sta realmente succedendo nella Silicon Valley, ma detto questo il topic di oggi è molto tecnico anche se con l'ospite che è anche un mio caro amico difficilmente si parla solo di elementi di tipo tecnico, è una di quelle persone con la quale si può spaziare e parlare prevalentemente di tutto, però Bandalè Cianci andiamo a introdurlo subito abbiamo con noi Michele Riva che sicuramente conoscete.Sitio Diorama è stato uno degli evangelist più conosciuti in Italia e in Europa per tanti anni e anche grande amico mio personale e di Gitbar.Ciao Michele com'è? Ciao Mauro, grazie ancora per l'invito, è sempre sempre bello beccarsi a questo bar.Io vedo che tu rimbalzi un un po' qua e là, dalla parte destra e sinistra dell'oceano Atlantico attualmente, dove ti trovi? Al momento sono nella mia, ancora per poco, dimora, nella bellissima provincia di Monza e come ti accennavo ho venduto casa, quindi tra poco inizierà il vero nomadismo digitale perché non ho ancora capito dove andrò a stare tra un mese.però sì, sto viaggiando tanto tra il Canada, soprattutto Stati Uniti e Italia per lavoro.L'anno scorso mi sono fatto sei bei mesi a Vancouver, British Columbia, un po' di tempo a San Francisco, un po' in Italia e quest'anno penso che dovrò replicare.Ti voglio fare subito una domanda che esula un po' dal codice e dalle cose, ma legata a questo nomadismo, tu sei ancora abbastanza giovane, però non hai più 18 anni, quindi come vivere il nomadismo alla tua età? Che poi mi fa ridere perché sei giovanissimo, però cosa cambia quando inizi a avere un certo livello di maturità e continui a muoverti a destra e a manca, come fai te? Beh allora per la carta nazionale dei servizi, io sono un giovane adulto fino ai 34 anni.Quindi mi prendo volentieri il tuo giovane, visto che ne faccio 30, tra oggi e il 23 che stiamo registrando, io vi faccio 30 al 29.Quindi per altri quattro anni sono giovane, me la prendo questa cosa.Grazie Mauro, mi fa piacere.Scherzi a parte, io ti direi che in realtà ho iniziato a girare tanto, tanto, tanto dopo il Covid, dopo le prime aperture, per cui ormai quattro anni fa, sì circa, per cui ho iniziato poco tempo fa e solamente l'anno scorso, oddio no, è vero, solamente negli ultimi due anni da quando ho avviato Orama ho iniziato per necessità a stare un po' di più sul fuso orario Pacific Time, quello di San Francisco, Los Angeles, Seattle, perché per vari motivi ho bisogno di stare su quel fuso orario.E devo dire, mi piace l'idea di dire "non so dove sarò tra sei mesi, posso decidere dove sarò, posso dire ok magari sarò a Vancouver, magari sarò a Città del Messico, oppure vado un mese a Verona, vado un mese ad Amsterdam, chi se se ne frega, nel senso finché ne ho la possibilità di girare senza essere troppo attaccato a un posto, a me questa cosa piace molto.E questa è anche una grande fortuna di avere il passaporto italiano che ci permette bene o male di andare ovunque vogliamo e quindi è una cosa di cui sono abbastanza orgoglioso il mio status da europeo e poi del mio passaporto rosso che mi fa andare bene o male dove voglio.Quindi in realtà là la vivo molto bene, piace, è un po' stressante come in questo periodo in cui ho venduto casa perché non ci sto mai, quindi cosa tengo a fare? L'ho venduta ma veramente devo sbrigarmi, cioè se conoscete qualcuno che affitta in Italia, io contattatemi pure perché potrei aver bisogno.Tu hai una capacità eccezionale di farmi sentire un boomer, un vecchio cazzo! Io veramente ogni volta che parliamo, dico "ma cazzo di uomo".Ma scusa, ma quanti anni di differenza abbiamo? Pochissimi.Eh amico mio, pochissimi.Non arrivi ai 40 te, dai.Veramente.Anche oggi ho imparato qualcosa di nuovo.40 quest'anno.Ah, ok, ok, probabilmente perché non ci vediamo da un po'.Ricordavo che fossi sotto i 40.- Sì sì, no, 40 quest'anno a luglio, quindi c'ho ancora un po' di tempo per reputarmi...non lo so, non posso dire di più.- Diciamo che la carta nazionale dei giovani lavoratori, dei giovani adulti non te la danno più, mi dispiace.- Esatto.- Pazienza.- Pazienza, anche perché comunque non sono in Italia, quindi non la prenderei uguale.però sai pensavo una cosa io ho visto un po seguite un po le tue le tue evoluzioni e le tue scorribande nelle aree del tech è una cosa che ho notato e ha catturato la mia attenzione o o almeno una cosa che mi ha sempre stimolato e incuriosito di sapere è questo shift che hai fatto tra super web focused a più, come possiamo dire, computer science, computer engineering, quindi abbandonare il web e spostarsi più nel mondo degli algoritmi, dei sistemi.Cos'è successo? Diciamo che do molto valore alle cose che puoi imparare una volta e che ti rimangono tutta la vita e il web non è una di queste.Stai invecchiando anche tu amico mio! Adesso sono io che mi sento boomer, però quando inizi a imparare, almeno quando inizi, quando io ho iniziato a imparare un po' web development, ho iniziato un po' per caso, sicuramente in un'altra puntata ne abbiamo parlato, che ho portato un curriculum in un'agenzia di collocamento che mi ha mandato a fare uno stage a Firenze, poi sono tornato in Lombardia, Milano, eccetera eccetera per cui tutto un po' per caso, io non ho una formazione formale, non ho fatto l'università, però per vari motivi avevo sul curriculum WordPress e questo è bastato per farmi mandare a fare web development.E in realtà quando inizi a imparare come funziona il web, cosa puoi creare con il web, sai dieci anni fa a questo punto, dodici anni fa, i siti erano quella roba figa che potevi fare in giro di una giornata e facevi tanta roba ed era in continua evoluzione.Poi c'è l'aspetto della fatiga di cui parliamo tanto che dopo un po' subentra e dici "ok sai che c'è ma chi me lo fa fare esattamente".E non lo so, l'idea di dover continuamente essere in fase di aggiornamento non mi ha più eccitato tanto come all'inizio perché appunto all'inizio hai tanti stimoli, impari tante cose, impari molto alla svelta, non sai assolutamente niente, sai il grande discorso dei "knowns and unknowns", cioè le cose che sai di non sapere.Mauro, poi tu lo sai molto bene, mi ricordo che avevi fatto un talk, mi pare, su questo topico, addirittura a Bari, se non sbaglio, io c'ero.- Sì, Bari Ecodemotion l'avevo fatto in entrambi.- E e quando inizi a sviluppare hai pochissime cose che sai di non sapere e tantissime cose che non sai di non sapere e quando ti rendi conto che hai imparato a usare, io sparo, tale tecnologia può essere React, a un certo punto ti si apre il mondo successivo e dici ok adesso devi andare lo step successivo che non sapevi esistesse, ma senza di quello ti ritieni una persona incompleta, un programmatore incompleto e quindi devi starglielo a imparare, poi ti si apre il mondo dopo e poi quello dopo ancora.La differenza che ho visto tra mettermi a fare più, passando il termine, computer science è che nel web questi mondi si aprono in maniera molto più veloce, c'è un ritmo molto più veloce che è guidato un po' dall'innovazione, magari in ambito front-end, che si evolve in maniera più rapida di quanto non faccia un algoritmo che invece, magari così dagli anni '70, rimane quello, lo impari e comunque più o meno andrà sempre bene.Penso al banalissimo quicksort o la Gextra o altro.Quindi sì, probabilmente sono invecchiato e ho voglia di essere un pochino più stabile e piuttosto dedicarmi a qualcosa che mi dà piacere imparare e non sono costretto a buttarlo via subito.Mentre facevo le scale per venire qua in studio stavo pensando a una cosa, ed è legata un po' al mio periodo scorso dove stavo approfondendo il mondo dei grafi.Molti di noi, me compreso, quando approccia a un topic per studiarlo cerca di vederne subito i risvolti utilitaristici del topic, quindi ti faccio un esempio, sto studiando un certo algoritmo per fare qualcosa, un algoritmo a tal dei tali e devo per forza pensare al prodotto digitale o al sistema che devo realizzare come portarlo a to market, cioè questo tipo di concretezza che viene ok spendo tempo per imparare qualcosa se ho lo stimolo di fare qualcosa che ha valore, produce valore.Spesso con la computer science questa relazione non è immediata, non è uno a uno.Quando studi un algoritmo o vivi in un contesto molto fortunato per cui hai triggerato meccanismo per cui lo metti all'interno di un prodotto, altrimenti è molto più difficile pensare un eventuale prodotto, qualcosa che genera valore legata a quello che stai studiando, è molto più facile farlo col web, cioè io mi studio Vue, mi studio Astro, mi studio Word, completate voi il campo bianco e posso fare da qualunque, l'e-commerce, il sito di mia cugina.esultato.Esatto e c'hai un effetto che è un effetto di gratificazione che è molto più immediato molto più in linea con quelli che sono i trend di oggi dove si va sempre alla ricerca della gratificazione immediata no? Quindi questo è il pensiero.Sì sicuramente iniziare con il web ti aiuta, nel senso che proprio forse anche questo che all'inizio sai parti e immediatamente dici "wow sto facendo qualcosa e vedo subito il risultato".Poi io sono passato per Paramount dove dalla mia esperienza web dovevo scrivere un framework che era simile a Next, per cui un pochino ho pucciato i piedi diciamo in un altro tipo di mondo e poi l'ambiente successivo dopo è stato NearForm, ma poi StartUp.StartUp è quell'unico ambiente, forse, in cui anche se fai algoritmi, se fai ricerca, se fai questa roba qua, i risultati li devi vedere subito, perché i ritmi della StartUp sono veloci.E quindi forse anche questo mi sta sprunando tuttora, sai, a dire, ok, ad esempio abbiamo di recente rilasciato OramaCore, che ne possiamo parlare più avanti, e ad esempio abbiamo dovuto fare degli studi capire rispetto a un ramo open source che algoritmo di ricerca utilizzare per il full text ad esempio.Non è banale dire "va beh uso gli alberi come ho sempre fatto", no, magari possiamo usare i grafi e alla fine abbiamo detto "ok, proviamo con infinite state transducer", che sono dei grafi.Nel giro di tre giorni ce l'avevamo, nel senso che è vero non è la gratificazione immediata, ma comunque il ciclo di vita dell'idea da teoria a poi come dire, da ipotesi a teoria e poi effettivamente d'applicazione è veramente veloce e quindi credo che l'esperienza startup soprattutto mi stia aiutando molto a essere più gratificato per quanto concerne appunto questa immediatezza dei risultati.Credo che questo un po' sostituisca appunto quello che invece avveniva all'inizio con il web development dove tu fai il tuo quadrato rosso, lo centri al centro della pagina e dici "wow, l'ho fatto io, adesso lo stiamo facendo su altre cose" ma la ratificazione è la stessa.Mi chiedo sposandoci nel ragionamento della ricerca immagino che molto del tuo lavoro è quello di andare a trovare l'algoritmo che fitta al meglio con certi use case specifici, quindi dal tuo punto di vista, proprio nel tuo processo mentale, qual è il processo di discovery dell'algoritmo? Come cazzo lo trovi in mezzo a gozziglioni le paper? Come come come trovi quello che fa il caso tuo? Hai una tecnica, un approccio? Assolutamente sì.Dipende dal dominio ovviamente.Per quanto riguarda gli algoritmi di ricerca, ricerca full text, vai nel golden standard, dici ok, loosene come fa? Cioè elastic search, quindi Lucine come fa? Utilizza Finite State Transducer che ha un paper che tu puoi andare interpretare e implementare.Ci sono casi in cui è estremamente semplice in realtà, sai vai a vedere lo stato attuale dei motori di ricerca e dici non so mail research, typesense piuttosto che elastic search.Quindi Lucine utilizzano due utilizzano gli alberi, uno utilizza i grafi.Che tipo di albero, perché poi ognuno usa il suo.Nel mio ricordo male c'è un Radix 3, TypeSense utilizza l'Adaptive Radix 3, Lucene utilizza il Finite State Transducer, quindi dei grafi.Inizia a vedere un po' lo stato delle cose, dice "ok, il mondo si sta muovendo in queste direzioni, andiamo a vedere i paper che hanno determinato l'impiego di questi algoritmi, in questi prodotti, cosa mi piace di più, cosa mi piace meno, quali sono i pro e i contro", perché sai che, non so se io penso ai radix tre posso ad esempio inserire continuamente nuovi nodi posso andarli a eliminare posso fare degli update non è facilissimo ma ce la fai nei grafi come finite dei transducer non puoi farlo devi ricostruire il grafo quindi questi sono pro e contro però il pro è molto più veloce è molto più facile fare la type tolerance insomma ci sono una serie di cose che tu a un certo punto ti trovi a mettere una bella tabella di pro e contro e dici ok sai che c'è un po gut feeling c'è un pochino ho la sensazione che questo funzioni meglio, ma dall'altra parte ho un'analisi che ho fatto, che hanno fatto anche i miei colleghi, che mettiamo insieme e diciamo ok, la nostra migliore ipotesi in questo momento è che questo sia il tool giusto, l'algoritmo giusto.Questo per quanto riguarda magari la ricerca, la ricerca full text.Se parliamo ad esempio di ricerca vettori, un pochino cambia.Penso che in questo caso la scelta che abbiamo fatto è di essere più opinionated, non so come si traduce in italiano, dire la verità, avere delle opinioni molto più forti, mettiamola così.Ad esempio, ora, Macor utilizza quello che si chiama hierarchical navigable small world, quindi ancora una volta una struttura grafo che sostanzialmente implementa un meccanismo di ricerca simile a una skip list e grafi a piccolo mondo, small world, una cosa geniale che quando l'ho visto ho detto è la cosa più bella e folle e geniale che abbia mai visto, funziona da dio, però lì è stato anche un pochino un lavoro di ricerca diverso, di andare a vedere ancora una volta l'attuale, però ci sono database come Milvus ad esempio che ti dicono che devi creare un indice a vettori, ora tocca a te scegliere se utilizzare HNSW, che è l'algoritmo di cui ho parlato ora, IVF Flat, CAGRA, piuttosto che LSH, e ti da una serie di opzioni che tu dici "beh, come faccio a saperlo?" Quindi te li vai a studiare e capisci ancora una volta i pro e i contro e ad un certo punto nel nostro discorso interno adorama è stato deciso che vogliamo far, non so, HNSW nel nostro caso, pensiamo sia la scelta migliore per il 99% degli utenti, implementiamo solo quello, facciamo funzionare benissimo e speriamo che sia la scelta giusta.il lavoro di ricerca dal nostro punto di vista parte tanto dal vedere lo stato attuale degli altri prodotti, come funzionano, quali sono i paper da cui sono state derivate le decisioni, e poi farsi un'opinione in base a esperimenti interni, test di carico, semplicità di implementazione e di utilizzo, eccetera, quindi ricerca pura.Quando andate a vedere lo stato dell'arte dei punti di riferimento, no? Immagino anche i punti di riferimento prevalentemente open source, no? Per cui è più facile accedere all'informazione.Cosa prevale? Il mondo della documentazione o il mondo del del reverse engineering, del leggere il codice? Purtroppo uno dipende dall'altro, inizia sempre dalla documentazione e poi finisce nel reverse engineering, sempre.Anche perché...sì, prego.Anche perché sai tu magari leggi un paper formale come quello del grafo dell'HMSW per la ricerca a vettori e chiaramente lui ti dice che ad esempio è una struttura immutabile per cui tu fai solo l'insert e poi la ricerca.Cioè tu non neanche fai solo l'insert, tu hai i tuoi documenti, li usi per costruire il grafo, il grafo rimane immutabile e tu ci fai una ricerca che è fenomenale, velocissimo.Però poi vai a vedere che Quadrant, Weave, 8milus, gli altri database vettori sanno anche gestire la deletion piuttosto che l'update, piuttosto che l'insert, e allora lì la documentazione non è che ti spiega esattamente come implementa l'algoritmo, vai a leggerti il codice.Quando sei fortunato il codice è scritto in Go, quindi lo capisci, quando sei sfortunato è scritto in C++ per cui fai scoppiare tutto.Lì poi vanno anche un po' a fortuna magari di cosa cerchi dove cerchi.Sto pensando che una cosa che sto implementando, c'è una piena aperta su Aramacore, è il temporal knowledge graph, che serve per implementare una memoria a lungo termine per large language models.e l'unica implementazione che ho trovato, un'implementazione come reference per me, è un'implementazione Python in beta da 5 anni che nessuno sta toccando e quindi molto probabilmente incompleta o non funzionante al 100% ed è l'unica cosa che ho trovato.Quindi quando manca la parte di reverse engineering è molto molto molto più difficile capire esattamente come comportarsi, soprattutto negli edge case.Voglio anche smentire il fatto che naturalmente una cosa che faccio da software engineer nel 2025 è quella di chiedere magari a ChagPT o Cloud e non sanno minimamente darmi la risposta.Quindi, diciamo, questo ti dà anche l'idea di quanta poca documentazione ci sia online, perché poi, nel senso, questi model prendono le loro informazioni dagli stessi posti in cui la prenderei io o chiunque altro, no? Quindi ci sono casi in cui effettivamente hai delle difficoltà a trovare una reference, un'implementazione che tu puoi prendere come riferimento, un po' te lo inventi, un po' guardi il poco che c'è e a un certo punto ti chiedi se magari vale la pena continuare in quel modo o fare altre, prendere altre decisioni.Alla fine è tutto lecito.Come gestisci la frustrazione in questo caso specifico, in queste situazioni specifiche? Sai, da ingegnere secondo me la frustrazione vera non è questa, nel senso non è non capire come realizzare quello che vuoi realizzare, ma è sempre la vera frustrazione non essere in grado di adattarsi e non trovare una soluzione alternativa.Per cui ci sta che inizio magari a implementare appunto un temporal knowledge graph, ho una PR che è aperta lì da due settimane prima o poi e la sto tenendo lì perché non ho idee, devo un attimo ragionarci, però ecco non mi rende particolarmente frustrato l'idea di dire "devo pensarci di più".Mi renderebbe molto frustrato dire "cavolo, non ho un'alternativa in mente, non so come altro risolvere questo problema".Quindi non ti ho risposto in maniera diretta alla domanda, perché comunque c'è una frustrazione da gestire.Quella, dal mio punto di vista, probabilmente io ti direi "ne parlo coi colleghi".Quando sono bloccato, ho altre persone nel team, un Tommaso piuttosto che un'altra persona, cito Tommaso perché lo conosciamo entrambi, ma anche altre persone che quando sono bloccato io devo rompergli le scatole finché uno dei due non si sblocca.Io credo che la comunicazione con i colleghi o con le persone nel tuo canale Telegram o su progetti open source, insomma comunque la comunicazione con gli altri sia l'unico vero modo per gestire questo tipo di frustrazione, non vedo un'altra alternativa.Anche se talvolta poi si declina anche solo rubber ducking ha un valore inestimabile.Ah certo certo assolutamente.Concordo con te.Soprattutto se fai rubber ducking con un collega che è un essere umano con cui puoi fare una figura de merda perché finché la fai con la paperella non ha valore no però quando poi io chiamo Mauro e gli dico "Mauro io non riesco a concatenare due stringhe in javascript perché?" tu mi dici "ma perché quella non è una stringa?" cioè quando fai la figura di merda poi è anche più veloce no? Anche più valore.No ma là è anche perché il famoso concetto degli occhi a suefati talvolta no? Certe volte abbiamo proprio bisogno del calcetto in culo dal collega.Questi ultimi giorni avete avete rilasciato Orama Core io devo fare mia colpa in realtà come come ti ho accennato in pretrasmissione sono un po fuori dei giochi non che mi dispiace non dirlo sono un po un po un po disconnesso cosa è cambiato da un anno e mezzo a questa parte in Orama? Forse ne avevamo parlato un annetto fa o poco prima di cosa fosse Orama.Inizialmente, faccio un assunto proprio in mezzo minuto, l'idea era quella di sviluppare un motore di ricerca principalmente full text, poi abbiamo implementato ricerca vettore e tante altre cose e questo motore di ricerca o database a vettore, che dir si voglia, aveva l'idea di girare su Cloudflare, su Edge Network, E ha funzionato fino a un certo punto, nel senso che su indici piccoli, fino a 100.000 documenti funziona alla grande.Quando inizia a frammentare, avevamo un algoritmo di sharding molto aggressivo che frammentava, diciamo che le strutture proposte dalle CDN non sono abbastanza avanzate e non abbiamo potuto sfruttare il 100% delle potenzialità di queste CDN e questo ci ha portato a decidere di non continuare a insistere e provare a fare qualcos'altro.Per cui, da un certo punto di vista, siamo stati in grado di avere 2000 utenti che stanno su Rama, su Rama Cloud e utilizzano il Cloud.Dall'altra, un livello di scaling che non ci ha soddisfatto.Abbiamo quindi preso la decisione di ricominciare come qualunque altro progetto JavaScript nel 2025.abbiamo riscritto il RAST e adesso abbiamo qualcosa di estremamente diverso dal punto di vista di architettura, ma anche di funzionalità, nel senso che dovendoci muovere poi appunto nel mondo che ci si propone nel 2025, dove l'intelligenza artificiale ha un peso che non può ignorare, abbiamo preso anche delle decisioni di includere alcuni modelli all'interno di Yoramacore.Se ti va, ne possiamo parlare un pochino più nel dettaglio, perché secondo me è interessante.L'idea non è solo quella di darti un motore di ricerca, quindi non fai solo cerchi scarpe rosse da uomo, puoi cercare avettori, quindi con un significato semantico che potrebbe essere "ho iniziato a giocare a golf da poco, vorrei delle scarpe adatte ma sotto i 150 euro.Ora tu puoi usare questa query come query di ricerca vettori, potrebbe funzionare ma una cosa che noi abbiamo fatto è prendere un large language model, utilizzare una tecnica di fine tuning che mira a togliere tutto quello che non serve, quindi farlo molto più piccolo, e ottimizzato per fare una sola cosa che è tradurre questa query di cui ti ho appena parlato, cioè ho iniziato a giocare a golf da poco, ha un acquiri di Orama che è scarpe da golf dove il prezzo è meno di 150 dollari.Io te l'ho detta discorsiva, in realtà immagina come un oggetto JSON proprio con i filtri stile Prisma, in cui hai questi filtri e Orama ti genera in automatico, ma te la genera in automatico in 60 millisecondi, 100 millisecondi, quindi è estremamente veloce.E poi immagina che magari tu, che hai un e-commerce, qualcuno ti fa questa domanda e tu dici "Fammi vedere se ho anche degli sconti".Crei quello che si chiama OnAgent, quindi una funzione JavaScript che ti permette di chiamare un endpoint esterno che ti ritorna magari uno buy link, un link per procedere all'acquisto, un codice di sconto o altro, e alla fine lo includi in una risposta che può essere generata da un large language model.Perché ti ho fatto l'esempio di una funzione JavaScript? Perché essendo che abbiamo scritto Oramacore in Rust abbiamo integrato Dino.Per cui hai un accesso ai dati in JavaScript da dentro il database con tutte le regole di sicurezza che ne devono derivare e questo ti permette di dire ok, se lo ritieni opportuno tu insegni ai model che ti porti con Oramacore e se lo ritieni opportuno puoi chiamare una di queste 100 funzioni JavaScript che ho scritto Oramacore la esegue server-side l'output di questa funzione farà parte del contesto che viene utilizzato da un altro language model che poi è quello che ti darà o i risultati di ricerca o una risposta a stile chat gpt con tutti i tuoi link con un markdown che puoi renderizzare come preferisci.E abbiamo diversi, diversi piccoli modelli di questo tipo che puoi utilizzare per fare diverse cose.Il nostro appunto, il primo è decidere il piano della query, cioè io ti ho chiesto queste scarpe, allora Orama ha un piccolo modello che dice "ok, l'utente ha chiesto delle scarpe da golf sotto i 150 euro, cosa devo fare? Beh, prima di tutto faccio una ricerca per vedere cosa nel catalogo, poi vedo se ho degli hook, li chiamiamo hook, sono degli agenti che posso chiamare ed eseguire in JavaScript che possono essere, non so, generare lo shopping link o un codice di sconto.Una volta che ho il catalogo, codice di sconto, vado a vedere magari dentro la memoria interna, la long term memory, se conosco già l'utente, se ha già acquistato delle scarpe, così le escludo dai risultati e poi rispondo.Ecco, queste quattro azioni di cui ti ho parlato vengono pensate da un piccolo modello, quindi l'ennesimo modello che è all'interno di Oramacore, che fa proprio questo, lo fa per te, dice ok, a seconda della richiesta dell'utente questo è il piano, il chain of thought che ci sta dietro e l'output tendenzialmente, io vorrei dire perfetto, ma diciamo estremamente ottimizzato per quello che è il tuo utente finale.>> LM: come è stato questo percorso di migrazione, partendo da quello che era? Intanto mi interessa, mi incuriosisce la riscrittura completa, perché sai, è un po' un meme, no? C'è qualcosa...lo riscriviamo in rasta.Quindi la prima domanda e come avete gestito l'efforto di una riscrittura completa in Rust? Io direi prima di tutto perché Rust, perché abbiamo dovuto valutare ovviamente varie scelte, c'era Rust, c'era Zig, c'era C++, c'era Go, alla fine l'expertise interna Orama era principalmente su Rust, soprattutto grazie a Tommaso, e quindi questa era la scelta migliore.Io non sono un grande scrittore di Rust, però in somma me la sono imparata.Adesso ogni tanto stresso Tommaso e mi faccio insegnare quello che mi manca, però provo a contribuire anch'io.La riscrittura era necessaria perché se pensi ad esempio alla ricerca sui vettori, i vettori per assuntone sono, non starò a dire come vengono creati, dirò solo che sono degli arrei larghissimi di numeri e questi numeri sono dei float 32 quindi ogni numero pesa almeno 4, pesa esattamente 4 byte e se tu hai ad esempio un milione di vettori da 1532 dimensioni l'uno, per 4 byte per ogni dimensione capisci che arriviamo ai terabyte subito no? E ora Orama Open Source gestisce qualche migliaio di vettori, ma ovviamente non può scalare, ora Open Source intendo, scusami, ora maschetto in JavaScript, non può scalare a miliardi di vettori per questo motivo.Per cui innanzitutto perché fa una ricerca brute force, cioè tu gli dai un vettore da comparare e gli dici "ok, ti trovi più simili".Noi invece con la riscrittura abbiamo detto "ok, invece implementiamo qualcosa che è un po' più fine, quindi non più una una complessità di tempo costante, ma logaritmica, che è decisamente meglio.Ma oltretutto andiamo a implementare, non so, product quantization, che quindi ti va a diminuire le dimensionalità di un vettore da magari 1532 a 96.E posso usare float 32, utilizzi int 8, che quindi è un byte, quindi da, non so, diversi kilobyte per vettore, ti pesa solamente 92 byte.Quindi una tecnica di compressione che in un prodotto JavaScript è molto difficile da ottenere.Mentre in Rust è estremamente facile da fare, invece.Seguendo proprio i paper ufficiali, tu dici "ok, si fa così, bella, lo faccio".Quindi il livello di scaling che abbiamo raggiunto l'avremmo comunque raggiunto con una riscrittura completa in JavaScript, con la penalità di non riuscire a comunque raggiungere le performance di cui abbiamo bisogno.Quindi in ogni caso, sapendo che avremmo dovuto riscrivere tanto, detto "ok, tanto vale che lo facciamo bene e lo facciamo imparando quello che ci manca da imparare e ricercando quello che ci serve da ricercare" quindi tutti i vari trucchi e strategie per scalare.Adesso faccio la domanda cattiva.Vai.Attualmente in Oram avete due...semplifico due grandi code base visto che non so se l'abbiamo detto ma avete rilasciato Orama Core in AGPL quindi avete due grandi code base mantenere Orama Java, Script e Orama Rust per semplicità chiamiamoli così, quanto cazzo costa mantenerle entrambe e quali sono le prospettive? Lo so è una domanda cattiva la taglio se vuoi.No no no no è una buona domanda diciamo che mantenere un rama javascript soprattutto ti costa poco se uno dei founder non è pagato a ore.Quindi comunque in un modo o nell'altro il tempo si trova, se lo faccio a luna di notte non interessa a nessuno, non importa che vada fatto.Sicuramente abbiamo delle partnership per Orama JavaScript che bene o male ci portano a continuare a garantire compatibilità.Penso a Fumadox, non so se l'hai mai visto, un tool di documentazione che è diventato abbastanza popolare.Abbiamo una forte partnership con loro e utilizzo Orama di default.Non esiste che gli dico "devi andartene da un'altra parte".No, io voglio i tuoi download, io voglio che il brand di Orama venga visto perché è un ottimo prodotto e sono interessato che, insomma, che perché Orama faccia parte del tuo ottimo prodotto.Per cui, da quel punto di vista, oggi dedichiamo una percentuale del tempo che non ti so dire perché non è fissa.Potrebbe essere il 10-20% a Orama JavaScript e tutto il resto a Orama Cloud e Orama Core, che sono appunto...Orama Core è quello che poi va a, diciamo, a essere il centro di Orama Cloud.quindi la versione o stata da noi, gestita da noi, dove tu non devi fare altro che mandarmi i tuoi documenti, io genero gli embeddings per te, faccio il chunking per te, faccio io il training dei codebooks per la product quantization, in modo che puoi scalare all'infinito, gestisco io tutto e ovviamente noi speriamo di andare a guadagnare lì, più che da Orama JavaScript, ma Orama JavaScript è comunque un'ottima, anche solo un'ottima pubblicità, noi non vale assolutamente la pena tenerlo vivo.Anche l'azione di give back verso la comunità ho visto che tantissimi progetti open source hanno adottato un ramo javascript da quello che ho visto.Sì, tanti e anche la licenza che abbiamo mantenuto è proprio a pace, nel senso che se a un certo punto qualcuno dovesse dire "mi sembra che Orama non lo stia mantenendo nella maniera più corretta o non ci stia dedicando abbastanza tempo e noi per qualche motivo non abbiamo le risorse perché non si sa mai" è un progetto che qualcuno può continuare da un'altra parte, eventualmente.Non è assolutamente la nostra idea, però insomma ha un tipo di licenza che ti permette di farlo.Hai citato che Oramacore è AGPL e questo si porta dietro altri tipi di considerazioni naturalmente.Pensavo una cosa in realtà con Oramacore tutto il concetto del ledge va a sparire in quel caso giusto? Si.Quindi si va su compute? Si c'è una cosa a considerare che noi sul ledge, se io penso, io sono in provincia di Monza, il nodo più vicino a me è a Milano, in media su 10.000 elementi la ricerca full text funziona in circa 70-100 millisecondi.La ricerca vettori, dato che, faccio una richiesta, il nodo di Milano deve andare al nodo più vicino che gestisce gli embeddings che potrebbe essere Francoforte o North Carolina, dipende da mille cose.C'è una latenza infinita, tu devi passare pacchetti di dati giganti perché i vettori sono giganti, anche con protocol buffers che vaglioni comprimi, sono comunque giganti.La ricerca vettori sta sui 400-500 millisecondi.Con OramaCore, dove è tutto all'interno di un unico pacchetto, gli embeddings li genera il server stesso che fa la ricerca.La ricerca full text in media è 35-50 millisecondi, la ricerca vettori è 35-50 millisecondi.Per cui capisci che il vantaggio architetturale da questo punto di vista è veramente significativo.Questo potrebbe essere anche un vantaggio a sistemi più più più complessi la cui infrastruttura è composta da più moduli, che ne so, hai il vector db, hai altri tool che fanno altre cose per cui il traffico è tutto via rete, questi elementi si fanno via rete e c'hai per forza una una latenza.Sai che è una cosa che sta sta ritornando spesso quella di prima c'era la tendenza no dividiamo, dividiamo, battere i micro servizi, dividiamo no esatto ed è una cosa che sta che sta ritornando cioè mettiamo insieme i pezzi in una cosa che funziona in modo pressoché atomico è una cosa che è ritornata anche nella chiacchierata che abbiamo fatto qualche settimana fa al Sistema di Natale con Matteo Collina.Certo, Matteo da questo punto, diciamo così, per quanto riguarda, se vuoi parlare di server monoliti e microservizi devi parlare con Matteo, non con me.Sì sì no, ma in generale la filosofia...No no, ma mi riferivo alla filosofia, Miki, nel senso il fatto di forse stiamo diventando un po' troppo per essere efficienti e efficaci.In realtà secondo me, almeno io ti parlo per un ramacore, noi te la stiamo nascondendo.Nel senso che se io penso ad esempio al fatto che, come ti citavo, la ricerca full text avviene su un grafo che è immutabile, però io devo inserirci i dati.Ora, quello che facciamo, noi inseriamo in un buffer su cui faccio una prima ricerca, poi ricerco nel grafo, alla fine ti do i risultati.Ma l'azione di reindexing, noi è vero che non te la facciamo in un servizio esterno, te la facciamo sulla stessa macchina, ma abbiamo dei requirement di sistema minimi, come ad esempio il fatto di essere multi-core, che vabbè lo do per scontato, ma l'avere accesso a più core mi permette di dire "ok, io dedico parti, diciamo, della mia macchina a un core solo a reindex".Frammento magari, Un'altro parte solo per la parte Python.Cioè quel core gestisce solo i processi Python che mi servono ad esempio per andare a generare gli embeddings che poi mando alla parte Rust per utilizzare, da utilizzare embedding per la ricerca a vettori.Abbiamo Dino integrato dentro il database per cui non vogliamo che condivida le stesse risorse necessariamente con lo storage dei dati per ragioni di sicurezza, allora mappo un'altra area della mia macchina e la dedico solo a quella.Cioè è vero che stiamo portando tutto all'interno di una struttura monolitica, ma è monolitica dall'esterno.All'interno è un sistema distribuito a tutti gli effetti, che rispetta questa regola, tale per cui dall'esterno deve apparire come un'unica macchina coerente all'utente finale.E l'utente finale mai si sognerebbe che tu stai gestendo ogni singolo processo e stai ogni singolo processo nell'area della macchina che vuoi, ma questo è esattamente quello che noi vogliamo fare.I concetti che stanno dietro ai sistemi distribuiti in termini di network li stiamo riportando all'interno delle macchine e dei software che stiamo scrivendo in Orama, proprio per garantire i vantaggi che hai nei sistemi distribuiti a microservizi, ad esempio, ma all'interno dei sistemi monolitici.A livello implementativo e di design, quali sono state le sfide proprio di portare tutto e di permettere elementi che possono agire in modo pressoché isolato all'interno di un contesto di questo tipo però? Ci sono state sfide o bestemmie particolari che avete lanciato in momenti specifici? Se io ti faccio una richiesta per una ricerca vettori, devo generare gli embeddings banalmente, abbiamo iniziato dicendo "si fa in Rust, c'è l'Onix Runtime, funziona in Rust".Allora è sbagliato, non funziona.Abbiamo scoperto che non funziona per niente, non bene come vorremmo quantomeno.Per cui abbiamo detto "serve un server Python".Ma come fai? Tiri su un server, fai una chiamata HTTP al server che sta nella tua macchina? Alla fine sì, abbiamo un server gRPC Python che è estremamente veloce, non ha praticamente network perché sta all'interno della stessa macchina, sta su un processo separato, tu lo chiami, ti dai l'embedding, lo usi.Per cui questa è una grossa difficoltà implementativa per noi perché stai avendo anche una dipendenza su un server a parte che potrebbe smettere di funzionare in qualunque momento, che ha bisogno di solviare meccanismi di recovery, eccetera.In futuro quello che faremo sicuramente sarà utilizzare, abbiamo già fatto, Tommaso ha già fatto degli esperimenti e li porteremo in produzione prima o poi, di utilizzare l'interprete Python dentro Rust.Ci sono i binding nativi all'interprete C, in modo da dover evitare anche un server esterno, ma far girare tutto in un processo che gestiamo noi in Rust.Questo è uno dei mille esempi di scelte architetturali che sono difficili, che ci hanno fatto bestemmiare tantissimo, Perché non è facile capire che, non so, hai bisogno di generale embedding se sei costretto a farlo in un modo.Poi vuoi interpretare JavaScript ma QuickJS per mille motivi non lo puoi usare, Node è scritto in C++ per cui è un casino da portare dentro.Dino funziona ma vuoi usare le isolate di V8 o vuoi usare Dino? Vuoi usare Rust di V8 o l'intero runtime o solo una parte o solo l'isolate? Tante considerazioni che richiedono tanti test.dai dai dai parlaci di come avete integrato Dino dentro, questo non in culo esiste.Facilissimo loro espongono una libreria chiamata javascript runtime che tu importi e fai come si dice in italiano spawni un processo e la roba figa tra l'altro è che sotto il culo, perdona francese però sta in francia lo posso usare, sotto il culo utilizza V8 per cui lui ti tira su delle isolate e ti dà la possibilità di dire "ok, su questo isolate voglio anche l'API di Dino" oppure definisco le mie API.Cioè ho bisogno di fetch, utilizzo request di Rust e implemento io fetch, come vuole JavaScript, oppure utilizzo quello già di Dino.La cosa figa è che appunto essendo isolate, sullo stesso processo ne possono vivere diverse, che è molto figo perché significa che se tu mi fai un while true e mi blocchi tutto non stai bloccando gli altri.Io ovviamente metterò dei timeout, metterò dei meccanismi di sicurezza.Noi prima di fare qualunque roba parsiamo il codice per capire se è ok, se non ha loop infiniti eccetera.Proviamo a capirlo.Però devo dire l'integrazione di Dino è stata una delle cose più facili, a dire la verità, perché il team Dino ha fatto un ottimo lavoro nel creare delle API per embeddare un JavaScript runtime in qualunque applicazione Rust.Ha fatto queste API molto bene, funziona molto bene.L'integrazione più difficile invece qual è stata? Bella domanda.Io ti direi che non è tanto un'integrazione...allora non Non l'ho fatto io, ma la mia percezione è che la cosa più difficile sia stata la persistenza su disco.Cioè che tutti i dati vivono in memory, sia quelli full text che vettori, che sono due dati molto diversi.Se tu uccidi il server e lo fai ripartire, ti ritrovi tutti i tuoi dati.Questo perché vengono serializzati su disco e a startup vengono ricaricati.Credo che questa sia stata la cosa più difficile in assoluto finora.Hai esplorato una delle domande che mi ero appuntato durante la cena perché mi incuriosisceva parecchio ed è il dump appunto su disco.Io mi immagino sai queste strutture dati a parte la parte degli embedding che potrebbe essere abbastanza non flar ma abbastanza semplice da memorizzare immagino so per intuizione così a fiuto mi sembra abbastanza semplice ma strutture di dati complesse come come come qual è l'approccio che si ha per memorizzare queste cose cercando di offrire un certo livello di resilienza in caso di crash di sistema? Sicuramente devi scegliere un formato di serializzazione che sia efficace ed efficiente, che sia abbastanza veloce sia in fase di scrittura che di lettura sia di compressione e decompressione devi capire quanto sei disposto a perdere se penso ai vettori, agli algoritmi di compressione, ai vettori come il product quantization ha una loss cioè è un perdi dei dati quando comprimi.E' anche vero che puoi sempre ricostruire cioè puoi anche decomprimere e abbiamo dei tool interni che ci dicono ok, li ricrei uguali a 98,90% 8,90 per cento, che per noi è accettabile per quello che devono fare gli embeddings.Per cui credo che il formato di serializzazione sia importante e credo che sia anche importante capire come frammentare i dati, perché il dato di per sé è facile.Cioè se tu pensi magari, adesso dico una stupidaggine, protocoll buffers, tu definisci il tuo schema, gli spieghi come sono fatti i tuoi dati, lui te li salva su disco.Ma non puoi salvarmi un terabyte di dati su disco in un unico file.Perché non ha senso.Poi quando lo devi decomprimere, cosa fai? Te lo streami tutto in memoria? No, non credo neanche tu possa, con certi formati.Forse Protocol Buffer sì, sinceramente non mi ricordo.Però ci sono casistiche in cui ti devi prendere l'intero documento in memoria e da lì lo decomprimi.Per cui la frammentazione dei dati e poi portarli su disco, mantenere dei checkpoint per dire "ok, ho serializzato fino a qui e poi qualcosa è successo e devo continuare".I meccanismi di retry, i meccanismi di ributto in memoria dall'ultimo checkpoint che ho fallito.Queste sono le cose un pochino più difficili secondo me.Poi non è la parte che ho seguito io in particolare, quindi mi parlare con Tommaso che è lui che...un follow up.Io ti consiglierei veramente di parlare con lui perché secondo me ha tanto da dire al riguardo e tanto da smentirmi sicuramente però sì è molto affascinante in realtà come come argomento quello di essere in grado di supportare un disastro in cui ti si spacca tutto e tu comunque torni in piedi.Credo che sia una di quelle situazioni che se gestite bene fanno la differenza in fase in fase di adoption perché si apre si si apre un mondo no io credo che abbiamo non lo so come siamo riusciti questa volta abbiamo toccato un sacco di punti e tipo boh, ho però la domanda finale o almeno il topic finale perché e questa mi mette terrore perché potremmo rimanere 14 ore a parlarne.Vai, sono spaventato ma vai.In uno dei tuoi talk, ritorniamo a parlare degli algoritmi intanto, in uno dei tuoi talk hai citato la filosofia degli algoritmi di ricerca e io so che sei un amante della filosofia in generale, adesso premesso che io sono pienamente convinto che l'algoritmo sia l'outcome di un processo creativo secondo te quando si parla di filosofia di algoritmi a cosa ci si riferisce nello specifico Allora, l'algoritmo lo puoi vedere in diversi modi.Lo puoi vedere come uno strumento matematico che dal punto di vista matematico ti porta da un punto A al punto B.Se pensiamo a Quicksort, che è un bellissimo algoritmo, ti dice "ok, tu hai un problema grosso, lo dividi in piccoli problemi, risolvi i problemi individuali e alla fine ti trovi la tua soluzione sotto il naso".Levenstein, la distanza di Levenstein per la typotolerance, quindi spell checker, trovare degli errori, se sbagli a scrivere c'è un typo, lo trovi con Levishtain, ti dice la stessa cosa, ti dice "tu hai un problema grosso, frammentalo in tanti piccoli problemi e quando risolvi ogni singolo problema ti trovi la soluzione davanti a te", che poi è un po' il concetto che sta alla base del dynamic programming.Io credo che tu possa guardare a questa cosa in due modi, a un punto di vista matematico e dal punto di vista filosofico.Io non sono mai stato tanto bravo in matematica, per cui trovo molto più facile vedere la filosofia che sta dietro a questo tipo di approccio dove ti dà quasi una lezione di vita, nel senso che scrivere algoritmi, capire algoritmi non è facile e qua c'è ancora un pochino di filosofia, nel senso che faccio conferenze da tanti anni ormai, ne ho fatte più di 100, ho parlato con tante persone, ho visto tante persone parlare e ci sono due tipi di persone che parlano, sono quelli che lo fanno per divertirsi, anzi tre, sono quelli che lo fanno per divertirsi, perché si divertono a farlo, ci sono quelli per accrescere il proprio ego in maniera spropositata e ci sono quelle che ci tengono che tu capisca qualcosa.Credo che nel mio caso lo switch per quanto riguarda gli algoritmi sia arrivato quando ho iniziato a parlarne pubblicamente.All'inizio era un "guardate quanto sono bravo, ho capito come funzionano gli algoritmi e ve li spiego in maniera più incomprensibile e complessa possibile perché ho il cervellone e dovete vedere che sono bravo, ditemi che sono bravo" perché sinceramente mi dispiace, sono stato uno strunzo, però ho fatto anche sta roba qua in passato.Invece adesso mi trovo molto più a mio agio a spiegare gli algoritmi, come ho fatto al Coderful, ad esempio, nei termini più semplici e accessibili possibili e poi parlare con le persone che mi dicono "ok, finalmente ho capito cos'è quella roba lì, cos'è un albero binario, come funziona la ricerca binaria, come funziona una skip list e credo che ci sia molta molta filosofia dietro la scelta di come approcciare non solo la scrittura e la comprensione dell'algoritmo ma anche la spiegazione dell'algoritmo stesso e ripeto non sono mai stato tanto bravo in matematica altrimenti non avrei dovuto in ogni modo dimostrare quanto ero bravo in passato e adesso ci tengo molto di più invece che anche gli altri capiscano quello di cui voglio parlare.Sai una cosa che ho sempre pensato quando si parla di algoritmi o almeno a livello esperienziale quando ho studiato algoritmi il problema che trovavo era quello di comprendere i passaggi ma con difficoltà a disegnare la l'immagine insieme no? Quando tu studi un algoritmo a parte che i libri diciamo non sono molto molto d'aiuto perché insomma talvolta sono guarda quanto ce l'ho grosso piuttosto che spettacolo, come quello che dicevi no? Però quello che poi alla fine si arriva ad avere una lista di step e molto raramente emerge il ragionamento completo, quindi è più una ricetta che comprendere il ragionamento e mi chiedo se oggi a parte algoritmi particolarmente semplici è possibile dedurre il ragionamento e le immagini d'insieme per algoritmi più complessi.Cioè qual è il percorso che ti porta da step A, step B, step 10, step 15 che non riesci a memorizzare one shot a avere le immagini insieme? Si, richiede una grande abilità.Io ho fatto un talk al Code Motion di Madrid con Angela, con cui ho cofondato Rama, in cui io spiegavo un algoritmo che abbiamo spiegato Geekstra, Levenstein, e non ricordo cos'altro, altri due algoritmi, vabbè cos'erano le HashMap, quindi la struttura dati, e un altro che adesso mi sfugge, e lo spiegavo io in termini matematici e poi tecnici, diciamo, da informatico, e poi spiegava lei invece da designer, cioè con una rappresentazione grafica d'insieme che non entra necessariamente nel dettaglio, ma che permette chiunque di capire come funziona.Il goal del talk che avevamo fatto era proprio quello, cioè dire "ma io come faccio a memorizzare tutti questi step, tutte queste casistiche, tutti questi if, cioè se non sono in grado poi di trovare una forma reale, non so, nel caso di...ah, di quicksort, ecco l'altro che abbiamo fatto, devi mischiare il mazzo di carte, è ovvio che io posso leggere una carta per volta, metterli in ordine.Se uso Quicksort faccio prima e Angela aveva proprio disegnato l'algoritmo visivamente che sposta le carte seguendo la logica di Quicksort, mentre io avevo invece spiegato la formula che ci stava dietro.Un altro talk invece che ho fatto con Paolo, che è stato un tuo grande ospite e un nostro grande collega, con Paolo aveva fatto questo talk invece a Bari, in cui c'era anche tu se non sbaglio, che avevi parlato poi dopo, in cui invece spiegavamo Diffie-Hallman, quindi lo scambio di chiavi pubbliche nell'algoritmo di encryption end-to-end, e l'abbiamo fatto con delle tavolozze di colori, quindi abbiamo portato i nostri quadri, ricordo, Paolo aveva il suo quadro, io avevo il mio, abbiamo scelto i nostri colori, con un colore comune siamo arrivati alla fine ad ottenere lo stesso colore che la nostra chiave di encryption.Io sono una persona che impara dal punto di vista visivo, per cui so che tanti dicono "no, non è vero, impariamo tutti lo stesso modo".Vaffanculo, no, io imparo così.Per cui è l'unico modo in cui posso spiegare adesso.Infatti faccio una fatica tremenda a parlare ora che poi è solo audio, no? E non posso magari condividere lo schermo e far vedere cosa è molto difficile per me però credo che in un mondo che diventa sempre più complesso l'abilità di spiegare in maniera semplice è importante purché non diventi banale nel senso che il downside che vedo in questo approccio è che le persone si abituano a ragionare in maniera semplice quando i problemi sono tanto complessi.La cosa che incoraggio a chiunque se posso permettermi di fare, una volta capito il primo layer, cioè il livello semplice, approfondire fino all'ultimo, il livello più complesso in assurdo, perché è l'unico modo con cui eventualmente crei un pensiero critico e sei in grado di dire "ok, quicksort è meglio di bogosort".Io posso descriverteli tutte e due e probabilmente qualcuno dice al volo "sì, ok, forse è vero", però se li descrivo e poi qualcuno va nel dettaglio e capisce che è vero, questo è quello che forse dobbiamo fare come programmatore.Io penso che con questa frase possiamo anche chiudere l'episodio e da qui è tutto, ci sentiamo alla prossima, no scherzo, sono d'accordo con te, infatti da qualche tempo a questa parte mi sto spendendo per la mia crociata che insomma dice "meno Twitter più paper".- Twitter è un'altra cosa da abbandonare - Tra l'altro bellissimo io ho ripreso a fare le mie lezioni d'inglese proprio oggi no? E parlavo con la mia professoressa d'inglese, ho la fortuna di avere una tizia troppo troppo figa per insegnare inglese che è una sveglissima, una super svegliona e mi diceva guarda quando uscì twitter e tra l'altro era una donna di tipo 60 anni non è una ragazzina mi disse quando uscì twitter noi nella mia cerchia ci venne da ridere perché dice la parola twitter usa un prefisso che è tweet ma se si va a guardare in gergo inglese cosa tweet voglia dire...non mi ricordo cosa vuol dire ma non era bellissimo esatto tipo pirla tipo stupido idioto come git, git non vuol dire stupidotto non so come dire è un modo simpatico per dire che sei stupido.Scemo, tweet vuol dire scemo tradotto letteralmente e quindi e quindi sono rimasto un po così insomma.Git vuol dire ingenuo.Meglio git che tweet.Sì mi sa di sì.Però ecco al posto meno tweet più paper suona suona suona sono a meglio.Amanti della natura potrebbero dire.No, questo è per ricordare, insomma, per riportare il ragionamento sul proprio il fatto che la semplificazione è una porta d'ingresso per l'approfondimento.Tenere sulla sola semplificazione spesso non porta da nessuna parte, ma aiuta ad attivare, ad accedere al percorso d'apprendimento che è un percorso che necessariamente presuppone dell'effort.L'oversimplificazione elimina quell'effort iniziale di cui parlavi.Però cosa succede? Che se tu non ci metti effort, la semplificazione Cioè rimane là e finisce a se stesso.C'è una grande narrativa che sta dietro al "dobbiamo semplificare, dobbiamo rendere tutto accessibile a tutti".Io sono d'accordo nel portare le persone oltre la porta d'ingresso, ma non è il punto d'arrivo.Quando anche prima dicevo "spiegare algoritmi in maniera semplice, accessibile a tutti", quello è il punto d'inizio per un discorso più complesso, non è il punto d'arrivo.non arrivi a capire quicksort se te lo faccio vedere con le carte.Capisci come funziona, ma non capisci come si implementa o di come può essere parallelizzato ad esempio o di come può essere, non so, per mille cose.Cioè una volta che sei lì poi devi fare del lavoro.Sai, chi fa talk, chi fa podcast, chi scrive può semplificare, può portarti a punto di inizio tutto qua.Che è comunque un grande vantaggio però poi insomma lo è perché senza non ci arrivi neanche probabilmente quindi è l'unico grande vantaggio di cui bisogno in quel momento.Il mio consiglio personale lo dico perché ci sono cascato e ci casco tutte le volte è veramente di non fermarsi lì.Ovviamente si mette una bolla di conoscenza molto superficiale che non ti porta da nessuna parte e ripeto io ci casco ancora continuamente.Ci caschiamo tutti assolutamente.Detto questo io direi che possiamo saltare al momento tipico e topico del nostro podcast quel momento chiamato il paese dei balocchi.Ecco il duco nel paese dei balocchi.Ah il Paese dei Balocchi! Il Paese dei Balocchi, la parte di podcast dove sia i nostri guest che i nostri host ci propongono, ci raccontano, ci spiegano qualcosa che ha catturato la loro attenzione e pensano valga la pena ad essere condivisa.Quindi Michele la mia domanda è hai qualcosa per noi? Io dico una cosa, se vuoi la tagli, per cui poi faccio ancora un pochino di post.Quando mi hai detto "è arrivato quel momento del podcast" ho detto "ecco, è arrivato il momento del cagare in discoteca".Non so se cogli l'eccitazione, ma ero pronto al peggio.Non so perché ho avuto un riflesso condizionato.Devo essere sincero.Ultimamente non...mi ricordo che l'ultima volta abbiamo parlato di libri e ultimamente non sto leggendo tanti libri sul tema informatica perché, come ti dicevo, sto studiando altro, sto iniziando l'università, sto studiando un altro...in un altro campo e e quindi diciamo oltre le mie 12-14 ore al giorno di lavoro, dopo quando finisco preferisco dedicarmi ad altro in questo momento.Una cosa che consiglio è innanzitutto darci una star su GitHub, orama-search/oramacore, perché sangue, sudore e lacrime in quel progetto.Secondo me all'interno si trovano delle chicche sia per chi vuole imparare un po' di più a livello di intelligenza artificiale generativa.Nel senso che ci sono dei pacchetti che proprio fanno quello, ci sono pacchetti che fanno fine tuning, ci sono pacchetti che utilizzano quello che viene chiamato prompt engineering dagli ingegneri, prompt design dai designer, delle tecniche abbastanza avanzate.Per chi vuole sapere di più di algoritmi, secondo me è un ottimo repository, perché veramente lo stiamo curando molto.oltre a questo cavolo Mauro mi ero dimenticato che c'era questa parte del podcast non mi sono preparato adeguatamente vabbè io mi sono preparato e ti rubo un balocco che balocco che sicuramente riconoscerai che è questo libro, l'ho consigliato l'altra volta esatto e lo riportiamo questo è "Groking Algorithms" penso che siano due ottimi starting point per approcciare ai dati.Il libro è "Codeless Data Structures and Algorithms" che è molto figo e poi questa volta porto un balocco completamente off topic.Io sono schiappa totale in cucina però ho una passione la ginger beer è tipo una droga io ne consumo una quantità illimitata e quindi volevo condividere con voi non ha senso questa cosa però lo faccio lo stesso la mia ricetta per la ginger beer perché faccio la ginger beer a casa è semplicissima da fare è bollire lo zenzero pelato con lo zucchero di canna e si fa lo sciroppo di zenzero a quel punto è sufficiente o mischiarlo con con l'acqua gasata tipo soda, stremo o qualunque altra cosa oppure mettere un po' di lievito e farlo lievitare in 24 ore avete la vostra ginger beer quindi questo insomma è il balocco aggiuntivo se volete per un attimo staccare gli occhi dal computer che funziona ve lo posso garantire e fare qualcosa altro.Mi hai fatto venire in mente due libri uno che è legato a Codeless Algorithms and Data Structure che si chiama Computer Science Distilled di adesso guarda ho cercato su google il nome che non mi ricordavo l'autore Vladaston Ferreira Filo F-I-L-H-O, molto bello con delle illustrazioni fatte molto bene che ti introducono veramente bene al mondo della computer science e questo consiglio consiglio anche un altro libro tu hai visto un Arcos che l'ho rivisto di recente? Sì un eone fa sì.Ok se ti è piaciuto un Arcos o qualcuno l'ha visto consiglio un libro che di Osvaldo Zavala che è un professore di storia nativo americana alla New York University penso e si intitola "Drug Cartels do not exist" e parla di tema narcos diciamo ed è molto molto molto bello interessante contro intuitivo ma storicamente accurato quindi non posso far altro che consigliarlo perché è un ottimo ottimo saggio.fantastico prenderemo nota anzi ti chiedo la cortesia se riesci a mandarmi lì su telegram così li mettiamo nelle note dell'episodio così insomma potete potete ecco buttarci un occhio occhio allora prima di lasciarvi però abbiamo un secondo Devo ringraziare, dobbiamo ringraziare chi ci supporta fa sì che questo podcast possa arrivare alle vostre orecchie pressoché ogni settimana abbiamo Daniele Cherky che ci invita una birra scrivendoci grazie per fornirci una panoramica friendly a 360 gradi sul nostro mondo anche a chi lavora nelle piccole realtà.Abbiamo un altro messaggio del nostro buon buon Livio ascoltatore ormai storico di Gitbar che è sempre presente con un supporto che ci invita a tre birre scrivendo "Ciao Mauro, in bocca al lupo per la tua costola, so che fa male, un saluto anche agli ammutinati e a tutti i membri del canale Livio".Sì è vero, devo dire che sono già passati 23 giorni perché sono riuscito a scheggiarmi, danneggiarmi la costa dal giorno del Capodanno, quindi insomma non potevo non potevo andar meglio però dopo 23 giorni la situazione è decisamente migliorata anche se ho altri tre mesi, ho altri due mesi davanti insomma per un completo ristoro grazie di nuovo sia a Livio che a Daniele Mick è stato è stato un super piacere di averti di avere di qua ai microfoni di Gitbar ogni volta che arrivi cioè arrivi con 10.000 carriole di cose nuove allora a questo punto come ben sai Gitbar è anche un po' di casa tua se vuoi una ginger beer fresca fatta in casa e poi puoi venire quando vuoi lo sai.Buono sapersi.Gitbar è un po' anche casa tua.Detto questo noi vi ringraziamo ringraziando di nuovo Michele noi vi diamo appuntamento alla prossima settimana ciao ciao siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo il ghitbar è davanti a una birra tutto ci sembra un po meno grave *risata*
