30 May 2018
Anche quest’anno si è tenuto il solito appuntamento con la conferenza per sviluppatori di Microsoft, ovvero Microsoft Build, dove come sempre sono state concentrate le novità rilevanti del 2017 e di questa prima metà di 2018. Per quanto mi riguarda, piuttosto che concentrarmi sulla conferenza in generale, (a cui questa volta non ho potuto assistere di persona al contrario dell’anno scorso) per il mio commentario ho scelto tre cose che mi hanno colpito particolarmente. Sul resto glisserò sia perché sono parti di stack che al momento non mi interessano, sia perché voglio parlare prevalentemente di Unix.
Prima di Unix però parliamo di qualcosa che non c’entra molto, ovvero Windows 10: su Windows 10 arriverà una nuova feature chiamata Sets. Microsoft ha deciso che, bene, vi piacevano le tab del browser? Vi piace tenere sott’occhio un sacco di roba tutta insieme? E allora perché non rendere “tabbed”, a schede, la navigazione su tutti i programmi? Abbiamo un simbolo simile a quello della nuova tab del browser, sulla barra del titolo delle finestre, con cui possiamo aprire nella stessa finestra dove stiamo modificando un documento di Word, Excel, o ritoccando una foto, un’altra applicazione con degli altri contenuti. In questo modo le finestre stesse si trasformano in spazi di lavoro a sé stanti.
E devo dire, cara Microsoft, anche se penso che questa visione vada raffinata, che sia lo stesso un’ottima intuizione. Props.
Ma ora veniamo alle cose importanti (che sono le cose che piacciono a me e le cose più bizzarre): Microsoft ha annunciato in occasione di questo Build che Notepad introdurrà il supporto a LF, ovvero ai terminatori di riga Unix. È la fine di un’epoca, considerato che i terminatori di riga sono sempre stati il grande cruccio degli sviluppatori non-Unix, che git ha introdotto un’opzione apposta per correggerli in automatico, e che Microsoft ha sempre adottato un atteggiamento un po’ protettivo da una parte (per esempio Visual Studio li supporta e ci mancherebbe altro), mentre dall’altra prendi un developer, trattalo male, lascialo aspettare per ore - giorni - anni - prima di implementare una cosa del genere, mandandolo per le piste col suo amministratore di sistema e coi suoi colleghi. Ma appunto.
L’altra novità che mi ha colpito è stata la voce “Open Linux shell here” nel file manager. Di solito è molto difficile trovare roba di questo tipo integrata in Windows e disponibile in questo modo, spiattellata in faccia in questo modo. Questo perché esattamente come macOS Windows non privilegia molto i power user, anzi: le opzioni che possono compromettere la stabilità vengono ben nascoste. In questo caso non solo troviamo una bella voce di menu da veri nerdoni, ma la troviamo anche riguardante Linux e la sua shell inclusa dentro Windows. Onestamente lo trovo non solo utile, ma un altro passo di Microsoft nella direzione di una strategia inclusiva nei confronti di Linux e di tutta la community che lo “foraggia”.
Quanto è fico tutto il resto? È fico, è fico. Ma io rimango:
- Un nerdone
- Un power user
- Un linuxaro
E quindi i miei takeaway (insieme ai lavioli gambeli del cinese sotto casa) sono questi.
14 May 2018
Sto diventando monotematico, me ne rendo conto, ma allo stesso tempo l’ecosistema di Elixir mi affascina a un livello inconcepibile. Sono già un po’ di giorni che tengo d’occhio le Pull Request che mancano perché Phoenix Framework 1.4 venga rilasciato, e mi sono accorto che piano piano i lavori stanno giungendo a una conclusione. Quanto ci piace questo? Tantissimo, perché ci sono un paio di cosette veramente gustose.
La prima è che finalmente è stato sostituito Brunch con Webpack per quanto riguarda il bundling degli asset. Questo non interesserà tanto gli sviluppatori backend, viceversa facendo io il frontendista di lavoro ho avuto modo di vedere come Webpack sia ormai lo standard de facto per il packaging del proprio JavaScript, e mi fa piacere che Phoenix si sia adeguato a questo trend. I motivi che ci sono dietro sono essenzialmente due:
- Più aderenza appunto a un tool che la community conosce bene
- La necessità sempre minore di scrivere un file di configurazione (e quello di Webpack è complicato) per il proprio caso d’uso. Suppongo che Brunch fosse utilizzato per la struttura del file di configurazione più semplice, ma adesso, beh, no more excuses.
La seconda novità di rilievo è che mentre Phoenix fino alla versione 1.3 ha utilizzato Cowboy (il più famoso webserver Erlang) alla sua prima release stabile, Phoenix 1.4 si basa interamente su Cowboy 2. Il motivo per cui questo è una figata lo potete leggere direttamente nell’annuncio di rilascio di Cowboy 2, ma essenzialmente ai miei occhi risalta una cosa: HTTP/2!
Per il resto, ragazzi, c’è ancora un sacco di roba sotto il cofano che però a me interessa relativamente. Ci sono tantissimi cambiamenti soprattutto rispetto ai transport e a come i Socket di Phoenix interagiscono coi transport. Accanto a questo troviamo bugfix e deprecation a pioggia che però potete leggervi nel changelog ufficiale, il quale viene aggiornato man mano che vengono smarcate le voci della lista delle cose che mancano.
Che altro dire? Ricordatevi di usare sempre le forbici dalla punta arrotondata così non vi fate male.
29 Apr 2018
In questa soleggiata manco per niente domenica di Aprile, smaltisco la stanchezza accumulata dalla settimana che è appena passata e che sul finale ha visto ripetersi ancora una volta l’eccezionale reunion di nerdoni di tutta Italia (circa, e anche circa un po’ di gente da fuori), ovvero Codemotion. L’edizione romana è quella a cui sono più affezionato per motivi ovviamente etnici, essendo io di Roma, ma in maniera altrettanto importante perché è stata la prima, quella da cui è partito tutto, e quindi oltre l’aspetto tecnico, di crescita professionale, di crescita personale, mettiamoci anche il Grande Amarcord Anulare di tutte le edizioni passate, di tutta l’acqua passata sotto i ponti, delle interviste a un ragazzo alle prime armi col public speaking che pensava due cose e se ne dimenticava quattro per strada.
Abbandonando il pensatoio dei ricordi, questo Codemotion mi ha permesso come al solito di vedere speaker di livello e soprattutto di reincontrare amici che non ho mai occasione di abbracciare. Riguardo gli speaker, quello che ha attirato di più la mia attenzione è stato il clamore intorno alla programmazione funzionale, un keynoter particolare, e quello che mi aiuta a portare il pane a casa ovvero i talk sullo sviluppo frontend e su JavaScript più in generale.
The Power of the Paradigm by Douglas Crockford
La sessione di keynote è stata emozionante, principalmente perché è stata tenuta da Douglas Crockford, l’autore della prima proposta riguardante JSON, e l’autore di “JavaScript: The Good Parts”. È uno dei miei miti, quindi non potevo assolutamente perdermelo.
Quello di cui ha parlato è stato illuminante, nel senso che ha consumato due filoni consequenziali: il primo è stato l’illustrare come i paradigmi evolvano a loro volta in altri paradigmi, e come lungo la storia dello sviluppo software siano stati trovati all’interno di determinati paradigmi dei concetti che abbiano portato al superamento di quegli stessi modi di concepire i programmi. Questo ci ha portati diretti al nuovo paradigma che si sta affermando, ovvero la transizione dalla programmazione sequenziale allo scambio asincrono di messaggi.
Secondo me a questo punto Crockford si è un po’ perso, nel senso che ha illustrato il suo nuovo progetto, una piattaforma per portare su tutti i linguaggi quello che è sostanzialmente lo scambio di messaggi tra processi tipico di indovinate un po’ quale piattaforma? Ma ovviamente la BEAM, con Erlang ed Elixir in prima fila come linguaggi con cui programmarci su.
Chiaramente Crockford ha incentrato le prime iterazioni di Seif, così si chiama il suo nuovo progetto, su una prima implementazione in JavaScript, tuttavia Seif è un vero e proprio protocollo di cui esisteranno miriadi di implementazioni in futuro.
Questo è senza dubbio interessante, ma in una sessione di keynote di Codemotion avrei preferito che venisse proseguito l’aspetto concettuale, dato che alcuni punti solamente lambiti riguardo la cultura del cambiamento e dell’evoluzione paradigmatica all’interno del software potevano essere approfonditi veramente tanto.
Unbundling the JavaScript module bundler
Il mitico Luciano Mammino durante il suo bellissimo talk ci ha fatto vedere quali sono i principi attraverso un cui funziona un module bundler per JavaScript come Browserify o Webpack. Siccome Webpack è un argomento che mi ha sempre affascinato, ho seguito il tutto con interesse apprezzando soprattutto il fatto che Luciano abbia anche spiegato come costruire un module bundler rudimentale attraverso pochi principi di base.
La presenza di Douglas Crockford al suo talk deve averlo innervosito un po’, ma tranquillo Luciano, se ho capito io tutto quello che hai detto significa che ti sei spiegato perfettamente e ce la possono fare tutti. Voto 10+ per il ragazzo dublinese d’adozione.
Beyond JavaScript frameworks with Elm
Nonostante io abbia cominciato a pistolare con molto poco successo con i linguaggi della famiglia ML tipo Haskell, una tecnologia che continua ad incuriosirmi per quanto riguarda le applicazioni frontend è Elm.
Erik Wendel, che è il founder dell’Oslo Elm Meetup e dell’Oslo Elm Day, ha illustrato una panoramica abbastanza ampia riguardo le funzionalità che offre Elm, quali problemi risolve, e perché sia meglio di JavaScript vanilla per le webapp. Tra le cose che ho apprezzato ci sono le seguenti:
- Un meccanismo centralizzato di gestione dei side effect
- Un linguaggio funzionale ML molto molto espressivo
- Il compilatore. Erik ha mostrato pochissimo del compilatore ma è veramente fichissimo
BEAM in Action: scrivere una web application con Elixir
Qui si giocava in casa, ma è stato comunque un talk rilevantissimo: i carissimi Claudio D’Alicandro (già mio collega e fondatore di Elixir Roma) e Gabriele Santomaggio (eminenza dell’ecosistema Erlang) hanno presentato una panoramica dei vantaggi di programmare in Erlang o (ancora meglio) in Elixir per le proprie webapp, stressando il punto chiave alla base della keynote di Crockford della mattina.
Ovvero il fatto che non solo Asynchronous Message Passing è il nuovo paradigma da inseguire, ma che grazie alle feature di actor modeling esposte dalla BEAM tramite (ad esempio) i GenServer, possiamo raggiungere questo status quo con Elixir in pochissime righe di codice.
Voto 10+ anche a Claudio e Gabriele 😍
Who’s afraid of open design?
Non avevo mai sentito Emanuela Damiani parlare, mi ero limitato a leggere qualcosa di suo e scambiarci qualche commento in giro per l’internet. Lei è nel team che ha sviluppato Photon, il nuovo design system alla base di Firefox. Ci ha parlato di come Mozilla si è messa in gioco per implementare davvero una strategia di open design, di come il team si sia dovuto fidare della community su alcune scelte, e abbia per altre dovuto imparare a comunicare le decisioni all’esterno.
E perché no, anche imparare a ricevere feedback.
Il talk di Emanuela è stato molto bello, perché ha contribuito secondo me a demistificare da un lato, e valorizzare dall’altro, l’operato di Mozilla che spesso è vista come una sorta di organismo immanente, ma che al suo interno in realtà ha delle persone che sono sensibili ai feedback come tutti noi e che cercano semplicemente di fare il loro lavoro al meglio.
Il nuovo Firefox per quanto mi riguarda è espressione perfetta di questo. E con le bellissime slide di Emanuela ho chiuso il mio giorno 1, lasciando perdere (mea culpa (?)) la birra finale dato che c’era una folla tale che sembrava un mosh pit ad un concerto dei Meshuggah.
Dopo il birrozzo in realtà c’era un altro intervento di rilievo che però ho saltato per negligenza (perdonatemi ragazzi!), ovvero Federico Caprari insieme a Enrico Risa per un talk a due bocche, quattro mani e quattro gambe tipo Goro di Mortal Kombat sulla combinazione di codice Elixir e Rust per applicazioni distribuite e iperperformanti.
Giorno 2: “Ah ma siamo ad una conferenza?”
Ultimamente sto provando una certa avversione nei confronti del mondo dei videogiochi, inspiegabilmente. Questo ha fatto si che il giorno 2, dove la track di game development era leggermente più nutrita, in preda ad una certa mancanza d’attenzione, ho preferito non guardare nessun talk dato che la scaletta che ho visto ha solleticato a malapena la mia curiosità.
Tra le cose interessanti che c’erano, in mezzo al marasma di talk sullo sviluppo videoludico, ho identificato queste:
- What Service Workers can do - di Maurizio Mangione (ciao Mauri! Mi hai salutato in conferenza ma ero veramente storto di sonno)
- Monads Explained for OOP Developers - di Mikhail Shilkov
- What Haskell taught us when we were not looking - di Eric Torreborre
Cui però non ho dato spago. Quello che invece ha impiegato la maggior parte del mio tempo è stato bighellonare insieme al mio esimio collega Francesco e al mio tecnicamente ineccepibile compaesano Alessandro parlando principalmente di programmazione funzionale, Lisp, Haskell, amenità, infrastrutture ridondate, sarcicce.
Codemotion si conferma anche con questa edizione quindi non solo quel coacervo di talk interessanti che è già da un paio d’anni, continuando ad alzare il tiro sia con gli speaker che con i keynoter, ma anche l’occasione a Roma e Milano per incontrare quegli amici che non vedi mai, con cui interagisci troppo tempo da dietro una tastiera e un monitor, per chiacchierare a colpi di birra anziché di righe di codice.
L’unico difetto che gli trovo comincia ad essere la track sul game development, dato che mi sembra una cosa abbastanza rara che le persone interessate a quella specifica traccia si facciano contaminare anche dalle altre, mentre chi frequenta Codemotion per (attenzione, buzzword in buca) DevOps, sviluppo frontend (React, Elm et similia), programmazione funzionale - ripeto - a me pare che non abbia molto l’interesse, a parte rari casi, di spararsi un’ora di sviluppo di videogiochi. Ma probabilmente è un mio limite, e sto solo generalizzando l’impressione che ho avuto personalmente.
Il verdetto finale non richiesto è ovviamente che anche le prossime edizioni mi vedranno in prima fila. Vorrei arrivare a proporre un talk. Che la Forza sia con me, con lo staff di Codemotion (sempre cari ragazzi), e con tutti li nostra.
Questo post è stato scritto principalmente su due letti, uno a Palestrina e uno a Cetona. Le foto sono ovviamente dei bellissimi e bravissimi ragazzi di Codemotion. La colonna sonora è To Be Everywhere Is To Be Nowhere dei Thrice.
