Aspettando il 2021, e mettendo da parte il codice

Di solito mi approccio alla scrittura del post di fine anno un po’ prima, invece quest’anno, quest’anno che per molti è stato peraltro piuttosto problematico, non so quasi che scrivere. Ho la testa vuota, in bolla, caput, perché per me è stato un anno di grande scoperta in verità: stavo pensando di fare la lista delle cose che ho fatto e di quelle che vorrei fare nel prossimo “chunk” della mia vita, ma a trent’anni queste cose da diario preferisco lasciarle agli altri e concentrarmi invece su qualcosa che sia più - come dire - olistico.

Il 2020 per me è stato un anno di scoperta perché ho trovato finalmente il coraggio di guardarmi dentro e capire che percorso di vita intraprendere, quali sono le cose che voglio imparare a fare, i posti dove voglio andare. Ho imparato ad apprezzare i capisaldi che vorrei dare alla mia esistenza, ho imparato a fare fuori cose che credevo fossero importanti e invece non andavano più bene, ho imparato che alcune cose vanno bene così. Potrebbero andare meglio ma potrebbero anche andare peggio, e pensare con ansia a come potrei migliorarle non mi fa bene.

Per me quest’anno è stato, al netto delle disgrazie e delle gioie, un anno di grande consapevolezza. È stato complicato fare queste riflessioni in un appartamento di qualche decina di metri quadri, su una sedia che è la stessa sia quando ti svaghi che quando lavori, ma credo di aver fatto un buon lavoro introspettivo: ho trovato la forza, io che ho l’ansia che mi tiene sempre per mano, di dirmi “ok, ma adesso basta”.

Le mie più grosse soddisfazioni in questo 2020 vengono proprio da questo aspetto qui: rilassandomi, mi sono potuto dedicare a cose assolutamente prive di senso (forse) come esperimenti usa-e-getta in qualsiasi linguaggio di programmazione, a pensare a cosa vorrei fare l’anno prossimo non solo dal punto di vista professionale né solo da quello “nerdico”. A scegliere una nuova casa¹, a cosa metterci dentro.

Sapete cosa vi auguro? Il 2020 è stato un anno di merda per un sacco di gente, ma non per me. Vi auguro un 2021 come il mio 2020: un anno che vi faccia capire che l’importante non è stare sempre a tremila con tutto (passioni comprese²); bensì che siete nel posto giusto, al momento giusto, perché è il vostro posto e il vostro momento. Per 365 giorni, per 24 ore al giorno.

Auguri.

In foto³, più o meno, come è stato il nostro lockdown.

Controavvento 2020: basta con 'ste cose fighette, arriva il post-avvento punk

È stato un anno particolare: riflettevo con un amico carissimo su come abbia l’impressione che dal momento in cui eravamo a casa sua a cercare un po’ di refrigerio dal caldo estivo¹ a questo Natale siano passate tipo due sere. Il tempo passa inesorabilmente: è il suo bello e il suo brutto. E in un anno bislacco come questo, il tempo passa proprio in maniera altrettanto stramba, perché chiaramente siamo stati messi alla prova in diversi modi dei quali non mi va nemmeno di parlare per non cadere nella solita retorica di come una pandemia globale ha cambiato il nostro modo di vivere.

Anche perché a me col piffero. Nel senso: ero un orso, permango nel mio status di orso.

Fatto sta che sono successe due cose molto importanti: la prima è una certa qual proliferazione di contenuti atti a insegnarti financo come lavarti i denti, dall’altra una certa insofferenza crescente da parte del sottoscritto e di tutta una silente parte di pubblico rispetto a dati contenuti.

È così che Agnese, nel pieno del suo anno di “walkabout”, ha intrapreso un progetto che non solo risuonava con la sua indole e con l’indole di tutto il suo gruppo di lavoro²: un Calendario del ControAvvento, per ricordare a tutti che va bene scegliere di passare il tempo sul divano a guardare il muro, che non dobbiamo lasciare che la sindrome dell’impostore ci fagociti davanti a questi schermi e timeline piene di traguardi tagliati. Che forse ci sono persone come loro, che al posto dei cento metri piani preferiscono correre le maratone - e sono fatte per conseguire quel tipo di risultati. Che come disse una mia grande fonte di ispirazione³, quello che conta è la lunga percorrenza.

All’interno di questo contesto Agnese è arrivata a formulare attraverso il suo post una serie di conclusioni assolutamente giuste (dal mio modesto e parziale⁴ modo di vedere) sulla brand identity. Senza volervi raccontare anticipatamente altro, vi invito a leggere direttamente quello che ha scritto lei clickando qui.

Una cosa però la voglio ancora scrivere: questo progetto, che ho seguito da bordo campo come un allenatore troppo anziano anche per impartire consigli, è una cosa tutta loro di cui sono fierissimo perché ho visto che un gruppo di persone in autonomia è arrivato a contaminarsi smodatamente, e a capire che il mischione clamoroso di competenze e punti di vista molto spesso produce qualcosa che va ben oltre la somma delle parti.

E al di là di classi astratte e funzioni pure, è qualcosa di cui dovremmo tenere spesso conto anche noi sviluppatori.

Photo courtesy of Suzanne Jutzeler

Back to Linux

Atto di dolore: il mio computer fisso è stato un Hackintosh per una cospicua dose di anni. L’ho costruito in un momento in cui la supremazia di Intel nelle macchine di Apple sembrava essere una cosa indiscussa per gli anni a venire, e in un momento di straordinaria compatibilità con tutto l’hardware esistente. Non mi sento di aver buttato soldi e tempo, anzi: ho acquisito negli anni mettendo le mani in pasta con varie distribuzioni di macOS per dispositivi non-Apple una certa conoscenza di quello che c’è sotto il cofano, cosa che per un appassionato di sistemi operativi è sempre una grossa soddisfazione.

L’ultima build è stata particolarmente compatibile e divertente, sono stato aiutato da Gianguido e il setup ce lo siamo fatto insieme in videocall anni e anni fa. E non c’era nemmeno una pandemia globale in corso!¹

Insomma: di punto in bianco per colpa di Apple smettono di uscire i driver NVIDIA per MacOS, quindi non posso più aggiornare il mio sistema operativo. Di seguito una lista di ottimi motivi che mi hanno riportato sulla retta via:

• Niente più aggiornamenti del sistema operativo, quindi niente più nuove feature. Non sarebbe stato un problema, le nuove feature dei sistemi Apple sono veramente fegatelli. Se non che…
• Le applicazioni hanno smesso quest’anno di supportare High Sierra (che era la versione a cui ero fermo): Docker mi avvisava con un inquietante popup che avevo una versione non supportata, e di aggiornare il mio sistema operativo; il carico da novanta ce l’ha messo Homebrew qualche settimana fa mostrando un bel messaggio in console dicendo che da quel momento se avessi incontrato qualche problema di build era fortemente sconsigliato che aprissi una issue su GitHub. Lo stesso iTerm non gira più su High Sierra se non sbaglio.
• Ho aggiornato il laptop a Big Sur. Sul lato performance niente da dire, penso che sia stato fatto un ottimo lavoro. Sul lato UI viceversa ho pensato “chi ha trasformato il mio computer in un Kid Clementoni?”
• Last but not least, le mie cuffie bluetooth appena acquistate hanno qualche problemino con lo stack bluetooth/audio di macOS.

Insomma, nonostante io adori il fatto di avere un sistema operativo curato dal punto di vista della UX, la convivenza era diventata estremamente difficoltosa; quindi mi sono sentito in potere, una volta accumulato il coraggio di mandare a terra un setup vecchio di circa 3 anni e spicci, di sbattere macOS fuori di casa.

Hello Linux my old friend

Non voglio fare paragoni azzardati (e sarebbe un enorme atto di hybris) ma ogni volta che succede questa cosa mi sento come Daniel Robbins che torna a Linux dopo anni di BSD. Il primo pensiero che ho avuto, una volta avviata la mia Linux box reinstallata di fresco, è stata “flexibility at your fingertips”, ovvero qualsiasi personalizzazione finalmente a portata di dito. Con un briciolo di vergogna mi chiedo: perché ci ho messo tanto?

Ovviamente ho dovuto prendere qualche precauzione: negli anni ho accumulato un sacco di piccoli trucchetti e cavolate personali per aumentare il throughput della mia giornata lavorativa, e tutta questa suite di script, programmini e utility varie ha richiesto qualche piccolo adattamento. In un weekend lungo comunque (standoci dietro relativamente poco tempo se non la mattinata che mi ha richiesto l’installazione iniziale di Arch Linux²) ho sfangato tutto quanto, soprattutto per quanto riguarda il remap della mia tastiera, su cui avevo fatto un bel lavoretto di fino usando Karabiner. Ho riportato tutto su Linux usando xkeysnail, un software di cui probabilmente parlerò più in dettaglio a breve.

Dall’altra parte, una volta attraversata l’imperscrutabile barriera del “avrò una workstation funzionante prima di sera?”, mi sono potuto sedere un attimo a osservare il setup che avevo tirato su. Un setup per la precisione composto di:

• Arch Linux (kernel 5.9.14-arch1-1 al momento della scrittura di questo post);
• Systemd 247.2 e systemd-boot come bootloader, grazie a gsora e smlb per i consigli³;
• GNOME 3.38.2;
• Tema Arc Solid, una certezza;
• Un po’ di estensioni per GNOME Shell, giusto perché di serie viene fuori un po’ sguarnita⁴;
• Tilix come emulatore di terminale;
• Rofi come launcher di applicazioni;
• Firefox come web browser;
• Una sequela di altre applicazioni con le quali vi annoierei e basta.

Devo dire che sono rimasto piacevolmente colpito soprattutto dal fatto che GNOME Shell abbia risolto i suoi problemi di performance, dal fatto che Nautilus che già prima era un signor file manager adesso è veramente super maturo (con un bel po’ di feature e una bellissima interfaccia⁵), e dal fatto che lavorare con Linux è ormai un piacere raro.

Docker non è costretto a ricorrere a una ridicola macchina virtuale per poter funzionare, e l’hardware che hai sotto lo puoi sentire scalpitare. L’altro giorno ho scritto a un amico che stavo compilando una release di Erlang - tempo che lui mi rispondesse la macchina aveva già finito. Insomma: avete capito no?

Lavorare con GNOME oltre tutto è una sciccheria: devo dire che una volta risolti i problemi di performance dell’ambiente grafico macOS non mi manca per niente, specie dato il fatto che mentre GNOME è migliorato esponenzialmente anno dopo anno la UI del mio Macbook è diventata sempre peggiore. L’esperienza utente è ugualmente rifinita, e con dei piccoli ritocchi al tema di base (come ho già detto uso Arc nella variante solid, anche se Adwaita è migliorato un sacco nell’ultimo anno) si può veramente azzardare il paragone con altre esperienze desktop nella UX delle quali vengono spesi miliardi l’anno.

Insomma: è anche la prima volta che provo un setup full Linux col mio doppio monitor. E devo dire che mi trovo egregiamente. Spero che la soddisfazione cresca ancora :-) e soprattutto spero di scrivere presto qualche piccola guida “vecchio stile” riguardo delle cose che ho scoperto in queste settimane di rinnovata convivenza col pinguino.

Elixir per idioti /8, costruiamo una API REST super semplice

È un sacco di tempo che non parliamo di Elixir, e il nostro percorso era rimasto un po’ appeso con la parte 7, dove avevamo creato un’applicazioncina di prova con Phoenix Framework. Se vogliamo fare cose più complicate come modellare un microservizio tutto nostro attorno a un dominio ben preciso però qualcosa come quello che abbiamo visto è limitante, perché visualizzare delle paginette web limita un pochino l’interoperabilità che possiamo avere con altri servizi.

E se al posto di pagine web volessimo servire dei JSON in puro stile API REST-ful¹?

Elixir e Phoenix coprono anche questo caso d’uso in maniera eccellente. In realtà potremmo fare il tutto anche senza Phoenix solo usando il webserver che ne è alla base, cioè Cowboy, ma Phoenix offre una serie di semplificazioni “on top” che ci rendono leggermente più semplice la vita, accorciano in maniera notevole questo tutorial, e risultano anche comode per evoluzioni future della nostra piccola API, come il supporto out-of-the-box a JWT².

Bando alle ciance, andiamo a creare il nostro nuovo progettino:

$ mix new tiny_echo_api --no-webpack --no-ecto

Usando lo scaffolder di Phoenix, che è fatto molto bene, andiamo a dichiarare che stiamo creando un nuovo progetto senza bisogno di frontend (--no-webpack) e senza strato di persistenza su database (--no-ecto)³.

Spostiamoci nella directory che è stata appena creata, installiamo le dipendenze del nostro progetto e facciamolo partire:

$ cd tiny_api
$ mix deps.get
$ mix phx.server

localhost:4000 ci mostrerà la solita paginetta di benvenuto, non diamole troppa attenzione, e andiamo immediatamente a implementare un nuovo endpoint che prende in input una stringa, e ce la restituisce dentro un JSON. Non un grande servizio in sé, ma è un ottimo modo per fare tutto il giro, vedere cosa ci mette a dispozione Phoenix e eventualmente cominciare a costruirci sopra qualcosa.

Apriamo il router, che abbiamo già visto nell’episodio precedente:

# lib/tiny_api_web/router.ex

defmodule TinyApiWeb.Router do
  use TinyApiWeb, :router

  pipeline :browser do
    plug :accepts, ["html"]
    plug :fetch_session
    plug :fetch_flash
    plug :protect_from_forgery
    plug :put_secure_browser_headers
  end

  pipeline :api do
    plug :accepts, ["json"]
  end

  scope "/", TinyApiWeb do
    pipe_through :browser

    get "/", PageController, :index
  end

  # Other scopes may use custom stacks.
  # scope "/api", TinyApiWeb do
  #   pipe_through :api
  # end

  # Enables LiveDashboard only for development
  #
  # If you want to use the LiveDashboard in production, you should put
  # it behind authentication and allow only admins to access it.
  # If your application does not have an admins-only section yet,
  # you can use Plug.BasicAuth to set up some basic authentication
  # as long as you are also using SSL (which you should anyway).
  if Mix.env() in [:dev, :test] do
    import Phoenix.LiveDashboard.Router

    scope "/" do
      pipe_through :browser
      live_dashboard "/dashboard", metrics: TinyApiWeb.Telemetry
    end
  end
end

E andiamo a modificare le rotte dichiarate in questo modo:

scope "/", TinyApiWeb do
  pipe_through :browser

  get "/", PageController, :index
  get "/echo/:payload", EchoController, :echo
end

In questo modo andiamo a dichiarare una nuova rotta disponibile solo in GET che ha la forma /echo/qualcosa, e andremo poi a fare in modo che quando noi chiamiamo la nostra applicazione sulla rotta /echo/qualcosa quella ci risponda a sua volta qualcosa dentro un JSON di risposta.

Nel router abbiamo dichiarato che andremo a pescare la funzione echo da un controller chiamato EchoController; Phoenix si aspetterà il modulo corrispondente, quindi andiamolo a creare, mettendoci dentro anche l’implementazione della funzione echo:

# lib/tiny_api_web/controllers/echo_controller.ex

defmodule TinyApiWeb.EchoController do
  @moduledoc """
  This module handles echo requests and replies back
  with an echo JSON containing the word used by the request.
  """

  use TinyApiWeb, :controller

  def echo(conn, params) do
    response = %{"reply" => params["payload"]}
    json(conn, response)
  end
end

Eccoci qua: come vediamo abbiamo definito il modulo TinyApiWeb.EchoController, ci abbiamo messo addirittura una bellissima @moduledoc per aiutare chi si imbatte in questo modulo a capire che cosa fa (Elixir dispone di utility che generano automaticamente la documentazione corrispondente da queste annotazioni), gli abbiamo detto di comportarsi come un controller Phoenix attraverso l’uso di use, e abbiamo implementato la funzione echo, che va poi a rispondere usando la funzione json messaci a disposizione da Phoenix per poter rispondere direttamente usando la mappa che abbiamo dichiarato.

Facciamo ripartire il servizio con mix phx.server e andiamo a vedere su http://localhost:4000/echo/this-is-an-answer che cosa abbiamo combinato:

$ curl localhost:4000/echo/this-is-an-answer
{"reply":"this-is-an-answer"}

Bonus trick: usare la destrutturazione

Volendo sfruttare la potenza della sintassi di Elixir, possiamo implementare la funzione echo in un altro modo, andando a usare la destrutturazione per tirare fuori il campo payload dai parametri della chiamata poi poi andare a costruire la mappa con la risposta direttamente inline:

def echo(conn, params) do
  %{"payload" => payload} = params
  json(conn, %{"reply" => payload})
end

Oppure, volendo essere più concisi, andando a sfruttare tutto quello che la sintassi di Elixir ci mette a disposizione, così da scrivere tutto su una sola riga:

def echo(conn, %{"payload" => payload}), do: json(conn, %{"reply" => payload})

A voi giudicare se in questo modo si perde di leggibilità. Quello che andiamo a fare in questo modo è utilizzare il pattern matching insieme alla destrutturazione direttamente nella firma della funzione. Le tre implementazioni che abbiamo visto sono assolutamente equivalenti.

Volete implementare un nuovo endpoint nel vostro servizio? Adesso avete visto come funziona tutto il giro. Potete sbizzarrirvi: fatelo! :-)

Elixir, programmazione funzionale e tanto ridere, live con Francesco Sciuti

Ultimamente sembro uno di quei tizi stile late nineties che non scrivevano mai sul blog e quando scrivevano finivano per scrivere una cosa tipo “non scrivo da un botto di tempo, ma tornerò”, poi non tornavano. Vorrei scrivere la stessa cosa, e vorrei garantire che non finirò come quei tizi, ma mi rendo conto che solo un track record positivo potrà confermare nel futuro che questa speranza non è stata disattesa.

A parte le farneticazioni da festa d’addio di Bilbo Baggins, sono stato ospite di una live di Francesco Sciuti in cui blateravo di Elixir e di programmazione funzionale: se è vero che chi sa fa e chi non sa insegna, effettivamente questo fa il paio col fatto che io non mi ritenga particolarmente qualificato per parlare di entrambe queste cose.

Eppure ci siamo divertiti un sacco! E ho avuto anche l’opportunità di raccontare alcuni aneddoti relativi alla mia vita universitaria, a quando ho iniziato a sviluppare, a spiegare un paio di concetti che ho assimilato durante gli anni e a mettere in luce alcune delle particolarità che rendono Elixir un ottimo linguaggio e un’ottima piattaforma per costruire applicazioni stateful e/o che fanno largo uso di concorrenza.

Francesco è veramente un grande, mi sono avvicinato al canale di Devmy da poco, e ho scoperto che tanti amici hanno già parlato da lui con argomenti super interessanti, per cui vi raccomando di guardare tutti (per quanto possibile) i video con attenzione, dato che gli speaker sono di calibro eccezion fatta per il sottoscritto :-D

Oltre lo sviluppo software, io e Francesco abbiamo altri punti di contatto: lui è un capellone e io sono un ex capellone¹, lui è un metallaro e io sono un metallaro, lui è un imbecille (nel senso buono del termine) e io anche (nel senso meno buono del termine).

Insomma, date le premesse sfavillanti, è stata un’esperienza meravigliosa che spero di ripetere a breve, comprensiva di micro-live-coding per spiegare multimethod e currying. Yeah!