git: rename a tappeto!

Mi capita spesso di impostare un repository git su un computer che non uso abitualmente; dopotutto il bello di git è proprio questo essere distribuito. Una delle cose che però scordo sempre, nella fretta, è di impostare lo username e l'e-mail che apparirà nei commit. Siccome tipicamente lavoro "da solo" su un repository, faccio abbastanza presto a rinominare tutti i commit sbagliati: il comando filter-branch consente infatti di agire sui commit di un ramo di sviluppo. Nel mio caso tutto si riduce ad un semplice:

git filter-branch --commit-filter '
                GIT_COMMITTER_NAME="Luca Ferrari";
                GIT_AUTHOR_NAME="Luca Ferrari";
                GIT_COMMITTER_EMAIL="email";
                GIT_AUTHOR_EMAIL="email";
                git commit-tree "$@";

        ' HEAD

Il trucco ovviamente funziona per commit non ancora resi pubblici. Il comando filter-branch consente anche di individuare particolari commit (ad esempio solo quelli sbagliati invece che tutti) e quindi di agire solo su tali.

Use assertions!

You use assertions, don't you?
Today almost every language/framework/library provides developers with an assertion-like set of tools. Use them!

The point is not that assertions are good for testing critical conditions, it is that they help documenting the code. Allow me to explain with an example:

private String doSomething( String input ){

     assert( input != null );

     return ;

}

What can you see here? That the input object cannot be null. Trivial. But there's more: developers are working here assuming someone has called doSomething with a null object argument, that is having input null is not only bad, it is a catastrophe! So if you are a doSomething client you are supposed to provide the right value for input arguments. 

Now, please remember that assertions are totally different from exceptions. The above method could have been written as:

private String doSomething( String input ){

     if( input == null )

         throw new Error();

     return ;

}

This is totally different: in the former method the developers clearly stated that they do not want to deal with a null input, it's on you to provide a not-null input object. In the above example instead developers are somehow dealing with null values, even if they are letting you to know that you did something wrong.

So when to use assertions and when to not use them? Assertions should be used for all the internal stuff, e.g., private methods, so things that should be called when input is not tainted. On the other hand, if you think you are going to get bad input, deal with it!

And remember: assertions are going to vanish when you are in release mode, so do not place anything more complex than a boolean test in them. For instance:

private void doSomethingElse(){

    assert( loadDataFromDatabase() != true );

    ...

} 

This is ugly wrong! Once the assertion is disabled, chances are (depending on the assertion mechanism of the language/framework/library), that the call to loadDataFromDatabase disappears too, and with it all your loading-data!

So please use assertions, and use against single variables!

git merge & commit message

E' stata apportata una modifica importante a git, il famoso DVCS sviluppato per il kernel di Linux e oggi utilizzato in moltissimi altri progetti. La modifica riguarda il merge di due o piu' rami: attualmente git effettua il merge in modo "silenzioso", inserendo un messaggio automatico che indica un generico "merge of ". Con la modifica apportata git chiedera' all'utente di inserire un messaggio personalizzato. Banale, ma molto efficace: anzitutto consente all'utente di motivare il merge, e in secondo luogo consente all'utente di riflettere fino all'ultimo sull'esigenza del merge e nel caso di annullarlo.

Lo stesso Linus Torvalds commenta così la nuova feature:

This change hopefully makes people write merge messages to explain their merges, and maybe even decide not to merge at all when it's not necessary.

I've been using that git feature for the last few weeks now, and it has resulted in my merges from submaintainers having various notes in them (well, at least if the submainter gave me any). So I'm trying to lead by example.

But if you don't like explaining your merges, this might be annoying. Of course, if you don't explain your merges, you are annoying, so it all evens out in the end. "Karmic balance", so to say.

goto (3)

Nuovo controllo dell'utilizzo della famigerata istruzione goto all'interno di progetti importanti. E' la volta di PostgreSQL, versione 9.1.1, che risulta avere ben 1639 istruzioni goto nell'intero albero dei sorgenti.

E che dire del KDE? Ebbene un controllo su un repository aggiornato ad oggi del popolare desktop trova solo 328 istruzioni di salto incondizionato. Ancora una volta questi numeri non dovrebbero stupire, specialmente se si pensa che KDE è sviluppato in C++ e quindi orientato agli oggetti.

C'è ancora chi crede in ....

In questi giorni sono rimasto sorpreso dalla scoperta che due progetti che per me dovevano essere morti e sepolti sono invece ancora attivi, e in alcuni casi addirittura finanziati!

Il primo progetto è Minix, il famoso sistema operativo Posix basato su micro-kernel e scritto (principalmente) da Tanenbaum, professore universitario la cui discussione con Linus Torvalds è storia. Ebbene Minix ha ricevuto una ingente somma di denaro affinché la ricerca sul suo microkernel possa continuare. Lungi da me voler criticare Minix, ma a nessuno viene in mente che forse, dopo tutti questi anni di sviluppo e ricerca, la soluzione microkernel non possa essere semplicemente applicabile? Possibile che esistano così tanti stupidi nel mondo che non si rendono conto di come il loro sistema operativo preferito possa girare meglio usando un microkernel? Possibile che tutti questi fantastici sviluppatori siano così ottusi da volere un kernel monolitico? Oppure è semplicemente inutile insistere sul microkernel visto che gli attuali kernel monolitici fanno quello che si vuole e sono pronti oggi? Io ritengo che l'idea del microkernel sia buona, ma quando implementata in user space. No, non è una contraddizione: si pensi ad OSGi e quanto bene funziona Eclipse.

Il secondo progetto che mi ha sorpreso, questa volta non per i finanziamenti, è OpenCDE, la versione Open del popolare Common Desktop Environment. Ho un ottimo ricordo del CDE e di quando lo usavo su delle già vecchie Sun Ultrasparc 2 con Solaris 8. Proveniendo allora dal mondo Windows, la minimalità e praticità del CDE mi sembravano ottime. Nonostante l'aspetto grezzo e poco curata, l'idea dei cassetti era semplicemente fantastica. Tuttavia il CDE aveva un enorme pecca: non facevo quello che il suo nome diceva, ossia non era un desktop ma una collezione di applicazioni con un pannello. L'integrazione fra le applicazioni era assente, concetti di drag-n-drop neanche a parlarne...

Pur avendo un ottimo ricordo del CDE, non capisco che senso possa avere mantenere in vita un tale ammasso di codice, se non per puro scopo educativo/storico. 

Ma alla fine queste sono altre due dimostrazioni di quello che si puo' fare con l'OpenSource: tutto! 

Purché abbia senso per chi lo sviluppa!

goto (2)

L'istruzione C goto è, come spesso si sente dire, sconsigliata in ogni contesto. Come mostrato in un mio vecchio post, il kernel di Linux include migliaia di istruzioni goto. Ebbene l'esecuzione della stessa ricerca all'interno del solo ramo sys di un kernel FreeBSD (8.2-RELEASE) mostra un totale di 20898 istruzioni goto! La cifra è grosso modo il doppio del corrispondente di un kernel Linux.

Ovviamente la cosa non deve trarre in inganno, non si è davanti ad un esempio di cattiva programmazione: le istruzioni goto si trovano infatti maggiormente nel codice specifico delle varie architetture supportate. Esse rappresentano un modo sintetico ed efficace di salto incondizionato.