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!

Gitbar episodio 44: due chiacchiere sull'open source, CouchDB e Elixir con Mauro Murru

Con grandissimo senso di colpa posto solo adesso una intervista che mi ha visto ospite, purtroppo è un periodo molto complicato a livello di progetti, tant’è che spero di condividerne sempre qualcuno su questo mio taccuino, e invece per sapere che sto facendo uno fa prima a prendersi un appuntamento su Google Calendar come abbiamo dovuto fare io e Mauro per questa sua puntata di Gitbar, il podcast per i software developer italofoni, in cui infatti ci sono molto più cose sui miei ultimi progetti che su questo stesso blog :-D

Innanzi tutto le cose importanti: il tema di questo episodio di Gitbar, in cui il buon Mauro “@brainrepo” Murru mi ha intervistato per una buona ora e mezza, è Elixir, insieme a una bella panoramica di CouchDB e alla discussione sull’importanza dell’open source per uno sviluppatore, sia come opportunità di crescita che ci consolidamento della maggior parte delle competenze – sia hard skill che soft skill.

Potete ascoltare l’episodio online, e andare su gitbar.it per altre perle ma soprattutto per i riferimenti al gruppo Telegram e per sapere in generale come entrare in contatto con la community.

Da parte mia non solo devo ringraziare Mauro per l’ospitalità¹, ma devo anche fargli i complimenti per la preparazione: la discussione sul pattern matching mi ha colto un filo impreparato perché di solito non mi trovo a dover rispiegare il concetto a qualcuno che già lo sa, e soprattutto non mi era mai capitato di parlare in “diretta radiofonica” con qualcuno che avesse una conoscenza così profonda di come si può usare il multi-master sync di CouchDB.

Sono molto felice del risultato: con un intervistatore così e un output del genere, spero che l’esperienza si ripeta!

Photo courtesy of Torsten Dettlaf

L'open source ci rende sviluppatori migliori: il panel di Codemotion il 29 settembre

Per tanto tempo durante le nostre chiacchierate negli orari più improbabili della giornata io e Mattia abbiamo scherzato sulla possibilità di un panel moderato da lui con il sottoscritto come partecipante. “Pensa se succedesse, che casino, hahah”, gli dicevo ingenuamente; poi all’improvviso mi ha scritto che sarebbe successo. Tipo lo scudetto della Roma, che non succede ma se succede.

E quindi il 29 settembre (ovvero questo martedì, dopodomani) saremo io, Leonardo Zizzamia e Matteo Collina, moderati da Mattia Tommasone, riuniti a parlare del perché contribuire a progetti open source renda sviluppatori migliori. La mia tesi di base, piccolo spoiler, è che renda sviluppatori migliori perché di base ci rende persone migliori.

L’orario lo trovate nella pagina dell’evento, a cui per accedere è necessaria l’iscrizione. Probabilmente verrà caricato poi il filmato anche su YouTube, ma è inutile che vi dica che così vi perdereste l’occasione di farmi delle domande imbarazzanti in diretta, o di fare delle domande serie a Matteo, Leonardo e Mattia che sono persone molto più competenti del sottoscritto.

Birba chi manca ;-)