Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua sul nostro bar degli sviluppatori.

Lo so, lo so che state pensando tra voi perché ho schippato la puntata della settimana scorsa.

Beh, come tutti quando si è vicini al burnout bisogna rallentare, premere il piede sul freno e ricalibrare un attimino il tutto.

L'ho fatto ed eccomi qua di nuovo a farvi compagnia in questo late giovedì early venerdì direi, visto che comunque nonostante tutto non riuscirò a uscire puntuale, però vi prometto che questa puntata sarà esplosiva.

Prima però di introdurre l'ospite perché ebbene sì non sono solo un super ospite con me, vi devo ricordare rapidamente i nostri contatti.

Info che ho c'è la gitbar.it, atbrain repo su twitter, i modi ormai canonici per contattarci.

Oppure il classico gruppo telegram, la nostra casa, il posto dove ci incontriamo e discutiamo di sviluppo software e non solo, talvolta parliamo anche di razzi che Elon Musk fa partire e le cui partenze probabilmente falliscono o cose di questo tipo.

Però detto questo io direi di non perderci troppo in chiacchiere e partire subito con la presentazione del super ospite di oggi.

Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti, che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.

GITBAR Abbiamo con noi Marco Gorelli, uno dei king della data science, senior software engineer a Quansite e core maintainer di Pandas, una libreria che penso tutti, almeno chi si è avvicinato anche da lontano alla data science, ha visto e ha provato.

Ciao Marco, benvenuto, come va? Ciao, grazie per questa introduzione.

Ho dimenticato qualcosa, ho detto qualcosa di sbagliato? Forse king della data science è un po' esagerato.

Tra un po' vediamo il perché mi sono fatto questa opinione di te.

Intanto, piccola domanda, nel tuo profilo leggo senior software engineer e contemporaneamente sei un esperto di data science.

Come fai a far vivere queste due anime insieme, che sono due punti di vista molto diversi nel vedere il codice? Eh, domanda interessante.

Allora, in realtà ho cominciato la mia carriera come data scientist.

Lavoravo, sì, come sono arrivato a senior data scientist in una startup inglese, però mentre lavoravo utilizzavo Pandas praticamente ogni giorno.

Ecco, a un certo punto cosa succede? Mi accorgo che c'è un bug nel mio codice.

Il bug, dopo un po' di esperimenti, ho capito che in realtà non era in quello che avevo scritto io, ma c'era qualcosa all'interno di Pandas che era cambiato da una versione all'altra in un modo che non doveva essere previsto.

Allora, cosa ho fatto? Ho aperto una issue lì su GitHub, e ho detto, eh, ciao, secondo me c'è questa cosa che dovrebbe funzionare, però non funziona più.

E loro mi dicono, uè Marco, ciao, grazie per il report, in effetti hai ragione, questa cosa dovrebbe funzionare, saresti interessato ad aprire una pull request.

Ecco, hai detto che i data scientist e i software engineers si approcciano al codice in un modo diverso.

Ecco, io all'epoca non sapevo neanche cosa fosse una pull request.

Avevo un'idea molto vaga di cosa fosse Git, però l'idea che il mio codice potesse finire all'interno di Pandas mi casava tantissimo.

Quindi, cosa ho fatto? Quella sera sono tornato a casa, ho trovato il contributing guide di Pandas, con un po' di pazienza me lo sono letto tutto, e con grande fatica ho aperto il mio primo pull request.

Loro mi hanno subito detto, ciao Marco, grazie per questa pull request, l'hai cominciata bene, ti diamo solo qualche dritta.

E ho trovato questa response incredibilmente incoraggiante, quindi ho aggiustato un po' di cose in base al loro feedback, e poi qualche giorno dopo me l'hanno approvata e l'hanno mergeata.

In quel momento ricordo di aver sentito questa scarica di adrenalina, l'ho raccontato a tutti, mi sentivo un gran tigo, e allora ho detto, vabbè, magari ci sono altre cose su cui posso lavorare, altri bug che posso magari risolvere.

Quindi ho preso, cercavo altre cose su cui lavorare, e poi cos'è successo? Stiamo parlando del fine 2019.

Inizio 2020, c'è stata sta merda di covid, sto lockdown e tutto, quindi mi sono ritrovato con parecchio più tempo rispetto a prima per lavorare su progetti personali, e ho pensato di investire questo tempo a contribuire ancora di più a Pandas.

Continuato così per un po', finché dopo circa un anno che contribuivo, mi hanno invitato a far parte del core team, ovvero dandomi permesso di poter mergeare e approvare le pull request di altri.

Però continuavo a lavorare come data scientist, questo fino a quel momento era stato soltanto un hobby, una cosa che avevo fatto puramente come volontario, finché nel settembre del 2022, quindi relativamente poco fa, non ho cominciato a lavorare dalla QuantSight come software engineer, e adesso lavoro su Pandas come parte del mio lavoro.

Quindi forse ho lasciato un po' indietro la parte di data science, però adesso lavoro sugli strumenti che si usano all'interno di quel campo.

Ti faccio una domanda, di solito quando si lavora nel mondo della data science, si lavora dentro un ecosistema, un contesto, che è quello dei Jupyter notebooks, dove lo scope, il contesto di quello che stai facendo è molto limitato.

Quando però approccia una codebase, che può essere quella di Pandas, ma una qualunque codebase, ti rendi conto che in realtà se il Jupyter notebook possiamo vederlo come il cortile di casa, la codebase diventa la città per quanto complessa e intricata.

Come hai affrontato questa sfida? Nel senso anche a livello psicologico? Non solo, cioè mi interessa sapere sia a livello psicologico che proprio a livello strategico, come hai deciso di affrontare quel livello di complessità? Un'altra ottima domanda, a livello strategico secondo me bisogna veramente distinguere le strategie.

Purtroppo vedo che alcuni data scientist sentono voci che i data scientist non scrivono del codice ben fatto e quindi cercano di scrivere bene il codice, scrivere codice pulito, di non utilizzare i Jupyter notebooks in tutto quello che fanno.

È tutto, ma secondo me è bene cercare di separare le responsabilità, ovvero nel momento in cui qualcuno sta facendo il lavoro del data scientist va benissimo sperimentare, va benissimo scrivere codice orribile e va benissimo buttare via il 90% di quello che si fa.

Nel momento in cui invece uno ha fatto l'analisi, ha creato il modello e arriva il momento di fare il productionization, ecco allora in quel momento conviene fare un passo indietro, assicurarsi di avere scritto dei test, di fare continuous integration e tutte queste pratiche che secondo me possono anche rallentare il lavoro del data scientist nel momento in cui si sta facendo sperimentazione, quindi queste pratiche che devi dal punto di vista strategico, ecco non bisogna farle subito, c'è il momento giusto di farle e il momento in cui si sta sperimentando secondo me non è quello.

Detto questo, ho parlato di codice pulito, questa è una mia grande passione, quello che trovo quando scrivo codice in Python come software engineer è che ho tantissimi strumenti che posso utilizzare per assicurarmi che il mio codice sia pulito.

Cioè ho Formatter, ho l'Inter, ho questo MyPy, però poi quando mi sposto nelle Jupyter Notebook non ho praticamente nulla.

Quindi un altro progetto su cui ho lavorato durante il lockdown è stata una libreria a Python che permette in teoria di poter far eseguire qualsiasi code quality tool scritto per Python però sulle Jupyter Notebook.

Figo, interessante, quindi è il portare l'Inter, il Formatter, quegli strumenti all'interno di un contesto dove in realtà non vengono usati perché come dicevi prima visto come codice usa e getta fondamentalmente.

Prima però di concentrarsi sui flow di sviluppo, sull'utilizzo di Pandas, volevo farti ancora una domanda generica perché noi abbiamo dato per scontato il concetto di Data Scientist e di Data Science.

Però credo valga, siccome noi nel podcast siamo quasi tutti software engineer e non sempre abbiamo modo di interagire con quest'altra categoria professionale, ecco mi interessava chiedere a te dovendo descrivere la Data Science e il ruolo del Data Scientist come la rappresenteresti? Forse lo vedo come un ruolo nel quale si sta cercando di catturare del valore dai dati.

Spesso le aziende si ritrovano con montagne di dati e non sanno necessariamente cosa farci, però hanno l'intuizione che se assumono qualcuno che sa farci qualcosa, allora ci sarà del valore lì dentro col quale potranno un giorno guadagnare qualcosa.

E quindi spesso assumono Data Scientist senza sapere bene cosa fargli fare.

E questa è una cosa che ho vissuto un po' in alcune aziende in cui sono stato assunto, mi hanno detto ah qui abbiamo un sacco di dati, abbiamo questa applicazione, magari potresti metterci dentro del machine learning.

E' una cosa che sinceramente non ho vissuto benissimo, preferisco dover lavorare in un contesto in cui ci sono aspettative un pochino più chiare.

Nonostante ciò questa è una situazione che ho sentito da tantissimi Data Scientist.

Anche perché tra l'altro tra lo step del Data Scientist e il business stesso ci sono tutto un altro ventaglio di ruoli che servono proprio per dare una mira, una direzione alla Data Science.

Uno di questi può essere anche parte della business intelligence, no? Assolutamente sì.

Quindi sì, generalmente consiglio di cominciare chiedendo, ok, supponiamo che io vi creo un modello di machine learning perfetto, proprio che prevede questa cosa di cui state parlando con perfezione.

Ecco poi, che cosa ci farete? E se loro non hanno una risposta, allora vuol dire che è troppo presto per cominciare a fare machine learning e che, come hai detto tu, il business intelligence magari sarebbe uno strumento più utile.

Cioè prima di provare a fare un modello, proviamo a capire i dati che abbiamo, a visualizzarli, a fare un po' di dashboarding.

Esatto, come dice un mio amico Data Scientist, dice, ascolta, prima di parlare di Data Science, fatti un'interfaccia su Tableau Oculic e non rompermi le balle.

Questa è la risposta che dà spesso lui, no? E un po' ricarica quello che ci hai appena detto.

Parliamo di toolkit della Data Science.

Quali sono gli strumenti, ovviamente Pandas non può mancare, ma quali sono oltre Pandas gli strumenti che un Data Scientist utilizza tutti i giorni? Allora, beh, posso parlarvi degli strumenti che utilizzavo io tutti i giorni, però a seconda del ruolo questi possono cambiare notevolmente.

Allora, sicuramente in primis serve un qualche modo per leggere dei dati dal database, quindi bisogna conoscere bene SQL o Mongo.

Poi, una volta che sono stati letti i dati, serve un modo per analizzarli, per processarli, per selezionare delle parti dei dati nei quali andare poi a studiare in modo più dettagliato.

Quindi generalmente ho utilizzato Pandas per questa parte del lavoro.

E poi bisogna visualizzare i dati, perché non ci si può fidare soltanto delle statistiche riassuntive.

C'è un famoso esempio, si chiama il AnswerComb Quotat, questi sono quattro insiemi di dati e tu potresti riassumere questi quattro insiemi di dati con esattamente le stesse statistiche.

Cioè, a cosa intendo? Tutti questi quattro insiemi hanno la stessa media, la stessa mediana, la stessa standard deviation, stesso minimo, stesso massimo, se fai una regressione lineare tra x e y viene lo stesso coefficiente.

Nonostante ciò, se poi visualizzi questi dati, ti rendi conto che sono completamente diversi.

E quindi quello che dicevo sempre quando lavoravo come data scientist era che non basta guardare queste statistiche riassuntive, è assolutamente fondamentale visualizzare i dati.

E quindi servono strumenti per farlo.

Cioè, hai nominato prima Tableau? Quello va benissimo.

Rimanendo all'interno di Python, io utilizzavo parecchio Seaborn e poi Plotly, che è una libreria per fare visualizzazioni interattive con relativamente poche linee di codice.

Chiaro.

Penso di aver fatto un corso su Udemy dove si usava Plotly.

Seaborn.

Seaborn, sì, sì, bello.

Comunque, giusto per finire, quasi sicuramente serve anche qualche libreria per creare dei modelli di machine learning e soprattutto per valutarli.

Per la parte di valutazione, forse la libreria usata più spesso è Scikit Learn.

E poi per far eseguire i modelli, anche all'interno di Scikit Learn ce ne sono parecchi, però poi c'è LightGBM, XGBoost per utilizzare dei modelli che sono, come si chiamano, gradient boosting machines.

Guarda, quello che stai dicendo è arabo, sappilo Marco.

Io non so se Carmine tu conosci questi modelli, ne hai sentito parlare.

Noi siamo artigiani del codice.

Come ti dici Carmine? Noi siamo umili braccianti del software.

Ciao a tutti, insomma, mi sono fidato.

Nella puntata, in realtà, qualche minuto fa, ma non vuolvo interrompere.

Va bene, quindi giusto per chiarire, cioè Pandas lo usi per lavorare con dati bidimensionali.

Ecco, questi sono modelli che funzionano molto bene su dati bidimensionali.

Nel momento in cui qualcuno ha dati come immagini, suoni, chat, ecco, poi serve la deep learning e quello è un mondo completamente diverso, del quale so relativamente poco.

C'è cercato di studiarlo, però non l'ho mai utilizzato nel lavoro.

Sei passato al lato oscuro del software engineering nel frattempo, no? Voglio chiederti un'opinione.

Oggi quando si parla di data science, nella maggior parte dei casi, almeno nel mondo hype driven, si parla di machine learning.

Quanto rimane ancora fuori dal machine learning? Di data science.

Cioè, quello che rimane fuori dall'insieme del machine learning è ancora utile per i processi? O è quell'elemento che lavora di nascosto e che alimenta poi l'hype? Quell'elemento che paga le bollette e poi c'è l'hype del machine learning, non so come dirlo.

È un po' provocante questa domanda.

Hai ragione, penso che alla fine il lavoro del data scientist sia forse il 95% fare cose che non sono machine learning.

E poi il machine learning lo trovi solo lì, nella parte di ottimizzazione finale.

Però purtroppo è quel 5% sul quale viene valutato.

Cioè, se tu devi fare un lavoro enorme di background per capire quali sono i requisiti, per trovare i dati, per pulirli, per immagazzinarli da qualche parte, per creare una pipeline, per poi esportare i dati da qualche parte, e poi il modello di machine learning può anche essere una cosa black box, cioè scusa, può anche essere una cosa, un package che usi in modo abbastanza black box all'interno di tutto quello, nonostante ciò, visto che tu lavori come data scientist, è quel 5% che la gente verrà poi a chiederti.

È un peccato però alla fine, penso che sia abbastanza raro poter lavorare come data scientist in un contesto nel quale tu puoi soltanto pensare al modello e attorno a te hai una squadra di ingegneri che ti fanno tutto il resto.

Quindi per il bene o il male è necessario imparare un bel po' di pratica di engineering.

Esatto, e tra l'altro hai sollevato, evidenziato un elemento importante, anche la qualità dei dati in ingresso, che è una discriminante super importante, e spesso una delle cose più trascurate in generale, no? Ed è, ripeto, quando parlo con i miei amici, loro si ostinano a dire, guarda che non si può parlare di data science se alla base di tutto non c'è una data governance dell'azienda, non c'è una qualità del dato, perché, come dicono loro, crap in, crap out.

Fondamentalmente questo si tratta.

Da quel punto di vista, ecco, lavorando sui tool, hai mai pensato a un modo o a una suite, o esiste una suite di tool, che aiuta nell'analisi e nel mantenimento della qualità dei dati in ingresso? Sì, ci sono un po' di librerie che offrono una validazione dei dati, spesso sono integrate con, cioè funzionano con Pandas.

Questo lo dico perché non esiste solo Pandas, esistono altre librerie di DataFrame, però Pandas è quella più usata, e quindi purtroppo queste librerie di validazione tendono a scriverle per Pandas perché sanno che così il loro software verrà utilizzato, però quello che fanno in teoria, non c'è ragione per cui non dovrebbe essere utile in altre librerie di DataFrame.

In genere penso che questi strumenti possono essere utili, però non possono sostituire il lavoro che il data scientist deve fare per capire i dati, e capire dove c'è sporcizia.

Cioè per dire, è abbastanza facile trovare articoli su cosa fare con Outlier, cosa fare quando ci sono dei dati mancanti.

Ci sono tutta una serie di strategie, però prima di cercare di applicare una di queste strategie, il data scientist dovrebbe prima chiedersi perché ci sono dei dati mancanti.

Questo può portare della luce su una parte del business process che non sta funzionando.

Mi viene in mente un esempio, in un'azienda in cui lavoravo c'era un sacco di dati mancanti, e un ingegnere che stava cercando di fare del auto machine learning li aveva tutti riempiti con zero perché aveva letto da qualche parte che si faceva così, senza essersi chiesto perché c'erano quei dati mancanti.

Il motivo per cui c'erano dei dati mancanti era per via del covid, quindi c'erano dei giorni in cui l'azienda aveva chiuso, e quindi serviva un altro metodo abbastanza specifico a quell'azienda per pulire quella parte dei dati.

Quindi questi strumenti vanno benissimo, però non dovrebbero sostituire la parte in cui il data scientist fa il lavoro di pensare e capire.

Mi accodo a questo tema perché anche a me è capitato spesso di lavorare in contesti del genere, insomma, dove la maggior parte delle volte si pensava di avere questa quantità di dati enorme e bellissima, quando poi alla fine quando ci vai a mettere mano erano cose che hanno state minimamente pensate per poi essere utilizzate in un approccio del genere.

Secondo te ha senso e ha valore che, non voglio dire per nuovi sviluppi perché forse sarebbe semplice, insomma, però diciamo è un flusso di lavoro ideale e sano che sia anche tutto il team o il data scientist stesso a dare degli insight a tutta la parte di engineering su come raccogere.

Nel senso anche questo è il lavoro del data scientist che indica la strada di engineer su come raccogere i dati.

E secondo te si può fare o è qualcosa che non è ben vista? Perché io ho avuto un po' le esperienze opposte.

Non so, è difficile dirlo.

In genere penso che la cosa migliore sia di cercare di coinvolgere tutti il prima possibile, giusto per evitare che ci siano fraintendimenti o che qualcuno non stia facendo qualcosa che magari per un'altra persona è ovviamente sbagliata e che creara molti problemi a lungo andare.

Per dire, un'azienda in cui ho lavorato avevano una quantità enorme di dati, però una cosa che ho scoperto un po' tardi è che in questo database loro aggiornavano le righe in base a quando gli ordini dei clienti cambiavano.

E quindi io che stavo cercando di creare un modello di machine learning basato sulla storia, non potevo sapere in realtà cos'era successo nella storia.

E quindi ero lì che dicevo, ok, abbiamo 12 anni di dati, però ci raccontano soltanto quello che è successo e non quello che stava succedendo finché non siamo arrivati al punto finale.

Quindi vi prego, adesso cambiamo il modo con il quale immagazziniamo i dati, però dovrete aspettare un altro paio di anni, almeno, finché qualcuno non può farne veramente uso e creare un modello di machine learning.

E fu così che arriviamo a parlare di event sourcing, vedo Carmine che ride, perché in realtà...

No, non voglio entrare nel loop, vi prego.

C'entreremo in una delle prossime puntate, proprio sull'utilizzo di modelli di storage basati sugli eventi e di scrivere software basato sugli eventi, che devo dire al lato ingegneristico è un effort importante.

Un sistema come quello che Marco stava dicendo è probabilmente molto più facile da ingegnerizzare, meno responsabilità, meno chunk di eventi giganti da trattare, elaborare, magari in realtà in mille casini.

Però nel contempo si perde la storia e per chi lavora sulla storia questo è un grosso problema.

Voglio però, a questo punto, visto che vedo che il tempo sta volando, voglio arrivare a parlare di pandas.

Quindi la domanda che ti faccio è, cosa fa pandas alla fine? Quali sono le responsabilità della libreria? Va bene, allora, pandas si usa per fare analisi su dati bidimensionali, quindi si possono scegliere sotto insieme di dati, si possono aggregare i dati magari per gruppo o a seconda di un indice che può rappresentare magari del tempo, si possono comparare diversi oggetti e in genere si può fare un'analisi dettagliata su dati relativamente piccoli.

Se bisogna trattare 50 gigabyte di data o dati che non stanno in memoria, allora pandas non è lo strumento giusto.

Telefoniamo al data engineer e gli diciamo risolvete il problema, questo è il processo, risolvete il problema, giusto? Dico bene? Ma più o meno, parte della risposta.

Ma lo dico perché mia moglie fa la data engineer, quindi più di una volta l'ho vista con il Jupiter notebook e dall'altra parte con l'idea scrivendo robens per spark e bestemmiando.

Dicevi scusa alla mia digressione? No, è divertente.

No, sinceramente non tutti i data scientists hanno la fortuna di avere sempre il data engineer a portata di mano e quindi spesso si ritrovano a dover utilizzare altri strumenti per lavorare con enormi quantità di dati.

Pandas generalmente è single threaded perché è basato su NumPy, però c'è un'alternativa che si chiama Modin che si vende un po' come una libreria, una versione parallelizzata di Pandas.

La promessa che loro fanno è che anziché fare import pandas fai import modin.pandas e poi tutto funzionerà come prima, però sarà parallelizzato.

In realtà non è così semplice, ci sono alcune cose che non possono funzionare perché per il modo in cui sono state progettate in pandas è molto difficile parallelizzarle.

Nonostante ciò permette ai data scientists, senza dover imparare Spark, di poter processare gigabyte di data in un modo, cioè con una sintassi che gli è già abbastanza familiare.

Modin però non è l'unico strumento che fa questo, c'è anche una libreria scritta in Rust di nome Polars, questa è una sintassi ben diversa da Pandas, però non è neanche completamente aliena.

Se lo usi ti senti abbastanza a casa da subito, prende un po' di parti da Pandas, un po' di parti da Spark, un po' di cose da R.

Comunque sì, poi c'è QDF che serve un po' come una versione di Pandas, però funziona sul GPU.

Insomma, ci sono tutti questi strumenti, però come dicevo prima, delle librerie ad esempio di validazione dei dati, in genere sono scritte solo per Pandas.

E quindi, come si risolve questo problema? Allora, il primo modo per risolvere questo problema è un protocollo per interchangiare tra queste librerie.

Quindi, tutte queste librerie adesso stanno implementando questo metodo che sarebbe doneTheDataFrame, e questo permette a qualsiasi altra libreria di DataFrame di poter prendere quell'oggetto, capire quello che ci sta dentro e trasformarlo in qualcosa che può capire.

Quindi, una libreria come Seaborn per fare visualizzazione, ora è scritta in Pandas, però quello che dicono che vogliono fare nella prossima versione è utilizzare questo metodo doneTheDataFrame per prendere quello che qualcuno gli dà, trasformarlo in Pandas e poi far eseguire il resto del codice come prima.

E quindi così potrebbero poter funzionare con tutte queste altre librerie di DataFrame delle quali sono finito a parlare.

Quindi, giusto per chiarire questa cosa, è una sorta di Bubblefish per Data Structures fondamentalmente? Non ho presente cosa intendi per Bubblefish, cioè tipo un traduttore? Esatto.

Bubblefish viene da Guida Galattica per gli Attropisti, era il pesciolino che si infilava nell'orecchio, qualcosa del genere comunque.

E come ci si comporta con linguaggi diversi? Perché so che, per esempio, Polars è scritto in Rust anche se ha i binding per un po' di linguaggi, Pandas è in Python.

Questa Data Structure deve essere serializzata in qualche modo, no? Questo Interchange, sì, allora da quello che so in questo momento funziona soltanto per librerie che hanno dei bindings in Python.

Ah, ok.

Da quello che ricordo, sì.

E Potente sta già sbloccando tante possibilità.

Tipo una libreria per visualizzazione si chiama Altair e questa, nell'ultima versione, già supporta tutte queste librerie diverse.

Prima funzionava solo con Pandas, adesso, utilizzando questo Interchange Protocol, può funzionare con tutte queste altre librerie.

Però una limitazione di questo Interchange Protocol è che bisogna comunque fare questo step di traduzione.

Quindi bisogna comunque tradurre Pandas e magari bisogna anche utilizzare PyArrow per fare questa traduzione.

Insomma, questo può dover incrementare il numero di dependencies nel progetto.

Un'altra iniziativa su cui sto lavorando, come parte del mio lavoro, è uno standard comune per le librerie di DataFrame.

Quindi, cos'è? Questo non è un tentativo di unificare gli API di tutte le librerie di DataFrame, perché sarebbe impossibile.

Quello che invece è, è un tentativo di creare per ogni DataFrame library un pacchetto separato che implementa questo standard relativamente minimale, però col quale, se scrivi del codice, hai la garanzia che questo funzionerà con qualsiasi libreria di DataFrame che aderisce allo standard.

Quindi, queste librerie di validazione dei dati, di visualizzazione, dovrebbero poter funzionare con altri tipi di DataFrame senza dover passare dal Bubblefish che converte a Pandas.

Io, in realtà, avevo una curiosità più che una domanda vera e propria, insomma.

Ho notato che si ricerca, anche un po' come ci stavi raccontando tu, di avere, diciamo, un'esperienza simile a quella che si ha con Pandas o con le librerie, ma anche in altri, insomma, linguaggi.

Ma, alla fine, c'è davvero una differenza di performance, nel senso che spesso vedo come motivazione fondante nella creazione di questo nuovo tool è perché quello con Python è lento, con Ruby è lento, con l'altro coso è lento, eccetera, eccetera.

Premetto, comunque, che utilizzo sia Python e sia Ruby, quindi sono amico dei fratelli lenti dal punto di vista delle performance.

Ma c'è effettivamente bisogno di avere più performance e portarlo più a performance? Io spesso, come succede, è un mero esercizio di stile, nel senso che io spesso l'ho visto fare solo per questo motivo qui e non perché vi fosse un reale collo di bottiglia nella manipolazione di cose con un altro linguaggio.

Ottima domanda, veramente.

Ogni tanto vedo persone online che sembrano legare la propria identità agli strumenti che usano.

È una cosa che veramente non capisco.

Cioè, nessuno ti darà mai dei punti per aver utilizzato uno strumento.

Prenderai punti per aver risolto un problema, per aver aggiunto del valore alla tua azienda, non perché hai utilizzato Polars anziché Pandas.

Detto questo, ci sono situazioni nelle quali la performance di una libreria è veramente il collo di bottiglia.

Mi sono ritrovato a fare analisi nelle quali aspettare che un group by di Pandas finisse ci voleva, non so, magari un intero minuto, mentre passando a Polars poteva finire nel giro di qualche secondo.

Un minuto rispetto a un secondo non fa la differenza se questo è un lavoro che scorre automaticamente nel background mentre stai facendo altro.

Però, nel momento in cui stai facendo sperimentazione, allora avere un feedback dopo tre secondi ti permette di rimanere molto più concentrato e molto più all'interno del flusso rispetto a uno strumento che ti dà feedback dopo un intero minuto.

Se ci mette un intero minuto, allora hai già avuto il tempo di distrarti, di controllare l'email, di fare altro e poi hai già perso, non ti ricordi già più quello di cui stavi pensando.

Quindi sì, penso ci sia un reale bisogno di questi strumenti diversi, non penso che sia solo una questione di stile.

Nonostante ciò, penso che la cosa migliore sia imparare questi strumenti e poi mescolarli.

Prendete le parti buone da ogni strumento e non legate la vostra identità a nessuno di questi, perché ogni strumento ha le sue limitazioni.

Era una domanda interessante, perché mi è capitato di avere discussioni con alcuni colleghi, mi dicevano, io non uso questo perché questo è meglio, questo è più veloce, insomma.

Quindi quando poi effettivamente nei nostri casi d'uso era questo batch che girava la notte che ci mettevano ora, che metteva due, non sarebbe effettivamente fregato nulla a nessuno.

Però questa cosa della sperimentazione non ce l'avevo pensato, effettivamente è un buon punto.

Sì, sì, insomma sì.

Ma in realtà è così, una domanda che mi è venuta questo sì adesso, poi lascio il campo.

Per quanto riguarda la visualizzazione dei dati, come c'è tanta differenza, c'è tanta differenza tra strumenti open e strumenti closed, nel senso faccio, o comunque strumenti con un tipo particolare di licenza, non voglio dire che bana ed amici su, però ci siamo capiti, ecco.

Perché spesso ho trovato come requisito, proprio in alcune cose che si devono fare magari per alcuni clienti, utilizzare questo tipo di strumenti perché garantivano, non lo so, un'affidabilità maggiore, erano effettivamente meglio, oppure erano più carini da vedere, insomma.

Anche sulle visualizzazioni, c'è più o meno uno standard, oppure è veramente a fantasia dello chef, di chi fa data visualization? C'è uno standard tra diversi strumenti, intendi? Che io sappia no.

Allora, quello che fa, la pandas espone dei metodi con i quali produrre delle visualizzazioni.

Diverse librerie possono fare questo plugin system e possono implementare la loro versione di questi plot che sia compatibile con l'API di pandas.

Quindi si può fare, non ricordo esattamente la sintassi, mi sembra che sia pandas.options.config, qualcosa del genere, però per mettere il backend per le visualizzazioni e poi se questo backend che hai scelto implementa questo API, allora puoi utilizzare quel backend al posto di quello di default che è matplotlib.

Nonostante ciò è una cosa abbastanza limitata, ci sono un po' di librerie che hanno seguito pandas e hanno implementato questo API, però sono relativamente poche e non si può dire che questo sia stata la soluzione alla frementazione che c'è nel mondo della visualizzazione.

Questo non è stato uno standard in quel mondo.

Voglio però fare due passi indietro, giusto per dovere di chiarezza.

Hai parlato di data frame, ok? Ma che cos'è il data frame? Perché noi siamo andati spediti a mille, però è giusto che facciamo un passo indietro e chiariamo questo concetto che potrebbe essere alieno a molti.

Giusto, ottima domanda, perché in effetti guardavo il podcast, ho sentito qualche episodio precedente, questo è un podcast per tutti i developer, non solo per i Pythonisti, non solo per i Data Scientist, va bene.

Allora, un data frame si può pensare come un insieme di colonne.

Ogni colonna può immagazzinare dei dati e la restrizione è che ogni colonna deve avere tutti i dati dello stesso tipo.

Quindi magari tutti i dati di una colonna possono essere integer, di un'altra colonna possono essere float, di un'altra colonna possono essere date con un certo fusolario, in un'altra colonna possono essere date con un altro fusolario.

In Pandas poi c'è anche questo escape hatch, si può avere una colonna di tipo oggetto che può immagazzinare qualsiasi cosa.

Non è efficiente, se avete, cari ascoltatori, se avete dei data frame con delle colonne di tipo oggetto, allora quasi sicuramente la vostra performance sarà più lenta di quanto non potrebbe essere, quasi sicuramente sarebbe una buona idea convertire quella colonna a un tipo apposito.

Però ci sono casi rari nei quali bisogna immagazzinare, non so, un integer, un float, una stringa, una data, tutto nella stessa colonna.

Ecco, Pandas offre questa possibilità però è sconsigliato.

Quindi sì, questo è quello che una data frame è, un insieme di colonne, ognuna delle quali è fatta per immagazzinare un certo tipo di dati.

Ho un'altra domanda in realtà.

Quando prima tu parlavi di dati bidimensionali è perché ti riferisci proprio a righe e colonne o c'è qualche altro concetto sotto? Esatto, proprio quello, righe e colonne.

In Pandas c'è un indice e quindi ogni colonna può avere un nome però anche ogni riga può avere un nome.

Questa è una cosa che torna molto comoda quando l'indice vuol dire qualcosa, ovvero quando è significativo, tipo quando magari nell'indice qualcuno ha salvato delle date.

Le data frame nascono con un indice che semplicemente parte da zero e cresce fino ad arrivare al numero di righe meno uno.

Questa è una cosa che a me dà un po' fastidio di Pandas, però è una di quelle cose che esiste da talmente tanto tempo che oramai sarebbe troppo difficile cambiare.

Ci ho provato, è stato un macello.

Perché non vogliono dire niente quei nomi.

Cioè, se io ho che la prima riga rappresenta il primo gennaio, la seconda riga rappresenta il secondo gennaio e così via, allora questi nomi, primo gennaio, secondo gennaio e così via, sono utili.

Se invece non ho un nome in mente per ogni riga, le mie righe sono semplicemente zero, uno, due, tre, quattro e così via, allora finisce per essere più una scorciatura che altro.

Questo lo senti veramente quando devi combinare due data frame nelle quali non ti interessa cos'è l'indice.

Perché Pandas allinea le data frame in base all'indice.

Ma se a te dell'indice non importa niente, finisci sempre per fare reset index.

Reset index, reset index, reset index, così che i tuoi oggetti saranno allineati.

Però sarebbe bello se ci fosse un modo per non dover pensare all'indice.

Se c'è una modalità nella quale tu dici, ok io uso Pandas nella modalità senza indice.

E' così, se voglio sommare due data frame, sommamele.

Cioè se hanno la stessa dimensione, allora somma la prima riga della data frame di sinistra con la prima riga della data frame di destra.

Non mi importa di che nomi ho dato alle diverse righe.

Mentre col sistema che c'è adesso, uno parte con 0, 1, 2, 3, 4, 5 fino alla lunghezza del data frame, poi magari toglie un po' di righe, poi le sposta un po', le ordina in base a una colonna, e poi i nomi finiscono per essere 2, 5, 7, 41, 36, 5 e non vogliono dire più niente.

Quindi mi piacerebbe poter togliere questa cosa, ma è troppo difficile.

Quindi non ha un riferimento con, sotto il coffano, il puntatore al dato di quella riga specifica.

È una sovrastruttura? Mi sembra di capire, io non conosco le internals di Pandas.

Sì, in teoria sarebbe una cosa che...

sì, una sovrastruttura, cioè un modo per dare un nome a ogni riga.

Cioè un concetto diverso dal concetto di index in un database.

Ok, chiaro.

Altra domanda che ti avranno fatto un gozziliardo di volte.

Perché usare Pandas e non il classico plain Python? Quindi mi scrivo, che ne so, un bel filter con Python al posto di utilizzare il data frame di Pandas.

Ottima domanda.

Allora, vi dico subito che se potete fare qualcosa con Python senza utilizzare Pandas, allora utilizzate Python.

Perché ogni software che usate ha i suoi bug e sicuramente ci sono meno bug in Python che in Pandas.

Detto questo, penso sia abbastanza raro poter fare tutta una pipeline di data science soltanto in Python.

Python non ha tanti dei metodi che ci sono in Pandas per fare aggregazioni.

Ad esempio, se io...

facciamo un esempio con Python.

Metti che io ho un dizionario e ho una chiave che è data e un'altra chiave che è valore.

Ecco, nelle date parto con primo gennaio, secondo gennaio, terzo gennaio e vado così via per tutto il 2022.

Ecco, e nei valori, magari, immagazzino quante unità di un certo prodotto ho venduto.

Se poi voglio fare una media mensile.

Ecco, se vuoi farlo puramente con Python comincia già ad essere un po' difficile.

Devi iterare manualmente su ogni elemento delle liste e poi devi manualmente ricordarti l'indice al quale sei e a che valore corrisponde.

Mentre Python ha già le sue subroutine predefinite che servono proprio per questo tipo di analisi abbastanza comune.

E a livello di performance invece ci sono delle strutture dati particolari che lo migliorano o più o meno possiamo dire che la performance è assimilabile al Play in Python? Visto che comunque sotto gira del Play in Python.

Dipende da come lo utilizzate.

Un errore che vedo spesso da principianti è di cercare di iterare sopra ogni riga di un data frame.

Cioè di dire, allora, prendo la prima riga del data frame e faccio questo, poi faccio questa la seconda riga, poi faccio questa la terza riga.

Ecco, se Pandas lo utilizzate così, allora è possibile che sia ancora più lento di fare tutto direttamente in Python.

Le parti performance critical di Pandas sono scritte in C, però per utilizzarle bisogna utilizzare dei metodi specifici di Python, quindi groupby e tutto.

Se utilizzate questi metodi, allora potrete utilizzare, potrete beneficiare dalla magia, dal performance improvement che otterrete dal codice scritto in C, anziché fare tutto in Python.

Ricapitolando, quindi, Pandas è un tool, una libreria che ci permette di caricare i dati, come detto prima.

Abbiamo detto trasformarli in un data frame e a quel punto fare dei filtri, modificare i dati e avere qualcosa in output.

Prima hai parlato di grafici, ecco.

Quando parli di caricare i dati, prima hai parlato di database, ma come si mettono in pancia realmente i dati a Pandas? Pandas ha dei connettori a vari database, quindi ci sono delle dipendenze opzionali che si possono installare e poi si può connettere Pandas a un database e magari scrivendo una query in SQL si può ottenere una Pandas data frame con i risultati.

Quindi, levami una curiosità, perché io buona parte dei tutorial li vedo sempre con CSV, gli dai in pasta un CSV e questa roba funziona.

In produzione quanto è usato il CSV? Che è un formato che mi sta sul culo, non potete immaginare quanto! Anche a me però mi sta sul culo meno dell'Excel.

Nonostante ciò.

C'è anche il CSV che è ancora più pane.

È utilizzato parecchio, devo dire.

C'era stato un user survey degli utenti di Pandas qualche anno fa e la funzione che la gente utilizzava di più era il read CSV, che era un po' deprimente.

Però si è utilizzato parecchio, cioè è semplice, però ha degli svantaggi, tipo che non ricorda i tipi dei dati.

Se salvate delle date in una Pandas data frame, allora avrete tutti i metodi che Pandas ha per poter lavorare con le date.

Nel momento in cui prendete questo data frame e lo salvate come CSV e poi lo rileggete in Pandas, avete perso i tipi.

E quindi quelle routine per fare trattamento efficiente con le date non funzioneranno più.

Perché Pandas non le autodetecta le date? Non di default.

Ok.

Quindi dovete ricordarvi o di passare l'opzione di detectarle, oppure di manualmente trasformarle.

Dire sta colonna contiene date.

Esatto, sì.

Mentre ci sono altri formati come il parquet che ricordano i tipi.

Quindi ci servono delle dipendenze in più, però per molti versi è un formato nettamente superiore.

Mi hai bruciato la domanda che avevo in testa immediatamente dopo che era su Avro e Parquet.

Sono dei formati poco conosciuti nel mondo dello sviluppo.

Ma che, questo ormai me ne parla costantemente Wi e mia moglie, sono di una potenza assurda e anche a livello proprio di prestazioni la lettura e la scrittura in quei formati è molto più rapida.

Ritorniamo a parlare di internals.

Andiamo a parlare di internals, ok? Voglio chiederti, Pandas in qualche modo eredita alcune dei limiti dei nostri linguaggi di programmazione.

Faccio un esempio classico, 0,1 più 0,2, quanto fa? Fa 3 o non fa 3? Perché se io lo chiedo al mio computer non fa 3.

E immagino che questo errore faccia bubble up anche con l'utilizzo di strumenti come Pandas.

Per cui la mia domanda è, questa cosa quando fa bubble up e arriva al data scientist, è un problema che il data scientist è noticeable al data scientist? Se ne accorge, gli rompe le balle? Oppure sono talmente marginali questi problemi che in realtà non arrivano a quel livello? Guarda, stai facendo delle ottime domande.

Cioè per essere qualcuno che ha detto che non lavora in data scientist, però stai facendo tutte le domande giuste.

Allora sì, Pandas con i tipi classici, questo è un problema.

Allora, perché spesso ci si ritrova con dei dati mancanti e il modo con il quale si rappresenta il dato mancante è none, not a number.

Però none è di tipo float.

Quindi se cominci con una colonna di tipo integer e hai soltanto un dato mancante, allora l'intera colonna diventerà di tipo float.

E poi ci saranno questi problemi di cui hai parlato.

Nel momento in cui fai operazioni aritmetiche con i float, ci sono problemi di precisione, utilizzano più memoria.

È veramente una rottura di scatole avere una colonna float, quando sarebbe bello avere una di tipo integer soltanto per poter immagazzinare un dato mancante.

Allora, in Pandas 0.25 forse o 1.0, comunque un po' di tempo fa, tre anni fa, tre quattro anni fa, è stato introdotto un tipo di data type diverso, ovvero nullable type.

Quindi questi permettono di immagazzinare integer, però di avere anche dei dati mancanti.

Il modo in cui lo fa è semplicemente tiene un array con i dati veri e poi tiene un secondo array che è soltanto un array di booleans che ti dice se il valore c'è o se il valore manca.

E nell'array originale magari c'è un valore sentinella tipo meno uno per rappresentare che lì il valore manca.

Questo però non è ancora il default, però apre un mondo di possibilità nuove.

Pandas 2 ha visto l'introduzione di un nuovo backend basato su PyArrow.

Allora, nominavi prima perché dicevi ah sì, la lettura di dati è rapidissima, ecco, è ancora più rapida se leggi nel backend di Arrow anziché quello classico di NumPy.

E l'introduzione di questi tipi nullable, quindi questi tipi che permettono di avere una colonna di integer con dei valori mancanti, questi hanno permesso lo sviluppo del backend con Arrow che a sua volta permette di avere una performance notevolmente migliore per certe operazioni.

Ora, è importante far notare che non tutto Pandas si può...

cioè questo backend di Arrow non funziona per l'intero API di Pandas, ci sono alcune cose che non sono ancora supportate, notevolmente il groupby non funziona ancora, però se pensiamo a Pandas 3 e Pandas 4, allora si può immaginare un futuro nel quale l'intero Pandas potrà funzionare con il backend di Arrow e quindi interoperabilità con altre librerie di DataFrame come Polars dovrebbe essere facilissima.

Lettura da formati come Parquet direttamente in Arrow sarebbe rapidissimo e questo è un po' il futuro, quello che abbiamo in mente, il futuro verso il quale ci piacerebbe andare.

Giusto una piccola nota, quando si parla di Arrow si parla di Apache Arrow, possiamo definirlo uno standard per definire questa struttura dati colonnare? Sì esatto.

Ok giusto per...

io mi sto spostando in un ambiente che non conosco in realtà, ho sempre paura e terrore di schiacciare il merdone, oppure paura e terrore che si affacci la signora e mi dica che cosa stai dicendo? Balla, stronzate! Abbiamo parlato di preparare i dati, elaborare i dati, però io so che Carmine aveva una domanda poi riguardante quello che succede nello step successivo però mi è appena venuta una domanda preliminare ancora, quindi Carmine ti chiedo di aspettare che mi è appena passata alla mente.

Ah ok, Python è un linguaggio non tipato, ok? Olascamente tipato, però finora abbiamo parlato di tipi, questa commistione, questo tool che fa largo uso di tipi in realtà è un linguaggio non tipizzato, crea dei problemi, dà dei problemi, oppure altra domanda, se Python fosse strettamente tipato sarebbe forse più facile per Pandas fare delle operazioni o è solo una mia sega mentale? Sarebbe più facile per Pandas come internals, non penso perché gli internals che sono critici sono scritti in C dove invece i tipi non sono come in Pandas che uno può scrivere dei tipi però alla fine se sono sbagliati non gli importa niente a nessuno purtroppo mentre in C bisogna scrivere dei giusti, quindi per gli internals non so quanta differenza farebbe, per gli utenti è possibile perché generalmente in un workflow di data science è bello poter mettere in produzione qualcosa che sia relativamente simile a quello che i data scientist hanno utilizzato per fare sperimentazioni, tipo se i data scientist hanno scritto del codice per fare delle sperimentazioni è bene modificarlo un po', pulirlo e tutto prima di metterlo in produzione però prendere quello che hanno fatto i data scientist, riscriverlo in un linguaggio diverso con strongly typed dover fare questo renderebbe troppo lungo il ciclo e sarebbe veramente difficile iterare sul prodotto, quindi se i tipi in Python fossero migliorati o resi un po' più stretti questo potrebbe permettere ai data scientist di fare il loro lavoro in Python con Pandas e tutto e poi nel momento in cui gli ingegneri vogliono fare il productionization di poter utilizzare i tipi di Pandas in un modo un pochino più stretto e poter essere apertiti prima se ci sono errori e tutto ci sono degli sforzi in questo campo, c'è Pydantic che è una libreria che offre una validazione a run time dei tipi in Python, c'è una libreria Pandas Stubs che adesso è mantenuta da alcuni dei Pandas Core Developers che fornisce dei tipi per Pandas, quindi se scrivi del codice in Pandas e hai installato questo Pandas Stubs e poi quando scorri MyPy dovresti poter vedere di che tipo è il risultato è ancora un po' un lavoro work in progress, non è completamente finito, però ci stiamo arrivando e secondo me questo è l'approccio giusto, piuttosto che cercare di spostare tutto un linguaggio diverso con altre caratteristiche, secondo me possiamo aggiungere più valore al mondo migliorando gli strumenti che già abbiamo So che Carmine aveva una domanda, hai introdotto la tematica a Pennello, quindi gli chiedo di farla, ma gli chiedo anche se prima di fare la domanda lui può leggere quel messaggio che ha scritto nella chat privata Prima stava parlando di Piv, insomma come diceva un mio collega, è tutto una stringa, se non lo è ancora non l'hai castata abbastanza, perché poi effettivamente alla fine si finisce lì e ci siamo finiti tantissime volte, specialmente quando andavamo a leggere dei dati non tipati da Excel di vario tipo o CSV, sempre questo gioco della stringa, magari c'eva lo solo spazio quindi non era più intero l'aspetto di uno spazio, ma alla fine è quello, fa parte anche quello del gioco In realtà la mia domanda, probabilmente il merdone lo sto per pestare io ora, ma in produzione, come si va in produzione con Pandas o più in generale cosa significa la produzione per un lavoro fatto da data scientist? Voglio parlare anche tanto di tutta la parte di machine learning perché ne so veramente poco e so che lì ognuno ha un'opinione diversa, ormai ne apro link e credo che stiamo un po' impazzendo nel giorno e c'è qualche cosa di nuovo ma in generale come si fa? E chi lo fa? Con grande attenzione.

Allora chi lo fa? Nei contesti in cui ho lavorato è stato un po' un lavoro che abbiamo fatto insieme data scientist con gli ingegneri e bisogna seguire le pratiche, le best practices, sicuramente fare il pinning delle versioni perché Pandas è sotto attivo sviluppo, sta cambiando in fretta e se voi avete sperimentato con Pandas 1.5.2 e poi in produzione scorre Pandas 1.5.3 è possibile che il vostro codice non funzioni più, lo so perché è così che ho cominciato a contribuire a Pandas quando ho avuto un mismatch tra versioni e mi sono accorto che è una cosa come vi dicevo prima che sarebbe dovuto funzionare però non funzionava più quindi si con tanti controlli in più, una cosa che trovo un po' fastidiosa che però non so come risolvere, non penso che ci sia una risoluzione facile, è che all'interno di un data frame se ci sono dei dati mancanti è abbastanza facile perderne traccia quindi ci sono dei dati mancanti, poi quando fai una somma come default i valori mancanti verranno esclusi, in molte operazioni i dati mancanti semplicemente vengono ignorati e questo può essere, magari è una cosa che il developer sta facendo apposta, però è anche possibile che il motivo per cui ci siano questi dati mancanti è per un errore di programmazione e quindi se volete usare Pandas in produzione consiglio di aggiungere dei check in più per dire cose come ok quando sono arrivato a questo momento non mi aspetto di avere valori mancanti ma se ci sono valori mancanti tirate un errore loud and clear, non continuate silenziosamente ad ignorarli perché altrimenti questo causerà problemi molto difficili da debuggare in futuro.

Ok, hai detto una cosa interessante, sto per testare un altro merdone sicuro, ma come si testa questa roba? Nel senso noi quando parliamo di software scritto da software engineers si tende sempre a porre, o almeno si dovrebbe, c'è chi lo fa più e c'è chi pensa sia un esercizio di stile anche questo, però si pensa tanto alla parte di testing.

Come funziona in ambito data science? C'è un equivalente della suite di testing che abbiamo diciamo dello sviluppo software più generalista? Oppure non, insomma, come effettivamente funzionano delle fixtures, fai delle robe insomma giustosissime per capire cosa sta succedendo che poi effettivamente cambiano i dati? Sì, ottima domanda, come tutte tra l'altro, veramente un piacere parlarvi.

Ecco, fare il testing nel data science secondo me è un livello ancora più difficile e questo è un problema perché i data scientists in genere già non sanno fare il testing normale, figuriamoci se devono poi imparare a fare una cosa ancora più difficile.

Quindi penso che sia veramente importante collaborare tra data scientists e ingegneri.

Servono test per assicurarsi che tutto il pipeline venga eseguito senza errori e questi tipo di test sarebbe meglio lasciarli agli ingegneri.

Servono anche test per poter dire non tanto che il codice scorra senza errori, ma per dire che i risultati siano statisticamente significativi, che l'accuratezza del modello sia buona.

Per questo generalmente si fa un processo chiamato cross validation, ovvero si fa il training su una certa parte di dati e si fa una previsione su una parte di dati che il modello non ha visto e si vede quanto spesso il modello ci ha azzeccato e quanto invece ha un po' sparato a caso.

Allora, sarebbe meglio se i data scientists si concentrassero su questo tipo di testing e gli ingegneri invece sul testing del pipeline, però tutti insieme poi possono fare uno smoke test, ovvero all'interno del CICD.

Generalmente è abbastanza difficile fare un intero cross validation perché richiede risorse abbastanza elevate, quindi quello che si può fare è semplicemente dire, ok, io faccio scorrere il modello però con un CSV con 5 righe, voglio assicurarmi che se metto questo CSV dentro tutta la pipeline che il modello faccia il training e tutto, voglio assicurarmi che nulla esploda.

È questo.

Non garantisce che il modello sia accurato o che darà delle previsioni che aggiungeranno del valore all'azienda, però è già una tranquillità in più.

Questo è interessante perché ovviamente non essendo il mio mestiere, ne sono comunque affascinato, e mi sono sempre chiesto, ok, ma tu fai il test, questa cosa come hai detto non è statisticamente rilevante, quindi che si fa? Nel senso, io so che se si rompe un mio test mi dice più o meno a che riga, più o meno che cosa si è rotto.

Ecco, qual è il processo di debugging per un data scientist? Che immagino sia comunque diverso da quello di un software engineer.

Totalmente, sì.

Allora, è anche un po' stressante perché è una cosa che generalmente le persone non capiscono.

Cioè, se un ingegnere dice, ah, il codice non funziona, datemi una settimana e bene o male un modo per aggiustarlo lo troverò.

Se qualcuno dice a un data scientist, ah, le tue previsioni sono accurate soltanto al 70%, entro la prossima settimana possiamo alzarlo all'80%.

Ecco, come data scientist tu non sai se ci riuscirai, non hai nessuna garanzia che riuscirai a scrivere un modello migliore o che riuscirai a pulire i tuoi dati adeguatamente.

Però, parlando di dati, secondo me il debugging nel data science dovrebbe cominciare proprio da lì.

Cominciate a rianalizzare i dati, ripuliteli, fate attenzione a tutto.

Generalmente è così che si migliora un modello, mentre cercando di aggiungere strati in più alla rete neurale, magari può aumentare il successo.

Stiamo rimastando il mardone, lo dico io così, non lo dici tu.

Vedo che il tempo è praticamente volato.

Io ho un'altra domanda, perché so che avete appena rilasciato la 2.0, quindi mi piacerebbe con te fare un rapidissimo momento changelog.

Potremmo fare la rubrica changelog all'interno del podcast? Questa cosa mi piace, ne parliamo nel nostro back-end, Carmine.

Facciamo un rapido momento changelog.

Cos'è cambiato di veramente? 2.0 sembra una major release, quindi aggiungo utilizzata Samver per il versioning e poi quali sono davvero le novità introdotte.

Va bene, un Pandas 2 in due minuti, vediamo se ce la facciamo.

Allora, innanzitutto, sì, c'è Samver, non strettissimissimo però sì, l'idea di base è che la versione patch è per le regressioni, la versione minore è per bug fixes, è per avvertire di futuri cambi che ci saranno, mentre la versione maggiore è per cambi che potrebbero essere backwards incompatible.

Allora, cosa c'è di nuovo in Pandas 2? Abbiamo accennato prima al nuovo back-end di Arrow.

Ripeto, non è completo, se cercate di utilizzarlo e c'è qualcosa che non funziona, non arrabbiatevi, questo è solo l'inizio, non siamo ancora arrivati alla destinazione.

Poi, cos'altro c'è di nuovo? Una cosa su cui ho lavorato come parte del mio lavoro, di cui sono abbastanza contento, è che adesso si possono rappresentare date che vanno indietro o avanti di miliardi di anni, perché prima le date si potevano rappresentare soltanto con una risoluzione di nanosecondi, e quindi si poteva andare indietro soltanto circa fino al 1700 o avanti fino al 2300.

Ecco, ora abbiamo giunto millesecondi, secondi, microsecondi, e quindi si può andare avanti o indietro tantissimo, quindi che stiate lavorando con uno scrittore di fantascienza o un archeologo, dovrebbe essere possibile lavorare con i loro dati.

Altri cambi in Pandas 2, ora leggere le stringhe con le date è diventato molto più consistente, prima il formato veniva un po'...

cioè, potevano esserci formati diversi all'interno della stessa colonna come default, e questo causava un sacco di confusione fuori dall'America, dove c'è un formato di date diverso rispetto a quello che hanno loro.

Loro cominciano col mese, noi cominciamo col giorno, questo causa un sacco di problemi.

Se volete a fine puntata poi facciamo un rant sia sulle date che sul sistema metrico utilizzato, che non è il sistema metrico decimale, e sulla quale potrei rantare per ore, visto che ho lavorato a lungo con gli americani.

Scusami Marco.

No, no, giusto.

Quindi ora, se proprio avete un motivo per il quale vi serve il comportamento di prima, potete utilizzarlo ancora passando format equals mixed, però non è più il default, quindi spero che così causi un po' meno confusione.

E poi un'altra cosa di cui sono contento è il copy on write.

Se avete provato a utilizzare Pandas, quasi sicuramente avete visto una cosa fastidiosissima chiamata setting with copy warning.

Una cosa per la quale se partite da una data frame e poi filtrate le righe in un qualche modo, oppure le colonne, e poi modificate la sotto data frame che avete creato, non si capisce mai bene se la data frame originale sarà modificata o meno.

E quindi c'era questo warning per avvertirvi di questo.

Ecco, ora come opzione c'è il copy on write, che vuol dire che tutto sembra che sia una copia, però la copia viene fatta effettivamente solo nel momento in cui modificate la sotto data frame, e quindi quella originale in teoria dovrebbe essere immutabile.

Per ora è ancora opzionale, però speriamo di poterlo far diventare il default in Pandas 3, che forse potrebbe uscire fra un anno.

Quindi avete già delle schedule pianificate? Sì, è una cosa fantastica.

Pandas è cominciato nel 2009, però per molto tempo è stato un lavoro della community fatto praticamente solo da volontari.

Mentre adesso abbiamo quattro persone che come parte del lavoro riescono a lavorare su cercare di migliorare Pandas.

Non è che tutto il nostro lavoro possiamo dedicarlo a Pandas, però almeno parte del lavoro, questo già fa un'enorme differenza, e quindi ora ci stiamo spostando molto più rapidamente e pensiamo di poter fare una major release ogni anno.

Questa è veramente l'importanza del contributo delle aziende verso queste librerie.

Anch'io in questo momento per esempio sono full time su codice open source.

Carmine lavora full time, anche lui ha suse su codice open source.

Quindi riusciamo in questo modo più fattivo, più forte a sostenere questo tipo di strumenti.

Il tempo è nostro avversario, quindi io ho un momento e poi passiamo subito al Paese dei Balucchi.

Come sempre ragazzi, io non so perché vengo sempre messo in mezzo in questa cosa, probabilmente perché sono l'unico che non si vergogna a parlare di soldi, ma non vedo perché vergognarsi.

È una cosa così bella parlare di soldi, perché i soldi sono veramente la cosa più bella del mondo.

Quindi donate perché dobbiamo fare una cena da massimo bottura con i vostri soldi.

Quindi è una cosa molto importante e siamo molto poveri, quindi donate copiosamente, veramente in tantissimi, mi raccomando dateci i vostri soldi e noi ne faremo l'uso più responsabile che se ne possa fare.

Ovvero metterli su delle cripto uscite da mezz'ora.

Il momento che mi prendo e ci prendiamo è quello per ringraziare chi ci sostiene, chi fa sì che quasi ogni settimana, perché abbiamo missato l'episodio della settimana scorsa, e io vi ho spiegato all'inizio perché, ma sono le persone appunto che si fanno carico e ci aiutano a pagare le bollette.

Questa settimana abbiamo una persona da ringraziare, Fabrizio Norvegna, che ci dona tre birre, quindi una a testa, e ce le beviamo con estremo piacere.

Ci lascia anche un messaggio, grazie ai ragazzi, continuate così.

Grazie Fabrizio per esserti preso cura di Gitbar, ed essere diventato un elemento, un po' come nell'open source, un elemento che si fa carico di un qualcosa.

Quindi grazie di cuore, noi solleviamo la nostra birra virtuale e facciamo cincina alla tua salute.

Grazie Fabrizio.

E' arrivato il momento tipico e topico di Gitbar, il momento in cui i nostri host e i nostri guest condividono con noi una libreria, un tool, un articolo, un video, un qualcosa abbia catturato la loro attenzione e reputo in importante condividerla appunto alla nostra community.

Quindi la domanda che voglio fare a Marco è, hai qualcosa da condividere con noi? Va bene, l'ho nominata prima e forse lo dico contro il mio interesse, però consiglio di dare uno sguardo a quest'altra libreria di DataFrame chiamata Polars.

Interessante, io ci ho anche già dato una mezz'occhiata, è un po' fuori dal mio ambito di competenze, ma noi comunque mettiamo il link nelle note dell'episodio.

Io non riesco a capire in realtà se Carmine è pronto, ce l'ha pronto il balocco o sta cercando rapidamente...

No, no, ce l'ho pronto.

In realtà sto guardando sul telefono perché il mio balocco è un pelino diverso.

È un'applicazione per il telefono, in questo caso per il Radio S.

Non so se esiste per Android, ma sicuramente ci saranno di simili e si chiama OneSec, che ho scoperto in realtà da qualche settimana e praticamente è un'applicazione che ogni volta che apriamo determinate app che possiamo scegliere, come ho fatto con Instagram, con TikTok, con Facebook, quando si va ad aprire c'è praticamente questo intermezzo di qualche secondo, dove praticamente ti serve a far riflettere sul fatto che la stai effettivamente aprendo e ti chiede se vuoi effettivamente aprirla o meno.

E serve anche un po' per non stare sempre con il telefono in mano.

È assolutamente utile, ho ridotto di tantissimo il mio tempo di permanenza su queste cose, ma è figa tutta la parte di analytics che ha.

Ed è interessante perché spesso prendiamo il telefono in mano e apriamo, non lo so, Instagram, Facebook o qualunque cosa e non ce ne accorgiamo nemmeno, lo facciamo veramente come rifletto condizionato.

Ho scoperto di aprire Instagram più di 40 volte in un giorno, una cosa veramente malata, insomma, quindi per chi voglia fare un po' di digital deluxe o avere più consapevolezza e più dati su come si usano determinate app, secondo me è veramente figa.

Si chiama V1Sec, la trovate sull'Apple Store.

Ecco il mio barone.

Bella.

Io in realtà mi sono già disintosicato dai social, però ho già in mente qualche persona a cui suggerirla.

Però una domanda, una volta che V1Sec mi ha analizzato i dati, posso poi importarli in Pandas e analizzarli? Non lo so, ma scommetto che se chiedi ti fanno l'export.

Allora, so che si sincronizza con Onkit o con Apple Health, secondo me se li chiedi te li danno.

In realtà è una bella domanda perché sarebbe interessante fare uno studio su tutte le persone che utilizzano quest'app.

È veramente terribile.

Ho messo anche il link ad entrato che non posso più aprire.

In realtà credo che se ci sono dei dati personali tu possa richiedere il dump.

Però non so in che formato e come.

Abbiamo parlato di data visualization.

Io ho un balocco legato alla data visualization.

Cercavo un tool gratis che non fosse Tableau, ma che fosse self-stabile.

Nuovamente grazie alla mia signora ho scoperto Superset.

Superset è un tool, credo stia sotto il cappello di Apache, infatti sì, scritto in Python per la data visualization.

È molto figo, c'è un sacco di connector, puoi fare filtri, robe, bello bello.

Quindi se ne avete l'occasione buttateci un occhio perché è parecchio figo.

Nel nostro mondo Superset non si conosce.

Nell'altra mia attività avevo il mio socio che mi chiedeva una dashboard rapida.

Essendo un'attività parallela io non posso alloccare tanto tempo.

Tipo con Superset sono riuscito a fargli una dashboard dettagliata e molto figa in roba di minuti.

Quindi buttateci un occhio, è un'ottima alternativa ai software commerciali come Tableau.

Devo dire, Tableau è un po' più potente, però questo è accessibile, non ha licenze, non ha rotture, è self-stabile e tanta roba.

Altro balocco che però è anche un cliffhanger.

Abbiamo parlato di Mastodon a lungo il periodo scorso.

Io, come alcuni di voi sanno, sto seguendo un po' la community Bitcoin.

Si parla parecchio di Nostr, che è un nuovo protocollo non solo per social network, ne parleremo presto a Gitbar.

Non vi dico altro, buttateci un occhio perché come protocollo, al di là del fatto che si possono fare una serie di cose che non sono solo social network, ma è un interessante protocollo simil-decentralizzato, perché in realtà si basa su un concetto di relay.

Stasera ho finito di installare il relay di Gitbar, giusto per fare un po' di prove.

Ma buttateci un occhio perché è interessante la filosofia che ci sta sotto e l'architettura dell'applicazione e del protocollo stesso.

Detto questo, io direi che in un'ora e mezza possiamo abbassare le luci nel nostro bar, passare lo straccio sul bancone e soprattutto ringraziare Marco.

Grazie Marco di essere venuto a trovarci, grazie di cuore.

Grazie a voi, è stato veramente un piacere.

È stato super figo scoprire cosa si nasconde sotto il cofano di uno dei tool più utilizzati dalla data science.

È stato bello scoprire le tue due anime, da software engineer e da data science, con le rispettive contraddizioni come ci sono in tutte le nostre categorie.

Mi è piaciuto tantissimo l'introduzione che hai fatto, sia sulla qualità del codice, che su come vediamo l'artefatto che stiamo producendo.

Che secondo me è una cosa che talvolta dovremmo fermarci e ragionare.

Stiamo costruendo qualcosa? Che cos'è questo qualcosa? Qual è il suo scopo? Qual è il suo lifetime? E perché devi assumere questa forma? Quindi grazie di cuore e io ringrazio anche Carmine.

Grazie a voi, avrei rifatto un po' di più.

Io l'ho messo in pausa, ma stai tranquillo che sia tu che il tuo allegro compare ci ricapiteremo qua a parlare di eventsourcing.

Non mi dimentico di voi.

Se ci stai ascoltando lo sai.

Stiamo aspettando solo che il carico di lavoro scenda e tu possa essere rilassato per venire a trovarci.

Detto questo Marco io ti ringrazio di cuore, ti ringrazio a nome anche di tutta la community di Gitbar.

Io vi ricordo rapidamente i nostri contatti, info.gitbar.it, etbrainrepo su Twitter e il gruppo Telegram.

Potete poi ritrovarvi su Telegram digitando Gitbar nel vostro Telegram client preferito.

Vi aspettiamo lì, siamo tanti e ci sono tantissimi nuovi scritti ogni giorno, quindi vi aspettiamo.

Grazie Marco, alla prossima.

Ciao ciao! Grazie a voi! Ciao! Grazie a voi!.