Una chiacchierata con:Gabriele Galatolo, Back-end developer e Data Scientist

Back-end Developer & Data Scientist, una doppia definizione, vuoi provare a spiegarci in cosa consiste il tuo lavoro?

È sempre complicato dire in maniera sintetica qual è il mio lavoro. Da tempo ho scelto di dire che sono uno sviluppatore, ma tutti pensano subito al tipo dietro al computer che scrive codici. Cosa che faccio, se non fosse che la mia realtà è distante dall’idea che si ha normalmente dello sviluppo (quello legato ai servizi che tutti usiamo nel quotidiano).

Per complicare la cosa, non solo mi occupo di software development in un ambito con delle specificità rilevanti (quello dei dati), ma affronto i progetti con un’ottica particolare, che toglie il fuoco dalla sola estrazione dell’informazione che il cliente vuole capire dai suoi dati, per ragionare in maniera più ampia su come garantire che questa estrazione funzioni… Sono sempre stato ancorato al motore di quel che succede, è una parte che in genere si conosce poco o per niente: lo sviluppo infrastrutturale (o middleware) è però ciò che consente di garantire un certo livello di prestazioni, o di rendere una soluzione scalabile…

Lavorare a livello infrastrutturale o middleware significa prendersi carico di tutte queste informazioni senza necessariamente conoscerne la semantica. I progetti di data science sono una pipeline ben definita (estrazione dati, preprocessing, modello, visualizzazione); noi ci impegniamo a ottimizzare ognuno di questi blocchi. Ad esempio nel data storage (come per altri componenti di Princess*) mi preoccupo di come i vari tipi di databases espongono le informazioni, ma posso ignorare  il contenuto dei dati su cui lavoro. Almeno quando non mi occupo della parte di estrazione di conoscenza e servizi al cliente in progetti, ad esempio, di computer vision o basati su reti neurali.

Quindi, oltre ad una doppia definizione, hai proprio un doppio ruolo; questo comporta uno sguardo diverso nell’approccio ai progetti?

Probabilmente sì. Quando mi occupo della parte di data science io non riesco a non chiedermi anche come ottimizzare la soluzione, come strutturarla, come non far scoppiare tutto, o non far durare l’analisi cent’anni. Qual’è il limite oltre il quale non spingersi? sono domande che non tutti nello sviluppo si pongono.

Forse questo sguardo mi viene da lontano. Io vengo dal mondo dell’informatica (mi considero un informatico in senso scientifico), ma la prima idea, la prima sensazione che l’informatica serva per trovare soluzioni funzionanti, semplici e veloci a problematiche complesse, credo che mi venga da lontano. A casa abbiamo sempre avuto il computer; io ci facevo solo i giochini, ma mio padre no. Lo vedevo mentre studiava i manuali  e trovava il modo per fare nuove cose, così ho iniziato a provare anch’io. Comunque, a un certo punto da uno che spippola mi sono trasformato in uno che usa la materia in maniera diversa, grazie anche alla mia prima prof di informatica, che il computer non ce lo ha fatto usare praticamente mai, per tutto il primo anno. Perché l’informatica prima di essere un linguaggio di programmazione (per cui se scrivi una riga sei un programmatore) è uno strumento per risolvere problemi di automazione in modo efficiente.

L’informatico affronta problematiche complesse e le sue soluzioni possono essere replicate in molti ambiti… hai presente la teoria delle code? Si può applicare al contesto dei supermercati come alla gestione dei dati. Ho lavorato nell’ambito delle piattaforme di high frequency trading: lì la rapidità di estrazione dei dati era fondamentale. Se le risposte non arrivavano nel giro del millisecondo aprivano una issue.

Questa esperienza, l’attenzione alla performance dello strumento che sviluppiamo, l’ho portata molto qui in Kode, perché le cose che facciamo sono intensive – sia in termini di quantità di dati che trattiamo, sia i framework che utilizziamo (che sono molto pesanti). E’ vero che non abbiamo limiti di tempi dell’ordine del millisecondo, ma se, ad esempio, nell’industria, alla fine di un batch dobbiamo essere in grado di dare i risultati dell’analisi sulla produzione appena conclusa, abbiamo pochi minuti prima che inizi il batch successivo.

Direi che per tornare alla domanda iniziale in realtà non esco mai né da un cappello né dall’altro e il mio sguardo ai progetti è sempre composto da entrambi i punti di vista.

Ci fai qualche esempio di attività di sviluppo infrastrutturale nel mondo della Data Science?

Ci sono attività molto orientate (specifiche del nostro settore) come il data storage; ma lato infrastruttura ci occupiamo anche dello sviluppo di framework come Princess e di tutti quegli strumenti che riducono la ripetizione dello sviluppo o semplificano e ottimizzano le integrazioni.

Un altro strumento, ad esempio, su cui stiamo lavorando è un Execution Assistant, che permette di sviluppare funzioni serverless, togliendo la responsabilità a chi sviluppa di occuparsi del deploy.

C’è tutto un movimento, che secondo me prenderà sempre più piede, che mira a consentire allo sviluppatore di non preoccuparsi di come e dove il suo software, o la funzionalità che sviluppa, sarà fatta girare.

Questo approccio si applica bene alla Data Science, perché lavorando in una pipeline con fasi ben strutturate e spacchettabili, è possibile dire a chi sviluppa la parte di analisi dati, di machine learning e modelli: “Scegli liberamente i linguaggi e i metodi che ritieni più adatti, perché come girerà, con che risorse, eccetera, non ti riguarda, se ne occuperà qualcun altro”; o meglio qualcos’altro.

*Hai citato un paio di volte Princess, puoi dirci cosa è? Lo hai sviluppato tu?

Sì, in effetti sono il papà. E pure la mamma… In sintesi Princess è un framework proprietario di Kode che racchiude, come una vera e propria cassetta degli attrezzi, gli strumenti di sviluppo per il Data Scientist. Ma Princess è un’altra storia, la raccontiamo la prossima volta.