mercoledì 26 marzo 2014

OpenWebMail ?

OpenWebMail e' una piattaforma di email web.
Non e' particolare, ce ne sono tante come OpenWebMail. Non dispone di un calendario e di nessuno strumento evoluto per essere classificata come una vera applicazione PIM (Personal Information Management), e' una semplice e funzionale applicazione di posta elettronica.

Perche' allora parlare di OpenWebMail?
In passato sono stato costretto ad utilizzare questa interfaccia come client di posta per un'azienda. Ebbene, seppur di semplice e intuitivo utilizzo, OpenWebMail non viene piu' sviluppato attivamente da diverso tempo.



Eppure ci sono ancora aziende che utilizzano OpenWebMail come unico client di posta per i loro dipendenti, e quel che e' peggio, ci sono anche fornitori di servizi che forniscono installazioni di OpenWebMail beta in produzione!


venerdì 14 marzo 2014

Towards a sigil style

It happens more day by day that I find myself writing or maintaning programs and scripts written in different languages, mixed and interpolated together.
This lead me to appreciate every day more those languages that apply a "sigil" style, where each variable is identified thru a special character (a sigil), such as for instance $var or @array.
The technical reason for having a sigil is often that the parser is simpler, since it is helped by the developer in understanding what looks like a variable and what looks like a bareword or a function. But the final result, at least for me, is that it is much simpler to read a sigil-based language than another one. I cannot explain exactly why and how, but it turns out that looking at a piece code that contains sigils prompt me in the right mood at the right line. Let's say for now that it is just a metter of seeing a sigil that pops up my attention and make me think what the symbol at the cursor is depending on its sigil.
And, it is worth saying, I appreciate the most those languages like Perl where different sigils are used to indicate different things (even if you will end using the scalar $ the most).

lunedì 10 marzo 2014

Atom vs Emacs

Atom.io e' un nuovo editor di testo, in fase di sviluppo.
E' promettente: un editor totalmente personalizzabile da parte degli utenti che possono scrivere facilmente moduli ed estensioni per cambiarne il comportamento e l'aspetto.
Ok, ricorda qualcosa....se non fosse per il "semplicemente" direi che e' esattamente identico ad Emacs. Eccetto che Emacs puo' essere ancora piu' semplice!
A parte le battute dovute piu' che altro alla religione degli editor, Atom appare veramente un clone moderno di Emacs.
Non solo Emacs e' di fatto l'unico vero editor totalmente personalizzabile che io abbia mai visto e usato, ma alcune delle feature di Atom sono identiche a quelle di Emacs.
Ad esempio, il modulo  Zen fa esattamente quello che il mio Emacs fa con poche righe di codice lisp, e soprattutto senza dover installare una estensione.
La possibilita' di avere i suggerimenti sui nomi dei file da editare e' esattamente quello che fa il mio Emacs con IDO.
Sort Lines  fa esattamente quello che il comando sort fa, solo che Emacs permette di eseguire gia' tutti i comandi disponibili su un buffer o una regione, e quindi risulta ancora una volta vincente.
E come per Emacs, le estensioni si sprecano e portano fino ad esempi inutili come Editor Stats  (francamente mi interessa sapere di piu' cosa sto editando che sapere 'quanto').

Insomma, a parte per la tecnologia utilizzata e per il fatto che la struttura di Atom mi appare maggiormente a "micro-kernel", direi che di differenze significative con Emacs non ce ne sono.
E questa mi sembra una bella vittoria per Emacs, precursore di molte idee riprese poi negli IDE e negli ambienti moderni.

Non mi e' ancora chiaro se Atom potra' funzionare anche in console e quindi via terminale remoto, cosa che Emacs svolge egregiamente (anzi, Emacs puo' lavorare in modalita' client-server e anche come wrapper di terminale).
Ma sicuramente una cosa e' chiara: Emacs ha una licenza piu' conveniente che quella di Atom.

PostgreSQL 9.4: decodifica dei WAL e replication slot

Ricordo che al PGDay.IT del 2012 il keynote (Simon Riggs) parlava di una feature che sarebbe stata introdotta in PostgreSQL riguardo la decodifica dei WAL in formato logico, ossia umanamente leggibile (istruzioni SQL o qualcosa di simile). Era stato detto che ci sarebbe voluto diverso tempo per implementare tutti i pezzi di questa conversione da binario a testuale, ma che era un passo fondamentale per la crescita di PostgreSQL.
Ebbene nella nuova versione, la 9.4, alla quale gli sviluppatori stanno lavorando, e' stata introdotta una patch che permette di convertire i WAL in formato testuale.
Qui si trova un primo esempio, piuttosto impressionante , della funzionalita' di decodifica dei WAL.
Da notare che l'esempio sopra riportato cita anche i "replication slots", un'altra feature aggiunta per l'imminente 9.4. L'idea e' semplice ed elegante: mentre prima il master non aveva alcuna conoscenza dello stato di replica degli slave, che quindi potevano andare off-line per molto tempo e rimanere "troppo indietro" rispetto al master, dalla 9.4 il master terra' lo stato di replicazione di ogni slave agganciato (uno slot appunto). Questo permettera' al master di conservare tutti e soli i WAL richiesti dagli slave, anche se non disponibili per molto tempo, senza costringere il DBA a indovinare quanti WAL mantenere (keep segmentes) o l'implementazione di un continuos archiving.

La 9.4 promette molte altre feature, ma quelle di cui sopra in fatto di replica sono sicuramente molto significative.

domenica 2 marzo 2014

On bug and bug reporting

A quite well established mindset with Open Source projects is that as much users a code base has, as much it will be tested and, therefore, will produce a continuosly growing quality product.
And it is true, indeed!
But what does it mean to test an Open Source project? Disregarding the low level testing with test suites, it means that true users will install, run and report back application misbehaviors, crashes, problems, and so on. And this is the point of this post: reporting back information to developers so that they could do their work and improve the software. I'm not focusing on how to write a good bug report, you can find a lot of information about in the net and in the project documentation itself. But have you ever thought about the importance to report as less information as possible to allow a developer to do her job? I mean: what do you think a developer will feel like opening the bug tracking system on the Monday morning and finding out tons of bug reports? Therefore, before posting a bug report, please ensure that none before you has openend the same report, and in case append to such report. You will achieve the goal of making the developer feel better and, most notably, to avoid wasting her time in reading just another report that reports the already known problem.
And if you have time, please provide a clear and short way to reproduce the bug, even if you are not the first reporter. Even better, write an automated test for the bug you are interested in: you will grant the developer some extra time to concentrate on the real bug instead of the aside artifacts.

And about testing allow me to spend some extra words: while it is very important to test the produced code, please consider that techniques such as Test Driven Development TDD not only promote the creation of tests ahead the code that implements a feature, but also that a feature should be requested due to a failed test.
In other word, if you want to add feature X to the project Y provide a short and clear test along with the feature request.
Why?
Because again, you are going to give the developer(s) some extra time and will help her better understanding what is your will. And most notably, while writing the test you will become a concrete part of the development and will better think about what you are asking (and why you are needing it). In other words: you will only ask something you can clearly explain and with as less as possible misunderstandings, while the developer(s) will have a concrete case to start developing on.

Fianlly, again on testing, please spend some time reviewing and providing new test cases for existing code, even if you don't have a feature request or a bug to work on.
Why?
Because Open Source developers often, or better almost always, do the hard work on their spare time, and will regret to implement some new code until they do not risk public embarassment. Therefore, if the code base has a strong and reliable test case, developers will be more likely to implement more code without having to worry about awkaward bugs.

sabato 1 marzo 2014

Editors

No, questo non è un post tecnico: gli editors a cui mi riferisco non sono quelli di testi, bensì quelli musicali. Gli Editors sono un gruppo inglese che sta avendo un grosso successo, e devo dire hanno uno stile e un ritmo carico. Il cantante ha una voce con una tonalità molto calda, che si rapisce.

Ebbene ieri sera sono andato, o meglio mia moglie mi ha portato, al concerto degli Editors a Bologna. Ammetto che probabilmente io non ci sarei mai andato di mia iniziativa: non è un genere di band che mi interessa vedere dal vivo. 
Fino a ieri sera.

Gli Editors sul palco sono veramente travolgenti. Lo spettaccolo è stato veramente bello e travolgente, e il gruppo non si prende nemmeno una pausa fra una canzone e l'altra.
Insomma ne è proprio valsa la pena, consiglio caldamente a tutti di vedere almeno un loro concerto. E così magari qualcuno riuscirà a spiegare da dove il cantante, esile, tira fuori questo vocione avvolgente.

E prima dell'inizio del concerto, mentre guardavo i gadget, qualcosa ha colpito il lato nerd del mio cervello. La mug ufficiale degli Editors non ricorda forse un'altra mug, di un editor famoso, guarda caso il mio preferito, ovvero lo GNU dietro a Emacs? Ok il simbolo degli editors è un toro, quello di Emacs uno gnu, ma effettivamente la somiglianza c'è.
Che si tratti solo di una concidenza fra il nome della band, il simbolo scelto e il mio editor preferito?





Sysadmin Panics: script di backup (ma non di recovery!)

Ogni tanto inciampo ancora in qualche script ben fatto per il backup automatico dei sistemi *nix, e spesso mi torna alla mente quanti script orrendi ho dovuto correggere a tal proposito in passato.
Due erano gli errori piu' ricorrenti che mi causavano diversi grattacapi:
1) test sbagliati o fallimentari sull'esistenza di backup precedenti;
2) mount errato o multiplo di locazioni di backup remote.

Per quanto riguarda il primo, test sbagliati sull'esistenza di backup precedenti, l'errore era spesso tanto semplice quanto subdolo: lo script presentava uno "slurping" test che non eseguiva il backup in caso di assenza di una copia precedente. In altre parole qualcosa del tipo:

if [ -f backup.zip ]
then
  mv backup.zip old_backup.zip
  # fai nuovo backup
fi

Ora in cosa e' fallimentare questo test? Se viene rimosso l'entry che segnala la presenza di un backup l'intero script non esegue. Ok, ma perche' dovrebbe essere rimosso da storage il backup precedente? Perche' ad esempio si e' aggiunto un disco nuovo (vuoto) o perche', in una fase di panico, si e' cancellato tutto il backup pregresso per fare un punto zero. E lo script di cui sopra puo' fallire silenziosamente facendo trovare il sysadmin di turno in una situazione in cui il backup di fatto non c'e'!
La soluzione e' ovvia e semplice:

if [ -f backup.zip ]
then
  mv backup.zip old_backup.zip
fi

# fai nuovo backup

Il secondo tipo di problema e' un po' piu' complesso: se il backup deve essere fatto su uno storage esterno e' bene che questo sia montato e smontato quando serve, per evitare contaminazioni dei dati. Il problema e' che spesso questo storage esterno viene condiviso via SMB o NFS, e il primo in particolare consente lo stacking mount ricorsivo, causando qualche problema nello smontaggio. La soluzione anche qui e' semplice ma un po' laboriosa: occorre montare e smontare i volumi testando il valore di ritorno delle chiamate di sistema. Altrimenti si rischia di non smontare un volume o, peggio, di fare il backup su una directory invece che su una share (e magari riempendo tutto il filesystem)!

E in generale l'insegnamento spesso dimenticato e' che non si puo' dire che una procedura di backup funzioni fino a quando non si e' fatto almeno un recovery positivamente.

Autovivification e defined-or in Perl

La regola che guida Perl e' quella di poter fare quello che si vuole con il minimo sforzo.
A tal fine Perl offre il concetto di "autovivification", noto anche a molti altri linguaggi di scripting, che consente di inizializzare una variabile (scalare o non) al suo primo accesso. L'idea e' quella di non dover pre-inizializzare le strutture dati, ma lasciare che questi si popolino in automatico quando occorre.
Come conseguenza dell'autovivificazione l'accesso ad un entry in un hash che non e' ancora stat definita produce l'inserimento dell'netry con valore undef, cosi' come l'accesso ad una cella di un array con posizione non ancora conteggiata implica la sua inizializzazione (e di tutte le celle precedenti) al valore di zero.
Perche' questo dovrebbe semplificare le cose? Perche' invece che scrivere un blocco di codice come segue:

%my_hash = ( FILES => 0,
DIRS => 0,
LINKS => 0 );
# ...
$my_hash{ FILES }++;
# ...
$my_hash{ DIRS }--;
# ...

e' possibile scrivere direttamente:

%my_hash;
# ...
$my_hash{ FILES }++;
# ...
$my_hash{ DIRS }--;
# ...

Perl e' sufficientemente intelligente da capire anche i riferimenti, e quindi tutto funziona correttamente anche usando strutture dati complesse.
Anche se esistono opportuni moduli per ridurre o eliminare l'autovivificazione (ad esempio evitando di popolare celle con chiavi mispelled), l'autovivification e' una proprieta' veramente molto utile.

Ma Perl non si ferma qui: le versioni recenti definiscono anche l'operatore "defined-or". Tale operatore, dalla sintassi a mio avviso orribile, permette di inizializzare in autovivificazione un elemento solo se questo non e' ancora stato definito.
La sintassi e' per me orribile perche' l'operatore di assegnamento "defined-or" usa, ovviamente, il simbolo '=' (assegnamento) preceduto da una doppia slash '//' (ad indicare e ricordare il simbolo di or logico '||'); tale sintassi ricorda vagamente un commento C++/Java e la cosa e' a prima vista fuorviante nella lettura del codice.
Ad ogni modo come funziona l'operatore? Si consideri il seguente esempio:

#!/usr/bin/env perl -w

use v5.10;
use Data::Dumper;

sub initialize{
  my ($hash_ref) = @_;

  $hash_ref->{ name } //= "Luca";
  $hash_ref->{ surname } //= "Ferrari";
}


$my_hash_ref = { name => "Mr. Luca" };
say Dumper( $my_hash_ref );
initialize( $my_hash_ref );
say "After the defined-or operator....";
say Dumper( $my_hash_ref );

che produce come output:

$VAR1 = {
  'name' => 'Mr. Luca'
};

After the defined-or operator....
$VAR1 = {
  'name' => 'Mr. Luca',
  'surname' => 'Ferrari'
};


L'idea e' questa: viene definito un hash che deve contenere come chiavi 'name' e 'surname', ma per dimenticanza (o pigrizia) solo il primo viene valorizzato. Poi si chiede alla funzione 'initialize' di inizializzare l'hash e questa esamina le due chiavi. La prima, 'name', e' definita e quindi non viene riassegnata, mentre la seconda non e' ancora stata definita e quindi viene assegnata ad un valore di default.
Valore di default: questo e' l'uso principale dell'operatore "defined-or".
In altre parole e' come se si fosse scritto:

if ( ! exists $hash_ref->{ surname } ){
   $hash_ref->{ surname } = "Ferrari";
}