Alessio Biancalana Grab The Blaster di Alessio Biancalana

Making Jack the dull boy

Headphone jack

Ho un mucchio di roba da scrivere, ma esattamente come Joey sono un procrastinatore seriale e piuttosto che parlare di questioni serie voglio virare verso il faceto. Parliamo quindi un po’ di Apple che vuole rimuovere il connettore jack audio (secondo rumor più o meno confermati) dal prossimo iPhone. A me sinceramente non è che interessi tantissimo, ma è innegabile che le scelte di Apple abbiano un impatto su come gli altri produttori costruiscono le proprie soluzioni.

Non ho letto molto sulla cosa: ho letto sostanzialmente poche fonti, di cui la più presente è stata Daring Fireball, su cui John Gruber riporta ripetutamente la sua opinione positiva riguardo questa scelta:

Ora, io sono particolarmente d’accordo con questo punto di vista:

Removing the iPhone headphone jack is a fine long-term goal. Complaining about the short-term annoyances is also fine. These are compatible.

Tuttavia penso che Apple la stia facendo un po’ fuori dal vaso. Mica per altro: è che secondo me la tray del CD rimossa dal Macbook Air non portò così tanto casino nell’ecosistema dei laptop; la rimozione del floppy drive nemmeno.

La rimozione di un alimentatore SafeMag a bordo dell’ultimo Macbook, viceversa, in favore di un unico slot USB-C a mio parere compromette l’usabilità del dispositivo, ponendo l’utente davanti a due scelte: o colleghi un dispositivo tramite USB, o carichi il portatile. Allo stesso modo, considerare l’attacco delle cuffie solo tramite Thunderbolt, di fatto mi sembra che vada nella stessa direzione.

Guardando con un po’ di visione di confluenza (grazie Ludovico per questo splendido termine che mi hai insegnato) gli eventi, probabilmente Apple sta tentando di convincere i suoi utenti – e il resto del mercato, come side effect – a collegare ogni cosa tramite Bluetooth.

Non è detto che sia un errore. È sicuramente una spinta un po’ coatta verso le tecnologie wireless. Dover cambiare le mie Piston per una coattata di Apple, viceversa, mi fa comunque rodere il, ehm, deretano.

Photo courtesy of Hernán Piñera

Epiphany vuole essere il nuovo Electron

GNOME Web

E così, anche GNOME si sta buttando nei runtime per desktop orientati alle tecnologie web. La cosa sinceramente mi lascia un po’ perplesso, ed è il sintomo di una mania che vedo sempre più dilagare nell’ecosistema Linux, in maniera però meno costruttiva del passato.

Si sta infatti affermando la prassi del risolvere un problema già risolto da qualcun altro nello stesso modo in cui l’altro l’ha risolto, semplicemente “because reasons”, senza un motivo apparente. È così, che, per esempio, come riportato da Joey Sneddon per GNOME Web:

The hope is that by widening access to Web’s web-app features it can attract developers who might otherwise build and package their apps using the Chromium-based Electron.

Stiamo parlando, per chi non lo conoscesse, di Electron, ossia la precedentemente detta Atom Shell: un framework per infilare un’applicazione web in un “corpo” da applicazione desktop. Per alcune cose funziona, per esempio Atom lo utilizza, e sicuramente consente di sviluppare in fretta un MVP che possa andare in produzione alla velocità della luce, i cui bug possono essere aggiustati in un secondo momento con una riscrittura, o con qualche bestemmia.

Ma questa speranza (quella di un altro Electron), c’è veramente? Perché dovremmo usare Epiphany al posto di Electron come container? Perché non cercare di spingere oltre il limite invece di limitarsi a raggiungerlo a malapena?

E questo, per essere totalmente chiari, vale per il motore di Epiphany, ma vale anche per tante tecnologie di Canonical come il vecchio Upstart – o il nuovo Ubuntu Snap in competizione con Flatpak (non voglio discutere su quale dei due sia meglio: ma uno prima o poi soccomberà e sarà stato solo lavoro buttato).

Twitter acquisisce Magic Pony

Twitter parla così della sua acquisizione di Magic Pony, compagnia con un focus particolare sul machine learning:

Magic Pony’s technology – based on research by the team to create algorithms that can understand the features of imagery – will be used to enhance our strength in live and video and opens up a whole lot of exciting creative possibilities for Twitter. The team includes 11 PhDs with expertise across computer vision, machine learning, high-performance computing, and computational neuroscience, who are alumni of some of the top labs in the world.

Qualche giorno fa, in un impeto di rimbecillimento posprandiale ho scritto due righe su Snapchat sul mio tumblog, puntando un po’ il dito verso il fatto che usiamo tecnologie come quelle di face recognition per farci le foto con la faccia a forma di panda.

Questa acquisizione va nella stessa direzione: un team che comprende già 11 PhD, messo a lavorare a un mucchio di codice per far fare dei video a Justin Bieber, o a Obama, o a mia sorella.

Fà strano, no?

Go static – ovvero il vademecum di GitLab sugli static site generator

I ragazzuoli di GitLab hanno cominciato a fare una serie di tutorial veramente ben fatti sui siti web statici, essenzialmente per promuovere il loro GitLab Pages, servizio in concorrenza con il molto più celebre GitHub Pages, ma decisamente più flessibile dato che offre la possibilità di fare hosting di siti statici non solo basati su Jekyll, ma su molti più generatori scritti in (praticamente) qualsiasi linguaggio.

Nonostante questo, chiaramente a parte i rimandi al loro servizio di Pages, il loro drilldown è una lettura molto neutrale e piacevole.

Go Debian

Il mitico Paul Tagliamonte ha scritto una serie di tool in Go per interfacciarsi con l’ecosistema Debian. Dell’esperienza che ne ha ricavato, globalmente, possiamo fare tesoro, specie riguardo “cool stuff” e caveat del linguaggio stesso:

Some of the things Go is great at: Writing a server. Deaing with asynchronous communication. Backend and front-end in the same binary. Fast and memory safe. […] Things Go is bad at: Having to rebuild everything for a CVE. Having if err != nil everywhere. “Better than C” being the excuse for bad semantics. No generics, cgo (enough said)

E così discorrendo. Assolutamente da leggere per fare tesoro di tutto, soprattutto nel mio caso, ossia quello di un junior gopher affamato di conoscenza.