Dall’idea alla realizzazione di un prototipo (testato!), in 5 giorni.

E’ il Design Sprint, un processo che condensa le migliori metodologie di product design, design thinking e business strategy, consentendo, in soli 5 giorni, di validare un’idea di business riducendo al minimo rischi e investimenti.

Ideato da Jake Knapp e Google Ventures nel 2010 e utilizzato da tutte le maggiori aziende della Silicon Valley, è un metodo che punta a sconvolgere gli usuali paradigmi di sviluppo incentrati attorno alla produzione di un MVP su cui testare un’idea di business (con conseguenti investimenti iniziali ad alto rischio), puntando invece sulla realizzazione di un prototipo il più possibile realistico, nell’arco di una sola settimana lavorativa.

Adatto per definizione alla dinamicità delle startup, è un metodo estremamente flessibile, applicabile anche in contesti più strutturati come medie e grandi aziende, dove può essere utilizzato per risolvere situazioni critiche legate al rilancio e/o aggiornamento di prodotti già esistenti, per loro natura molto difficili da evolvere.

Come funziona?

Suddividendo il tempo in momenti ben definiti, ognuno con un obiettivo semplice, ma al tempo stesso fondamentale, per raggiungere l’obiettivo finale: il test con i futuri potenziali utenti/clienti del prodotto da sviluppare.

Il metodo favorisce il ragionamento individuale, minimizzando tutte quelle situazioni che solitamente sfociano in brainstorming incontrollati, prediligendo la discussione strutturata e il processo decisionale collettivo e critico.

Le principali fasi del Design Sprint (Understand, Diverge, Converge, Prototype, Test) accompagnano il team di lavoro in un’esperienza immersiva ed estremamente stimolante che, se fatta con la giusta attitudine, consente di ottenere dei risultati difficilmente raggiungibili con mesi interi di lavoro, ottimizzando e rendendo puri tutti i processi decisionali tipicamente stressanti e time consuming.

La nostra esperienza

MV Labs ha avuto l’onore di partecipare al primo workshop sul Design Sprint a livello mondiale organizzato da Tangible e tenutosi a Bologna il 20 giugno, toccando con mano l’energia e l’efficacia del metodo di Knapp, in una giornata all’insegna della produttività. Abbiamo ripercorso e affrontato le 5 fasi dello Sprint sviluppando un progetto di una fantomatica startup del mondo della finanza, con Jake in persona che ci ha condotto attraverso la giornata dispensandoci preziosi consigli e condiviso le esperienze avute nelle più grandi aziende della Silicon Valley.

La sessione si è svolta con l’introduzione del contesto e della problematica a cui l’app da realizzare voleva proporre una soluzione: la gestione automatizzata del risparmio personale. Negli Stati Uniti il fenomeno “mani bucate” è dilagante, ecco perché una app del genere ha ben più di un motivo valido per essere proposta sul mercato. Abbiamo quindi dedicato la giornata applicando i principi del Design Sprint a questo contesto, ripercorrendone le 5 fasi principali, con l’obiettivo di individuare e testare possibili soluzioni implementative.

1. Understand: obiettivo della prima fase di un Design Sprint è lo sviluppo di una conoscenza comune e condivisa del contesto operativo della soluzione da testare. Si procede quindi con l’intervista di figure chiave all’interno dell’azienda, individuando potenziali categorie di clienti, i problemi da risolvere nello sprint, gli obiettivi a breve e lungo periodo e analizzando possibili soluzioni già esistenti sul mercato.
2. Diverge: scopo del secondo step dello Sprint è quello di esplorare quante più soluzioni possibili al fine di individuare pattern ricorrenti eliminando le soluzioni non condivise e concordare sulle ipotesi di sviluppo successive. In questa fase il lavoro viene eseguito perlopiù individualmente, attraverso l’utilizzo di tecniche di sketching e mind mapping. Risultato della fase è l’individuazione del percorso critico da testare nell’ultima fase.
3. Converge: è in questa fase che si decide cosa verrà prototipato e testato, analizzando in dettaglio le scelte fatte precedentemente (eliminando le ipotesi non realizzabili) e producendo lo storyboard del prototipo da realizzare nella fase successiva.
4. Prototype: si procede sviluppando il prototipo vero e proprio, attraverso l’utilizzo di strumenti veloci e flessibili (essenzialmente tool di presentazione interattiva) al fine di ottenere un risultato il più vicino possibile all’esperienza di un prodotto reale.
5. Test & Learn: il prototipo viene fatto testare a un gruppo di 5 utenti, che vengono registrati e intervistati, mentre il team di lavoro analizza e verifica le assunzioni iniziali. Al termine di questa fase lo sprint si conclude con la raccolta dei risultati e con il planning di una successiva iterazione di correzione e aggiustamento.

E’ stato interessante e stimolante vedere come sia possibile arrivare, anche in una sola giornata e con team composti da persone con ruoli ed esperienze completamente diverse, a soluzioni concrete e condivise da tutti, facendo progressi difficilmente immaginabili a inizio giornata. Uno dei segreti è l’utilizzo di strumenti (perlopiù carta, penna e lavagne) conosciuti e utilizzati facilmente da chiunque, che consentono di far comunicare tutti allo stesso livello, annullando le barriere tecnologiche e favorendo lo scambio di idee continuo. Altrettanto importante l’importanza di un clima positivo e proattivo, orientato al goal e alla creazione di forti affinità professionali, il meno possibile contaminato dalle interruzioni (niente telefono o distrazioni durante gli Sprint!).

Non potevamo chiedere di più da questa esperienza, e non vediamo l’ora di introdurre i nostri clienti ai risultati dell’applicazione del Design Sprint!

Vuoi provare l’esperienza del Design Sprint nella tua azienda?

Sei una startup con un’idea da realizzare? Hai un’azienda con un prodotto da rilanciare? Devi trovare delle soluzioni concrete in poco tempo da testare sul mercato? Contattaci e prova con mano l’esperienza di un Design Sprint!

Quale occasione migliore quindi della prima edizione di Elm Europe, la prima conferenza in Europa su Elm, un linguaggio funzionale per creare applicazioni web che ci ha da sempre incuriosito in MV Labs e che non vediamo l’ora di utilizzare in qualche progetto complesso – l’abbiamo già sperimentato con ottimi risultati per relizzare la parte client di php-middleworld.

La conferenza è iniziata con il keynote di Evan Czapliki, il creatore di Elm, che ha parlato di come evolvere un’applicazione Elm man mano che la complessità aumenta. Infatti Elm ha ormai raggiunto il punto in cui diverse aziende hanno in produzione codebase di decine di migliaia di righe di codice Elm, e l’organizzazione del codice è fondamentale per garantirne la mantenibilità. Il punto focale da cui è partito Evan è stato scoprire le strutture dati più adatte allo specifico caso d’uso, senza lasciarsi necessariamente influenzare dal loro aspetto grafico. Per esempio una lista di checkboxes potrebbe essere modellata con strutture dati diverse a seconda delle regole che devono essere applicate a quella lista: deve essere possibile aggiungere elementi? Ogni elemento è indipendente dall’altro o può capitare che la selezione di un checkbox influisca su un altro checkbox? C’è un limite massimo sul numero di checkboxes selezionati? Le risposte a queste domande possono indirizzare la scelta verso la struttura dati più adatta al caso d’uso. Inoltre, una corretta modellazione dei dati diventa fondamentale anche per documentare la correlazione tra varie componenti di un’applicazione. Altro punto importante è stato ridurre le API pubbliche che ogni componente espone, in modo da avere modo di mantenere all’interno delle strutture dati gli invarianti di dominio che non possono essere completamente specificati a livello dei tipi.

Sulla modellazione delle strutture dati si è soffermato anche Greg Ziegan nel suo talk Building reordable UI in Elm, suggerendo di costruire le nostre API come se fossero dei veri e propri prodotti, passando attraverso ricerche di mercato, determinando cos’è effettivamente riutilizzabile, proponendo alla community delle API prima effettivamente di implementarle.

Altro talk molto interessante è stato Rethinking Style di Matthew Griffith in cui ha presentato la sua libreria style-elements che affronta il problema di definire il layout dei componenti di un’applicazione da un nuovo punto di vista. L’idea di fondo è, come i tipi forniscono garanzie per il codice, fornire un meccanismo che garantisca che il layout di un’applicazione sia completamente definito una volta che il codice compila. In questo modo diventa possibile pensare ad un refactoring dello stile similmente a come un compilatore in un linguaggio tipato ci guida nel refactoring del codice.

Il secondo giorno della conferenza si è aperto con il keynote di Richard Feldman che ha affrontato a suo volta il tema di scalare un’applicazione Elm. Similmente al tipico ciclo utilizzato in TDD, Richard ha proposto di procedere nello sviluppo seguendo il ciclo Build -> Discover -> Refactor. Un’approccio del genere è facilmente utilizzabile in Elm dove refactoring anche massicci non comportano eccessivi problemi grazie all’ottima assistenza fornita dal compilatore. Altro punto molto interessante del discorso è stato la sottolineatura della differenza tra l’architettura delle applicazioni secondo una prospettiva object oriented (in cui è compreso per esempio anche il modello a componenti tipico di React), in cui è necessaria avere una comunicazione padre/figlio per passare messaggi tra i vari componenti, e dall’altro lato applicazioni puramente funzionali dove invece la sorgente della verità non è distribuita ma centralizzata.

Molto energico ed interessante il talk Elm from a business prospective di Amitai Burstein, il quale è partito dalla definizione di successo di un progetto, che deve essere realizato nel tempo previsto, con il bubget concordato e rendendo felice il cliente. La sua ricetta per ottenere ciò è sviluppare solo l’essenziale stimando le singole issue in box temporali ristretti (più si allungano più è facile sbagliare le stime). Elm aiuta sicuramente in questo processo in quanto l’architettura ben definita e poter contare sull’aiuto del compilatore permettono di avere un’idea più chiara dello sforzo richiesto e, cosa non da poco, mantenere gli sviluppatori felici!

In generale è stata una conferenza interessante in cui è stato possibile fare il punto della situazione dello sviluppo di Elm e conoscere varie persone che stanno sviluppando con Elm progetti molto interessanti. Il formato della conferena si è rivelato un po’ particolare, con una pausa dopo ogni talk per favorire la socializzazione tra i partecipanti. Il cibo francese come da aspettative non ha deluso, quindi direi che ci sono tutti i presupposti per pensare già al prossimo viaggio a Parigi!

Alla prossima conferenza!

Con l’avvento dei Personal Computer e di Internet soprattutto, una ventina di anni fa, le potenzialità di ciascun essere umano sono state notevolmente estese. All’epoca, per conoscere qualcosa era necessario trovare e consultare un’enciclopedia; chiedere a qualche amico saggio; chiamare qualche servizio a pagamento. Con l’avvento di Internet, di Altavista prima, e di Google poi, di Wikipedia, tutto ciò non è stato più necessario. Qualche click e tutta la conoscenza umana era (ed ancora è) a nostra disposizione. Non solo; abbiamo cominciato a fare acquisti, a giocare, a controllare lo stato delle nostre finanze; tutto online. Tutto sul PC. Nel bene, e nel male. Siamo stati di fatto costretti a trovarci di fronte ad esso per poter fare tutte queste cose.

Con l’arrivo degli Smartphone lo scenario è notevolmente cambiato: informazioni e servizi ci hanno seguito. Abbiamo potuto fare tutte queste cose attraverso un unico dispositivo, un piccolo display portatile. Di conseguenza, molta enfasi è stata data alla progettazione di questi dispositivi: dal punto di vista dell’hardware (con schermi sempre migliori e batterie sempre più durevoli), ma anche dal punto di vista del software. Delle interfacce, in particolare. La User Interface, così come avveniva per i personal computer, è stata il punto di contatto naturale, quello più evidente, tra l’utente e la tecnologia. Ed ecco che la User Experience e la User Interface sono state (e spesso ancora sono) confuse. La ricerca non si ferma, tuttavia.

Si diffondono Siri, Cortana, Alexa. Le interfacce vocali, insomma. Come ci fa notare Ben Sauer (in quello che è stato secondo me uno dei migliori talk della conferenza), non c’è più bisogno di un’interfaccia visuale. Jennifer Fraser e Lina Bonapace rafforzano ulteriormente il concetto quando introducono Internet of Things e raccontano di come l’enfasi si stia finalmente staccando dallo schermo, per spostarsi su quella che è la vera esperienza dell’utente; quella che questi ha con i servizi. Concetto richiamato in causa anche da Alberta Soranzo, che nel suo keynote pone enfasi sulla visione olistica di un sistema e del valore da questi fornito.

Finalmente, risulta dunque evidente che gli oggetti non sono altro che “avatar”, ovvero punti di contatto tra l’utente e un sistema. Emerge il concetto di service design; di qualcosa che va al di la della semplice interazione tra un utente e uno schermo. Jeroen van Geel al suo workshop parla di Customer Journey Mapping, uno strumento per analizzare il processo di interazione con un sistema anche prima e dopo il suo utilizzo; Jared Spool e Rachel Daniel raccontano di come aumentare la consapevolezza sull’esperienza utente in un team; su come gestire il rapporto tra ricercatori e designer UX, product manager e reparto sviluppo. Non parliamo più, quindi, solo di oggetti o applicazioni; o processi. Parliamo di sistemi. Sistemi complessi.

L’elettronica, l’informatica, la psicologia, il design (non solo digitale) diventano dunque elementi tutti imprescindibili per costruire un’esperienza utente che sia fluida, coerente, pratica. Diventa dunque imprescindibile anche la necessità di abbattere i Silos di conoscenza. Bisogna trovare il modo per facilitare la collaborazione tra figure con background diversi tra loro. Sono dunque contento di aver portato anche la nostra esperienza con un lightning talk sull’Event Storming (slide), una tecnica che – oltre a facilitare notevolmente l’esplorazione di un dominio – colloca sullo stesso piano figure con background diversi, facilitando l’individuazione e quindi il raggiungimento di obiettivi comuni.

Sono convinto che la strada intrapresa – a livello generale, ma anche nel nostro piccolo – sia quella giusta; che ci si stia finalmente rendendo conto che progettare un sistema non sia preoccuparsi di come e dove mettere bottoni, tabelle e label; ma piuttosto organizzare un’esperienza continua nel tempo e tra dispositivi, superando le difficoltà e sfruttando le potenzialità dei vari strumenti coinvolti.

Queste le mie riflessioni al termine di UX Scotland 2017, una delle conferenze di riferimento a livello mondiale sulla User Experience, a cui sono stato davvero contento di partecipare. Credo mi abbia lasciato spunti notevoli su cui continuare a riflettere e sviluppare idee e progetti. Il cambio di prospettiva su ciò che ci aspetta è secondo me notevole: abbiamo incognite e sfide affascinanti davanti a noi. Che ne pensi tu? Mi farebbe piacere conoscere la tua opinione!

Erlang Factory Lite era la prima conferenza italiana a tema Erlang/Elixir. L’aver scelto Roma come location della conferenza e la presenza di due dei creatori di Erlang ha attirato partecipanti da tutta Europa per un pubblico molto internazionale.

La giornata si è aperta con il talk di Robert Virding che ci ha guidati in un pellegrinaggio verso la terra promessa nella quale il software è altamente concorrente, facilmente integrabile con sistemi esterni e resistente ai fallimenti interni. Come da filosofia Erlang, è necessario accettare che prima o poi qualcosa fallirà e progettare il nostro software in maniera da gestire gli errori per far si che questi influiscano il meno possibile sul funzionamento delle applicazioni.

Il pomeriggio, invece ci ha riservato un ottimo talk di Joe Armstrong che ci ha raccontato come ha utilizzato Erlang per controllare da remoto e programmare il funzionamento di un Sonic Pi per riprodurre fedelmente un brano di Rachmaninov. Sfruttando l’ottima gestione della concorrenza di Erlang, ogni singola nota era prodotta da un processo separato, ciascuno con il suo specifico timer indipendente dagli altri. Il risultato finale è paragonabile ad un concerto in cui più di 19000 pianisti suonano insieme un singolo brano producendo con una tempistica perfetta una nota a testa.

Molto interessanti, dal mio punto di vista, anche i talk di Michele Finelli, che ci ha introdotto la teoria dei tipi illustrando la corrispondenza tra programmi in un linguaggio tipato e dimostrazioni logiche delle proposizioni corrispondenti, e di Jo Liu che con Elixir e qualche RaspberryPi ha creato una replica del funzionamento di Internet. In chiusura, Francesco Cesarini ci ha raccomandato l’importanza di un monitoring accurato, sia per prevenire problemi gravi quando iniziano a manifestarsi, sia per essere capaci in seguito di ricostruire accuratamente l’origine dell’issue. Per fare questo sono necessarie tre componenti fondamentali, le metriche dell’utilizzo dei singoli componenti, i log degli eventi che succedono nel sistema e gli allarmi, eventi che possono scatenare conseguenze (per esempio, svegliare qualcuno se si è verificato un problema grave).

Il giorno successivo mi sono spostato da Roma a Ferrara per poter prendere parte anche a UniversalJs Day, la seconda edizione della conferenza che raccoglie le esperienze più interessanti riguardanti l’utilizzo di Javascript non strettamente in un client web.

Ha aperto la giornata Maurizio Mangione che ci ha introdotto nel mondo delle progressive web applications, soffermandosi sopprattutto sull’utilizzo del Service Worker, che ci permette di ottimizzare il critical rendering path e di avere un controllo completo sulle nostre strategie di caching. A seconda del nostro caso d’uso, possiamo decidere di andare sempre a pescare dalla cache, prima dalla cache e, in caso non ci sia quello che cerchiamo, dalla rete, oppure prima dalla rete e in caso di fallimento dalla cache; in quest’ultimo caso, riusciamo ad ottenere il funzionamento di una applicazione web anche in scenari offline o di connessione instabile.

Matteo Frana e il nostro Andrea Coiutti, ciascuno nel proprio talk, ci hanno raccontato le problematiche e le soddisfazioni che hanno incontrato implementando server side rendering in applicazioni complesse, il primo utilizzando React, il secondo con Mithril. Dal routing fino alla condivisione dello stato e l’internazionalizzazione, ci hanno guidato attraverso i vari passi e le piccole accortezze che permettono di implementare correttamente un’applicazione isomorfica. Un dettaglio dei vari passaggi potete trovarlo su https://isomorphic-mithril.mvlabs.it.

Il pomeriggio Francesco Strazzullo ci ha presentato Pixi JS, un framework per la creazione di interfacce web utilizzando direttamente WebGL. Questo consente di saltare il ciclo di rendering del browser andando a interagire direttamente con le potenzialità della scheda grafica per ottenere animazioni 2D molto fluide.

La giornata si è chiusa con il talk di Francesco Raimondo che ci ha introdotto nel mondo del retro gaming in Javascript utilizzando Phaser.io, mostrandoci come si può realizzare facilmente un gioco veramente addictive da godersi nel browser!

Complimenti agli organizzatori di entrambe le conferenze per la gestione degli eventi!

Ci vediamo alla prossima conferenza!

PSR-7

Tutto ha avuto inizio con PSR-7, un insieme di interfacce condivise per rappresentare i messaggi HTTP in PHP, consentendo un’astrazione delle applicazioni dal layer HTTP.

La caratteristica principale di PSR-7 è di essere indipendente dal framework e questo permette di poter utilizzare le sue interfacce con diversi framework quali Symfony, Zend Framework, Laravel e molti altri.

Questo grande vantaggio permette agli sviluppatori di scrivere codice indipendente dal framework con ampie possibilità di essere riutilizzato in altri progetti basandosi soltanto sulle interfacce PSR-7.

MIDDLEWARE IN PHP

L’altra parola chiave è middleware: dal momento in cui l’ecosistema PHP ha beneficiato di un’astrazione sufficiente dai messaggi HTTP, il passaggio successivo è stato pensare alla modalità migliore per realizzare applicazioni web a partire da questa astrazione.

Citando Matthew Weier O’Phinney, il concetto di middleware può essere riassunto in una singola funzione

function (request, response) : response

L’idea di fondo è che gli oggetti rappresentati nella richiesta HTTP e nella risposta HTTP vengano passati a una funzione che fa qualcosa con questi per restituire una risposta HTTP.

Questo modello dimostra di essere veramente semplice e utilizzabile per scopi diversi. Infatti, è già stato utilizzato con successo in diversi altri linguaggi di programmazione.

La modalità standard di comporre molteplici middleware è di passare un terzo argomento alla funzione in modo da permettere di invocare un altro middleware:

function (request, response, next) : response
{
    // do something on request
 
    response = next(request, response)
 
    // do something on response
 
    return response
}

Vari framework, come Zend Expressive, Slim, Radar o Spiral si basano già sul concetto di middleware per creare applicazioni web.

RIUTILIZZARE MIDDLEWARE

Ora che abbiamo un modello così facilmente componibile basato su un’astrazione HTTP indipendente dai vari framework, possiamo iniziare a scrivere componenti riutilizzabili che potrebbero funzionare per ogni progetto PHP. Di sicuro il lavoro dello sviluppatore sarà notevolmente facilitato.

Abbiamo, quindi, la possibilità di avere middleware che si occupa di loggare tutte le richieste ricevute, middleware per il routing, middleware per gestire le autenticazioni oppure per gestire le sessioni degli utenti. Il ruolo del framework diventa semplicemente quello di tenere uniti tutti i pezzi del nostro lavoro nel miglior modo possibile.

La domanda che sorge spontanea a questo punto è: c’è qualcuno che ha già implementato il middleware che potrebbe servirmi per l’applicazione che sto sviluppando?

E’ ARRIVATO PHP-MIDDLEWORLD!

Per ora l’unica risposta alla domanda precedente poteva essere fornita da Packagist, Github, o – nel peggiore dei casi – da google.

Dopo aver ricevuto così tanto dalla community nel corso degli anni, abbiamo pensato che fosse giunto il momento di restituire qualcosa di importante. Così è nato php-middleworld.com, con l’intento di dare agli sviluppatori PHP degli strumenti per trovare rapidamente il middleware di cui hanno bisogno (spesso potendo scegliere tra varie implementazioni).

IL FUTURO

Abbiamo già in mente diverse migliorie per php-middleworld.com.

In primo luogo ci piacerebbe permettere ai diversi sviluppatori di aggiungere il middleware da loro sviluppato in modo da far crescere il nostro database grazie al contributo di tutti.

In seguito vorremmo aggiungere anche middleware compatibile con PSR-15, in modo da essere pronti quando questo nuovo standard sarà approvato.

Non dilunghiamoci troppo, per informazioni più dettagliate visita php-middleworld.com e segui @phpmwd su Twitter!

Stay tuned!

Giunto alla sua quinta edizione, quest’anno dotJS si sposta nella cornice moderna e all’avanguardia del meeting center di “Les Docks de Paris” a Seine-Saint-Denis, per ospitare 1200 sviluppatori giunti da tutto il mondo per assistere ai talk sugli argomenti più caldi della stagione. Ovviamente non prima di un’ottima colazione ipercalorica a base di brioche e cioccolata.

La formula è sempre la stessa: una serie di interventi alla “TED Talks”, di 18 minuti ciascuno, con speaker scelti tra i migliori nel loro campo, che si alternano sul palco nel corso di una giornata ricca di spunti e idee da sperimentare, senza dimenticare gli spazi dedicati alle presentazioni dei partner, al networking, e alle esibizioni.

Uno dei temi chiave di questa edizione è come continuare a far evolvere la piattaforma web e tutto l’ecosistema di tecnologie che le ruotano attorno, in un momento dove la fruizione di contenuti da parte degli utenti si sta spostando sempre più verso piattaforme native (specialmente su device mobili), che garantiscono esperienze più complete ed efficaci.

E’ il momento delle progressive web apps, applicazioni in browser che sfruttano le ultime tecnologie per ottenere un comportamento e delle funzionalità del tutto simili alle esperienze offerte dalle app native. Come? Attraverso i service workers.

I service workers sono essenzialmente degli script che agiscono come proxy tra il browser e il server e che consentono di implementare direttamente nei browser tutta una serie di funzionalità asincrone (si pensi ad esempio alle notifiche push e alla sincronizzazione dei contenuti in background) che fino ad oggi erano prerogativa delle app native. Questo, come illustrato nell’intervento in apertura di Nolan Lawson, apre la strada verso una fruizione e un’esperienza web sempre più immersiva e completa, con tutti i vantaggi dello sviluppo su piattaforma web.

Naturalmente a oggi il supporto non è ancora completo, ma tutti i vendors si stanno via via allineando con la specifica. Ed è qui che entrano in gioco i vari transpiler, che consentono di uniformare e utilizzare di fatto anche le ultime innovazioni del linguaggio. Interessante l’intervento di Christophe Porteneuve sulla configurazione e l’utilizzo di Babel, che ci toglie molte curiosità su come utilizzarlo al meglio.

Anche la realtà virtuale applicata al web può trarre beneficio dai service workers. Ada Rose Edwards ci illustra come, ad esempio, è possibile utilizzarli per migliorare le performance di rete in una applicazione che utilizza le WebVR API utilizzando la tecnica del progressive enhancement e ridurre drasticamente i tempi d’attesa dovuti al caricamento delle risorse, uno degli ostacoli principali delle applicazioni VR.

Dopo un interessante e tecnicissimo talk sulla gestione della memoria nel V8 engine da parte di Fedor Indutny, andiamo a pranzo, con buona pace dei colleghi a Codroipo ancora in attesa della baguette.

Il pomeriggio è tutto dedicato alla discussione su come i vari framework front-end si stiano evolvendo nella direzione di un approccio modulare (attraverso i componenti) facendo eco a parecchi principi della programmazione funzionale, tanto da arrivare all’idea della UI vista come una pura funzione di rendering.

In questo senso apprezziamo che i maggiori player (Angular, React, Vue) si stiano dando molto da fare per rendere la vita semplice agli sviluppatori e ridurre la cosiddetta “JS fatigue”. L’obiettivo è avere dei framework che siano semplici da imparare e da utilizzare.

Il talk di Evan You svela alcuni principi di funzionamento di un framework reattivo come Vue.js, Igor Minar fa una retrospettiva dell’evoluzione di Angular dalla versione 1 alla 2. Innovativa la proposta di Guillermo Rauch, con la presentazione di Next.js, un framework minimale per applicazioni React renderizzate lato server.

Parola chiave del pomeriggio: “Universal JS“. Applicazioni che condividono la stessa base di codice sia lato server che lato front-end. Pare sia questo il trend del momento, che tra l’altro ci vede all’opera in prima persona su un progetto sviluppato proprio come applicazione isomorfica (stay tuned for updates!).

Tra una pausa caffè (in tazze da mezzo litro) e un paio di morsi alla baguette che avremmo dovuto riportare a Codroipo (oops..), ci rendiamo conto di quanto le API HTML5 non smettano mai di stupire, soprattutto per le potenzialità che sono in grado di sviluppare sul lato multimediale. Avreste mai pensato di controllare una macchina del fumo in JS? No, neanche io, ma la spettacolare esibizione del duo Sam Wray e Tim Pietrusky fa capire quanto sia possibile fare lato audio/video con JavaScript. Oltre a come sia possibile portare la nebbia della Val Padana in un centro congressi a Parigi. Cool!

I talk si susseguono serrati, inframmezzati da veloci sessioni di Q&A con gli speaker e la novità di questa edizione, i lightning talk, interventi di 4 minuti dove tutti possono partecipare e presentare le proprie idee. La sera arriva subito, e l’organizzazione ci sorprende ancora una volta con un afterparty degno di nota, ricco buffet e free beer per tutti. Qualche ora per scambiare qualche parola con nuove conoscenze e permearsi di nuove idee da sperimentare al ritorno a casa.

Ci siamo divertiti, ora non rimane altro che organizzare una bella rooftop grill nei nostri uffici!
The baguette is a lie! rooftops are not

Photo credits: dotConferences

Devo dire che il risultato è stato una giornata molto interessante, con talk di ottimo livello. Il formato, che potrebbe essere considerato impegnativo da seguire per una giornata intera, si è rivelato invece più stimolante e più interattivo per l’audience rispetto ad un approccio tradizionale.

Dopo i saluti iniziali degli organizzatori, ai quali vanno i miei complimenti per aver messo in piedi un evento così ben riuscito, il primo talk che ho seguito è stato presentato da Christoph Reinartz di Trivago, il quale ci ha presentato il flusso di lavoro quotidiano, dall’apertura di una issue fino al deploy in produzione. E’ stato interessante soprattutto vedere l’utilizzo strutturato ed efficiente di pratiche quali i feature flags per permettere a/b testing e una code review molto partecipata (di standard, ogni merge request è revisionata da 3/4 persone).

Dopo un buon pranzo ristoratore, il pomeriggio è iniziato con un talk sugli internals di Git. Non è mai facile prestare attenzione al primo talk dopo aver mangiato (coincide con l’orario della pennichella!), ma in questo caso Paolo Perrotta è riuscito a stimolare l’appetito di conoscenza dei presenti con un talk veramente interessante: nonostante l’utilizzo quotidiano di Git  per qualunque progetto, ho avuto modo di scoprire molte cose riguardo a cosa si nasconde all’interno della cartella .git.

Il pomeriggio è proseguito con un talk su Elixir in cui Andrea Leopardi ci ha fatto scoprire i concetti base del linguaggio. Un’applicazione Elixir è costituita da svariati processi isolati l’uno dall’altro, che riescono a comunicare semplicemente passandosi messaggi in maniera asincrona. Quest’implementazione dell’actor model ci consente di modellare le nostre applicazioni in modo da poter gestire agilmente i cambiamenti e i fallimenti che possono accadere. Questo ci permette di realizzare velocemente applicazioni distribuite e fault tolerant.

A seguire Ju Liu ci ha guidati a bordo del Titanic per cercare di capire se il finale della storia raccontata dal film del 1997 avesse uno sfondo di verità. Effettivamente analizzando i dati si scopre come “Prima donne e bambini” non sia solo un modo di dire: circa il 90% delle donne di prima classe si sono salvate, mentre gli uomini che viaggiavano in terza classe hanno avuto generalmente sorte ben peggiore. Lo spunto storico e cinematografico è servito per introdurci nel complicato mondo del machine learning e vedere come un computer riesca effettivamente ad interpretare dati ed elaborare euristiche. Il Take away principale del talk comunque è stato: “Impara a conoscere i tuoi dati prima di darli in pasto al computer”.

A concludere la giornata è stato Andrea Francia che ci ha accompagnati in un code kata fatto direttamente in Bash! Oltre a scoprire le potenzialità della Bash (anche se la sintassi non è proprio così intuitiva…), è stato molto interessante costruire un mini framework per il testing e utilizzarlo in un approccio test first.

Mi è dispiaciuto non poter essere in contemporanea ad ascoltare qualche talk dell’altra track… per il dono dell’ubiquità ci stiamo ancora lavorando…

La giornata è stata ricca e piena di spunti interessanti. Spero che possa ripetersi anche l’anno prossimo!

Per quanto riguarda il settore devOPs, è tutta una questione di automazione dei processi: la realizzazione di sistemi che rendano autonome e automatiche le procedure ripetitive e “noiose” quali il testing, l’integrazione e il deployment del codice. Automazioni che da un lato sgravano gli sviluppatori da una responsabilità, dall’altro garantiscono un funzionamento meno incline ad errori umani in una parte significativa nella filiera di produzione e distribuzione del codice.

In MV Labs da sempre ci impegniamo per garantire la più alta qualità possibile nel processo produttivo. Inoltre, con l’aiuto di tool automatici opportunamente scelti e configurati, riusciamo a perseguire questo obiettivo nel lavoro quotidiano. In quest’ottica, la partecipazione a OpsCON (European meeting on IT operations and Open Infrastructures) ci vede in prima linea per rimanere al passo con gli ultimi trend emergenti nel settore operations e per condividere le nostre esperienze con gli altri partecipanti.

L’edizione 2016 si svolge nella splendida cornice della città di Firenze ed è organizzata dall’Associazione Culturale Inventati (www.inventati.info) in collaborazione con Atlassian.

Tra gli interventi della giornata spicca senza dubbio quello di Gabriele Bartolini, che ha spiegato come la sua azienda promuova l’innovazione del processo produttivo invitando i dipendenti ad investire parte del proprio orario di lavoro nello studio e nell’introduzione di nuovi strumenti di lavoro. Impossibile non citare «It’s easier to ask forgiveness than it is to get permission»; una massima di Grace Hopper e un principio che facciamo nostro anche in MV Labs. L’impiego di nuove tecnologie richiede infatti una buona dose d’intraprendenza e coraggio. Ecco perchè anche noi in MV Labs dedichiamo parte del nostro tempo a progetti interni. Ciò ci consente di valutare nuovi strumenti e sbagliare, senza tuttavia mai esporre al rischio i sistemi business critical dei nostri clienti.

Tra gli altri argomenti toccati non poteva mancare ovviamente docker: tema caldo degli ultimi anni, sfiorato da quasi tutti gli speaker e affrontato in modo particolare da Federico Minzoni con un interessante intervento dove ha evidenziato le similitudini concettuali tra l’utilizzo di Docker e il libro di Italo Calvino «Lezioni americane: Sei proposte per il prossimo millennio». Un talk atipico ma davvero interessante.

Chiudiamo citando Vladimir Cavalcanti che ha offerto molti spunti di riflessione su come organizzare il workflow aziendale in ottica di miglioramento dell’innovazione (in termini di processo produttivo) e la cultura generale del lavoro aziendale come strumento per innovare e rimanere competitivi sul mercato (portando casi di aziende come Blockbuster e Kodak che da leader di mercato si sono ritrovate sul lastrico per essersi sedute sugli allori).

Cercheremo sicuramente di applicare, per quanto è possibile, alcuni degli spunti che abbiamo ricevuto oggi.

Città molto bella, tanti speaker e argomenti per tutti i gusti sono le poche parole che basterebbero per raccontare di quest’esperienza. Ecco comunque un riepilogo degli interventi che ci hanno maggiormente impressionato.

Il primo giorno è iniziato con il keynote di Graham Daniels, con un talk molto interessante sulle problematiche legate alla mancanza di diversità nel nostro campo. Graham in particolare ci parla dell’ambiente “ostile” che le minoranze (etniche, di sesso, etc) spesso si trovano ad affrontare nella vita lavorativa quotidiana e ci ricorda che spesso ne siamo in parte colpevoli anche senza rendercene conto. Per questo ha dato vita al Code Manifesto per aiutarci a ricordare che la diversità è un’opportunità di crescita per tutti.

Photo by Goran Levacic

Altro talk degno di nota è stato sicuramente quello di Zoran Antolovic intitolato “Self-testable API docs – Docs shouldn’t lie!” che ci ha dato alcuni spunti sulla generazione di documentazione per API e sul loro test, argomento che stiamo sviluppando proprio in questo periodo in MV Labs. Il consiglio di Zoran è di utilizzare JSON Hyper: schema e tool open source CodeCeption per testare che gli endpoint restituiscano valori coerenti con la documentazione generata.

A seguire è stata la volta di Marco Pivetta con il suo talk sull’Event Sourcing e CQRS. Marco ha descritto i problemi risolti ma anche introdotti da questo approccio. La separazione netta tra comandi ed eventi (CQRS) semplifica la modellazione del dominio; poter disporre della storia completa di tutti gli avvenimenti (Event sourcing) rende l’applicazione molto flessibile in particolare quando bisogna recuperare o filtrare dati. Uno degli aspetti negativi è – ad esempio – la coerenza eventuale (eventual consistency), che rende difficile dare all’utente un feedback immediato sulle sue azioni. Problematiche con le quali ci siamo già scontrati, e che abbiamo affrontato – anche assieme a Marco stesso – nel progetto che stiamo sviluppando in MV Labs e che utilizza questo approccio.

E’ stata quindi la volta del nostro Marco, che ha riproposto il suo talk “Elm or how I learned to love front-end development“.  ELM è un linguaggio funzionale per il frontend che compila in Javascript. Grazie al formalismo della programmazione funzionale (oltre che alla tipizzazione statica e alla compilazione), gli errori al runtime diventano un brutto ricordo e il mantenimento del codice risulta meno complesso. Puoi scoprire di più su Elm e su questo paradigma attraverso le slide utilizzate a Zagabria, ma anche il video di un precedente intervento di Marco. Se invece vuoi vedere questa tecnologia all’opera, puoi visitare il nostro sito PHPMiddleworld :)

Il secondo giorno si è aperto con il keynote di Maciej Ceglowski che ci ha intrattenuto con un bellissimo talk sul futuro che ci attende e su come dovremmo approcciarci ad esso con una visione un po’ meno entusiasta per poterci focalizzare su problemi più concreti. La massima della giornata è stata senza dubbio:

“Never dying must be annoying: imagine having 30000 years of browsing history haunting you!”

Philipp Krenn nel suo talk “Se7en deadly deployment sins” ci ha poi fatto riflettere sui “peccati” che ogni sviluppatore prima o poi commette, paragonandoli ai 7 peccati capitali. Cita ad esempio la lussuria: è davvero necessario utilizzare sempre le ultime tecnologie disponibili? O l’invidia: perché cercare di fare personalmente cose che qualcun’altro ha già fatto per noi?

Chiudiamo poi con l’ultimo talk di Saša Jurić che ci ha parlato di Phoenix un framework per Elixir (basato a sua volta su Erlang) per lo sviluppo di applicazioni web. Phoenix vanta dalla sua delle performance straordinarie: parliamo di decine di migliaia di richieste per secondo, latenze nell’ordine dei microsecondi e 2 milioni di utenti connessi ad una singola macchina. Saša ci ha mostrato come la creazione di una applicazione di chat con i web socket sia estremamente semplice. Termina l’intervento con una forte affermazione: Pheonix è, ad oggi, il miglior framework per la creazione di applicazioni web per qualsiasi tipo di progetto. Sicuramente un framework da tenere sott’occhio e che proveremo presto in MV Labs!

Due giorni sicuramente impegnativi ma che ci hanno fornito molti spunti di riflessione sul lavoro quotidiano, ci hanno fatto conoscere nuove tecnologie e ci hanno fatto provare nuove pietanze locali!

Doviđenja Zagreb!

Diversi talk di ottima qualità e l’ottimo feedback all’intervento di Marco e Steve chiudono questi due giorni, impegnativi ma pieni di ottimi spunti e buona compagnia.

Per quanto riguarda i talk degni di nota della prima giornata, va sicuramente citato il keynote di Rasmus Lerdorf (inventore del linguaggio PHP), che ha parlato delle migliorie introdotte da PHP7, in particolare per quanto riguarda l’aumento di performance delle nostre applicazioni web (sia in termini di utilizzo della CPU, sia – soprattutto – nel consumo di memoria). Rasmus ci ha inoltre fornito alcuni consigli su come migrare a questa nuova versione di php e come ottimizzare al meglio il nostro ecosistema per accogliere le nuove funzionalità; argomenti poi ripresi nell’ottimo talk di Julien Pauli che è entrato nel dettaglio delle varie ottimizzazioni introdotte da PHP7. Un talk decisamente tecnico che ci ha permesso di capire meglio come sia stato possibile un incremento prestazionale cosi importante.

E’ stata quindi la volta di Enrico Zimuel, core developer di Zend Framework, che ha introdotto la versione 3 del framework (in rilascio a Giugno). Le novità sostanziali proposte sono state un miglioramento notevole di performance rispetto alla versione 2, l’ottimizzazione per PHP7 e – soprattutto – una serie di semplificazioni, che rendono più semplice l’approccio al framework per chi si avvicina ad esso per la prima volta. Enrico si è soffermato In particolare su Zend Expressive, un microframework che farà parte di ZF3 e orientato al middleware. Grazie a questo approccio è possibile strutturare le applicazioni in modo da rendere i vari componenti che si prendono cura di gestire i cross cutting concerns (ovvero tutto ciò che non riguarda strettalmente la logica di dominio) facilmente riutilizzabili anche su piattaforme/framework diversi.

E sono stati proprio il middleware e questa derivata, inedita interoperabilità tra i framework gli argomenti trattati da Marco e Steve nel loro talk dal titolo “Beyond PSR-7: The magical middleware tour”. I colleghi ci hanno fornito una panoramica generale su questo approccio, partendo dalle origini dello sviluppo in PHP, introducendo quindi i motivi che hanno portato al middleware, esplicitando quindi i problemi che questo risolve, concludendo quindi l’intervento con esempi di implementazione di middleware con diversi framework.

La prima giornata si è quindi conclusa con la cena sociale, occasione per incontrare amici nuovi e vecchi, come qualche membro del PHP User Group Friuli, e con la sempre simpatica compagnia del PUG Roma.

E’ giunta quindi la volta della seconda giornata di conferenza, che si è aperta con il keynote di Nikolay Krapivnyy, che ci ha spiegato come Badoo, il più grande social network di incontri al mondo, è riuscito a risparmiare oltre 1 milione di dollari grazie alla migrazione a PHP7. Nikolay ci ha spiegato in dettaglio come è stata gestita la migrazione, quali problemi sono stati incontrati e come sono stati risolti e infine ci ha presentato i risultati, un carico sulla cpu dimezzato e un uso della memoria di ben 9 volte inferiore tradotto quindi in un dimezzamento del numero di server e un risparmio di oltre 1 milione di dollari.

Un altro hot-topic di questo PHPDay è stato sicuramente l’Event Sourcing, un approccio completamente diverso (rispetto al CRUD tradizionale) nel gestire i dati delle nostre applicazioni dove tutte le operazioni vengono gestite attraverso un log di eventi ed è quindi possibile ricreare lo stato esatto dell’applicazione per ogni preciso istante del passato. Come ci ha fatto notare Willem-Jan Zijderveld nel suo ottimo talk, l’event sourcing può essere la soluzione alla perdita di dati quando si eseguono operazioni di delete e update, a scapito però di una difficoltà implementativa da non sottovalutare. In particolare Willem-Jan ci ha fornito alcuni esempi con Broadway, uno dei framework più maturi per l’event sourcing in php. Un talk decisamente interessante che ci ha dato un nuovo punto di vista sulla gestione dei dati.

Oltre a quelli citati, sono stati coperti molti altri argomenti in questi due giorni: sicurezza, regular expression, docker, cloud, machine learning, approccio funzionale su php e molti altri. Interventi quindi per tutti i gusti e per tutti i livelli di conoscenze.

Due giorni impegnativi, ma che ci hanno lasciato con molti spunti di riflessione e nuove conoscenze da applicare nel lavoro di tutti i giorni. E’ stata inoltre una ottima occasione per trascorrere un po’ di tempo tra di noi di MVLabs in un ambiente un po’ diverso dal solito.

Un grazie agli organizzatori e allo staff di PHPDay che ha reso possibile questo evento. Ci rivediamo sicuramente il prossimo anno!