Elixir per idioti /4, definire moduli e funzioni

La scorsa volta, che ormai è stata un po’ di tempo fa, avevamo visto come operare sulle liste tramite le funzioni messe a disposizione dal modulo Enum. Un modulo non è altro che una raccolta di funzioni, come una scatola degli attrezzi; possiamo usare i moduli per organizzare meglio il nostro codice e raggruppare le funzioni che scriviamo per affinità. Adesso riprendiamo le basi del linguaggio e poniamoci una domanda: cosa succederebbe se io volessi scrivere un modulo tutto mio con blackjack e squillo di lusso in cui raggruppare le mie funzioni?

È abbastanza semplice, ci basta usare defmodule. Un modulo Elixir ha questa faccia:

defmodule Hello do
  def salute(name) do
    IO.puts("I salute you, " <> name)
  end

  def sayhello(name) do
    IO.puts("Hello, " <> name)
  end
end

Insieme a defmodule stiamo imparando anche come definire delle funzioni. Una funzione in Elixir si compone della keyword def, un nome, e degli argomenti (quelli passati tra parentesi). In seguito possiamo richiamare le funzioni del modulo che abbiamo definito in questo modo:

Hello.salute("Alessio")

E otterremo che venga stampato a schermo un saluto col nostro nome, come da codice. Se vogliamo provare a giocare un po’ con la definizione dei moduli possiamo buttare giù uno script Elixir al volo, creando un file chiamato hello.exs con questo contenuto:

defmodule Hello do
  def salute(name) do
    IO.puts("I salute you, #{name}")
  end

  def sayhello(name) do
    IO.puts("Hello, #{name}")
  end
end

Hello.salute("Alessio")
Hello.sayhello("Arcibaldo")

Per eseguirlo ci basta spostarci nella directory dove si trova e lanciarlo con il comando elixir:

$ elixir hello.exs
I salute you, Alessio
Hello, Arcibaldo

Possiamo definire quanti moduli vogliamo. In uno script piccolo di un solo file fatichiamo a vedere l’utilità di una cosa simile, ma quando abbiamo tanti file e un progetto che comincia ad assumere una stazza importante, l’ordine è fondamentale. Per quanto riguarda la creazione di un nuovo progetto (non uno script piccolino, proprio un progetto di quelli potenzialmente grandi) da zero vi rimando al post di Francesco, che illustra molto bene il tool che viene usato per gestire i progetti in Elixir, Mix, insieme al suo uso più comune, ovvero mix new.

La keyword return in Elixir

Vale la pena spendere due parole, dato che stiamo parlando per la prima volta davvero di funzioni, su come definire i valori di ritorno delle proprie funzioni in Elixir. Al posto di usare return come in tantissimi altri linguaggi, tra cui JavaScript, Java, o Ruby, in Elixir il valore di ritorno di una funzione è semplicemente l’ultima espressione che scriviamo dentro di essa.

Per dare un occhio più approfondito a questa piccola particolarità possiamo definire un modulo che si occupi di fare piccole operazioni sui numeri:

defmodule SimpleMath do
  def divide_by_two(number) do
    number/2
  end

  def square(number) do
    number*number
  end

  def sum_three(number) do
    number+3
  end
end

Salvando questo modulo come simple_math.ex possiamo caricarlo dentro iex e farci degli esperimenti:

iex(1)> import_file("simple_math.ex")
{:module, SimpleMath,
 <<70, 79, 82, 49, 0, 0, 5, 56, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 159,
   0, 0, 0, 17, 17, 69, 108, 105, 120, 105, 114, 46, 83, 105, 109, 112, 108,
   101, 77, 97, 116, 104, 8, 95, 95, 105, 110, ...>>, {:sum_three, 1}}
iex(2)> 4 |> SimpleMath.divide_by_two |> IO.puts
2.0
:ok
iex(3)>

Come vediamo, all’interno delle funzioni ci basta usare un’espressione per identificarla come valore di ritorno. Se volessimo la stringa ciao come valore di ritorno, non dovremmo fare altro che scrivere "ciao" alla fine della funzione. Per chi viene da altri linguaggi questa è una differenza non da poco, dato che Elixir non è strutturato per permettere per esempio i cosiddetti “early return”¹ all’interno delle funzioni. Io però con questo meccanismo ho preso confidenza abbastanza in fretta.

Adesso che sappiamo come definire funzioni ma soprattutto come definire moduli dove raccogliere le nostre funzioni, possiamo mantenere il codice ordinato. Non ci resta altro che cominciare con qualche piccolo progettino².

Vai alla parte 3

React Europe 2018: riportando tutto a casa

Sono passate un po’ di settimane e ho sedimentato quello che ho visto andando a React Europe (grazie ad AdEspresso, che mi ha pagato viaggio e biglietto). Oltre i francesi che parlano come sempre un pessimo inglese e come di consueto fingono persino di non capire quando qualcuno tenta di chiedergli qualcosa che non sia “water”, in realtà ho visto parecchie cose riguardanti React e non solo; e adesso mi riporto tutto a casa, in una parafrasi del titolo del primo disco dei Modena City Ramblers che belli ma non ci vivrei quanto ci pare, ma è stato uno dei dischi della mia formazione e quindi ve lo beccate.

È stata una bellissima conferenza, che mi ha fatto soprattutto misurare le competenze che ho acquisito nel tempo su questa libreria e su questo stack (Redux et similia), facendomi rendere conto sia di quanto io valga come sviluppatore React, sia di quanta strada io debba ancora fare prima di potermi considerare come uno che ha una conoscenza approfondita di come funziona React al suo interno. Ho anche notato che per mia fortuna ho dei colleghi che sono in grado di insegnarmi ogni giorno qualcosa di nuovo.

La sessione di keynote di Ken Wheeler

Il mio talk preferito è stato la sessione di keynote di Ken. Ho conosciuto Ken l’anno scorso durante il mio giro a Redmond per Build, e devo dire che sono rimasto impressionato da due cose: è l’unica persona oltre Sean Larkin che mi abbia mai consigliato di provare a scrivere un plugin per webpack, ma soprattutto è un adorabile americanissimo patriotticissimo cialtrone.

Con il suo savoir faire ci ha introdotto le novità di React 16, le nuove API (tra cui la Context API, che passa da essere etichettata come magia nera ad essere un cittadino di prima classe), tutto applicato ad un caso di studio dove trasformava un e-commerce di baguette in un e-commerce di pane in cassetta statunitense con tanto di stelle e strisce sullo sfondo. Ha fatto ridere ed è stato d’impatto – quasi come beccarlo a pranzo e vedere che si ricordava di me.

I trend: CSS in JS e render props

CSS-in-JS è un trend che nella community React ha sempre fatto discutere. Anche quest’anno, con la fioritura di un sacco di librerie dedicate a questo paradigma che consente di includere il codice dello stile CSS di un elemento all’interno del suo codice JavaScript, abbiamo avuto di che parlare insieme a tutti gli speaker. Chiunque parlasse di CSS ha menzionato l’uso di una libreria CSS-in-JS; il discorso nel suo complesso è troppo ampio per essere affrontato in questo post, ma direi che anche se ormai è stato sdoganato come sia possibile programmare secondo questo approccio e questa organizzazione, larga parte della community ha ancora le sue perplessità e in tanti utilizzano ancora Sass e CSS legacy standalone.

L’altro trend su cui non ho visto nessuno speaker fare silenzio (circa) è quello delle render props. L’anno scorso Michael Jackson, l’autore di React Router, ha tenuto un talk in cui spiegava come secondo lui i componenti di alto ordine fossero sopravvalutati e secondo lui non risolvessero il mistero principale che è quello della fonte di provenienza dei dati su cui fare logica mentre si sviluppa un componente. Contestualmente ha introdotto il concetto di render prop, ovvero una prop di un componente che non fa altro che eseguire una funzione passando in input dei valori relativi allo stato interno di quel componente stesso.

Questo permette, avendo un componente con una sua logica di stato, di iniettare il comportamento di rendering dall’esterno. È interessante, e in AdEspresso abbiamo cominciato già da un po’ ad usare le render prop per i nostri componenti: devo dire che una volta afferrato il concetto (che di suo è semplice per chi ha una conoscenza di React superiore all’hello world) ci si abitua in fretta e il codice finale risulta molto pulito.

Team come quello di Apollo hanno riscritto la propria suite di componenti React passando da un approccio basato sugli higher order component a un approccio basato su render props. Gli esempi che sono stati fatti live mi hanno convinto che sia un approccio virtuoso, anche se come sempre non esiste né il martello d’oro né il proiettile d’argento.

Varie ed eventuali: la Francia, il cibo

Parigi è un posto particolare, accattivante, con uno stile tutto suo. Personalmente ho trovato modo di scontrarmi con i francesi anche nelle piccole cose, e ho trovato chi effettivamente ha finto di non parlare una parola di inglese davanti a me, chi veramente non lo parlava, e chi non mi ha rivolto la parola per i motivi più bislacchi. Nonostante la fauna, il posto è accattivante e ho capito due cose: la prima è che ci dovrò tornare, dato che non ho trovato il tempo né le forze di andare in centro a visitare posti come Notre-Dame; la seconda è che anche se a me non è piaciuta molto (per il poco che ho visto), capisco benissimo chi la ama alla follia data la sua particolarità anche nelle minuzie di una periferia come quella di Charenton-le-Pont dove eravamo noi.

Lo so che è come giudicare Roma andando solo al centro commerciale Roma Est, ma questi sono gli strumenti euristici che ho. Accontentatevi.

La conferenza nel suo complesso invece non solo ha esibito dei talk e degli speaker di grandissima qualità, ma è la prima convention di sviluppatori dove (perdonate la trivialità, lo so) vedo offrire un buffet di cibi tipici di una qualità veramente sopraffina, tra panini al fois gras, salmone affumicato e non, altri tipi di pesce, quiche mastodontiche e una selezione di formaggi da far girare la testa.

Il primo giorno tra i miei gusti non proprio facilissimi in fatto di pesce e il fatto che oggettivamente il pranzo è stato meno particolare, il mio piatto è stato il tipico piatto da conferenza.

Il secondo giorno invece tra i mini hamburger di manzo e di salmone cucinati sul momento, il salmone e una generale maggiore varietà io, Gabriele, Mattia e Andrea abbiamo opposto molta meno resistenza al preludio dell’abbiocco post-prandiale. Che, sì, è un modo molto colto per dire che ci siamo sfondati di cibo.

Ma consentitemi di riprendere l’argomento francesi e spocchia per un paragrafo almeno: è mai possibile che alla domanda “do you speak english?” si abbia come unica risposta uno sguardo scocciato? È mai possibile che visto un turista palesemente estero lo si approcci parlando solo in francese e anche in maniera piuttosto incomprensibile per uno che ha orecchio verso un sacco di lingue? Ma soprattutto, è mai possibile che per le dieci di sera chiudano tutti i posti che ti possono dare un minimo di conforto culinario? Io questo non lo so, buona serata a tutti. Quello che so è che il mix di bellezza architettonica, spocchia degli autoctoni e cucina oggettivamente caratteristica, buona e varia, fa sì che Parigi ti rimanga nel cuore a prescindere dal sentimento negativo o positivo che susciti, come una sorta di post-it con scritto “ricordati che sei stato qui”.

E anche se quando i francesi parlano inglese non si capisce un benemerito, anche se sono andato a letto senza una cena che non fosse un pacchetto di patatine, anche se ho appurato che i parigini¹ a domanda non rispondono affatto, mi porterò sempre dietro quanto mi sono divertito, quante cose assurde ho visto (come la replicazione di un event store basato su Redux attraverso nodi multipli), e quante persone fantastiche ho incontrato².

Come usa Instapaper Marco Arment?

Stamattina sul mio digest di Quora ho beccato una vecchia risposta di Marco Arment alla domanda su come lui stesso usasse Instapaper. La cosa che mi fa ridere è che lui non solo ha risposto, ma nella risposta parla di sé in terza persona come se dovesse tirare a indovinare:

And if I had to guess, I’d imagine that he doesn’t use Evernote or Facebook much, he auto-sends liked articles to App.net for testing, and he auto-sends all archived articles to Pinboard. He also has Twitter and Tumblr linked but doesn’t auto-post there, preferring instead to manually select when to post.

Mi ci sono fatto sopra una risata di cuore. È uno strano ragazzo.

Microsoft Build 2018, scartabellando tra le cose interessanti

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.

Elixir: Phoenix Framework 1.4 in arrivo

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.