Alessio Biancalana Grab The Blaster di Alessio Biancalana

L'origine del window switcher

In questi giorni mi sono concesso un po’ di completo relax, e nel relax ho cominciato a smaltire un po’ di arretrati di Pocket, arrivando alla review dell’iPhone X su Daring Fireball. No, non ho comprato un iPhone X, no, non lo farò, ma trovo il modo di scrivere di John veramente scorrevole e stimolante; la chicca che ho trovato a poca distanza dall’inizio è lo Switcher, di cui non sapevo assolutamente nulla.

“Excuse me,” he told us, as he pressed a key combination on his keyboard, his monitor screen instantly changing to a different program. He talked on the phone for a minute or two, occasionally typing, before he finished the conversation and pressed a key combination to switch back to his Thunderscan notes.

Oggi, nel 2018, con un colpo di Alt-Tab possiamo passare in un secondo dal browser alla suite ufficio, dal terminale all’editor di testo. Possiamo cominciare a scrivere alla nostra fiamma in mezzo secondo. Possiamo far finta di lavorare mentre guardiamo Facebook1.

Andy Hertzfeld ha scritto il primo window switcher per Mac, in un’epoca in cui scrivere questo tipo di applicazioni era veramente, veramente difficile. Personalmente sono molto affezionato al mio Alt-Tab sin dai primi anni con Linux, e leggere la storia di come è stata concepita questa funzionalità devo dire che è stato emozionante.

A conti fatti, per parecchi nerd come me, Hertzfeld è responsabile di una parte del computing desktop come lo conosciamo oggi. Switcher è stato integrato successivamente in MacOS Classic, continuando ad evolvere fino ad OS X con l’implementazione “attuale”. Nel frattempo anche Windows e Linux hanno implementato i loro window switcher: tutto per via di questa storia, che trovo straordinariamente affascinante.

  1. Se un mio datore di lavoro presente, passato o futuro dovesse inciampare in questo post, ci tengo a specificare che è solo un esempio dei molti possibili. 

Elixir per idioti /2, tipi e operazioni sui tipi

Visto che abbiamo imparato come configurare Elixir sulla nostra macchina, un po’ di esperimenti e un approccio di base.

I tipi sono interi, numeri (in virgola mobile), booleani, atomi1, e stringhe.

Possiamo giochicchiarci in iex:

iex(1)> 1 + 2
3
iex(2)> "hello" <> "world"
"helloworld"
iex(3)> false || true
true
iex(4)> !true
false
iex(5)> !false
true
iex(6)> true == true
true
iex(7)> 2 == 2
true
iex(8)> 2 == "2"
false
iex(9)> 2 == 2.0
true
iex(10)> 2 === 2.0
false

Cose che possiamo notare sin da subito: le operazioni con tipi discordanti non funzionano, al contrario per esempio di JavaScript dove possiamo sommare stringhe e numeri indistintamente ottenendo una concatenazione (per esempio, grazie al casting implicito “molto libertino”); oltre questo, la comparazione con l’operatore == è debolmente tipizzata, ma i tipi compatibili tra loro sono molti meno. 2 è diverso da "2" ma è uguale a 2.0, che è in virgola mobile.

L’uguaglianza con il numero in virgola mobile viene falsificata da una comparazione “strict”, ovvero con triplo uguale, che fa anche un check del tipo.

I tipi li considero sempre la parte noiosa, ma vanno studiati; tra le cose divertenti invece abbiamo l’interpolazione di stringhe, che è abbastanza utile:

iex(15)> lang = "Elixir"
"Elixir"
iex(16)> "I'm studying #{lang}"
"I'm studying Elixir"

Stiamo carburando? Stiamo carburando! Mancano ancora un po’ di basi, tra cui le strutture dati fondamentali per non scrivere cose nonsense. Le vedremo in seguito.

Vai alla parte 1

Vai alla parte 3

  1. Gli atomi sono una figata, chi conosce la programmazione funzionale penso li conosca bene. Per chi non la conosce, sono delle stringhe “on steroids”; ne parleremo più avanti in ogni caso. 

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

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.

Member of

Previous Random Next