Sabato 25 novembre presso la Fondazione Aldini Valeriani (F.A.V.) a Bologna si è svolta la NoSlidesConf 2017, una conferenza molto particolare organizzata da The Wild Bunch, contraddistinta da una filosofia e un metodo ben precisi più che dal focus su specifici strumenti o linguaggi.
La particolarità sta nel fatto che i talk non prevedono l’utilizzo di presentazioni già confezionate (da cui il nome dell’evento).
Ogni presentazione è una sessione tecnica di live-coding, che dimostra direttamente cosa è possibile fare con lo strumento (linguaggio, framework, pattern, servizio, …) oggetto del talk.
Alcuni di noi hanno partecipato, chi per la prima volta e chi da habitué, e vorremmo condividere le nostre impressioni (nel caso l’immagine qui sopra non fosse spoiler sufficiente, vi anticipo che sono molto positive).
Competitive Programming for fun and self-improvement
Marco Arena, C++ Specialist di Scuderia Ferrari e leader dell’Italian C++ Community, ha parlato del competitive programming come opportunità per allenare le proprie skill da programmatore. Esistono diversi siti di competitive programming, ad esempio Codewars, CodinGame, HackerRank.
Il principio di funzionamento è abbastanza simile: il sito mette a disposizione un insieme di esercizi di programmazione dai kata più semplici a problemi complessi. Gli utenti hanno la possibilità di mettere alla prova le proprie capacità di programmazione risolvendo questi problemi in un linguaggio a scelta.
Partendo da questo spunto, Marco ha proposto alcuni problemi non eccessivamente complicati, ed ha spiegato come anche il problema più semplice possa essere affrontato da diversi punti di vista in un’ottica di miglioramento continuo.
Se i siti di competitive programming in senso stretto richiedono solo di risolvere un problema il più rapidamente possibile, questo può essere solo il punto di partenza.
Non appena viene risolto un esercizio, possiamo fare una breve retrospettiva e valutare altri possibili vincoli (“e se evitassi di usare if/else?”).
Oppure effettuare modifiche, implementazioni alternative (“come verrebbe con uno stream invece di un array?”), e la possibilità di introdurre pattern (“questo si potrebbe fare con una fold”).
Per chi si volesse mettere alla prova, su HackerRank trovate i problemi proposti insieme ai suoi spunti per estensioni.
Abituarsi a dedicare del tempo ogni giorno a risolvere uno o due esercizi del genere può aiutare a diventare più pronti nel riconoscere soluzioni a problemi comuni.
Ci si abitua anche nel porsi le “giuste” domande sul codice che stiamo scrivendo – senza contare che spesso questi esercizi vengono proposti anche nei colloqui di lavoro (soprattutto all’estero). Partendo da quest’idea, Marco ha iniziato ad organizzare incontri periodici di Coding Gym per divertirsi imparando e mettendosi alla prova insieme.
An “emotional” app with Xamarin
Il talk di Antonio Liccardi si è concentrato su due tecnologie che è possibile combinare con risultati interessanti.
Da un lato, i servizi cognitivi di Microsoft Azure offrono API per l’utilizzo di strumenti di intelligenza artificiale, ad esempio la possibilità di analizzare una fotografia per riconoscere la posizione di un viso al suo interno e le emozioni prevalenti.
Dall’altro, Xamarin è una piattaforma per lo sviluppo di app cross-platform, in due modalità:
- native, con la definizione di business logic condivisa e UI differenziate per piattaforma
- usando Xamarin forms, che permettono di descrivere anche le UI con un linguaggio di markup condiviso (e in certi casi inevitabilmente più limitato)
Durante la sua sessione, Antonio ha sviluppato in C# con Xamarin una semplice app in grado di inviare una fotografia ai servizi cognitivi Azure, e visualizzare il risultato dell’analisi a schermo.
Internal DSL design in Scala
In questa sessione Alessandro Lacava ci ha dato esempio della flessibilità di Scala, un linguaggio multiparadigma che si poggia sulla Java Virtual Machine.
Un Domain Specific Language, o DSL, è un “meta linguaggio” che consente di astrarre operazioni più complesse in istruzioni e costrutti più vicini al linguaggio naturale;.
Si pensi a cosa è in grado di fare lo Structured Query Language (SQL) nell’ambito dei database relazionali.
Mettendo a disposizione parole chiave di facile comprensione (dove il “facile” può essere soggettivo…), ci consente di operare su strutture dati complesse, nascondendo ai nostri occhi la reale implementazione di queste funzionalità.
Alessandro ho esposto con dovizia di particolari i gli strumenti che Scala offre agli sviluppatori per crearsi un proprio linguaggio, in grado di esprimere meglio gli intenti della logica di business all’interno del dominio della nostra applicazione.
Non avevo mai visto Scala prima d’ora, a volte ho avuto difficoltà a comprenderne la sintassi, ma ho apprezzato comunque la sessione; il mio scopo era quello di avere un breve assaggio di questo potente linguaggio, e devo dire che la mia originale prerogativa può ritenersi soddisfatta 🙂
Functional Refactoring
Come sviluppatori siamo (o crediamo di essere 😉 ) tutti bravi a suddividere problemi complessi in piccoli problemi più semplici, e comporre poi i risultati: la composizione è alla base della scrittura del software, qualunque sia il linguaggio.
Purtroppo, come ci ha fatto notare Matteo Baglini, l’eleganza e la semplicità di una composizione sono spesso minate dalla necessità di gestire casi particolari: ad esempio, se sto aggiungendo un prodotto ad un carrello di acquisto, devo gestire l’assenza del prodotto in magazzino, o il pagamento che non va a buon fine.
Una soluzione possibile per gestire questi casi speciali è quella di esplicitarli come oggetti di primo livello, a loro volta gestiti come elementi “agnostici” del loro contenuto.
Anziché usare solo un oggetto che rappresenta un carrello, verrà utilizzata una scatola in cui mettere quell’oggetto. Tale scatola potrà essere a seconda dei casi un TrueResult se tutto fila liscio o un FalseResult se ci sono stati errori.
A questo punto, si può cercare di invertire il proprio punto di vista per mantenere l’incapsulamento: invece di elaborare una sequenza di operazioni su oggetti diversi, il nostro software potrà diventare una catena di funzioni applicate allo stesso contenitore, che via via trasforma il proprio contenuto.
Un blocco di codice imperativo o a oggetti si può così trasformare in codice in stile funzionale – mettendo quindi a nostra disposizione numerosi strumenti a diversi livelli di complessità per la composizione delle funzioni (map, flatMap, apply solo per citare i più semplici). Il tutto supportato dalla solida base matematica della teoria delle categorie.
Imparare la programmazione funzionale non è sicuramente semplice, ma una volta superato l’impatto di funtori, monadi e morfismi, può fornire un punto di vista completamente diverso nell’affrontare i problemi.
Live coding a Mondrian art generator in Elm
Un talk particolarmente divertente, grazie alle battute di Ju Liu, cinese di nascita, cresciuto in Italia ed ora residente a Londra.
Per rompere il ghiaccio, cosa c’è di meglio che citare l’incipit della Divina Commedia, con la piccola variazione di sostituire Javascript alla selva oscura? Non ci sono dubbi: se spesso Javascript tant’è amaro che poco è più morte, l’incontro con Elm per Ju è stato come uscire a riveder le stelle.
Dopo l’ennesimo, frustrante, “undefined is not a function“, si è messo alla ricerca di un’alternativa, trovando una soluzione in Elm.
Elm è un linguaggio funzionale che mette a disposizione fra l’altro un transpiler per la generazione di Javascript (tutto sommato, Ju non ha nulla in contrario ad usare JS: l’importante è non doverci mettere mano direttamente 🙂 )
Per dare una dimostrazione delle potenzialità di Elm, Ju ha realizzato passo-passo un generatore di quadri in stile ispirato a Mondrian, assistito dall’eccellente compilatore e dai suoi messaggi accurati e precisi. Siamo così abituati a messaggi generici o fuorvianti che ottenere dal compilatore suggerimenti corretti su come sistemare un bug è stato quasi sorprendente.
Procedendo per piccoli passi e definendo via via un domain-specific language, ha raggiunto l’obiettivo desiderato con semplicità e naturalezza.
Ho trovato molto utile anche l’Elm Debugger: avvalendosi dell’immutabilità di tutte le strutture dati, permette di mantenere la cronologia di tutti gli stati dell’applicazione e farne un replay.
Per chi conosce React, Redux e i loro developer tools la cosa potrebbe essere familiare, personalmente trovo che produca sempre un certo “effetto wow”.
A Bite of Rust
Altro talk, altro linguaggio…
Dopo Scala, C# e C++, abbiamo avuto l’occasione di assaggiare anche Rust, linguaggio fuori dal coro originato dalla comunità di Mozilla.
Come tutti sanno, Mozilla è stata colei che, verso la fine degli anni ’90, ha rotto le uova nel paniere a Microsoft, proponenedo un nuovo broswer web alternativo a Internet Explorer, dopo la dipartita del precedente antagonista, Netscape.
Firefox ha avuto grande successo, ma dall’avvento di Google Chrome, le cose hanno iniziato a peggiorare.
Il browser di Mountain View ha rosicchiato velocemente quote di mercato a Firefox, diventando ben presto il favorito tra sviluppatori e semplici utilizzatori. Tra i tanti punti a favore, la velocità e la gestione separata dei processi si sono rivelate carte vincenti.
Mozilla, preso atto del cambiamento in corso, ha cercato un modo per tornare ad essere competitiva.
Serviva un browser più veloce, meno esoso in termini di risorse ed in grado di sfruttare al 100% l’hardware dei giorni nostri.
L’approccio è stato radicale: serviva un linguaggio veloce e vicino alla macchina come C, ma al contempo in grado di limitare la possibilità di “spararsi nei piedi”, come si dice dall’altra parte dell’Atlantico…
E così è nato Rust, linguaggio tanto interessante da riuscire ben presto a convincere anche molti sviluppatori fuori dalla community di Mozilla, e che oggi lo utilizzano proprio dove prestazioni ed affidabilità sono inderogabili.
Michele D’Amico ci ha dato un assaggio, ma è stato un bel boccone!
Il linguaggio ha alcune peculiarità come ad esempio la cosiddetta “ownership delle variabili”. A compile-time si ha la garanzia che nessuno alteri la stessa variabile in più punti del codice. Altri concetti, come borrowing e lifetime hanno trovato spazio nella presentazione, anche se 45′ erano troppo pochi per avere poter pretendere di più.
Introduction to type driven development in Idris
Un linguaggio dopo l’altro, siamo al turno di Idris, linguaggio funzionale con un potente sistema di gestione dei tipi – in Idris, i tipi sono first-class citizens.
Marco Perone, sviluppatore con spirito da matematico, ci ha dimostrato fin dove ci si può spingere nell’uso di questo sistema di tipi, usando come esempio il classico problema di programmazione della Torre di Hanoi.
Non solo si possono definire funzioni che accettano solo parametri dei tipi corretti (come in ogni altro linguaggio tipizzato). Sfruttando i tipi in maniera più pervasiva, è possibile arrivare a definire funzioni che accettano solo parametri con valori corretti!
Garantire il corretto utilizzo delle funzioni a tempo di compilazione permette di prevenire ogni sorta di problema in esecuzione.
Si può addirittura arrivare a sostituire parzialmente i test: se non è possibile chiamare una funzione nel modo sbagliato, diventano superflui tutti i test per casi negativi.
Approccio molto interessante e radicalmente diverso da quello dei linguaggi più comuni.
Cooking Akka.Net and ServiceFabric together
Alessandro Melchiori ha iniziato il suo talk spiegando innanzitutto l’Actor model, un modello matematico pensato per lo sviluppo di applicazioni concorrenti.
I punti chiave, in breve, si possono riassumere in:
- Ogni attore può inviare e ricevere messaggi a/da altri attori.
- Lo stato interno di ogni attore non è esposto all’esterno.
- Lo stato interno si può modificare solo tramite messaggi.
- Ogni attore è eseguito da un singolo thread e gestisce una sua coda di messaggi.
La combinazione di questi fattori consente di risolvere alla radice i problemi di concorrenza: ogni attore è un thread a sé stante, che non condivide in alcun modo lo stato con gli altri, prevenendo automaticamente problemi come deadlock, starvation, e così via.
Esistono diverse implementazioni dell’Actor model, fra cui Erlang, Elixir, Akka, Akka.NET e i reliable actors di Azure Service Fabric.
Con il semplice esempio di un contatore, Alessandro ci ha mostrato alcune delle potenzialità messe a disposizione dall’Actor model e dalle sue implementazioni in Akka.NET e Service Fabric.
Una volta creato un ActorSystem, è possibile avviare lo spawn di un gran numero di actors (anche milioni). Questi attori avranno un comportamento ben definito, immutabile o variabile come in una macchina a stati.
Gli attori possono essere definiti in gerarchie padre/figlio, per permettere l’utilizzo di diversi pattern e strategie.
Per esempio un attore può fungere da dispatcher per i messaggi diretti ai suoi figli, e può valutare come comportarsi nel caso un figlio fallisca (riavviarlo, o riavviare tutti i figli, o informare a sua volta il proprio padre).
Questo permette, fra l’altro, di isolare le operazioni a rischio di fallimento in fondo alla gerarchia di attori, limitandone l’impatto.
Si ottiene così un meccanismo di fault tolerance di gestione relativamente semplice – per esempio, un respawn dell’attore mantiene la stessa coda di messaggi e quindi permette di riprendere immediatamente il normale funzionamento.
È stato interessante ritrovare in una diversa implementazione concetti già incontrati in altre implementazioni dell’Actor model (la mia infarinatura di Elixir è tornata utile 😉 )
Create your own DSL in Kotlin
Cos’è un Domain-specific language? Per Victor Kropp, sviluppatore JetBrains nonché maratoneta e triatleta, si possono distinguere due tipologie di DSL:
- esterni: linguaggi creati per uno specifico compito, come SQL per l’interrogazione dei DB relazionali o VHDL per la modellazione dell’hardware;
- interni: linguaggi che possono essere definiti all’interno di un altro linguaggio.
Kotlin, linguaggio sviluppato da JetBrains, si presta particolarmente bene alla definizione di DSL. Tanto per fare un esempio, quello proiettato nella foto precedente è un blocco di codice Kotlin perfettamente valido.
Nonostante qualche tentennamento nell’esposizione Victor è riuscito a tenerci per tre quarti d’ora incollati alle sedie, provocando continui strabuzzamenti d’occhi e mormorii. Questo perché è riuscito a trasformare un blocco di codice per l’inserimento di appuntamenti in agenda in qualcosa che via via assomigliava sempre più a un testo scritto quasi in linguaggio naturale.
Grande conclusione per la giornata di talk, che ha rafforzato il mio desiderio di imparare Kotlin ed iniziare ad utilizzarlo sul campo.
Grazie Victor per gli insegnamenti che mi sono portato a casa e che ho potuto condividere con la mia gilda su Kotlin.
Per ulteriori approfondimenti sul tema gilde in Intré, vi consiglio la presentazione del nostro collega Emanuele nel nostro articolo su IAD 2017.
Conclusioni
Dopo gli ultimi talk col botto (parlando con gli altri partecipanti, anche quello di Andrea Francia ha fatto fuoco e fiamme!), è il momento dei saluti. Tutti riuniti in una sala, dopo il doveroso ringraziamento a sponsor, speaker e partecipanti, arriva l’agognata lotteria, con in palio eBook e licenze di JetBrains.
Complimenti agli otto fortunati che si sono portati a casa un premio! Noi purtroppo non siamo fra quelli, ma sicuramente non ce ne andiamo a mani vuote: i grandi talk della giornata ci hanno lasciato tante nuove conoscenze e molta voglia di sperimentare.
Non mancheremo alla prossima edizione!