Il racconto del team di Orobix
THE Ò-BLOG
Pycon IT 2023: WOW!
16 Giugno 2023
Tempo di lettura: 5 minuti
Il 2023 è stato il terzo anno per Orobix alla Pycon IT e anche l’anno in cui abbiamo cercato di uscire dalla nostra comfort zone per ritornare, dopo PyconX (Orobix: AI gets to work!), a condividere un po’ della nostra esperienza con altri sviluppatori.
Pycon si conferma essere una conferenza di grande interesse e valore formativo sotto molti aspetti: tecnico, creativo, sociale.
La community è più attiva che mai e sentirsi accolti ogni anno da facce conosciute, aprendosi alla possibilità di conoscerne di nuove, è uno dei principali punti di forza di questo evento. ❤️ Senza nulla togliere all’alto profilo professionale dei relatori, che permette di astrarre la complessità dei temi tecnologici, portando gli speech ad un livello non necessariamente avanzato, ma che catturi l’attenzione di tutti. È pienamente raggiunto l’obiettivo di fornire una contaminazione di spunti tecnologici, best practice, librerie, tool, ed in generale garantire un contesto fertile per collaborazioni ed idee.
Siamo soddisfatti dell’apprezzamento ricevuto per i nostri due talk tenuti dai colleghi Federico Belotti e Refik Can Malli, l’affluenza e le domande poste dal pubblico ci incoraggiano a continuare in questo percorso di comunicazione e continuo miglioramento. 🙏
Speriamo che la community ne sia uscita arricchita quanto noi, che ogni anno cerchiamo di apprendere il più possibile, ma soprattutto di convincere i colleghi rimasti a casa ad unirsi a noi negli eventi futuri.
D’altronde anche il nostro manifesto lo dice: "WE ARE at our best together, when we share visions and circulate knowledge."
È anche per loro che abbiamo pensato di riassumere alcuni dei talk che ci sono piaciuti di più e che pensiamo valga la pena riascoltare.
1 - "Robyn: A fast async Python web framework with a Rust runtime" - Sanskar Jethi - raccontato da Franco Parodi
Sanskar Jethi è l’autore di Robyn, un framework web Python con runtime Rust. Si tratta di uno dei framework web Python più veloci, tant’è che consente prestazioni quasi native pur mantenendo la facilità di scrittura del codice Python.
Suscita molto interesse in quanto permette di ottenere:
- alte performance
- facilità di sviluppo
- multithread, funzioni asincrone
Oltre al fattore performance, un’ulteriore caratteristica che lo rende interessante è il fatto che non richieda alcuna competenza su tecnologie web (reactjs, vue, angular… ) in quanto è sufficiente conoscere Python, a favore cioè di un’autonomia nell’implementazione di soluzioni web (non sono necessarie figure fullstack). Alcune tra le principali caratteristiche che lo contraddistinguono:
- scritto in Rust
- runtime multithread
- semplice API
- supporto funzioni sincrone/asincrone
- sviluppo e supporto costanti.
Risorse:
- Talk: PyCon Italia 2023 – Spaghetti – Friday – YouTube
- GitHub: /robyn
2 - Don't just test, my friend, test better - Cheuk Ting Ho - raccontato da Mattia Federici
Vi siete mai trovati bloccati in righe di test che sembrano tutte uguali? Avete passato un po’ di tempo a pensare a tutte le possibili liste di integer che potete testare? Forse Cheuk Ting Ho ha qualche consiglio per voi!
Pytest dispone di una grande quantità di strumenti creati appositamente per testare diversi scenari che si discostano dai casi base.
Vediamoli:
- Parameterize: consente la parametrizzazione dei test, dando la possibilità di eseguire lo stesso codice di test con n input diversi.
- Hypotesis: si basa sulle proprietà degli input, trattati in modo generico secondo ‘strategie’. Ad esempio, la strategia “List of Integers” genera casi limite come liste vuote, numeri interi molto grandi, zeri o negativi in modo pseudocasuale e ripetibile durante i test.
- Fixture: questo decoratore consente di mantenere gli elementi “costanti e invariati” durante l’esecuzione dei test. È possibile aggiungere un contesto di validità della fixture, come modulo, classe, sessione o pacchetto, per limitarne l’ambito.
- Markxfail: sapendo in anticipo che un test fallirà su un certo sistema operativo o a causa di un bug noto, markxfail permette di saltare un test in modo elegante.
Risorse:
3 - Rust is easy - Luca Baggi - raccontato da Marco Bignotti
Cosa succede se scriviamo codice python all’interno di un programma Rust? Letteralmente, cosa succede se inseriamo questa funzione:
def hello(name):
return "Hello " + namein un file main.rs e lanciamo cargo run? Sembra assurdo, ma il risultato può essere sorprendente. No, il codice non verrà compilato, se qualcuno se lo stesse chiedendo. Ma ecco il messaggio di errore che riceviamo:
help: write `fn` instead of `def` to declare a function
Allora perché non sostituire semplicemente def con fn, compilare di nuovo e vedere cosa succede?
Questa è la brillante introduzione fornita da Luca Baggi per motivare il suo discorso introduttivo su Rust. L’idea è che si dovrebbe essere in grado di scrivere codice Rust valido, per quanto semplice, iniziando a scrivere codice Python e guardando i messaggi di errore uno alla volta.
In effetti, con poche iterazioni, Luca è riuscito a scrivere una funzione Rust valida che si compila con successo. Il tutto senza mai consultare la documentazione ufficiale, i corsi online, i MOOC, Copilot, StackOverflow o qualsiasi altra risorsa online/offline vi venga in mente. Solo guardando i messaggi di errore.
Ma qual è il punto? Perché stiamo parlando di Rust a una conferenza su Python? E perché noi, come sviluppatori Python, dovremmo essere interessati a un linguaggio di basso livello come rust?
Per anni abbiamo sentito dire che Python è facile. È vero, ma non è del tutto esatto. Dovremmo piuttosto dire che Python è accessibile. Qual è la differenza? Beh, la sintassi è bella e facile da capire, ma nulla ci impedisce di commettere gli stessi errori che gli sviluppatori (junior?) fanno sempre nel tempo (me compreso). Per citarne alcuni: scrivere interfacce difficili da rispettare e da capire, non rispettare le API solo perché, beh, possiamo farlo, non rispettare i tipi, ignorare i design pattern quando è opportuno,….
Rust ha preso una strada diversa e previene molti di questi problemi per costruzione, spesso in fase di compilazione. Python non ha tutti questi strumenti integrati. Tuttavia, data la sua natura dinamica, nulla ci impedisce di adottare gli stessi pattern e le stesse buone pratiche che hanno reso Rust un linguaggio così popolare.
Risorse:
4 - Creating an AI-Python Infrastructure that works with a reasonable scale - Andrea Guzzo - raccontato da Refik Can Malli
Andrea Guzzo ha parlato del motivo per cui molti progetti di AI non vengono utilizzati in produzione e ha condiviso consigli su come creare prodotti di AI utilizzando tecnologie moderne e Python come linguaggio di programmazione principale. Ha spiegato che è possibile creare prodotti di AI di valore senza aver bisogno delle risorse di una grande azienda tecnologica.
Ha descritto uno stack completo di un framework Python che può essere eseguito completamente on-premise e ha mostrato esempi che includono anche componenti UI per interagire con i task NLP. Poiché il campo dell’NLP si muove molto velocemente, ha spiegato brevemente il trend attuale dei large language model e ha fornito esempi di scenari di implementazione. Procedendo sulla descrizione di casi reali ha menzionato gli MLOps maturity level e le loro specifiche. Infine, ha presentato la libreria Bear per lo sviluppo in Python.
Risorse:
5 - Remote Teams are autistic - Miriam Perrone - raccontato da Lisa Lozza
Non tutti i talk alla Pycon trattano di programmazione, gli argomenti sono eterogenei e io tendo ad approfittare della varietà proprio per aggiornarmi sui temi tecnici, ma anche per imparare qualcosa di più dal punto di vista delle softskill o del management.
Il titolo che ho considerato più accattivante e attuale quest’anno è stato quello del talk di Miriam Perrone: “Remote Teams are autistic“. Miriam è riuscita, partendo dalla sua esperienza come autism consultant, ad analizzare i team remoti, per trovare alcuni interessanti tips sulla gestione di tali team. Miriam spiega quali sono le similitudini tra persone nello spettro dell’autismo e team remoti, concentrandosi sul tema della comunicazione. Una persona autistica può non essere in grado di comprendere la differenza tra due toni di voce o interpretare il linguaggio del corpo, concentrandosi quindi solo sulle pure parole. Allo stesso modo i sistemi di comunicazione che utilizziamo di più dalla diffusione del remote working (chat e email) possono portare ognuno di noi ad avere difficoltà nell’interpretare le più semplici comunicazioni. Da quì si sottolinea l’importanza dell’essere consapevoli di queste difficoltà, del non fare assunzioni, ma di assicurarsi che ci sia piena comprensione delle informazioni condivise, cercando di essere più chiari possibile nella comunicazione.
Il talk mi ha ricordato anche quanto sia fondamentale ricordare che ognuno di noi è diverso, bisogna impegnarsi nel riconoscere quali modalità di comunicazioni sono più efficaci e quali meno, per ogni membro del team. Penso che questo possa considerarsi uno dei segreti per costruire un team consapevole, coinvolto e performante.
Risorse:
6 - Code Debugging and Refactoring with OpenBugger: a Python Library for Self-Supervised AI Debuggers - Tommaso Furlanello - raccontato da Federico Belotti
Tommaso Furlanello ha esplorato il nuovo mondo dei LLM come code-assistants, concentrandosi sulla “constatazione che GPT raggiunge il suo limite non quando produce codice difettoso, ma quando non riesce a correggerlo”. Passando in rassegna i recenti progressi della ricerca sui LLM, Tommaso ha osservato che per fare finetuning di modelli così grandi (come OpenAssistant) è necessario disporre di un’enorme quantità di dati e di calcolo, e quando si è sprovvisti di GPU, occorre trovare idee creative per generare buoni dati in modo sintetico. Tommaso ha poi spiegato come è riuscito a generare una quantità ragionevole di dati per mettere a punto un LLM per ragionare sul codice, individuare i bug e risolverli: 2K esercizi Python di LeetCode con le soluzioni sono stati analizzati per ottenere la rappresentazione Concrete Syntax Tree (CST), poi usando il suo OpenBugger ha iniettato bug invertibili nella rappresentazione CST ottenendo 20K esempi di codice con bug e indicazioni di debug, che sono stati infine usati per generare prompt simili al Question-Answering da dare in pasto ai LLM al momento del finetuning.
Risorse:
