Codemotion Milano 2016

Venerdì – Keynote: The Most Important Thing

Il keynote è stato curato da Mike Lee. Si è parlato poco di codice bensì di altre tematiche quali la nostra dipendenza dall’elettricità, i tanti comfort che diamo per scontati e scenari apocalittici dovuti alla crisi e a catastrofi ambientali.
Come faremmo a procurarci cibo e acqua se un giorno i supermercati non riuscissero più a essere riforniti? La risposta di Mike è quella di adottare uno stile di vita che, pur non potendo fermare questo inevitabile processo, lo aiuti a rallentare, permettendo all’umanità di adattarsi al cambiamento. Qui il video integrale della presentazione.

L’insegnamento di un talk come questo, del tutto inaspettato per un evento come Codemotion, è lo spunto di staccare ogni tanto lo sguardo dal monitor e riflettere: la mia routine quotidiana, spesso l’unica cosa che vedo, non è la cosa più importante in assoluto, e dando il giusto peso alle cose si può riuscire a vivere in modo più equilibrato, responsabile e soddisfacente.

Venerdì – Promises Are So Passé

Tim Perry ha riportato l’attenzione sui nostri argomenti preferiti con un talk su JavaScript asincrono e sulle feature di ES 2015 e oltre che rendono più semplice la scrittura di tale codice. Tim è partito dal modo di scrivere codice asincrono risalente a qualche tempo fa, con le callback, passando alle Promise e quindi a come i generator ci permettano di semplificare il Promise Hell, arrivando infine ai nuovi costrutti di async e await.
Non ancora ufficialmente inclusi nelle specifiche di ES7, implementano nativamente i costrutti che combinano generator e promise, rendendo il codice molto più leggibile.

Devo dire che il livello di dettaglio era veramente adeguato e seguendo gli esempi che accompagnavano questo ragionamento è stata una presentazione semplice da seguire ma allo stesso tempo molto istruttiva. Credo che ognuno avrebbe avuto qualcosa da imparare da un talk di questo genere. Qui le slide della presentazione di Tim e qui il video integrale della presentazione.

Venerdì – Getting started with Go

In questa sessione Florin Patan ha fatto una bella panoramica su Go, illustrando sia le più rilevanti peculiarità del linguaggio che le caratteristiche della comunità che vi gravita attorno.

Fin dalla pubblicazione delle sue prime versioni, nel 2007, Go si è contraddistinto per alcune feature che tuttora attraggono gli sviluppatori; partiamo dalla semplicità, filo conduttore della sua architettura.

Quando si compila un programma scritto in Go (che ricordiamo è disponibile per tutte le maggiori piattaforme), quel che si ottiene è un unico file binario eseguibile. Niente librerie, niente runtime da installare sulla macchina di destinazione: tutto quel che serve è pronto all’uso. Questo, in ottica di architetture a microservizi e deploy veloci, è sicuramente una manna dal cielo.

La concorrenza è di una semplicità disarmante: attraverso le goroutines, si possono eseguire parti di codice in parallelo, senza preoccuparsi di tutti quegli aspetti spinosi che in genere i thread si portano dietro. Le goroutines non sono thread veri e propri, ma dei light-weight thread gestiti interamente dal runtime di Go, il quale nasconde allo sviluppatore tutta la complessità che deriva da operazioni di sincronizzazione e verifica di eventuali race-conditions.
La comunicazione fra goroutines avviene attraverso i channels, componenti ad-hoc in grado di abbattere tutti gli ostacoli di questo altro aspetto della programmazione multithread.

Go non è né un linguaggio a oggetti, né un linguaggio funzionale; permette di avere oggetti e funzioni come “first-class citizens“, ha il concetto di interfaccia (implementata “automagicamente” quando un tipo ne soddisfa il contratto) ma non favorisce l’ereditarietà, bensì la componibilità degli oggetti.
I test sono possibili senza bisogno di installare nessuna libreria, in quanto tutto quel che serve è già presente nell’installazione di base.

Insomma, ci sono un sacco di aspetti interessanti che val la pena approfondire, e che purtroppo non possono trovare spazio per il taglio di questo articolo.

La comunità di Go cresce costantemente; insomma, val la pena prendersi un po’ di tempo e fare qualche esperimento, come ad esempio hanno fatto i ragazzi di Parterre (che hanno tenuto il talk “We started with RoR, C++, C#, NodeJS and… at the end we chose Go): dopo diversi tentativi, solo grazie a Go sono riusciti a soddisfare i requisiti di performance necessari alla loro applicazione, ovvero web API con picchi di 10000 richieste al secondo.

Grazie quindi a Florian (@dlsniper) per averci fatto venire l’acquolina in bocca, e complimenti per il suo contributo a Go (in quanto mantainer del plugin IntelliJ per Go).

Venerdì – The hitchhikers guide to UXing without a UXer

La proposta di Chrissy Welsh parte dallo spunto di come fare UX senza un esperto di UX.
Speravo ardentemente che un talk di questo genere potesse darmi dei trucchetti e delle linee guida per risolvere facilmente il mio problema di riuscire a realizzare interfacce grafiche “ben poco allettanti”. La risposta di Chrissy è riassunta in una slide con le parole “Greatness doesn’t take shortcuts”: se vuoi un buon risultato devi lavorare sodo per ottenerlo.

È stato un rapido ma esaustivo excursus sulle tecniche da utilizzare e i principi da seguire per progettare una buona UX. Qui le slides

Venerdì – Going loopy

Come si è potuto constatare dall’agenda, questa edizione di Codemotion ha puntato molto sul linguaggio Go, con addirittura cinque talk.
Quello che ho seguito io, presentato da Eleanor McHugh, ha affrontato un task semplice come quello di scorrere gli elementi di un array e ha mostrato diverse possibili implementazioni in Go facendo emergere tutti gli aspetti e peculiarità di questo linguaggio in soli 40 minuti (qui le slides del talk).

Devo dire che non è stato per nulla facile seguire tutti i dettagli soprattutto per me che non avevo mai visto Go. Quello che ho portato a casa da questo talk è che Go ha dei concetti interessanti che sicuramente vale la pena di approfondire.

Venerdì – Knowledge is Power: Getting out of trouble by understanding git

Il talk su git di Steve Smith di Atlassian è stato uno dei miei preferiti.
L’aula era stracolma tanto che gli organizzatori hanno dovuto bloccare gli accessi impedendo l’ingresso a nuovi partecipanti. Alla domanda iniziale “chi di voi usa git” praticamente tutti hanno alzato la mano.
Con questo punto di partenza comune Steve è partito dai git internals, passando quindi per branch e tag fino ad arrivare a comandi di alto livello come bisect.

È stato un talk magistrale: un buon livello di dettaglio supportato da slide ben fatte che lo rendevano ancora più coinvolgente, come se la personalità di Steve non bastasse. Sono sicuro che tutti quelli che hanno partecipato sono tornati a casa conoscendo un pochino meglio git. Qui le slides e qui un video della stessa presentazione fatta al devoxx.

Venerdì – React – render() to DOM

L’ultimo talk della giornata, è stato tenuto da Boris Dinkevich su React. Più nello specifico Boris ha approfondito un aspetto tecnico molto interessante e peculiare di questa libreria ovvero cosa avviene al render(): tutti conoscono il Virtual DOM, ma pochi hanno idea di che cosa sia effettivamente.
In modo molto semplice Boris ha introdotto un concetto per volta usando come pretesto la realizzazione di una sua libreria, BorisJS, con le stesse funzionalità di React. Versione dopo versione, miglioramento dopo miglioramento, ha coperto i dettagli principali che caratterizzano React.

È stata una presentazione molto specifica ma estremamente utile per capire un concetto chiave di una libreria così popolare. Qui il video della stessa presentazione fatta al ReactNext 2016.

Sabato – keynote Coding Culture

La giornata di sabato non è stata da meno a partire dal keynote di Sven Peters, il secondo di Atlassian in questo Codemotion.
È difficile mettere per iscritto una presentazione di questo genere, ma soprattutto trasmettere energia e passione come ha saputo fare Sven.
Raccontando lo stile e i valori di Atlassian ha dato consigli concreti su come migliorare la propria cultura e ha saputo ispirare e motivare tutti i presenti a essere sviluppatori migliori contagiando anche quelli che ci stanno attorno.

Devo dire che con questo talk e con quello di venerdì su git, Atlassian ha fatto una figura veramente eccellente a questo Codemotion. Qui una pagina di Sven stesso con presentazione e video

Sabato – The (almost) lost art of Smalltalk

Ogni anno mi diletto a seguire conferenze ed eventi sull’ignoto…del mondo dei linguaggi di programmazione.

Quest’anno è toccato a Smalltalk, una pietra miliare nella storia della programmazione.
Forse non tutti lo sanno, ma fu grazie ad Alan Kay, suo inventore, che Smalltalk è passato alla storia come il primo linguaggio di programmazione ad oggetti. Nonostante fu lo stesso Alan Kay ad introdurre il termine “object”, più tardi trovò a doversene pentire; nella sua idea di linguaggio infatti il concetto cardine alla base di tutto era quello della comunicazione tramite messaggi fra entità che chiamò oggetti perché al momento non gli veniva in mente niente di meglio. Quel che ne derivò poi (ereditarietà su tutto), non fu certo quello che avesse in mente, come ebbe a dire successivamente (prendetevi 5 minuti e leggete, ne vale la pena!).

Nella sua presentazione, Nikolas Martens (@rtens_) sono rimasto stupito a più riprese; ha esordito dicendo che Smalltalk “blowed is mind“, esprimendo l’intenzione di provare a fare lo stesso con noi; nel mio caso c’è riuscito perfettamente.

La presentazione è stata molto coinvolgente; niente slides, ma un tablet collegato a mo’ di lavagna virtuale e codice scritto ed eseguito al momento.
La prima volta che ho rischiato di cadere dalla sedia è quando Nikolas ha aperto Pharo, spiegandoci cosa fosse. Come altri linguaggi di programmazione, anche Smalltalk ha ricevuto negli anni diverse implementazioni; una delle più note è  Squeak, che non è una semplice implementazione del linguaggio con relativo runtime e librerie di base, bensì un intero ecosistema; Pharo è un fork di Squeak, che si pone come obiettivo quello di fornire allo sviluppatore un moderno ambiente di sviluppo.
Lanciato l’ambiente, Nikolas ha mostrato come tutto al suo interno sia programmabile; oltre a scrivere codice nell’editor interno, è possibile modificarne aspetto e comportamento, andando ad adattarlo di volta in volta alla situazione che si sta affrontando. Una volta terminato lo step di implementazione corrente, Nikolas committava (usando git); nel commit però non ci finiva solo il codice, ma uno snapshot completo dell’intero sistema!
Immagino che non sia di facile comprensione, e altrettanto lo è da spiegare per iscritto, per cui ritengo sia necessario che l’occhio voglia la sua parte (qui alcuni video).
In pratica ogni step di sviluppo viene cristallizzato in uno snapshot (nel gergo di Pharo prende il nome di “image“), che contiene tutto il necessario: non solo il codice modificato, ma anche l’ambiente e gli eventuali web server usati internamente per lo sviluppo di applicazioni web. I vari step intermedi di codice posso essere invece a loro volta committati all’interno dell’ecosistema di Pharo, utilizzando il suo sistema di versionamento interno.

Insomma, non un semplice talk su un linguaggio di programmazione ma uno scorcio su un mondo completamente inusuale: bravo Nikolas!

Sabato – Progressive Web Apps: trick or real magic?

Maurizio Mangione ha preparato un talk davvero interessante. Questo argomento che non tutti conoscono è uno dei più caldi del momento: si tratta di applicazioni web che fanno un passo oltre rispetto a quelle tradizionali avvicinandosi alle app native.
Una Progressive Web App infatti, tramite il supporto del browser, è in grado di avere supporto offline, sincronizzarsi in background, ricevere notifiche push, aggiungere l’icona sulla home. L’effetto finale dovrebbe essere molto simile a una app nativa dando il vantaggio all’utente di non dover necessariamente installare un’applicazione.
La presentazione di Maurizio ha spiegato dal punto di vista tecnico come questo sia possibile e ha illustrato come sviluppare una semplice PWA a partire dal Service Worker che è il cuore dell’app.

Quello che secondo me è mancato a questa presentazione è una introduzione più generica con qualche demo che facesse rendere conto della magia delle PWA. Qui potete consultare le slide dell’intervento.

Sabato – Gang of Four Patterns in a Functional Light

Mario Fusco di Red Hat ha illustrato come alcune feature di Java 8 possano permettere di superare la verbosità di Java in favore di una versione più semplice è leggibile grazie a un approccio funzionale e alle lambda function.
L’aspetto positivo di questa presentazione è che Mario ha effettuato il refactoring in diretta mostrando come convertire codice in modo funzionale. Su GitHub è possibile trovare il codice con gli esercizi risolti.

Grazie a questo talk ho imparato a vedere i pattern in una maniera diversa e ad apprezzare l’approccio funzionale. A mio avviso però, quello che metteva in luce questo talk non era tanto l’inutilità dei pattern, come ho sentito dire ad alcuni, ma piuttosto come risolvere un problema intrinseco nel linguaggio Java, anche se forse a questo proposito ho qualche pregiudizio.

Sabato – RxJS – destroy the state machine!

Altro talk interessante, tenuto da Stenver Jerkku sulla programmazione reattiva. Stenver ha fatto una presentazione semplice ma che ha lasciato trasparire l’impegno e la passione che ha per questo argomento.
Tramite dei grafici molto intuitivi per rappresentare gli stream, concetto base della programmazione reattiva, ha posto le fondamenta utili per approfondire poi questo argomento. Sicuramente il concetto di Stream è molto interessante anche se faccio un po’ fatica a vederlo applicato a un’applicazione web tradizionale, sarà che sono abituato a pensare a stream come un flusso di dati molto fitto mentre il flusso di click di un utente mi sembra tutt’altro.

Ad ogni modo è stato molto utile avere un introduzione di questa libreria in modo da poterla considerare quando dovrò scegliere il prossimo stack tecnologico. Slides della presentazione.

Sabato – Software Heritage: let’s build together the universal archive of our software commons.

L’ultimo talk al quale ho assistito prima della chiusura è stato quello di Stefano Zacchiroli su Software Heritage.
Ha raccontato come per lui e il suo gruppo il codice non contenga solo istruzioni ma vera e propria conoscenza e come pertanto vada preservato. Proprio questo è l’obiettivo di Software Heritage: preservare potenzialmente per sempre tutto il codice open source con tanto di versionamento.
Sì, avete capito bene, Stefano vuole farsi una copia di tutti i file di tutti i commit di tutti i progetti open source. E l’ha già fatto, in parte, raccogliendo più di 150 terabyte di dati deduplicati da GitHub, Debian e GNU.
A parte lo scopo che uno può condividere o meno, sicuramente una parte che tutti hanno trovato interessante è la tecnologia che sta dietro un progetto del genere.
Si tratta di un grafo Merkle, simile a quello usato da git per archiviare i commit, molto performante tanto da poter essere gestito tranquillamente da un database postgres.
Dall’altra parte vi è un software che esegue periodicamente la scansione degli indirizzi web registrati tenendola aggiornata sulla disponibilità delle pagine e attivando il crawler quando necessario.

I dettagli tecnici da riportare sarebbero veramente molti e ne potete trovare qualcuno nelle slide di Stefano. Devo dire che sono rimasto veramente colpito e ispirato da un progetto così ambizioso. Faccio i miei complimenti a Stefano e al suo gruppo.

Sabato – Closing Keynote: BDD – Bias driven development

Mario Fusco ha raccontato come tutti i preconcetti che abbiamo ci impediscano di lavorare al meglio delle nostre possibilità, tanto per dirne una vi è mai capitato di sentire la frase “ma si è sempre fatto così”?
Ma Mario è andato più a fondo toccando temi più vicini alla nostra psicologia. Dopo tanti esempi altamente istruttivi ha concluso con alcuni consigli motivazionali, anche se un po’ controcorrente, dicendo di smetterla queste metodologie, stand-up meeting, post-it, pomodori, planning poker, (guardare per credere) di smetterla di giocare e d’iniziare a essere quello che siamo cioè ingegneri, ampliando il nostro Toolbox in modo da avere sempre lo strumento giusto al momento giusto.
A parte il discorso metodologico che non condivido appieno, concordo invece sul fatto che tutti questi nostri giochi non devono essere il fine, ma devono essere un semplice strumento, che possiamo tenere nel nostro tool box insieme a Java e agli altri strumenti “validi”, che ci deve aiutare nel nostro mestiere d’ingegneri.

A questo link è disponibile la registrazione dell’intervento di Mario.

Conclusioni

Mi avevano detto che il Codemotion era un po’ calato ultimamente come qualità dei contenuti. Quello che posso dire io, avendo partecipato a quest’ultimo, è che se effettivamente il livello si sia abbassato, le edizioni precedenti devono essere state veramente spettacolari. Non posso dire che sia stato tutto perfetto ma sicuramente sono stato contento di aver partecipato.