Grab The Blaster di Alessio Biancalana

Fix the machine, not the person

Il buon Andrea mi ha consigliato “di striscio” (ossia linkandola altrove, e ci sono arrivato per caso) questo interessantissimo scritto di Aaron Swartz.

When you’re upset with someone, all you want to do is change the way they’re acting. But you can’t control what’s inside a person’s head. Yelling at them isn’t going to make them come around, it’s just going to make them more defiant[…].

No, you can’t force other people to change. You can, however, change just about everything else. And usually, that’s enough.

Memo per me: aggiustando la macchina prima delle persone, si cambia il comportamento di queste. Modificando tutto questo, togliendo le storture, in genere si aggiustano anche problemi interiori - e si trova un maggior gusto nel vivere, nel lavorare, e così via.

Facebook per Android, cosa diavolo...

Ora, parliamo un po’ dell’applicazione di Facebook per Android e traiamo qualche conlusione sparando a casaccio nel mucchio di codice. Innanzi tutto, c’è da dire che stamattina ho guardato per sbaglio e ormai la taglia dell’applicativo è XXL; come sono finito a notare questa cosa per sbaglio? Perché ieri sera l’applicazione ha iniziato a chiudersi da sola.

Esattamente: la apro, e va in chiusura forzata da sé. Ho dovuto cancellare i dati dell’app e riconfigurarla. Visto questo precedente, che si è anche ripetuto nel tempo e su più dispositivi, io mi domando le seguenti due cose:

  • Come diamine è possibile che ReactJS sia così tanto popolare come framework, quando è lampante che l’applicazione di Facebook funziona abbastanza male? Come è possibile che la pubblicità fatta da Facebook abbia sortito un effetto così positivo?
  • Come diamine fa un’applicazione a pesare 200 e rotti mega per fare due cose? Ok, ok: non sono esattamente due cose, ma sono comunque un po’ di cose. Tumblr non è molto diversa come approccio, eppure ne pesa solo 60, ossia meno di un terzo.

Meh. Torno al mio Ruby.

JRuby lentissimo a precompilare gli asset - la risposta è NodeJS

In questi giorni al lavoro mi sono trovato davanti a una cosetta allo stesso tempo interessante e allucinante: un applicativo Rails deployato sotto JRuby (astenersi commenti tipo “OMG JRuby ma che state a fà”) che per precompilare gli asset impiegava un tempo tra i 40 e i 50 minuti, quando non si piantava tutto il job di continuous integration.

E olé, verso nuove avventure: addentrandomi un po’ dentro questa roba ho capito che rake usa l’ambiente Javascript che si trova sotto il sedere per precompilare/minificare/offuscare/quellochevepare, quindi ho sostituito il runtime a livello applicativo con tre righe semplici ma efficaci nella configurazione:

if defined?(ExecJS) && system('which node')
    ExecJS.runtime = ExecJS::Runtimes::Node
end

Questo fa si che, una volta trovato l’eseguibile di NodeJS sul filesystem, e appurato che si stia usando ExecJS per eseguire il Javascript all’interno dell’applicazione, venga utilizzato NodeJS come runtime Javascript, e non quello built-in di JRuby che causa un rallentamento notevole.

Nel nostro caso, il tempo impiegato dalla build è stato ridotto da 45 minuti medi a circa 5 minuti medi. Chiaramente questa soluzione necessita di NodeJS installato sulla macchina.

Tiny npm packaging

Gianluca ha avuto l’ottima idea di stilare una comodissima checklist di cosa dovremmo includere in prima battuta quando mettiamo su un pacchetto per npm da zero. Giusto qualche osservazione:

  • Il .gitignore mi sembra un po’ scarno, ma effettivamente per un tiny package (e quindi un pacchetto che segue la filosofia Unix, ossia quella di fare una cosa e farla bene) c’è poca roba da considerare, quindi poca da ignorare
  • Di solito genero il package.json tramite npm init, ma anche avere un modello come quello che c’è nel post non è male; detto questo, sto iniziando a pensare di scrivere un piccolo eseguibile per generare un package.json al volo :-)
  • Basta co’ ‘sto feross standard style! A me piacciono i puntevvirgola. :-P

RainLoop: mettere in piedi una webmail senza sforzo

RainLoop

Et voilà: primo post del 2016. :-)

Con tutta questa cloud siamo abituati sin troppo ad usare le applicazioni all’interno del nostro browser; io stesso uso da sempre GMail, le altre applicazioni di Google e svariati servizi solo tramite un visualizzatore di pagine web. Da un po’ di tempo tuttavia sto meditando sia di mettere in piedi un mailserver personale, anche se non mi reputo in grado di sostenerne l’impegno - più che altro quello morale; viceversa, in ufficio la nostra webmail ha bisogno di una imponentissima svecchiata.

In questo scenario il buon Julian mi ha picchiettato più volte la spalla consigliandomi RainLoop, un client email web-based che mi ha intrigato sin da subito: il traguardo di questa applicazione infatti è quello di fornire un’esperienza d’uso molto simile a quella di un servizio email offerto da un qualsiasi provider, unita chiaramente ai pregi di una (o un pool di queste, diciamo) casella email self-hosted.

Fatte queste doverose premesse, in questi giorni ho cominciato a smacchinare per ottenere un’installazione di RainLoop funzionante su una macchina con CentOS; eccovi quindi una piccola recensione.

Installazione

Per imparare qualcosa in più su questo software (e sul mondo Red Hat, dato che di solito per le macchine uso Debian), ho preferito non installare RainLoop tramite Docker (visto che ha un suo Dockerfile), mettendo invece su un webserver Apache andando a completare una classica installazione LAMP (quindi con MySQL sotto le natiche).

Scompattato il tarball di installazione (per cui gli sviluppatori forniscono anche qualche riga di scripting), installato qualche modulo PHP mancante e riavviato il webserver per l’ultima volta, ho avuto una bella sorpresa: tutto funzionante e zero sbattimento :-)

Configurazione

RainLoop espone un path al quale possiamo configurare la webapp per modificarne alcuni comportamenti, tra cui l’accesso ai server di posta: nella sezione dei domini, ci basta infilare il nostro mailserver tramite una label, le impostazioni IMAP e quelle SMTP. Quando poi andremo a effettuare l’accesso, potremo utilizzare le credenziali della casella di posta: RainLoop farà da middleware, validando queste informazioni e sincronizzando la casella di posta. Non male, mh?

Inoltre, ci sono anche delle opzioni apposite per il branding. Tramite l’acquisto di una licenza premium, possiamo anche fare l’upload di un logo personalizzato.

Utilizzo

L’uso è quello di un normale client web-based IMAP: abbiamo un pulsante per qualsiasi azione, e una semantica di ricerca per quanto riguarda i messaggi simile a quella usata da Google. La cosa che mi ha lasciato perplesso è che non ho ancora visto nulla per fare raggruppamento dei thread, probabilmente qualcuno avrà sviluppato un plugin per questo.

Ecco qua, ho parlato troppo presto. RainLoop supporta il threading tradizionale di IMAP, basta attivarlo nelle opzioni. L’ho visto in questa issue su GitHub.

Insomma, un software che ti salva veramente la vita: la composizione di mail è ottima e offre tutto quello che può servirci, la lettura della posta anche, adattandosi sia a mail HTML potenzialmente molto antipatiche, sia ovviamente al testo semplice. Per quanto mi riguarda l’unica vera pecca di questo software è che i temi non sono veri temi, e il software non mi sembra ben estensibile.

La scelta dei temi infatti non cambia la veste grafica di RainLoop, ma solo lo sfondo della webmail; allo stesso modo non apprezzo moltissimo il look ‘n feel dei pulsanti e delle barre, un po’ retrò e al quale a quanto pare dovrò abituarmi. Senza dubbio molto meglio dell’aspetto incartapecorito delle applicazioni concorrenti, non c’è che dire :-)

Veramente troppo, troppo fico. Ho finalmente trovato un’alternativa agli antipatici client email desktop, che più di qualche volta presentano impuntamenti e ritrosie; spero che questo si comporti bene.