Codemotion 2016 @ Milano

Nella vita non si smette mai di imparare, se consideriamo poi tutte le novità che si susseguono negli ultimi tempi in campo tecnologico servirebbero le vite di un gatto per seguire tutto.

In questo senso le conferenze di tecnologia si rivelano un buon modo per esplorare nuove tendenze in un modo vivace e divertente, grazie ad esperti del settore che vestendo una funzione giornalistica filtrano le novità individuando gli argomenti più newsworthy, ricordandoci che non siamo gli unici ad imparare cose nuove, il che fa molto bene per alleviare la sindrome dell’impostore.

Il Codemotion di Milano è stata una conferenza altamente multidisciplinare, per cui quello che segue è il percorso che ho deciso di seguire, rimanendo vicino al Front End ma spaziando anche un po fuori dalla mia comfort zone.

Giorno 1 – 25 Novembre

20161127_151904Essendo partito in mattinata da Roma con i miei colleghi di team, ho dovuto saltare necessariamente l’apertura dell’evento e il primo slot delle 11.30, per quanto Italo sia veloce non è comunque un MagLev e 3h servono tutte. Iniziamo a seguire l’agenda del primo giorno.

Promises Are So Passé

Tim Perry parla della gestione dei flussi asincroni in JavaScript, che essendo single thread mal si presta alla gestione dell’esecuzione di codice con dati che provengono da risorse di rete, situazione che attualmente in ES5 gestiamo con le promise, che in ES6 possiamo ancor meglio approssimare con i generator gestendo l’esecuzione delle funzioni, ma che potrebbe raggiungere lo stato dell’arte con asyncawait. Si tratta di un costrutto in fase di proposta per ES7 che permetterebbe una sintassi ancora più chiara e diretta rispetto all’operazione che si svolge perché, finalmente, built in nel linguaggio, sempre usando il meccanismo delle promise ma in modo più esplicito nei contesti specifici.

Glissiamo sul successivo

In questi eventi ci sono sempre molti partecipanti, il che significa che se tutti hanno lo stesso obbiettivo che si trova nello stesso posto la situazione diventa caotica, come è stato per il pranzo con una fila che neanche a un Apple store il giorno dopo la presentazione dell’ultimo iPhone. Dopo 1h di attesa la sala del talk che mi interessava, “The hitchhikers guide to UXing without a UXer” era già strapiena, per cui ho ripiegato sulla sala adiacente dove si svolgeva la spiegazione sul gioco di Bud Spencer & Terence Hill, d’altronde a chi non piacciono gli spaghetti western? Peccato che gli speaker si sono dilungati fin troppo sui trivia di Kickstarter piuttosto che condividere qualcosa di interessante per il pubblico sul progetto tecnico in se, me ne sono andato via dopo 15 minuti di fuffa.

Understanding Angular 2

Shmuela Jacobs illustra le principali caratteristiche di Angular 2, mettendo in risalto gli aspetti della modularità con i componenti, la versatilità dovuta a TypeScript che permette di compilare per diverse piattaforme, e il rapporto particolare che si deve tenere con l’HTML della pagina attenendosi ai comandi messi a disposizione da Angular che funge da livello di astrazione. Interessante anche il trick suggerito per ricordare l’ordine delle parentesi per eseguire correttamente un binding [()]banana in the box.

Coding for Accessibility

Kamilla Khabibrakhmanova tratta un argomento ingiustamente bistrattato nel lavoro quotidiano di molti sviluppatori, ovvero l’accessibilità. Fa sempre bene ricordare i motivi per cui un sito facilmente accessibile da persone con limitazioni di vario genere risulta comunque migliore da usare per tutti, con dovuti distinguo, anche in situazioni d’uso particolare, come condizioni di illuminazione particolari piuttosto che uso con una sola mano, piuttosto che suddividere i contenuti in paragrafi per facilitare focus e attenzione.
Poche e semplici regole che applicate con rigore possono fare la differenza, e in nostro aiuto vengono vari strumenti di sviluppo per verificare eventuali criticità nella pagina:

Accessibility Developer Tools (Chrome)

http://achecker.ca/

Come rendere il proprio prodotto una bomba creandogli una intera community intorno!

20161125_171825Alessio Fattorini, community manager di NethServer, smonta alcuni miti su come si costruisce un pubblico di follower attorno ad un prodotto rovesciando la situazione, ovvero come sia il prodotto a dover in un certo senza nascere dai propri futuri follower, mettendo al centro inclusività ed ascolto, ovvero risposte veloci e trasparenti e trasformare i feedback, soprattutto quelli negativi, in azioni perché è li che si trovano le opportunità.

Giorno 2 – 26 Novembre

20161127_151957Ultimo giorno di fuoco, colazione “continental” con uova pancetta funghi affettati ricotta formaggi crostata cornetto spremuta cappuccino, e via.

Avendo pernottato in hotel vicino al Politecnico iniziamo l’agenda della seconda giornata seguendo il talk di apertura.

Coding Culture

Sven Peters parla del tipo di cultura che ad Atlassian porta ad un ambiente fertile per gli sviluppatori software, descrivendo la cultura come una cosa a tratti intangibile ma viva, ovvero una serie di abitudini ed azioni più o meno spontanee che creano la giusta atmosfera in cui ci si senta emotivamente sicuri per incoraggiare dibattiti costruttivi e stimolanti.

The first fifteen lives of a software engineer

Nikos Zinas, in un talk dal titolo inspirato ad un libro la cui trama rimanda a Madoka Magica e un’ordine narrativo non lineare in stile Suzumiya Haruhi ripercorre la sua carriera di sviluppatore e come ogni suo ruolo abbia costituito un nuovo inizio non necessariamente collegato in maniera lineare con quello precedente. Con il passare del tempo non crescono solo le skill tecniche date dal tempo speso sul codice ma cambiano anche la personalità e le esigenze dell’individuo portando a trarre soddisfazione e benefici da ruoli che prima non si consideravano interessanti o viceversa per ruoli che in passato si erano rilevati fallimentari a causa di fattori contingenti.

Progressive Web Apps: trick or real magic?

Maurizio Mangione affronta il tema delle prestazioni, esordendo da due dati oggettivi strettamente correlati tra loro, il basso lasso di tempo che un utente è disposto ad accettare per il caricamento di una pagina e il crescente peso medio delle pagine web con tutti i loro assets che oramai si aggira intorno ai 2.5mb. Accennando alle vecchie tecniche di ottimizzazioni delle grandi immagini sezionate in più file, parla del difficile bilanciamento tra la velocità reale e quella percepita anche a scapito di quella reale, e di come ottimizzare la fase critica della “prima impressione” tramite la cache e i service worker.

Prendendo ad esempio applicazioni in cui la dinamicità dei contenuti è molto importante si può optare un flusso in cui prima si cerca di contattare il server e quindi invalidare la cache locale ed aggiornarla o in alternativa mostrare una copia vecchia, oppure casi come twitter dove prima si mostrano comunque i contenuti vecchi cachati e poi se ne recuperano di nuovi.

Gang of Four Patterns in a Functional Light

Mario Fusco di Red Hat nella sua live demo introduce le lamda e altri nuovi costrutti di Java 8, evidenziando come il famoso testo sui Patterns fosse all’epoca anche troppo orientato agli oggetti, dato che molti pattern hanno la loro ragion d’essere nella natura fortemente object oriented di Java, rivedendo quindi alcuni dei più famosi sotto un’ottica funzionale.

https://github.com/mariofusco/from-gof-to-lambda

Thirty months of microservices. Stairway to heaven or highway to hell?

Sander Hoogendoorn espone pregi e difetti delle architetture strutturate in microservizi, che se da una parte rispetto ai vecchi monoliti facilitano scalabilità ed impiego di linguaggi backend diversi, dall’altro spostano la complessità gestionale nella quantità di repository da manutenere ed il monitoring da effettuare su tutti i diversi servizi che nella loro totalità consentono il funzionamento del sistema, ed il fatto che tra servizi che parlano via JSON non esistono contratti tra i diversi endpoint. Una strada ancora nelle fasi iniziali di esplorazione da parte delle aziende, le quali sono storicamente refrattarie ai grandi cambiamenti, ma che in molti stanno avvicinando.

In un passaggio da architettura monolitica ad una distribuita la strada è lunga, seguendo una curva che rimane stabile per lungo tempo fino a quando tutti i componenti del vecchio sistema sono migrati in servizi indipendenti, a quel punto si possono sperimentare tutti i benefici in termini di stabilità e manutenzione dei suoi componenti.

Un architettura che però non fa magicamente svanire la complessità ma la trasforma in forme diverse, teoricamente più facilmente gestibili perché più atomiche ed indipendenti, solo il futuro potrà confermare o smentire se sia effettivamente la strada giusta.

Ciao Milano

https://sresc.io/tKA

Lascia un commento

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.