Alessio Biancalana Grab The Blaster di Alessio Biancalana

Elixir per idioti /1

Visto che ci siamo cominciamo l’anno nuovo col piede giusto, e diamo il via alla serie di post “Elixir per idioti”, ovvero appunti sparsi, confusi e ordinati semicasualmente sul mio viaggio nell’ecosistema di Elixir.

Bando alle ciance, iniziamo:

Why

Elixir è un linguaggio con una sintassi molto simile a quella di Ruby che però, contrariamente appunto a Ruby, sfrutta la potenza della BEAM, ovvero la virtual machine di Erlang, e dell’ecosistema OTP per costruire ed eseguire applicazioni per la maggior parte di rete, a bassa latenza, distribuite, fault-tolerant.

Quello che a me fa impazzire è che oltre ad essere un vero gioiellino per le web application ed in generale la programmazione distribuita, la sintassi funzionale impura Ruby-like lo rende in realtà un meraviglioso giocattolino general purpose, che diventa adatto per costruire qualsiasi tipo di programma, anche un CLI tool o altro.

Il sito ufficiale del linguaggio è elixir-lang.github.io.

Setup

Il setup dell’ambiente è abbastanza facile. Su macOS:

$ brew install elixir

Su Linux leggermente meno, ma dipende dalla distribuzione che usiamo. In genere abbiamo il pacchetto elixir nei repository della nostra distribuzione. Per Arch Linux è sufficiente un:

# pacman -S elixir

Ubuntu e Debian per esempio prevedono che venga usato il repository di pacchetti di Erlang Solutions:

$ wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb
$ sudo dpkg -i erlang-solutions_1.0_all.deb
$ sudo apt-get update
$ sudo apt-get install esl-erlang elixir

In caso di necessità comunque, informazioni aggiornate possono essere trovate sulla pagina ufficiale.

REPL

Figata! Ora che abbiamo il nostro setup possiamo divertirci con il REPL.

A Read–Eval–Print Loop (REPL), also known as an interactive toplevel or language shell, is a simple, interactive computer programming environment that takes single user inputs (i.e. single expressions), evaluates them, and returns the result to the user; a program written in a REPL environment is executed piecewise. The term is most usually used to refer to programming interfaces similar to the classic Lisp machine interactive environment. Common examples include command line shells and similar environments for programming languages, and is particularly characteristic of scripting languages.

Wikipedia ci dà una definizione abbastanza precisa di cos’è un REPL, ed io ad oggi considero questo tipo di applicativo la via più breve per imparare un linguaggio di programmazione, sperimentare funzioni specifiche e scoprire sempre cose nuove riguardo gli internals.

Tip: moltissimi altri linguaggi hanno un REPL incluso nell’ambiente di sviluppo, come Python (python), JavaScript (node o la stessa console di Chrome), Ruby (irb), Haskell (ghci).

Il nostro REPL nello specifico si chiama iex. Lanciandolo nel terminale ci dà un po’ di informazioni utili, dopodiché sta a noi cominciare a fabbricare i nostri elisir:

blaster at gandalf in [~]
22:02:51 › iex
Erlang/OTP 20 [erts-9.2] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]

Interactive Elixir (1.5.3) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)>

Ci siamo.

Hello world

Il percorso di apprendimento di un nuovo linguaggio comincia sempre con un hello world.

iex(1)> IO.puts("hello world!")
hello world!
:ok
iex(2)>

Beh, per ora è tutto 😎

Vai alla parte 2

(2017) => 2018;

Festa!

È stato un anno fenomenale in ogni senso. Grandi vittorie, grandi fallimenti, e grandi accadimenti che non possono essere categorizzati in nessuno di questi due insiemi. In ogni caso, è giunta l’ora del consueto resoconto di fine anno mentre gli ultimi preparativi per la cena fervono, gli amici si mettono in marcia, e io comincio già a sbadigliare nonostante mentre sto scrivendo siano solo le 5 di pomeriggio.

Prima di passare ai buoni propositi, vediamo se la checklist di quest’anno è stata rispettata con una bella retrospettiva:

  • Finire il webserver in C per l’esame di Reti: check
  • Portare al 99,99% il mio grado di conoscenza di JavaScript: check? Probabilmente si, grazie ai ragazzi di RomaJS, a Cristian e a Luca
  • Aiutare qualcuno a costruire qualcosa di grande: non è decisamente andata come speravo per nessuno degli intenti che mi ero prefissato con questo punto; fail
  • Imparare Elixir: direi che qua il check possiamo metterlo, con anche una medaglietta per il mio impegno con la community di Elixir Roma portata avanti insieme all’esimio collega Claudio
  • Programmazione funzionale: adoro Elixir e quando scrivo JavaScript cerco di scrivere codice funzionale. Tuttavia per ora è ancora qualcosa che devo portare all’anno nuovo, a maggior ragione dato che con Haskell sono rimasto una pippa
  • Imparare a fare gli integrali: fail, o meglio sono al punto in cui ero a fine 2016
  • Visitare due o tre posti meravigliosi: tra Seattle e il viaggio di nozze in Giappone ci siamo. E direi che siamo sulla buona strada per farlo ancora, dato lo sforzo che la mia adorabile moglie mette nel tirarmi fuori di casa

… moglie? Ebbene si, mi sono anche sposato 😂 e per ora sembra che io abbia proprio fatto la cosa giusta.

Blaster's wedding

Il terno al lotto sta nell’aver trovato una che quando blatero di service worker o di funzioni variadiche in giro per casa non mi guarda come se fossi un alieno sceso da Plutone. È una donna che ha pazienza. La adoro.

Tornando allo scopo del post, è ora di cominciare a stilare la checklist per il 2018:

  • Haskell, punto
  • Imparare a fare gli integrali parte 2, ovvero provare a darci dentro con l’università
  • Più post sulla programmazione funzionale
  • Più post su Elixir
  • Più post e basta
  • Stare di più con mio padre e mia sorella

E mi sa che anche per quest’anno siamo a posto. Nel 2017 ho tralasciato alcuni aspetti della mia vita. Spero di smettere con quest’anno.

E spero per ciascuno di noi, come sempre, che l’anno venturo sia migliore del precedente.

:wq

Debian Alioth diventerà Debian Salsa

Debian ha deciso di dare una rinfrescata alla sua developer experience, così il giorno di Natale con una mail su debian-devel-announce Alexander Wirt ha annunciato l’entrata in beta di Debian Salsa, il progetto che andrà a rimpiazzare pian piano il buon vecchio Debian Alioth.

Since summer we have worked on our git.debian.org replacement based on GitLab. I am really happy to say that we are launching the beta of our service today. Please keep in mind that it is a beta, we don’t expect any database resets, but under unexpected circumstances it might still happen.

The new service is available at https://salsa.debian.org. Every active Debian Developer already has an account. Please request a password reset via https://salsa.debian.org/users/sign_in – your login is either your Debian login or Debian e-mail address. SSH Keys from udldap get synced into your account.

Alioth per anni ed anni ha servito bene la community, ma si tratta di andare avanti: per quanto funzionale, sicuramente sarà meglio passare a qualcosa di graficamente più accattivante e soprattutto funzionalmente aderente a quello che si aspettano i contributor reclutati di recente.

Quel qualcosa è stato identificato in GitLab, di cui non ho mai fatto mistero di essere un grande fan. Mi fa veramente piacere che un altro grande player del panorama opensource si aggiunga al portfolio di adopter di GitLab, dato che è una piattaforma meravigliosa.

Anziani, bambini, e API lente

Noi programmatori (o in generale noi del reparto IT, per così dire) siamo abituati a vedere la tecnologia in un modo strano: siamo spesso abituati ai disservizi, a interfacce che non mostrano esattamente quello che non dovrebbero, ad errori a runtime eccetera. Per quanto possano essere distanti da questo modo di pensare, persino i nostri coetanei che non si occupano di informatica seguono questa linea di pensiero, e aspettano due minuti prima di dare fuoco ad un dispositivo che non risponde.

Viceversa, ho avuto modo di osservare di recente un bambino e un’aziana a contatto con la tecnologia, ed entrambi al primo spinner mancante (segno di caricamento) e davanti ad un interfaccia che non segnava quello che loro si aspettavano hanno letteralmente dato fuori di matto. Tap a caso sull’interfaccia, se siamo fortunati refresh compulsivi altrimenti solo banali lamenti a voce contro il device, eccetera eccetera.

Ovviamente emerge sempre di più la necessità per il futuro di UI progettate bene, ma anche di backend performanti e livelli di trasporto che siano in grado di rendere onore a queste performance.

Riguardo il trasporto delle informazioni, ovviamente bisogna solo aumentare la copertura hi-perf sul territorio nazionale (e parlo per noi). Riguardo i backend performanti Rust ed Elixir sono due linguaggi che a me piacciono molto e che potebbero fungere da soluzioni.

RomaJS natalizio, tra Angular su vasta scala e lazy loading

Che meraviglia le festività natalizie, e che c’è di meglio delle festività di Natale se non i meetup prefestivi? Ci si fa gli auguri, tra quei pochi che riescono a presenziare sfuggendo ai parenti, alle cene aziendali, agli eventi dove è del tutto assente il coding, e tra una fetta di pandoro e l’altra1 si parla di cose veramente interessanti. Questo mese abbiamo avuto due talk eccezionali:

  • “Angular su progetti da milioni di euro” di Alessandro Avolio,
  • “Image loading techniques” di Guido D’Orsi.

Il talk di Alessandro, “Angular su progetti da milioni di euro”, è stato una conferma per alcuni aspetti, illuminante per altri. Mi ha dato spunto su alcune pratiche da introdurre nei prossimi progetti e mi ha chiarito alcuni dubbi che avevo riguardo lo sviluppo agile in consulenza. È molto interessante come il team di cui fa parte Alessandro abbia in qualche modo potuto segregare il proprio dominio applicativo rispetto ai produttori delle API (ovvero gli sviluppatori backend dello stesso team); le domande alla fine hanno fioccato, e gli argomenti delle questioni poste sono stati tra i più disparati: dalla compilazione del bundle al processo agile del team2. Sicuramente è stata anche un’occasione notevole per mettere alla prova un framework di questo tipo su progetti che non siano la solita todo app, ma qualcosa di molto più reale (dove, ahimé, il rischio di farsi male aumenta esponenzialmente).

Guido invece ci ha presentato varie tecniche per gestire il lazy loading delle immagini nel nostro sito. Ancora una volta abbiamo avuto un talk “no-slides”, con live coding e tutto il resto: Guido mi fa impazzire, perché ogni volta che porta un talk del genere fa delle cose assurde, come quando ha scritto un Virtual DOM senza colpo ferire. Anche questo talk è stato pieno di spunti, dato che non solo nella prima parte ci siamo concentrati molto sulle performance di caricamento, ma nella seconda abbiamo anche analizzato tecniche per la produzione di placeholder leggermente più impattanti dal punto di vista delle performance che però siano decisamente più belli a vedersi.

  1. Nessuna fetta di pandoro è stata mangiata a RomaJS in questo meeting, è un’idea che come tutte le idee veramente buone mi è venuta troppo tardi. 

  2. Alessandro, hai svicolato sul “cosa fanno le altre 30 persone” ma noi non ti daremo mai tregua 😈