Alessio Biancalana Grab The Blaster di Alessio Biancalana

GNOME Shell con GPU Intel, configurazione (circa) finale

GNOME Shell Tearing-free

E insomma, dopo tanto smanettare forse credo di aver trovato una quadra su quella che dovrebbe essere la mia configurazione ottimale per quanto concerne GNOME Shell e la poverissima GPU Intel a cui mi diverto a dare il tormento tenendo spenta la scheda grafica discreta (che non mi serve praticamente a niente su Linux, se non a trasformare questa macchina in una fornace da calcolo).

In poche parole, modificando /etc/environment lo facciamo diventare come segue:

#
# This file is parsed by pam_env module
#
# Syntax: simple "KEY=VAL" pairs on separate lines
#

CLUTTER_VBLANK=True

Dopodiché configuriamo il driver video in questo modo, modificando il file /etc/X11/xorg.conf.d/20-intel.conf:

Section "Device"
	Identifier  "Intel Graphics"
	Driver      "intel"
	Option      "TearFree"    "true"
	Option      "SwapbuffersWait" "true"
	Option      "AccelMethod" "sna"
EndSection

In parte questo mistero l’avevamo già eviscerato in passato, riuscendo a migliorare la situazione ma non a debellare la problematica. Quello che questa configurazione fa è forzare uno specifico metodo di accelerazione grafica (che è quello di default, e dovrebbe essere quello di ultima generazione - sia mai che non andasse da solo), impostando poi sia TearFree che SwapbuffersWait.

Insieme a questo anche uno specifico tweak di Clutter fa sì che le performance siano migliori nel complesso, a costo di usare qualche ciclo di calcolo in più. Mi pare che questa configurazione performi molto meglio sulla mia macchina, ne sono veramente soddisfatto.

Questa configurazione va molto, molto bene anche con Wayland.

Forse c’è ancora qualcosa che si può fare. I’ll keep you posted.

Trappole più comuni in Elixir

Recentemente mi sono appassionato molto ad Elixir, linguaggio funzionale che fa uso della Erlang VM per definire una piattaforma veramente versatile orientata ai processi isolati comunicanti via messaggi.

In particolare questo post che ho letto di recente su Blackode mette in luce alcuni aspetti particolari del linguaggio con i quali chi non ha confidenza rischia di fare assunzioni un po’ troppo coraggiose.

Un ottimo esempio:

We think that the result of list ++ value would be [1,2,3,4,5,99] but in general it will be [1,2,3,4,5|99]. This is a improper list. You cannot use length function over. In proper list, when you iterate over the list, the tail would be [] empty list. This is different with the improper list.

Ubuntu, il ritorno a GNOME, e al diavolo la convergenza

Ubuntu Unity with Arc Teme

Ti gratti la testa pensando che magari non hai letto bene i titoli dei feed una settimana fa, poi sgrani gli occhi, capisci che diamine accade, ti fai una risata, fai sedimentare, decidi di scrivere, ti interrompono, cancelli tutto, il lavoro entra a gamba tesa minando definitivamente la tua produttività di infimo scrittore.

È così che dopo una settimana sei ancora lì a cercare le parole per commentare un evento del genere: Ubuntu abbandona Unity, e passa a GNOME. Dopo anni di scatole rotte con la convergenza, con questo e con quest’altro, e dopo aver creato un brand niente male con la propria fichissima (secondo alcuni) interfaccia grafica, tutto alle ortiche perché giustamente chi se ne frega della convergenza ora che l’ultima moda è l’IoT che appizza le informazioni nel cloud, il quale sicuramente è un business che per Linux funziona meglio.

We will shift our default Ubuntu desktop back to GNOME for Ubuntu 18.04 LTS.

Ma è davvero così?

Incertezze

Non si è capito poi molto di che cosa abbia intenzione di fare Canonical per Ubuntu 18.04 LTS, se non (per il momento) degli straordinari proclami su Unity e GNOME: quello che viene detto, è che in realtà “continueremo a sviluppare il miglior desktop di sempre”, ma non si capisce se questo sia riferibile a Unity 7 o all’esperienza desktop globale, integrando GNOME alla perfezione e applicando delle patch qua e là per far sentire gli utenti meno spaesati.

We will continue to produce the most usable open source desktop in the world, to maintain the existing LTS releases, to work with our commercial partners to distribute that desktop, to support our corporate customers who rely on it, and to delight the millions of IoT and cloud developers who innovate on top of it.

Più di tutte le frasi sul futuro, questa ha attirato la mia attenzione in modo abbastanza coatto, lasciandomi incerto: è così vero che vengono abbandonati tutti i progetti relativi a Unity? L’alternativa è che Unity rimanga solamente come shell grafica, delegando tutto il comportamento sottostante a GNOME, che verrà reintegrato nel sistema operativo in maniera più pesante rispetto a come è già stato fatto sinora.

In ancora un altro scenario, è possibile che Canonical lasci perdere Unity 8, e si concentri su Unity come shell grafica puramente detta, cotninuando quel filone di sviluppo, integrando gli stessi pezzi di GNOME che integra adesso; in questo contesto avrebbe comunque senso “we will shift our default Ubuntu desktop”, dato che significherebbe solo “signori, abbiamo cambiato idea per la prossima release, e grazie per tutto il pesce”.

Ubuntu GNOME

Oppure ancora, come molti hanno già scritto, ed è importante notare che non sono stati smentiti da nessuno (anzi, Mark Shuttleworth stesso domenica ha avallato questa ipotesi), Ubuntu passerà veramente a GNOME. Questo mi farebbe veramente molto piacere, perché la distribuzione Linux di Shuttleworth rientrerebbe nel “mainstream” delle distribuzioni Linux normali – per così dire – abbandonando lo sviluppo di un fattore realmente distintivo, concentrandosi sulle cose che non funzionano e migliorandole. Non solo per Ubuntu, ma per Linux in sé, marchio dal quale Ubuntu (al contrario di Android, possiamo dirlo) non è mai stata capace di affrancarsi del tutto. Ed è meglio così.

Coopetition

In quest’ottica forse si potrà ricominciare a vedere Ubuntu come un contributor attivo della comunità e dell’upstream Linux principale. Questo upstream ad ora comprende un numero indefinito di “cose” tra cui le principali, Linux/Xorg/Wayland/KDE/GNOME – e basta. Mir, ad esempio, non ha mai visto vera luce e non ha mai cercato di ritagliarsi uno spazio in questo ecosistema, preferendo stare al margine. Data anche l’ingerenza di Red Hat, sicuramente queste sono scelte che non pagano, mentre è molto più virtuoso cercare di contribuire all’ecosistema Wayland con il proprio compositor, con i propri bugfix, in definitiva con il proprio codice.

Per gli anni a venire, mi auguro di rivedere Ubuntu in prima fila per Linux su desktop, esattamente come gli anni passati, ma senza schierarsi a parte con un brand diverso dicendo “noi siamo più fighi”, perché tanto Linux non credo che abbia bisogno di questo. Non ne ha bisogno e non ne avrà mai bisogno perché non è così che l’ecosistema è stato generato, e non è decisamente così che il segmento microscopico mondiale di utenza Linux vede ciò che è necessario.

Piuttosto, a me non fanno impazzire le performance delle animazioni di Mutter, il window manager di GNOME Shell. Magari Canonical potrebbe contribuire con delle patch.

P.S.: Marco Usai mi ha mandato uno splendido audio col suo virilissimo accento sardo per spingermi a pubblicare questo post. Purtroppo nella prima stesura ho dimenticato di menzionarlo.

Pics courtesy of OMG! Ubuntu and Arc Theme’s GitHub

Codemotion Rome 2017 – inseguire elefanti 🐘 fino alla luna 🌝

Codemotion Rome 2017 - To the Moon

Come al solito volevo scrivere prima questo post, ma in questo periodo sembro avere un backlog abbastanza scombinato (e i capelli un po’ dritti). Questa scombinatezza di piani però non mi ha distolto dall’andare lo scorso weekend al Codemotion, e farmi avvolgere dall’amicizia di tante persone che non vedevo da tantissimo tempo, dal calore di chi vedo spesso a Roma, ma soprattutto dalla preparazione degli speaker di cui quest’anno mi sono goduto i talk.

Non so se è per qualche ragione particolare, ma quest’anno per me è stato il Codemotion più bello di tutti. Forse ho sentito di più la mia missione di “portatore di novità” in quanto a bagaglio culturale aziendale, forse effettivamente gli speaker di quest’anno avevano qualcosa in più (vero Luca? Vero Matteo?), o forse semplicemente sotto alcuni punti di vista ero più rilassato tanto da riuscire a godermi meglio l’evento, ma nessun Codemotion mai fatto supera per me quello di quest’anno.

Codemotion è anche vedere cirpo incantato in questo modo

Che cosa ho seguito

Molto del valore che ha avuto per me la conferenza quest’anno sicuramente lo devo agli speech che ho scelto di seguire, e con un pizzico di fortuna (può capitare il talk leggermente fiacco) ho piazzato tutte le mie scommesse sui cavalli giusti, nonché ovviamente su persone che mi hanno fatto portare a casa un bagaglio clamoroso di conoscenze e sentimenti.

Nello specifico, e in rigoroso ordine cronologico:

  • Giorgio Natili - Unethical JavaScript: La voce sexy di Giorgio mista al suo accento “peggiore di Mario” (parole sue) di solito è sinonimo di qualità. Anche questa volta non mi ha deluso, parlando di best practice miste a un po’ di ultimo grido per scrivere codice leggibile facendo un po’ meno gli hipster e un po’ di più i ragazzi gentili nei confronti dei colleghi che dovranno mantenere le nostre applicazioni. Messaggio principale: “Scrivi sempre il codice come se il prossimo maintainer fosse un pazzo psicopatico che sa dove vivi”.
  • Luca Lanziani - Introduzione a NodeJS: Durante il meetup preserale della meravigliosa community di RomaJS (di cui qui alcuni esempi di figaggine) Luca ha presentato le basi per scrivere Javascript sul server senza paura e con un minimo di cognizione di causa. La cosa interessante è che era stata preventivata un’introduzione un pelo più profonda (e interattiva), cosa andata improvvisamente a monte visti due fattori: l’aula pienissima di persone, e il fatto che in pochi in realtà si erano già confrontati con NodeJS anche solo in maniera embrionale. Rispolverare le basi è sempre interessante, bisognerebbe farlo periodicamente con ogni tecnologia o framework, e date queste premesse anche i più senior hanno potuto (imho) portare comunque a casa un valore aggiunto.
  • Russ Olsen - To The Moon: Troppo inspirational anche per una track inspirational. Russ Olsen ha descritto il percorso dalla terra alla luna, le decisioni strategiche che hanno condotto a questo traguardo, gli ostacoli, e le storie di uomini che hanno gettato il cuore oltre quegli ostacoli. Ho pianto come un vitello, e ho anche riscoperto il motivo per cui faccio quello che faccio, ogni giorno.
  • Luciano Mammino - Universal Javascript Web Applications with React: Non avevo mai visto uno speech di Luciano, è molto bravo e ha introdotto un concetto interessante, demistificando il concetto di Universal Javascript (ossia il codice che può essere eseguito in maniera indiscriminata lato server e lato browser), mostrando come attraverso una serie di best practice e facendo riferimento a determinate librerie si possa raggiungere questo risultato con poco sforzo.
  • Ronnie Chen - Staying Alive: Patterns for Failure Management From the Bottom of the Ocean: Rimanendo nella stessa aula, ho avuto il piacere di seguire Ronnie Chen, Data Engineer di Slack che ha parlato di pattern per la gestione del fallimento, facendo riferimento a uno degli oggetti più pericolosi per chi fa il sub, ovvero il rebreather. Prendendo spunto dalle procedure di emergenza in caso di malfunzionamento dei rebreather, e dalle best practice (come le checklist pre-immersione) per verificare in maniera preventiva l’operatività di questi, Ronnie ha illustrato come portare questi pattern all’interno di una tech company. Il paragone tra un server sotto botta e un rebreather che ama far scherzi è stato particolarmente efficace.
  • Nicola Iarocci - RESTful Services Made Easy: The Eve REST API Framework: Il talk di Nicola è stato un hands-on interessante su un framework che ha sviluppato lui per servizi web REST in Python. A parte l’apprezzatissima scelta tecnica di basarsi su Flask per gestire le richieste agli endpoint, mi è risultata veramente efficace la strategia di far gestire praticamente qualsiasi cosa a livello di configurazione, dando la possibilità al programmatore di inserirsi nel ciclo di vita della API solo quando ne ha realmente bisogno. In questo modo secondo me il time to market si abbassa di un casino di tempo.
  • Matteo Manchi - React Native for multi-platform mobile applications: Non avevo mai approcciato le applicazioni Android o iOS, se non per qualche ora totale della mia vita. React Native sembra un buon approccio allo sviluppo mobile per massimizzare la condivisione del codice su più piattaforme, e riuscire comunque a non perderci in performance renderizzando in ogni caso componenti grafici nativi. Matteo poi, come speaker, è veramente bestiale, tiene l’attenzione del pubblico e qualsiasi concetto lo esprime in maniera molto chiara, senza fronzoli, e sempre con qualche battutina che alleggerisce il clima. Come ultimo speech è stato veramente una boccata d’aria fresca, e non ho avvertito minimamente la pesantezza di tutta la conferenza sulle spalle. Plus: appena uscito volevo andare a scrivere JS per mobile. 😂
  • Alberto Brandolini - Chasing Elephants: Alberto è stato un keynoter veramente tosto. Il suo talk è stato controverso, perché da un lato ha celebrato ancora una volta il “perché lo facciamo”, dall’altro mi ha fatto venire un po’ di depressione specialmente con le sue frasi riguardo il fatto che nessuna azienda italiana ha mai visto un senior developer in faccia. Sono tendenzialmente d’accordo, e questo mi intristisce molto. Anche qui un bagaglio molto interessante da portare a casa: “good developers go where good developers are; good developers are compulsive learners”.

Alberto Brandolini - Chasing Elephants at Codemotion 2017

Il pelo nell’uovo

“Ma ha anche dei difetti” è un meme che mi fa sempre ridere. E anche questo Codemotion, come quelli passati, e come la Panda 4x4, ha anche i suoi difetti. Difetti minimi, per carità, ma vale la pena andare a trovare il pelo nell’uovo per evitare lo status quo, no? 😇

In realtà come miglioramento marginale quello che ho potuto vedere è che molto della conferenza era spostato sul lato architetturale dello sviluppo di un’applicazione, o sul frontend. Una cosa a cui mi piacerebbe assistere sarebbe una maggior diversificazione tra le piattaforme utilizzate, mentre il feeling di quello che propone la comunità (che mi rendo conto che non sia esattamente controllabile da Codemotion) è sempre un po’ “Javascript, Java - e poi ci sono i soliti ignoti tipo Golang e Elixir”.

Mi rendo conto che sia meno appetibile, e che vada contro i miei stessi interessi, ma a me piacerebbe vedere anche altri tipi di informatici come gli esperti di networking confrontarsi a Codemotion, eventualmente a scapito di Javascript che quest’anno ha avuto una track dedicata.

D’altra parte mi fa piacere che una tecnologia che mi piace tanto come questa abbia una track tutta sua e un percorso privilegiato… forse un po’ troppo? Dopo questa critica, in ogni caso, sono sicuro che Guido mi verrà a prendere per un orecchio in ufficio 😂

Ending theme

Siamo arrivati in fondo. Spero che Codemotion continui così, è una grande conferenza con i suoi punti di forza e le sue contraddizioni. Mi fa piacere che in molti continuino a frequentarla, e che ormai sia il punto di riferimento in Italia. Al di là dell’aspetto tecnico, è anche un modo per incontrare tantissimi amici che altrimenti non vedrei mai, e un momento per dire “ok, stacco gli occhi dal monitor”.

Al prossimo Codemotion 😎

Images courtesy of Codemotion. Thanks guys!

ChatOps, Botstation, e un momento di relax con RomaJS

Nell’ultimo mese ho avuto a che fare con un po’ di grattacapi interessanti; in particolare, con il mio nuovo team ci siamo trovati nella condizione antipatica di dover svolgere alcuni task ripetitivi senza che tutti conoscessero esattamente le operazioni da svolgere e i comandi da dare in pasto alle macchine.

Per questo motivo ho deciso di introdurre un po’ di pratiche ChatOps (qui qualche informazione in più), in modo da avere un bot a disposizione che mi consentisse di dedicarmi alle cose importanti, senza essere infastidito dal “come si fa”, da una miriade di cose ripetitive, e così via. Il primo passo è stato studiare un po’ la piattaforma di Slack (che usiamo in UniquID) e capire cosa potevo fare grazie alla libreria slackbots per NodeJS; il passo induttivo, invece, è stato dare forma a un piccolo minion che prendesse i comandi dal team e li trasformasse in azioni reali.

Alessio Biancalana at RomaJS, ChatOps

ChatOps è divertimento

Immediatamente mi sono accorto che a meno di qualche ritocco era tutto pronto: una forma simpatica del bot ne ha facilitato l’adozione da parte del team, che in meno di poche ore aveva già accolto il nuovo arrivato e il suo cervello artificiale con tanti sorrisi. Lui è ancora lì che fa cose per noi, quando gliele chiediamo, e ogni tanto aggiungiamo qualche funzione che potrebbe essere utile – insieme ad altre sicuramente più facete.

Una cosa che ho notato è che adesso pur mantenendo un debito tecnico abbastanza elevato sulle attività sistemistiche, comunque il team è in grado di gestirle senza degli specialisti, senza frustrarsi, e avendo comunque nei casi peggiori una linea guida su come diavolo fare una determinata cosa, data proprio dal sorgente del bot.

Codice sorgente che allo stato attuale, dopo un po’ di macchinazioni, è diventato all’incirca quello che segue:

var Botstation = require('botstation');
var bot = new Botstation.Bot();
 
bot.config({
    key: 'xoxb-157105193143-eJdSjJRttSCU2DAd3IdAtBoi',
    name: 'Dat Bot'
});
 
bot.task({
    name: "Help",
    matcher: "isMessage",
    content: "!help",
    exec: (bot, data, params) => {
        bot.postMessage(data.channel, 'Do you need help?', params);
    }
});
 
bot.start(() => {
    console.log('Bot started!');
});

Botstation

Il codice qui sopra non è campato in aria, bensì deriva da un lavoro di semplificazione che ho fatto su ciò che avevo in un momento precedente; ho realizzato infatti che non ci sono moltissimi framework per scrivere bot, così ho provato a buttarne giù uno mio, con una API architettata in modo da poter aggiungere quanti task mi servivano nascondendo tutta la (poca per il momento, a dir la verità) complessità di gestione del websocket, degli eventi del bot, e così via. Ho chiamato questa nuova creatura Botstation.

Il prossimo passo che vorrei intraprendere è quello di rendere Botstation multipiattaforma, scrivendo un meccanismo per cui avendo a disposizione vari adapter (Slack, Telegram, Facebook) si riesca a mettere in piedi un chatbot senza sforzo nascondendo la complessità della diversità dei servizi e delle loro API. Solo che non ho tempo di farlo adesso 😁

Fortunatamente, però, ho visto che i vari wrapper per le API di Telegram e compari sono orientati agli eventi nella stessa maniera.

RomaJS: ChatOps in compagnia con birra e taralli

Ho presentato questo piccolo lavoretto allo scorso RomaJS (veniteci a trovare!), credendo di fare solo da riempitivo perché non c’era nessun altro che portasse uno speech di livello. A sorpresa, invece, le persone sono rimaste abbastanza colpite sia dall’approccio ChatOps, fortemente orientato al cazzeggio inter-team, sia dalla facilità con cui è possibile scrivere un chatbot – con o senza Botstation, che ora come ora funge solo da wrapper di Slackbots.

RomaJS: ChatOps in compagnia con birra e taralli

Avrei dovuto scrivere questo post parecchi giorni fa, ma purtroppo sono state settimane complicate ed è stato veramente difficile mettere insieme i pezzi per via degli impegni di questi giorni. Un aspetto veramente stimolante è stato incontrare anche a Codemotion, in questi giorni appena passati, svariate persone che mi hanno chiesto come stesse andando lo sviluppo di Botstation e mi hanno esposto alcune domande e alcuni dubbi.

Io ovviamente sono stato felicissimo dell’impatto (seppur piccolo) che sta avendo un framework del genere, che onestamente avevo iniziato a scrivere solamente come esercizio personale. 😎

Quindi?

Riassumendo:

  • ChatOps vi aiuta a liberarvi del peso di task orientati alla sistemistica, ripetitivi, noiosi;
  • Un bot utile è sempre ben accolto; un bot con funzioni aggiuntive stupide, insensate e ironiche ancora di più perché migliora il morale
  • Botstation vi può aiutare, se usate Slack. Presto vi potrà aiutare anche se usate altre piattaforme di messaggistica 👌