Vim setup per Markdown

Di recente ho iniziato ad essere insoddisfatto degli editor Markdown che uso - o meglio, loro il loro lavoro lo fanno benissimo, sono io che avendo un flusso di lavoro orientato alla riga di comando non riesco a integrarli perfettamente. Ho provato a scrivere qualche plugin di ZSH per dover passare sempre meno dal cursore del mouse e rendere tutto “streamlined”, ma proprio non ci riesco.

Viceversa la cosa che adoro è usare Vim, e stamattina avendo un po’ di tempo a disposizione ho spulciato un po’ l’Internet; greppa che ti rigreppa è uscito questo meraviglioso post che illustra come creare un setup completo per editing di file Markdown con Vim senza troppi sforzi.

I’ve been struggling with the Vim setup I use to write for a while now. For a geek, I have a pretty standard work flow. iTerm is my terminal emulator. Inside that I run tmux. Inside that I run vim. I write my text in Markdown and commit my work to a Git repository. For ages I’ve been using my regular coding setup with a few hacks to the ftplugin for Markdown. It worked but it didn’t work well. I’ve since decided that it’s time to set about fixing it.

E con questo, diciamo addio a Byword e Typora, dato che almeno per il momento posso definirmi soddisfatto.

GNOME Shell con GPU Intel, configurazione (circa) finale

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

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”.

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 🌝

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.

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”.

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!