Alessio Biancalana Grab The Blaster di Alessio Biancalana

Documentation first

Ancora un’altra frase iconica di Joey Hess, giuro che poi la smetto.

I write documentation first and code second.

Joey Hess e l'impegno come Debian Developer

Durante la piccola carrellata di post che ho attraversato scrivendo il piccolo (ed ennesimo) rant contro l’abuso delle riscritture delle history di progetto su Git tramite l’uso di git squash, ho letto qualche intervista in più a Joey Hess. In particolare mi ha attratto molto questa coppia di frasi:

I seem to have more time to spend in other online communities since I left Debian, but in a more diffuse way. Maybe that’s just what it’s like, to be involved in Free Software but not in the embrace of a big project like Debian.

Ho alzato le sopracciglia, principalmente per una ragione: l’affinità con il development sulla distribuzione di Joey ha attraversato le stesse fasi che ha attraversato la mia, suppongo. Avevo 50 pacchetti su AUR per Arch Linux, alcune mie cosette sono persino nei repository della distribuzione, eppure un giorno ho fatto “disown” di tutto, e ho lasciato il campo libero a chiunque volesse adottare la mole di roba che avevo da fare (che non era comunque troppa).

Da un momento all’altro ho sentito come di dover avanzare verso altro. Alla fine le community, i progetti open, io li vedo come luoghi dove una persona può passare grande parte del suo tempo, ma alla fine deve andar via verso una nuova avventura per affrontare un nuovo viaggio. La scelta di rimanere, che il luogo sia del codice o una distribuzione Linux, o qualsiasi altra cosa inerente l’open source, è una scelta forte; e ritengo che pensare di rimanere per sempre maintainer di un software, di un pacchetto, o di che altro, sia abbastanza degno di un Tacchino Induttivista.

Git squash, log riscritti, bazooka e mosche

Ieri sera, ho beccato sul feed reader un elemento che ha catturato immediatamente la mia attenzione; Matthew Garrett infatti ha esibito quanto fastidio possa dare l’impossibilità di comprendere il lavoro delle altre persone dovuta allo squash dei commit sulla history di un progetto Git, specialmente se tutto questo accade all’interno di un progetto open source:

I’ve got some familiarity with Kubernetes, but even then this commit is difficult for me to read. It doesn’t tell a story. I can’t see its growth. Looking at a single hunk of this diff doesn’t tell me whether it’s infrastructural or part of the integration. Given time I can (and have) figured it out, but it’s an unnecessary waste of effort that could have gone towards something else. For someone who’s less used to working on large projects, it’d be even worse. I’m paid to deal with this. For someone who isn’t, the probability that they’ll give up and do something else entirely is even greater.

Il punto che spesso mi piace sottolineare è messo a fuoco in modo spettacolare da Joey Hess, nel titolo stesso di “Our Beautiful Fake Histories”:

Beautiful fake histories. Because coding is actually messy; our actual edit history contains blind alleys and doublings back on itself; contains periods of many days the code isn’t building properly. We want to sweep that complexity away, hide it under the rug. This works well except when it doesn’t, when some detail airbrushed out of the only remaining history turns out to be important.

Ed è veramente così. Chiaramente c’è un sacco di Work In Progress di cui fare tanta pulizia alle volte, ma mi sembra che l’attenzione verso la history di un progetto sia portata alla luce da certi personaggi in maniera maniacale, come se fosse l’unica cosa di cui preoccuparsi, quando probabilmente l’unico vero paletto dovrebbe essere la qualità del codice. Il pattume nel log di git lo possiamo lasciare alle retrospettive, o comunque ad altri momenti del flusso di lavoro, che il progetto sia aperto o chiuso.

Onestamente, penso che chi passa il tempo a urlare contro le persone perché facciano rebase della propria history sia solo un incapace a cui piace mettersi in mostra senza mettere sul piatto nulla di tecnico se non paura e terrore instillato nei confronti di chi potrebbe contribuire in maniera più rilevante a un qualsiasi progetto. Alla fine, invece, quello che si ottiene è solo l’allontanamento di molti dal progetto stesso. Su un progetto open source smetteranno di contribuire. Su un progetto lavorativo, le persone troveranno (o inventeranno) altri task per allocarsi altrove.

Sulle persone che amano fare sceneggiate di questo tipo, Daniel Robbins ne dà un buon excursus durante “Costruire Una Distribuzione”. Cercate la parte sugli “strani”.

Gboard per Android potrebbe essere irrilevante

Ho già visto un paio di articoli leggermente caustici sul fatto che Google non abbia introdotto la sua Gboard su Android, ma abbia privilegiato prima iOS. In realtà, mi sembra una querelle abbastanza senza senso anche solo come pensiero, mica per altro ma perché ci sono un paio di ragioni fondamentali per cui ritengo il suo arrivo su Android poco rilevante.

La tastiera Google

Android ha la tastiera Google, che racchiude alcune tra le funzionalità più smart disponibili nel telefono, come la dettatura. Non è esattamente la stessa cosa, ma sicuramente Google potrebbe arrivare ad implementare le funzionalità di Gboard direttamente nella tastiera Android nativa, come confermano anche svariate fonti.

Io dal canto mio ho disabilitato parecchia roba, preferisco una tastiera che fa la tastiera, senza impicci.

Android stesso

Android è un sistema operativo pesantemente contaminato, come esperienza utente, da Google. Vuoi una funzionalità di ricerca spinta? Se non hai modificato troppo il comportamento del device che usi, probabilmente ce l’hai direttamente nella home screen.

La mossa di Google è interessante, perché le tastiere secondarie si sono rivelate un elemento affascinante per gli utenti iOS. Per gli utenti Android temo non sia lo stesso. In conclusione, quindi, le funzionalità di Gboard potrebbero non essere un gamechanger per Android alla stessa maniera di come lo sono per iOS.

WhatsApp per desktop (?)

WhatsApp Desktop App

Tra una cosa e l’altra ho visto che un paio di giorni fa è stata rilasciata una desktop app per WhatsApp; incuriosito sono andato a cercare dettagli e ad esaminarla – anche se purtroppo ho riscontrato esattamente le stesse criticità della versione web.

Dato che, ovviamente, questa WhatsApp “desktop app” non è nient’altro che un wrapper Electron che ripropone la versione web con un’icona dedicata. Il che significa che le performance non sono stellari (e non sto parlando del fatto che sia una web app in generale: le performance di WhatsApp Web sono abbastanza becere in confronto ad altre webapp come, beh, Webogram), e ovviamente tocca tenere il telefono acceso e collegato altrimenti non te ne fai niente.

E niente, via anche questa. Magari al prossimo giro WhatsApp potrebbe decidere di darci un attrezzo che funziona. Nel frattempo potreste considerare di passare a Telegram :-D

Tra l’altro, devo dire che sono rimasto sorpreso: mi sono fatto un giro su ChitChat, un progetto open source (per Mac) che fa grossomodo la stessa cosa, e c’è una stupenda comparativa nelle issue, molto utile visto anche che a livello estetico le due app sono identiche; eppure quella open sembra tenere botta eccellentemente.