Alessio Biancalana Grab The Blaster di Alessio Biancalana

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.

So long, and thanks for all the software

Ian Murdock

Ian,

Sei stato una tra le persone che più hanno contribuito a rendermi ciò che sono. Ora, presumo che dovremo cavarcela senza di te; sarà difficile.

Jekyll e il flusso di pubblicazione

Jekyll

In un suo post, Nicola mi ha elogiato di aver mantenuto il ritmo di pubblicazione nonostante il passaggio a Jekyll. Per chi non lo conoscesse, Jekyll è il motore su cui si basa questo blog - o forse dovrei dire “non-motore” visto che di fatto è solo un generatore di siti statici. È vero, Jekyll da fuori sembra una figata assurda e quando poi ci sei dentro scopri che mentre tante cose sono facilissime rispetto a un CMS tradizionale, altre mancano di immediatezza, come la scrittura di un post. Visto che il buon kOoLiNuS si è dimostrato perplesso, vediamo di fare chiarezza su cosa influisca realmente in un flusso di pubblicazione basato su Jekyll, e anche su qualche aspetto collaterale.

Mentre lascio a te la lettura e la valutazione di questa mossa, volevo mettere in evidenza la frase finale. Jekyll sarà anche figo, ma è senz’altro geek e abbastanza tecnico… e quando nella vita si vuole stare comodi non sempre certe soluzioni sono tali da invogliarti ad approcciare alla scrittura.

Con l’eccezione di Dr.Blaster e Lucio, infatti, non conosco nessuno che una volta migrato su questa piattaforma abbia mantenuto il precedente ritmo di pubblicazione…

Pregi di Jekyll

Sicuramente una delle cose più rilevanti, è che hai tutto in locale. Nel caso in cui tu voglia scrivere, hai tutto a disposizione per farlo: basta aprire l’editor di testo, iniziare a buttare giù qualcosa, riguardarlo, dargli una forma (e una formattazione). Quando hai finito, chiudi l’editor di testo e via: salvi il file e ti basta fare un commit e un push su GitHub (oppure rigenerare il sito, nel caso in cui tu non stia usando un sistema di Continuous Integration o GitHub Pages come faccio io). Tutto arabo vero? Ecco appunto: a questo arriviamo dopo.

Un altro grandissimo pregio, è che praticamente non c’è bisogno di backup, dato che la larghissima maggioranza dei blog generati da Jekyll che conosco sono sotto un opportuno sistema di versioning. Jekyll, d’altronde, è pensato per fare proprio questo: mantenere il proprio blog tramite solo testo, un’alberatura di file grossomodo semplice e qualche comando da terminale. L’idea è geniale, anche perché espandendo il concetto espresso poco sopra, mantenendo tutto versionato e su un hosting Git/SVN, aggiungere contenuti non comporta praticamente sforzo, il backup si fa da sé, e così via.

Oltre questo, troviamo anche una personalizzabilità invidiabile: basta modificare i template dei formati dei propri post, tramite il Liquid Templating Markup, per aggiungere nuovi custom post type e tanto altro. Insomma, una cosa per veri smanettoni smaliziati, il che ci porta direttamente ai difetti. :-D

Difetti di Jekyll

Bello Jekyll, fico Jekyll, però è anche vero che per un blogger tutto questo significa alle volte una fatica bestiale. Nonostante l’infrastruttura perfetta infatti (dal punto di vista tecnico), il blogger è comunque una creatura che vive di impressione e ispirazione; la criticità quindi diventa proprio l’assenza di frontend, il fatto che senza strumenti che ti aiutino non riesci più a trovare quell’immediatezza, quel flusso di lavoro a cui ormai lungo i decenni il CMS ti ha abituato (nel mio caso, prima FlatNuke poi WordPress). A me Jekyll piace ancora, ma è anche vero che dopo più di un anno dalla migrazione, nell’intento di incrementare il ritmo di pubblicazione, ho cominciato a scrivere una gemma Ruby che dovrebbe contenere una serie di helper. L’ho messa su GitHub come quasi tutto il mio codice, e penso che presto ne farò il push anche su RubyGems.org :-)

Insomma, non è tutto oro quello che luccica, anzi: purtroppo nel caso di Jekyll è assolutamente reale che non c’è più quell’immediatezza che c’era con altri CMS; quello che è vero, tuttavia, è che lo strumento cambia il modo di scrivere, e sicuramente Jekyll ha fatto in modo che scrivessi cose leggermente più ponderate. Pian piano spero di arricchire Burst di funzionalità in modo da fornirmi tutto quello di cui ho bisogno.

È troppo vero: Jekyll ha reso di me un blogger peggiore (forse? Dato che comunque non scrivo più così spesso), ma penso che mi abbia reso più riflessivo e un programmatore migliore, indubbiamente. Il fatto che mi abbia dato nuove necessità da soddisfare, e nuovi problemi da risolvere, per me è un pregio ma per altri senza dubbio può essere un freno. E lo sarà: non è fatto per uscire dall’ambito geek, e quello che deve fare lo fa eccellentemente.

Difetti? Ne ha, però…

È vero che usare un martello di un tipo piuttosto che di un altro tipo non cambia che il chiodo venga piantato, ma uno dei siti più belli che io abbia visto nell’ultimo anno è basato su Jekyll e merita una menzione: parlo del sito di opensensorsdata, e di tutti i sottodomini, rigorosamente jekyllizzati. È un esempio ottimo, secondo me, di come Jekyll possa corrispondere in modo più che ottimo a determinate esigenze aziendali.

E ora scusate, devo andare a scrivere un software in Ruby per automatizzare la scrittura dei post per il mio blog basato sulla generazione di siti statici. A volte penso che, semplicemente, invece di automatizzare tutto solo per il gusto di farlo, dovrei semplicemente muovere il culo e scrivere di più :-)

Swift per Linux

So che è “roba di Apple”, ma il port su Linux di Swift mi intriga. Alla fine da quello che ho visto è un incrocio tra Python e Javascript (che sono due linguaggi che infatti adoro), con operatori interessanti e il supporto alla GlibC. Chissà, magari ci farò qualcosa di più uno di questi giorni :-)

Quello che è sicuro, è che per l’intanto il port su Linux è stato fatto. Sul sito ufficiale trovate i .deb disponibili per le ultime versioni di Ubuntu. Su Arch Linux, ovviamente, potete installarlo tramite il PKGBUILD che c’è su AUR.

PHP 7.0

Evidentemente i ragazzi di PHP amano il brivido del rischio e dei ripensamenti:

After doing the last evaluations in the RMs circle before going for 7.0.0 RTM preparations, we came to the conclusion that the current state does not look reasonable to be packaged as the final release.

Dopo lo stralcio di cui sopra di una mail al gruppo di lavoro, proprio due giorni fa è apparso il tag di PHP 7.0. Ovviamente, come tutte le creature appena nate, ne viene sconsigliato l’uso in produzione: handle with care :-)))

Member of

Previous Random Next