Buildr est un outil écrit en ruby qui se substitue à maven. L'installation passe par ruby-gems, aussi il est facile de changer la version d'une gem qu'on utilise en lui passant la version entre deux underscores :
maGem _uneAutreVersion_ faitQuelqueChose.

En combinant cette facilité avec la possibilité offerte par les alias du shell, c'est très rapide pour changer rapidement la version de buildr utilisée. Ainsi, je suis actuellement en cours de migration de notre build de buildr 1.3.5 vers buildr 1.4.4, mais je n'ai pas fini mon travail et j'ai besoin de changer de version pour faire une release rapide sur une branche :

$ buildr --version
Buildr 1.4.4
$ alias buildr='buildr _1.3.5_'
$ buildr --version
Buildr 1.3.5

Le retour arrière se fait par la destruction pure et simple de l'alias :

$ buildr --version
Buildr 1.3.5
$ unalias buildr
$ buildr --version
Buildr 1.4.4

Et voilà ! Vous êtes paré pour de nouvelles expérimentations.

Buildr utilise les conventions et les repos maven. Pour un projet spring-mvc qui utilise également spring-jdbc, cela fait beaucoup de dépendances. Heureusement, Buildr::group permet de les rassembler par groupId :

Avec Ubuntu, viennnent les JDK 5 et 6. Si vous utilisez update-alternatives, vous pouvez d'ores et déjà changer de version à volonté. Mais comment faire si vous travaillez sur du code plus ancien qui nécessite une JVM 1.4 qui elle n'est pas installée dans votre Ubuntu ?

Récemment nous avons du sérialiser des objets dans des fichiers, et une des personnes dans l'équipe a proposé XStream. C'est une librairie développée par ThoughtWorks (la société de Martin Fowler) qui permet de faire du marshalling/unmarshalling d'objet en XML. J'avais eu beaucoup de mauvaises expériences avec les librairies XML Java (soit trop intrusives niveau métier comme par exemple JAXB soit trop bas niveau comme DOM/SAX). XStream répond à toutes les attentes :

public class MonObjet {
    private int monAttributEntier = 3;
    private String monAttributString = "attribut";

La lecture de cet billet : Editorial: NPEs must die, m'a posé une nouvelle fois la question de la programmation défensive. Dans son éditorial, l'auteur nous explique qu'en java une NullPointerException ne casse pas le système, ce qui pousse les programmeurs fainéants (et trop le sont :( ), à ne rien faire. Il nous dit ensuite :

This is just plain bad coding. An NPE tells you almost nothing about what really went wrong. Instead, Java developers should check objects before invoking methods on them, and throw a more specific and meaningful runtime exception, such as an IllegalArgumentException, with details about what value was incorrect.

Rien à dire sur le principe de guidage en indiquant précisément le problème (quelle valeur n'est pas bonne et pourquoi). En revanche, "check objects before invoking methods on them" amène à la programmation défensive.

Une fois le recovery clockworkmod installé, vous pouvez facilement changer votre système en entrant dans le recovery. Mais avant cela, il est conseillé de faire une sauvegarde de l'actuel à l'aide également du recovery : allumez votre mobile en appuyant simultanément sur volume- vous voyez apparaître le menu suivant

Pré Scriptum : les manipulations décrites ici modifient la mémoire constructeur (ou opérateur) du téléphone en invalidant la garantie, c'est à vous de voir si vous vous sentez suffisamment à l'aise pour récupérer le tir si les choses ne se passent pas comme prévu. "Rooter", cet anglicisme pas très joli signifie acquérir les droits "root" soit "racine" à l'administration, en l'occurrence de son mobile. l'utilisateur "root" ou super-utilisateur vient du monde UNIX qui dès le début des années 80 avait défini une politique de gestion des droits sur des systèmes multi-utilisateurs. Si on avait dit aux concepteurs des droits utilisateurs de ces machines (de type serveur) qu'ils seraient utilisés sur des téléphones mobiles 25 ans plus tard (à l'époque encore au stade de la recherche), je pense qu'ils auraient bien halluciné.

Il y a quelques temps, nous avons constaté dans notre équipe des lenteurs très importantes lorsque nous faisions tourner nos tests unitaires. Le déroulement global qui prend entre 5 et 8 minutes (selon les machines), passait à 30 minutes voire plus.

La cause de ces lenteurs était l'utilisation d'un sytème de fichier en ext4 avec mysql suite à de nouvelles installations d'ubuntu. En effet, en ext4, une fonctionnalité ayant pour but de maintenir une meilleure intégrité des données a été activée par défaut, il s'agit des "write barriers". Pour contourner le problème il suffit de désactiver ces write barriers sur les montages utilisés par mysql (ici /opt) dans /etc/fstab :

/dev/sda2 on /opt type ext4 rw,barrier=0

Cf :

• http://bugs.mysql.com/bug.php?id=46959
• http://www.tedman.com/techie-notes/fedora12onthinkpadx61s

Edit : suppression des parenthèses après la remarque de Philippe

Ma musicothèque est essentiellement en FLAC (en provenance des CD que je continue d'acheter), et je me sers de ces fichiers FLAC pour générer mes MP3. J'importe ensuite ces MP3 sur le macbook de Nadège pour emmener notre musique avec nous. Comme je fais cette manipulation assez souvent, je me retrouve avec plein de doublons dans iTunes (je n'ai pas encore très bien compris les heuristiques d'import d'iTunes). Comme j'ai un peu galéré pour trouver une solution "automatique", je la mets ici.