Alessio Biancalana Grab The Blaster di Alessio Biancalana

Cauldron devlog, settimana #10

La settimana scorsa ho saltato il devlog di Cauldron perché ho fatto un casino con l’organizzazione dei tempi anche dato il fermento per un po’ di bisboccia imminente coi colleghi.

Cauldron alla sua undicesima settimana

Innanzi tutto c’è da dire che cogliendo l’occasione di un paio di viaggi in treno belli pesanti mi sono deciso a iniziare il processo per far avere a Cauldron un’icona, richiedendola al design team di GNOME, i quali ragazzi sono stati gentilissimi: Jakub Steiner ha persino condiviso dei primi bozzetti che sono assolutamente adorabili. Oltre questo mi sono concentrato nel mettere a punto un README che non facesse schifo e che linkasse al contempo al resto dell’ecosistema di GNOME.

Questa settimana invece mi sono dedicato a cose più fattuali e “code-wise” visto che avevo a disposizione un paio di macchine serie (purtroppo il mio amatissimo laptop ha i suoi limiti quando si tratta di questo genere di cose). Innanzi tutto ho finalmente implementato una logica di download più robusta per cui vengono scaricati tutti gli articoli salvati dall’utente, mentre prima me ne perdevo parecchi per strada semplicemente perché non mi andava di stare a litigare con la paginazione.

Mi ci è voluto un po’ ma l’adorabilissimo serde ha fatto il suo.

Su un versante più relativo all’eye-candy, invece, ho fatto in modo che quando vengono caricati gli articoli venga visualizzato un bellissimo spinner al posto del bottone di refresh. All’inizio avevo usato un normalissimo spinner GTK, dopodiché il tutto è diventato un po’ la tana del bianconiglio.

Mi sono accorto infatti che libadwaita espone un suo Spinner, che ovviamente è costruito sullo spinner di GTK ma è molto più facile da impostare (leggasi: ha una API umana). Ha anche un look un po’ più moderno. Purtroppo però è disponibile solo in libadwaita 1.6, che a sua volta è scritta per GNOME 47. Ho quindi colto l’occasione per portare l’applicazione a GNOME 47, principalmente aggiornanto le feature del crate di Relm4 e finalizzando gli smanettamenti che avevo già iniziato sul manifest Flatpak di sviluppo.

Insieme allo spinner ho anche portato la mia prima icona custom, per l’azione di archiving, all’interno dell’app: ho avuto qualche problema a farla andare correttamente con la dark mode, ma una volta data una letta al manuale ho capito il sistema di specchi e leve che usa GNOME per fare il fill in automatico delle icone a seconda che si usi la dark mode o no, e ho risolto.

L’aspetto che ancora non riesco a inquadrare e sul quale ho persino da ridire è il testing. Non sono ancora riuscito a scrivere dei test decenti, e penso che dopo qualche refactor mi sarà più facile. Vorrei testare anche la UI oltre che la logica di business, ma ho capito che con GTK è un bagno di sangue.

masto.cazzo.lol

Oltre a esortare Marco a continuare il suo post sul perché è diventato manager, complice il mio periodo di crisi mistica sul mio futuro lavorativo1, gli sono immensamente grato. Innanzi tutto perché come spiegavo oggi a un altro amico, mi reputo estremamente fortunato ad averlo nella lista di persone a cui posso rompere i coglioni.

Ma, oltre questo, perché è uno che alla fine ha un po’ la mia stessa testa quando si parla di approccio alle cose. Parlavamo da settimane e giravamo intorno al fatto che ci sarebbe piaciuto sperimentare col fediverso e con un’istanza più piccola, dedicata a pochi amici, solo su invito.

Alla fine dopo diecimila pippe mentali e dibattiti fantasmagorici siamo andati a sbattere su Mastodon come software e lui ha aperto mettendoci soldi e voglia masto.cazzo.lol, il cui nome mi ha subito fatto innamorare. Ho contestualmente scoperto che mentre per lui la cosa era piú un esperimento, io stavo già gettando il cuore oltre l’ostacolo alla faccia dell’osservazione non partecipante migrando tutto il mio profilo da livellosegreto.it2 alla nuova istanza.

  1. nel senso che ultimamente è una cosa a cui penso spesso. Forse ne dovrei scrivere approfonditamente, ma il succo è: se pensi di poter avere un buon impatto su chi ti sta intorno e pensi che il tuo traguardo sopra ogni cosa sia far stare bene chi lavora con te, dovresti dunque considerare il management? 

  2. ragazzi, sono stati anni bellissimi. Grazie di aver dato una casa al mio “self” italiano sul fediverso. Vi voglio bene. 

Il ruolo delle distribuzioni Linux nel 2024

Questo weekend sono stato a un matrimonio. Nonostante la bellezza stupenda della genuinità di un gruppo di amici che si riunisce per far festa1, una cosa in particolare che mi ha colpito è stato parlare con un altro invitato, anche lui addentro al mondo dell’informatica quanto me: parlando del mio lavoro, della distribuzione Linux su cui ogni tanto metto le mani, ovviamente è scappato il “ah, ma è ancora sviluppata?” di rito.

Questo ancora una volta mi ha portato a chiedermi se abbia senso il concetto di distribuzione Linux, che infatti sta morendo per come era inteso negli anni passati. Ad oggi quello che viene comunemente inteso come distribuzione Linux ha molti meno livelli rispetto a prima:

  • Il primo livello di configurazioni di base, rappresentato dalla gerarchia del filesystem, dagli strumenti preinstallati e dalle location predefinite in cui il package manager installa i pacchetti di base;
  • Da systemd in su è praticamente tutto standardizzato, e le personalizzazioni sono minime;
  • Lo userspace è dominato praticamente in toto, nei sistemi operativi immutabili per esempio, da sistemi di distribuzione come Flatpak o Docker, dove la distribuzione Linux in sé non interviene più nel “distribuire” appunto i programmi utilizzati dall’utente, tantomeno nel personalizzarli con temi o impostazioni diverse da quelle predefinite dai team di sviluppo.

Ne consegue che ormai il ruolo di una distribuzione Linux è quanto più a basso livello possibile: diminuendo le differenze nello userspace e standardizzando i meccanismi di distribuzione delle applicazioni tratti come il supporto alla Full Disk Encryption, la presenza o meno di un determinato modulo del kernel, l’inclusione di programmi per consentire l’osservabilità del sistema (come una suite di programmi eBPF), risultano tutti fattori differenzianti per le distribuzioni Linux.

Distribuzioni che a questo punto possono permettersi di smettere di dedicare forza lavoro al patching delle applicazioni, per preoccuparsi di quello che dovrebbero in realtà fare al meglio: consentire il funzionamento del sistema operativo come un orologio, senza errori.

Il che, personalmente, è la cosa che mi appassiona e interessa di più.

  1. Perché di questo si è trattato, più che di un vero e proprio banchetto nuziale, nonostante l’ottimo catering. A tratti una cerimonia, a tratti un piccolissimo rave party. Ancora i miei migliori auguri a Marco e Guan Xing. 

Cauldron dev log, settimana #8

Da metà Luglio più o meno sto scrivendo un client Pocket per Linux che ho iniziato per un paio di motivi principali:

  • Mi serviva, essendo io un utente del servizio, e mi dava enormemente fastidio che l’unico client decente fosse quello ufficiale per macOS;
  • Non avevo mai sviluppato un’applicazione con la GUI che non fosse una webapp, e mi sembrava il momento storico adatto per cimentarmi con questa sfida.

Avendo maturato una precisa consapevolezza di quale è lo stato dell’arte sullo sviluppo in Rust e GTK, e dovendo il talk che farò a openSUSE Asia poggiare su un esempio reale, mi ci sto dedicando da più di due mesi settimanalmente.

Oggi sono riuscito a implementare la dark mode senza particolari barbatrucchi:

Cauldron dark mode :-)

In realtà la cosa peggiore finora, oltre far visualizzare la webview per renderizzare il contenuto degli articoli, è stata riuscire a iniettare del CSS dentro la webview stessa. L’approccio che ho scelto è subottimale ma funzionale: scorrendo le callback messe a disposizione dalla struttura dati della webview ho visto che c’era una connect_resource_load_started, che viene eseguita a ogni carimento (appunto) di una risorsa remota. In questo modo avendo accesso all’istanza della webview da un punto strategico è possibile innestare nel meccanismo “reattivo” di Relm4, che ho scelto come libreria che orchestra gli update all’interfaccia, del codice che provvede a impostare nel content manager della vista stessa il foglio di stile necessario per il rendering corretto.

Questo era necessario prima di tutto perché altrimenti detto senza mezzi termini la UI faceva schifo, pena e pietà; ho però rubato un paio di trucchetti dal codice di NewsFlash in merito e ho scoperto che reagendo a un paio di classi CSS apposite è possibile anche supportare la dark mode di GNOME senza nessuno sforzo.

A parte quello di scrivere quelle due righe di CSS in più, chiaramente.

Oltre questo ho implementato un paio di cose stupide ma che fanno sembrare l’applicazione un po’ più vera e meno un giocattolo:

  • La UI adesso reagisce in maniera appropriata quando un articolo viene archiviato, togliendolo dalla lista degli articoli disponibili e tornando allo stato iniziale;
  • C’è una piccola call to action che fa da empty state quando nessun articolo è selezionato. Pensavo fosse una scemenza, invece mi piace un sacco il feeling :)

Cauldron "empty state"

Sto togliendo piano piano tutta la rumenta grossa a livello di codice che ci può essere a livello di debito e di UX. Non sono ancora soddisfatto del testing, ma ci sono due cose che mi preme fare prima di subito:

  • La submission su FlatHub
  • Scrivere un README decente, con screenshot e quel poco di documentazione che fa la differenza tra un progetto amatoriale e uno, invece, serio.

Oltre questo, vorrei chiedere gentilmente un logo al design team di GNOME perché le mie abilità con Inkscape sono al livello di una scimmia ubriaca.

Terrò un talk durante openSUSE Asia 2024!

Se dovessi dire quale è l’emozione che ha prevalso di più in queste ultime settimane della mia vita, non ci riuscirei. Sono successe tante cose sia sul versante professionale che personale, ma in particolare di una cosa sono ultra felice: il talk che ho proposto qualche tempo fa per openSUSE Asia 2024 è stato accettato.

Il che significa che quest’anno, dopo essere stato in Giappone per ben tre settimane, mi godrò un’altra bella fetta di tempo a Tokyo per partecipare a openSUSE Asia, che quest’anno si tiene ad Azabudai Hills, con un talk sullo sviluppo di applicazioni per il desktop Linux in Rust con GTK, in particolare con alcune librerie che permettono di scrivere codice dichiarativo semplificando un po’ il flusso di lavoro, come Relm4.

Ho solo venti minuti per parlare di tutto questo quindi dovrò andare veloce e non mi potrò permettere particolari excursus, ma in particolare un aspetto su cui mi vorrei concentrare sarà una comparazione tra l’esperienza che ho sempre avuto sviluppando con tecnologie web e l’esperienza che sto invece avendo con lo sviluppo di un client per Pocket. Ci sono sicuramente tantissime differenze, come i tempi di build, le tecniche di distribuzione, e il fatto di avere UI e logica di business “impacchettati insieme”, ma anche tantissimi punti in comune, specie se si compara una tecnologia come React a una come Relm4, che ne è comunque figlia nell’approccio.

Ne racconterò sicuramente di più dopo la conferenza, per ora il mio pubblico giapponese (!!!) ha la priorità.

Cenni su openSUSE Asia

Già da qualche anno dei colleghi mi avevano incentivato a partecipare a openSUSE Asia, ma non l’avevo mai fatto perché non pensavo di essere abbastanza qualificato. Nell’ultimo anno la situazione è cambiata perché ho cominciato a dare una mano sulla distro, mantenendo il pacchetto di Elixir, portando alcuni pacchetti che erano assenti e soprattutto facendomi una cultura sul funzionamento del progetto attraverso le varie mailing list.

OpenSUSE Asia è un luogo di incontro fisico in Asia appunto per permettere lo scambio di idee di persona dove gli sviluppatori occidentali sono fortemente incoraggiati a partecipare, proprio per non far sentire le persone asiatiche in una sorta di silos, fenomeno che a volte accade in svariati progetti per via del fuso orario. Siccome l’idea mi intrigava, ovviamente mi sono subito messo a scartabellare e approfondire.

Dal blog ufficiale di openSUSE:

The openSUSE Project is excited to announce that openSUSE.Asia Summit 2024 will be held in Tokyo, Japan. The openSUSE.Asia Summit is an annual conference for users and contributors of openSUSE and FLOSS enthusiasts. The former summits received major participation from Indonesia, China, Taiwan, Japan, South Korea, and India.

Since the first openSUSE.Asia Summit was held in Beijing in 2014, the summits have been great opportunities for the online community to gather in person, know each other, and share knowledge and experiences about openSUSE including applications running on it. However, COVID-19 made it difficult for 3 years. One of our goals of this year’s summit is to provide a place for communication. Please note that we will not accept talks by video call this year.

Che altro dire… non vedo l’ora di essere sull’aereo. Ci si vede a Tokyo! :-D

Member of

Previous Random Next