SCJP, mékeskidit ?

La SCJP est une certification Java sous la forme de QCM, délivrée par Sun.  Elle permet d’attester que le certifié possède une connaissance détaillée du langage Java. On dit souvent qu’elle demande au développeur de fonctionner comme un compilateur Java.

Blah blah… certification, piège à *** ?

Dans notre beau métier, les certifications ont souvent peu de valeur. Elles permettent aux SSII de vendre des consultants “juniors experts certifiés” (cherchez l’oxymore ), et aux éditeurs de gagner de l’argent sans trop d’effort. Plus la certification est facile à obtenir, moins les candidats hésitent à la passer, et plus l’éditeur y gagne financièrement. Ce qui n’arrange pas la réputation des dites certifications.

La SCJP n’est pas facile

A l’inverse, la SCJP est difficile à obtenir, et demande une préparation spécifique. Je connais plusieurs personnes, pourtant très compétentes, qui  n’ont pas réussi cet examen. Vous pouvez avoir 5 ans d’expérience en développement Java et vous prendre une rouste.

Valeur intrinsèque de la SCJP

La valeur de la SCJP n’est ni dans les 3h d’examen, ni dans le bout de papier obtenu à la fin, mais bien dans le travail réalisé en amont. Ce travail permet de maitriser en détail les subtilités du langage Java, ainsi qu’un bon nombre d’API. Il y a de grandes chances que votre façon d’écrire du code Java change significativement entre avant et après la certification.

Cette certification n’est certainement pas assez reconnue sur le marché du travail. Soyons honnête, ce n’est pas en la passant que vous doublerez du jour au lendemain votre taux de facturation, ou que les chasseurs de tête vous tomberont dessus.

Cependant, c’est pour vous même que cela fera toute la différence. Il faut le voir comme un investissement personnel, payant à long terme : votre maitrise du langage vous rendra plus productif, plus sûr de votre code. Au jour le jour, cela amènera nécessairement une reconnaissance de vos pairs.

Non-Pub : les consultants Excilys sont certifiés SCJP

Permettez-moi une petite digression, non pas pour faire de la pub, mais plutôt pour souligner mon propos.

Le groupe Excilys recrute ses consultants en partie via des stages ingénieur de fin d’étude. Les stagiaires sont formés en interne, et le passage de la certification leur est offert. Dès lors, la réussite de la SCJP est un prérequis à l’embauche à la fin du stage.

Si ce mécanisme est en place, c’est qu’il a fait ses preuves : cela permet de s’assurer que les consultants ont une bonne maitrise du langage Java.

Préparer la SCJP

Les conseils suivants ne sont pas nécessairement LA seule façon de s’y prendre, mais si ça peut vous aider c’est cool.

Plus de 800 pages : toutes à lire sans exception (sauf au chapitre 5 )

• Lisez l’intégralité du bouquin de référence une première fois, en prenant le temps de comprendre. A la lecture, j’ai été souvent surpris, il y a de nombreuses subtilités Java qui sont inconnues des développeurs, surtout dans les premiers chapitres. Par la suite, relisez les chapitres sur lesquels vous ne vous sentez pas à l’aise.

Ayez toujours un NetClipse sous le coude

• En parallèle de la lecture du livre, faites des mises en pratique. Pour moi, cela voulait dire avoir toujours un Eclipse à portée de la main quand je lisais la SCJP. Le moindre doute, ou la moindre nouveauté, et hop un bout de code qui met le principe en œuvre.

Testez votre compréhension

• Répondez aux questions de fin de chapitre sérieusement, et notez vos résultats. C’est un bon moyen pour voir si vous avez bien lu et compris un chapitre. Si les réponses ne vous paraissent pas évidentes, il faut relire .

Trouvez des compagnons de galère

• Ne travaillez pas seul : émulation et challenge sont les meilleurs moyens de bien apprendre et de ne pas faire d’impasse. Trouvez-vous quelqu’un qui la prépare aussi, et partagez vos découvertes.

Fixez une deadline

• Prenez un voucher et réservez une date. La SCJP demande un travail sur la longueur, et il est facile de reporter en disant “je réserverai quand je serai prêt”. En fixant une date, vous paniquerez et vous vous forcerez à travailler .

“J’utilise des List tous les jours, je peux sauter le chapitre 7 !”

• Ne faites pas d’impasse sur les API. Connaître les signatures et les contrats des différentes méthodes d’un NavigableSet, c’est au moins aussi important que maîtriser la syntaxe du “goto” .

“J’ai masterisé JavaBlackBelt, je suis fin prêt !”

• JavaBlackBelt et consorts, c’est très bien, mais ce n’est pas la SCJP. Ce type de quiz est intéressant au départ, et il y a certainement des questions difficiles, mais on en a rapidement fait le tour. De plus, la forme n’a strictement rien à voir avec la SCJP, et bosser uniquement sur JavaBlackBelt est le meilleur moyen de se planter.

La dernière ligne droite

C’est probablement mon conseil le plus important : à l’approche de la deadline, passez des examens blancs avec ExamLab for SCJP. C’est gratuit, et c’est le meilleur outil pour s’entrainer. Ça ne tourne que sous Windows, ce qui n’est certainement pas une excuse pour faire l’impasse (débrouillez-vous, installez virtualbox).

ExamLab en résumé

• Une interface “aussi pourrie” que celle de la vraie SCJP (très important, pour ne pas être déstabilisé par la forme).
• Contient tous les types de questions présents dans la SCJP, y compris les “codes à trous”.
• Des examens de 3 heures sans interruption possible, fini les révisions en dilettantes à la “je répond à une petite question, je regarde la réponse, je prend un café”.
• Un concentré des questions les plus dures qu’on puisse trouver dans la SCJP. Le premier exam est en général une bonne claque.
• 5 examens, ce qui n’est pas énorme, c’est pourquoi il est préférable de les garder pour la “dernière ligne droite”. Ceci dit, vous pouvez toujours tenter le premier examen pour vous donner une idée du principe.

Je n’ai aucune action chez ExamLab (ce n’est même pas une entreprise ), mais c’est réellement le produit qui m’a fait le plus bosser et m’a permis de réussir ma SCJP.

L’examen

Le jour de l’examen, ne vous laissez pas déconcentrer, le temps passe vite. Je me suis retrouvé devant un écran CRT tout gros tout moche, une souris peu ragoutante, des reflets sur l’écran, un bonhomme à côté qui renifle… bref, il faut faire abstraction et garder à l’esprit qu’on est en exam.

Le temps imparti est largement supérieur à ce dont vous aurez besoin. Il y aura des questions où vous ne serez pas certain de la réponse, et en général y passer plus de temps ne sert à rien. Soit vous savez, soit vous faites un coup de poker .

Conclusion : qui aura le plus gros…

…score ?

Allez, histoire de mettre un peu de compétition et de motivation, balancez vos scores en commentaires . Et comme on n’est jamais si bien servi que par soi-même, je commence : 91% à la SCJP 6 .

Pour ceux d’entre vous qui aiment la difficulté, le blog d’Olivier Croisier fourmille de quiz plus tordus les uns que les autres. Pour approfondir vos connaissances, n’hésitez pas à lire également l’excellent Effective Java, de Josh Blosh.

Il ne me reste plus qu’à souhaiter bonne chance aux futurs candidats, et notamment aux motivés du groupe JDuchess .

Edit 24/08/2010 : Oracle vient visiblement d’annoncer que la SCJP serait désormais une OCJP. Le contenu ne change pas, celle-ci devrait donc garder la même valeur .

Bonus : le titre en chanson

D’où vient le titre de cet article ? D’une joyeuse chanson des inconditionnels du rap-musette :

Java c’est pas de la menthe à l’eau, Java c’est du rock’n roll !

Les auditeurs réguliers du Java Posse doivent aussi connaître la Java Song :

Java, Java, Java Java jing-jing-jing

It’s not a cup of coffee but it’s hot as can be

Came pourin’ through the Gates on a “Big Mac” Nealy

Singin’, Java, Java, Java Java jing-jing-jing

Défi : comprendre du code inélégant*

*Edit : j’avais initialement écrit “imb*table”, mais il paraît que ça ne fait pas très sérieux

Êtes-vous capable de comprendre ce que fait la méthode computeConvexHull() en moins de 3 minutes ?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
public List<GeoPoint> computeConvexHull(Set<GeoPoint> points) {



    // Path list

    ArrayList<GeoPoint> path = new ArrayList<GeoPoint>();



    // Pick the min longitude point as first

    GeoPoint first = null;

    for (GeoPoint point : points) {

        if (first == null || point.getLongitude() < first.getLongitude()) {

            first = point;

        }

    }



    if (first != null) {

        path.add(first);

    } else {

        throw new IllegalArgumentException("Can't retrieve the western point");

    }



    boolean right = true;

    boolean loop = true;



    while (loop) {



        GeoPoint current = path.get(path.size() - 1);



        GeoPoint next = null;

        double nextLatitudeDiff = 0;

        double nextLongitudeDiff = 0;

        boolean recordNext = false;

        for (GeoPoint point : points) {

            if (!point.equals(current)) {

                double latitudeDiff = point.getLatitude() - current.getLatitude();

                double longitudeDiff = point.getLongitude() - current.getLongitude();

                if (longitudeDiff == 0 || longitudeDiff > 0 == right) {

                    if (next == null) {

                        recordNext = true;

                    } else {

                        // Compare the 'a' in the linear equation Y = a.X

                        // that correspond to the line slope.

                        boolean negativeSlope = latitudeDiff * nextLongitudeDiff - nextLatitudeDiff * longitudeDiff < 0;



                        if (negativeSlope) {

                            recordNext = true;

                        }

                    }



                    if (recordNext) {

                        recordNext = false;

                        next = point;

                        nextLatitudeDiff = latitudeDiff;

                        nextLongitudeDiff = longitudeDiff;

                    }

                }

            }

        }



        if (next != null) {



            // Check abnormal case

            if (path.size() > points.size() + 1) {

                throw new RuntimeException("Convex hull computation failed");

            }



            path.add(next);



            /*

             * If we are not back to the first point, let's continue finding

             * the path.

             *

             * Otherwise, do nothing => going back from the stack, this is

             * actually the end point of the recursive algorithm.

             */



            if (path.get(0) == next) {

                loop = false;

            }



        } else {

            // We have reached the point on the right, let's go back!

            right = !right;

        }

    }



    return path;

}

Alors ? Checkstyle lui donne une complexité cyclomatique de 16. Plutôt difficile d’y voir clair. Moi en tout cas, je n’en suis pas capable.
Et pourtant, j’en suis l’auteur . Critique de code bien ordonnée commence par soi-même !

Le développeur, lecteur à temps plein

On entend souvent dire que produire un code de qualité, c’est un coût à court terme et un gain à long terme. C’est faux.

En tant que développeur, je passe l’essentiel de mon temps à lire du code, et proportionnellement peu à en écrire. En effet, avant chaque modification, je parcours le code pour en comprendre les tenants et les aboutissants, et décider des modifications que je vais réaliser.

Étudiez la manière dont vous développez, vous verrez c’est édifiant .

Puisqu’un développeur passe l’essentiel de son temps à lire du code, le meilleur moyen de gagner en productivité, c’est avoir un code qui soit facile à comprendre.

Améliorer la qualité du code, c’est un gain immédiat, un point c’est tout.

Pas de refactoring sans tests

Il est impossible de produire un code de qualité dès le départ. Ne vous morfondez pas, ce n’est pas grave.

Pour améliorer le code, rien de tel que le refactoring, qui consiste à transformer le code sans en modifier le fonctionnement extérieur. Des tests unitaires sont alors nécessaires, car ils permettent d’exprimer le comportement du code et de garantir qu’il n’a pas varié. Les tests doivent être écrits avant tout refactoring.

En fait, idéalement, vous faites du TDD et votre code est déjà testé. Il n’est cependant pas rare de rejoindre une équipe où personne n’a “eu le temps” d’en écrire un seul.

Mais revenons à notre code incompréhensible…

Enveloppe convexe, mékeskidit ?

Comme son nom l’indique , la méthode computeConvexHull() permet de calculer l’enveloppe convexe (l’emballage) d’un ensemble de points géolocalisés.

Enveloppe convexe

Le principe de l’algorithme est de partir du point le plus à l’ouest, trouver le chemin de l’enveloppe dans le sens anti-horaire jusqu’au point le plus à l’est, puis faire de même dans l’autre sens.

Toutefois, nous ne connaissons toujours pas précisément son fonctionnement.

Des tests pour comprendre et exprimer ce que fait le code

Afin d’y parvenir, je vous propose d’écrire des tests. C’est un bon moyen pour comprendre et documenter le fonctionnement du code, et contrairement aux commentaires, les tests évoluent au même rythme que le code.

Pour ne pas alourdir l’article, je vous laisse consulter les tests en question.

Quand cesser d’écrire des tests ? Quand vous êtes certains d’avoir couvert tous les comportements possibles du code. Vous pouvez par exemple utiliser EclEmma pour obtenir le pourcentage de couverture des classes que vous testez. 100% est un minimum, cela ne garantit pas que vous n’avez rien oublié.

Écrire des tests, c’est aussi découvrir des bugs

Ceux d’entre vous qui ont lu les tests se sont certainement exclamé : “Hey, c’est de la triche, il y a des tests en commentaire !”.

Il s’avère qu’en tentant d’exprimer le comportement que j’attendais de ce code à travers mes tests unitaires, j’ai rencontré des bugs.

J’ai donc écris du code mettant en évidence ces comportements inattendus :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
@Test(expected = TimeoutException.class)

public void onePointSetLoopEndlessly() throws Exception {

    final Set<GeoPoint> points = new HashSet<GeoPoint>();

    points.add(new GeoPoint(10, 10));



    timeoutAfterDelay(300, new Runnable() {

        public void run() {

            hullHelper.computeConvexHull(points);

        }

    });

    Assert.fail("One point set should loop endlessly (timeout from tests after 300 ms)");

}

private void timeoutAfterDelay(int delayInMs, Runnable codeToRun) throws TimeoutException, InterruptedException,

        ExecutionException {

    ExecutorService executor = Executors.newCachedThreadPool();

    FutureTask<?> future = new FutureTask<Object>(codeToRun, null);

    executor.submit(future);

    future.get(delayInMs, TimeUnit.MILLISECONDS);

}



@Test(expected = RuntimeException.class)

public void computationFail() {

    Set<GeoPoint> points = new HashSet<GeoPoint>();



    GeoPoint northWest = new GeoPoint(10, 5);

    GeoPoint southWest = new GeoPoint(0, 0);

    GeoPoint southEast = new GeoPoint(5, 10);

    GeoPoint northEast = new GeoPoint(15, 10);



    points.add(northWest);

    points.add(southWest);

    points.add(southEast);

    points.add(northEast);



    hullHelper.computeConvexHull(points);

    Assert.fail("Should fail when there are two eastern points with same longitude");

}



@Test(expected = NullPointerException.class)

public void pointsNullThrowsNullPointerException() {

    hullHelper.computeConvexHull(null);

    Assert.fail("Null set should throw a NullPointerException");

}

Avant de refactorer, il faut corriger les bugs :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Tout d'abord, en vérifiant les paramètres d'entrée.

public List<GeoPoint> computeConvexHull(Set<GeoPoint> points) {

    if (points == null) {

        throw new IllegalArgumentException();

    }

    if (points.size() == 1) {

        return new ArrayList<GeoPoint>(points);

    }

// [...]



// Par ailleurs, il s'avère que ce if n'était pas assez complexe...

if (longitudeDiff == 0 || longitudeDiff > 0 == right)



// Il devient :

if (longitudeDiff == 0 && latitudeDiff < 0 == right || longitudeDiff > 0 == right)

// Beaucoup plus clair, isn't it ?

Je vous laisse parcourir la version corrigée. De même pour les tests unitaires, qui désormais passent tous.

Refactoring : principe

Un refactoring en bonne et due forme, c’est une suite de petites modifications avec exécution des tests entre chaque modification, pour s’assurer que l’on ne change pas le comportement.

Pour réaliser ce refactoring, j’ai mis en œuvre les principes suivants :

• Choisir des noms descriptifs pour les classes, méthodes et variables.
• Minimiser le nombre d’arguments des méthodes, maximum 3 arguments. Si une méthode utilise les attributs d’un objet passé en paramètre, elle doit devenir une méthode d’instance sur cet objet. Lorsque des méthodes d’une même classe se passent le même argument les unes après les autres, il faut transformer cet argument en variable d’instance.
• Pas d’arguments de sortie : les méthodes ne modifient pas l’état des arguments qui leurs sont fournis.
• Pas de redondance : s’il y a de la redondance, il y a probablement une opportunité d’abstraction manquée.
• Séparation verticale : les variables et les fonctions sont définies au plus près de leur utilisation. Les méthodes utilisées par une méthode du niveau d’abstraction supérieur doivent être placées immédiatement en dessous de celle-ci.
• Variables explicatives : passer par des variables intermédiaires avec des noms explicites, plutôt qu’écrire des méthodes d’une seule ligne.
• Limiter le nombre de switch.
• Chaque méthode fait une seule chose, il est préférable d’écrire de nombreuses méthodes de quelques lignes avec des noms significatifs.

Voici comment j’ai procédé :

• J’ai tout d’abord décomposé le code en plusieurs méthodes isolant les différentes étapes de l’algorithme.
• Puis j’ai supprimé les arguments de sortie.
• J’ai ensuite créé des classes encapsulant les différents traitements.
• Et ainsi de suite :  j’ai transformé le code par itérations successives, en appliquant chacun des principes listés précédemment. Il ne faut pas tout faire d’un coup, mieux vaut réaliser une petite modification, exécuter les tests, commiter, et continuer.
• Au fur et à mesure des transformations, je n’ai pas hésité à créer de nouvelles classes. Cela a temporairement augmenté la base de code, mais il s’avère qu’une fois les responsabilités bien séparées, de nombreuses simplifications apparaissent.

Pour finir, j’ai réalisé une dernière transformation qui ne plaira pas forcément à tout le monde : créer des classes d’algorithme stateful, qui travaillent sur des variables d’instance plutôt que sur des paramètres.

Cela permet de limiter grandement le nombre de paramètre, et le code devient alors une succession d’appels de méthode. Il faut donc soigneusement choisir les noms de méthodes, et limiter au maximum la taille des classes afin de ne pas perdre le fil. De plus, par nature ces classes ne sont pas threadsafe.

Le refactoring n’est donc pas un “ravalement de façade”, mais bien une succession de transformations qu’on ne peut prévoir d’avance. Je n’avais pas la moindre idée du résultat auquel je souhaitai arriver quand j’ai commencé à réaliser ces modifications.

Enfin, il est important de se limiter dans le temps, car il est difficile de définir des objectifs mesurables pour un refactoring.

Refactoring : résultat

La méthode computeConvexHull() est désormais bien allégée :

1
2
3
4
5
6
7
8
9
10
11
public List<GeoPoint> computeConvexHull(Set<GeoPoint> points) {

    GeoPointSet geoPointSet = new GeoPointSet(points);



    geoPointSet.checkPreconditions();

    if (geoPointSet.hasOnePoint()) {

        return geoPointSet.copyAsList();

    } else {

        HullFinder hullFinder = new HullFinder(geoPointSet);

        return hullFinder.findAntiClockwiseHull();

    }

}

L’algorithme est compréhensible à travers quelques méthodes clés. Tout d’abord, dans la classe HullFinder :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
public List<GeoPoint> findAntiClockwiseHull() {

    findBounds();

    findEastPath();

    findWestPath();

    return assembleHull();

}



private void findBounds() {

    Bounds bounds = geoPointSet.findBounds();

    westernPoint = bounds.getWesternPoint();

    easternPoint = bounds.getEasternPoint();

}



private void findEastPath() {

    eastPath = eastPathFinder.findPath(westernPoint, easternPoint);

}



private void findWestPath() {

    westPath = westPathFinder.findPath(easternPoint, westernPoint);

}



private List<GeoPoint> assembleHull() {

    List<GeoPoint> hull = new ArrayList<GeoPoint>;

    hull.addAll(eastPath);

    hull.addAll(westPath);

    hull.add(westernPoint);

    return hull;

}

Et pour finir, dans la classe PathFinder :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
public List<GeoPoint> findPath(GeoPoint startPoint, GeoPoint endPoint) {

    initPath(startPoint);

    initLastFound(startPoint);

    findNextPoint();



    while (!endReached(endPoint)) {

        addBestCandidateToPath();

        findNextPoint();

    }



    return path;

}



private void findNextPoint() {

    PositionDelta bestDelta = null;

    GeoPoint bestPoint = null;

    for (GeoPoint point : geoPointSet) {

        PositionDelta delta = buildDelta(lastFoundPoint, point);

        if (delta.isBetterCandidate(bestDelta)) {

            bestPoint = point;

            bestDelta = delta;

        }

    }

    lastFoundPoint = bestPoint;

}



private void addBestCandidateToPath() {

    path.add(lastFoundPoint);

}

Pour consulter l’intégralité du code, il faut aller lire les sources .

Remarquez l’absence de commentaires. Les noms de méthodes et de variables permettent d’exprimer ce que fait le code.

Le plus souvent, les commentaires au sein du code sont une erreur. Ils n’évoluent jamais à la même vitesse que le code.

Quand vous lisez un code complexe, plutôt que d’y insérer des commentaires qui expriment ce qu’il fait (et donc dupliquer l’information), il est préférable de le modifier pour rendre son fonctionnement explicite.

Par ailleurs, cet algorithme n’est certainement pas la meilleure manière de calculer une enveloppe convexe. J’ai souhaité en conserver le principe général plutôt que de changer d’implémentation, pour que l’exemple garde tout son sens. Si vous avez mieux, lâchez vos coms !

Conclusion

À travers cette mise en pratique, j’espère vous avoir donné un aperçu des différents mécanismes à mettre en œuvre au cours d’un refactoring.

C’est loin d’être facile, et cela demande du courage. Il est bien plus aisé de laisser le code se délabrer.

Quand un collaborateur vous balance “touche pas, ça marche“, le code est probablement pourri. Mais ce n’est pas parce que c’est un projet poubelle qu’il ne faut rien faire, au contraire ! Pensez juste à prendre des radiographies du patient .

Je me suis largement inspiré de Clean Code pour écrire cet article. Ce livre a remis en question mes habitudes de développement, j’ai pris une claque. À mettre entre toutes les mains !

Comme une grande partie des lecteurs de ce blog, vous avez certainement déjà travaillé sur des applications web Java EE de taille variable, sur lesquelles vous avez fait un nombre indécent de redéploiements à chaque fois que vous vouliez valider des modifications fraîchement apportées. Puis vous avez dû découvrir que depuis Java 1.4, la JVM permet de faire du Hotswap en mode debug, c’est-à-dire de remplacer du code à la volée au runtime.

C’est bien, mais il y a quand même des limitations : on ne peut que modifier le corps d’une méthode déjà existante, si l’on ajoute une méthode ou une classe elle ne sera pas prise en compte. Idem pour les membres statiques, les annotation ou encore les fichiers properties accédés via un ResourceBundle.

C’est pour pallier ces manques que la société Estonienne ZeroTurnaround a développé JRebel, un outil destiné aux développeurs désirant gagner du temps dans leur cycle de développement.

JRebel, c’est quoi ?

Comme l’explique en anglais un article du blog de ZeroTurnaround, JRebel est principalement un agent à installer dans votre serveur d’applications, qui va réagir à des mises à jour de classes, ou plus généralement de ressources composant votre application. À l’aide d’un fichier de configuration rebel.xml, vous allez spécifier une liste de ressources à surveiller, par exemple des répertoires contenant des JAR et des fichiers properties. Lors du déploiement de votre application, l’agent va utiliser cette configuration pour scruter des changements dans ces répertoires (un timestamp plus récent).

Pour appliquer ces changements, JRebel introduit un classloader qui va se charger de détecter le chargement des classes, pour ensuite générer des classes anonymes grâce la génération de bytecode on-the-fly. À chaque modification d’une classe dans votre IDE, une nouvelle classe anonyme sera générée pour modifier le comportement de la classe originale, grâce à un savant mélange de JIT et de magie noire (l’article ne rentre pas trop dans les détails du fonctionnement interne, secret de fabrication oblige puisque c’est un outil commercial).

Fonctionnement de l'agent (image issue du site de ZeroTurnaround)

Au final, la perte de performances est minimisée comparé au gain de temps entrainé par le fait que l’on ne soit pas obligé de redéployer toutes les 5 minutes. Que vous utilisiez des JAR, des WAR, du Spring, Struts, Wicket ou autre Hibernate, sur des serveurs Glassfish, Websphere, JBoss, ou encore Weblogic, il y a de fortes chances que JRebel le supporte de base ou via des plugins. Et si votre framework favori n’est pas dans la liste, une API vous permet de développer votre propre plugin.

Mise en pratique

Cas simple : modification d’une méthode

Nous allons maintenant tester JRebel sur une application web type HelloWorld. Comme je l’ai déjà dit plus haut, c’est un outil commercial mais une version d’évaluation de 30 jours est disponible sur le site. L’installation est très bien expliquée par un wizard prenant en compte votre IDE et votre serveur, donc je ne m’attarderai pas sur le sujet.

J’ai choisi d’utiliser Netbeans et Glassfish pour déployer une application toute simple : une calculatrice. Je dispose d’une servlet nommée Calculator, chargée de faire des additions et des soustractions :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public class Calculator extends HttpServlet {



    protected void processRequest(HttpServletRequest request, HttpServletResponse response)

    throws ServletException, IOException {

        response.setContentType("text/html;charset=UTF-8");



        String operation = request.getParameter("operation");

        Integer result = null;



        if (operation != null && request.getParameter("a") != null && request.getParameter("b") != null) {

            Integer a = Integer.valueOf(request.getParameter("a"));

            Integer b = Integer.valueOf(request.getParameter("b"));



            if (operation.equals("add")) {

                result = a + b;

            } else if (operation.equals("sub")) {

                result = a - b;

            }

        } else {

            throw new IllegalArgumentException("Don't fool me, use correct parameters: a, b and operation!!");

        }



        PrintWriter out = response.getWriter();



        try {

            out.println("The result is " + ((result == null) ? "unpredictable" : result));

        } finally {

            out.close();

        }

    }

Attention, Netbeans est malin et par défaut fait du deploy-on-save. Il faut donc désactiver l’option dans les propriétés du projet pour ne pas interférer avec JRebel.

La configuration du fichier rebel.xml, à placer dans WEB-INF/classes/, va ressembler à ceci :

1
2
3
4
5
6
7
8
9
<?xml version="1.0" encoding="UTF-8"?>

<application

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xmlns="http://www.zeroturnaround.com"

  xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">

    <classpath>

        <dir name="D:\NetBeansProjects\WebApplication1\build\web\WEB-INF\classes"/>

    </classpath>

</application>

On demande donc de prendre à chaud tout ce qui va changer dans le répertoire où sont placées les classes compilées.

Dans les logs du démarrage de glassfish, on peut ainsi voir :

Procédons à une modification mineure du corps de la méthode processRequest() :

1
2
// On a changé le message affiché

out.println("Congratulations, the result is " + ((result == null) ? "unpredictable" : result));

Après compilation du fichier et rafraîchissement de la page dans le navigateur, on obtient immédiatement le changement :

Modification à chaud du corps d'une méthode

Dans le cas présent, JRebel a fait l’équivalent du hotswapping standard de la JVM, mais sans avoir besoin d’être en mode debug.

Un cran au-dessus : ajout de méthodes / classes

Amusons-nous maintenant dans le domaine de l’inédit. Pour satisfaire notre envie de separation of concerns, on va externaliser le code métier dans une classe différente de la servlet :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Calc {



    public static Integer add(Integer a, Integer b) {

        return a + b;

    }



    public static Integer substract(Integer a, Integer b) {

        return a - b + 2;

    }

}



// et dans la servlet :

if (operation.equals("add")) {

    result = Calc.add(a, b);

} else if (operation.equals("sub")) {

    result = Calc.substract(a, b);

}

On enregistre, on compile et on vérifie : la nouvelle classe (et indirectement de nouvelles méthodes) a été prise en compte automatiquement (pour en être sûr, on peut bidouiller l’addition pour qu’elle calcule a + b + 1 par exemple).

Et les ressources ?

Pour l’instant nous nous sommes contentés de modifier du code Java. Et si on essayait des fichiers properties ? Ca tombe bien, notre client vient justement de nous faire part de son vœu de pouvoir internationaliser le nom des opérations add et sub !

On va donc utiliser un ResourceBundle :

1
2
3
4
5
if (operation.equals(ResourceBundle.getBundle("operations").getString("add"))) {

    result = Calc.add(a, b);

} else if (operation.equals(ResourceBundle.getBundle("operations").getString("sub"))) {

    result = Calc.substract(a, b);

}

On compile, on rafraîchit et là… c’est le drame !

1
2
3
4
5
6
7
8
9
10
11
WARNING: StandardWrapperValve[Calculator]: PWC1406: Servlet.service() for servlet Calculator threw exception

java.util.MissingResourceException: Can't find bundle for base name operations, locale en_GB

        at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1521)

        at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1260)

        at java.util.ResourceBundle.getBundle(ResourceBundle.java:715)

        at com.excilys.blog.jrebel.servlet.Calculator$$M$6334694c.processRequest(Calculator.java:38)

        at com.excilys.blog.jrebel.servlet.Calculator$$A$6334694c.processRequest()<generated>

        at com.excilys.blog.jrebel.servlet.Calculator.processRequest(Calculator.java:51)

        at com.excilys.blog.jrebel.servlet.Calculator$$M$6334694c.doGet(Calculator.java:65)

        at com.excilys.blog.jrebel.servlet.Calculator$$A$6334694c.doGet()<generated>

        at com.excilys.blog.jrebel.servlet.Calculator.doGet(Calculator.java:65)

Et oui, les ressources sont cherchées dans le répertoire build\web\WEB-INF\classes\operations.properties, hors comme on ne fait pas de build complet le fichier properties qu’on vient de créer ne s’y trouve pas encore . Pas de souci, on le copie à la main (ou on fait un build complet, mais c’est plus long), et là ça marche ! Remarquez au passage que les classes mentionnées dans la stacktrace ont des noms un peu bizarres, certaines sont marquées <generated> : cela correspond à ce que j’ai expliqué plus haut au sujet du fonctionnement interne de JRebel.

Zut, le client vient de décider qu’à présent, on aura des noms d’opérations en français. Pas de souci, on a juste à changer notre properties (celui dans le dossier build/, sauf si vous décidez de monitorer également la version dans src/), et les changements sont pris à chaud :

Encore une killer-feature : le plugin Spring

Comme évoqué dans les principes de fonctionnement, JRebel supporte entre autres les changements à chaud de configuration du framework Spring grâce à un plugin dédié. Voyons un peu comment ça fonctionne. Après avoir supprimé le static des méthodes de la classe Calc, j’ai décidé d’en faire un bean Spring :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"



       xsi:schemaLocation="http://www.springframework.org/schema/beans

                                   http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">



    <bean id="calc" class="com.excilys.blog.jrebel.Calc" />



    <bean class="org.springframework.web.context.support.ServletContextAttributeExporter">

        <property name="attributes">

            <map>

                <entry key="calcBean">

                    <ref bean="calc"/>

                </entry>

            </map>

        </property>

    </bean>

</beans>

Ce bean est ensuite récupéré dans la servlet de la manière suivante :

Je vous passe la configuration du web.xml, elle est tout à fait standard. Cependant JRebel ne permet pas de prendre à chaud les changements dans web.xml, on va donc être obligés de redéployer notre application (mais on le fera plus après, promis ). Redéploiement et rafraîchissement de la page web, ouf, tout fonctionne normalement.

Pour tester le plugin Spring, on va introduire une modification mineure : renommer l’attribut du contexte permettant de récupérer bean.

Compilation, rafraîchissement (en ces temps de fortes chaleurs…), applaudissements. On vient de bénéficier d’une modification de la configuration de Spring sans avoir à redéployer !

Conclusion

Résumons un peu. Avec un seul déploiement (parce que je m’y suis pris trop tard, avouons-le), on a réussi à prendre en compte immédiatement des modifications de méthodes, des ajouts des classes, des modifications des fichiers properties accédés par un ResourceBundle et surtout des fichiers de configuration de framework (Spring dans cet exemple). Ça en jette, non ? Tout ça pour pas un rond si vos développement durent moins de 30 jours, sinon il faudra débourser une somme relativement modeste (189$ pour une licence annuelle standard).

Le Rebelle aussi utilise JRebel.

Petit plus pour les décideurs, à chaque démarrage du serveur, JRebel affiche des estimations sur le précieux temps qu’il vous a fait gagner, de manière à mesurer les gains qu’apportent de tels outils :

Pour aller plus loin

• Site de JRebel
• JRebel ou comment accélérer le développement
• Java Posse #306 – JRebel Interview
• Youpi ! Ca marche aussi avec Maven
• Enfin une bonne raison de se mettre à Scala

Comme beaucoup de lecteurs de ce blog, j’utilise un IDE au quotidien. Sur mon projet actuel, c’est Eclipse combiné à un serveur Websphere. Pour des raisons pratiques, je fais un tail -f des logs du serveur dans la console d’Eclipse, et qui dit serveur d’applications Java + logs en niveau DEBUG dit énormément d’informations à scanner pour trouver ce qui m’intéresse réellement (quelques Mo de logs par jour !).

Colore tes logs !

La solution que j’ai retenue pour facilement m’y retrouver, c’est Grep Console. Ce plugin pour Eclipse permet de colorier dans une console certaines parties de texte qui matchent une ou plusieurs expressions régulières. Par exemple, les WARN en orange et les ERROR en blanc sur fond rouge.

Les boites de dialogues ultra-simples de configuration de Grep Console

On voit dans la fenêtre de gauche toutes les expressions régulières que j’ai choisies de matcher et dans celle de droite la configuration de l’une d’entre elles : définition de la regexp, choix des couleurs d’arrière-plan ou d’avant-plan pour la ligne entière ou pour les groupes capturés par des parenthèses (cependant on ne peut pas imbriquer les parenthèses).

Voici le résultat dans la console d’Eclipse :

Conclusion

Simple mais efficace, je vous conseille vivement d’installer ce plugin qui permet de gagner du temps si vous avez des logs sous les yeux à longueur de journée ! Rendez-vous sur l’update site http://eclipse.musgit.com. Seul bémol, je n’ai pas encore trouvé d’astuce pour colorier d’anciens logs dans d’autres fichiers (une sorte de less coloré). Si vous avez un outil qui fait ce genre de choses, je suis preneur .

]]> http://blog.excilys.com/2010/06/30/illuminez-vos-logs-dans-eclipse/feed/ 2 http://blog.excilys.com/2010/06/30/illuminez-vos-logs-dans-eclipse/ http://feedproxy.google.com/~r/blogexcilyscom/~3/aw_n_vwndYM/ http://blog.excilys.com/2010/06/25/de-switcher-nest-pas-jouer/#comments Thu, 24 Jun 2010 22:20:38 +0000 Pierre-Yves RICAU http://blog.excilys.com/?p=2375 Amis utilisateurs de Checkstyle, avez-vous remarqué que les switch sont des sources inépuisables de complexité cyclomatique ? Sans parler de leur équivalent pour les objets, les if () {} else if (){} else if (){} else if (){} à répétition.

Parmi les reproches récurrents faits aux switch, il y a le fait qu’ils ne respectent pas le principe Ouvert/Fermé. A chaque ajout de nouvelles valeurs, il faut modifier tous les switch qui les manipulent.

Il est toujours possible de se passer d’un switch. Un moyen simple est d’utiliser une Map. Ainsi, le code suivant :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public String getMessage(int messageCode) {

    String message;

    switch (messageCode) {

        case 42:

            message = "the Answer to the Ultimate Question of Life, the Universe, and Everything.";

            break;

        case 13:

            message = "Good luck!";

            break;

        // [...]

        default:

            throw new IllegalArgumentException("Unknown code");

    }

    return message;

}

devient :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
private final Map<Integer, String>  messagesByCode = new HashMap<Integer, String>();



private void initMessagesByCode() {

    messagesByCode.put(42, "the Answer to the Ultimate Question of Life, the Universe, and Everything.");

    messagesByCode.put(13, "Good luck!");

    // [...]

}



public String getMessage(int messageCode) {

    String message = messagesByCode.get(messageCode);



    if (message == null) {

        throw new IllegalArgumentException("Unknown code");

    }



    return message;

}

Cela fonctionne aussi si le switch (ou les if/else) contient du code à exécuter qui varie suivant les cas. Ainsi :

1
2
3
4
5
6
7
8
9
10
11
12
public void doAction(String action) {

    if ("syso".equals(action)) {

        System.out.println("Yeah");

    } else if ("syserr".equals(action)) {

        System.err.println("Yahoo");

    } // [...]

    else {

        throw new IllegalArgumentException("Unknown action");

    }

}

// [...]

doAction("syso");

devient (j’en conviens, des first-class functions simplifieraient le code) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
private final Map<String, Runnable> actionsByName = new HashMap<String, Runnable>();



private void initActionsByName() {

    actionsByName.put("syso", new Runnable() {

        public void run() {

            System.out.println("Yeah");

        }

    });

    actionsByName.put("syserr", new Runnable() {

        public void run() {

            System.err.println("Yahoo");

        }

    });

}



public void doAction(String action) {

    Runnable runnable = actionsByName.get(action);



    if (runnable == null) {

        throw new IllegalArgumentException("Unknown action");

    }



    runnable.run();

}

// [...]

doAction("syso");

Clairement, si ce type de modification permet de se passer de switch sans modifier la signature des méthodes, elle n’est pas idéale. Une bien meilleure option ici serait de se souvenir que Java est un langage orienté Objet, et utiliser le polymorphisme pour implémenter le pattern strategy :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public interface Action {

    void doAction();

}

// [...]

public void doAction(Action action) {

    action.doAction();

}

// [...]

public class Syso implements Action {

    public void doAction() {

        System.out.println("Yeah");

    }

}

// [...]

public class Syserr implements Action {

    public void doAction() {

        System.err.println("Yahoo");

    }

}

// [...]

doAction(new Syso());

On pourrait enfin utiliser les possibilités offertes par les enum Java :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public enum ActionEnum implements Action {

    SYSO {

        public void doAction() {

            System.out.println("Yeah");

        }

    },

    SYSERR {

        public void doAction() {

            System.err.println("Yahoo");

        }

    };

}

// [...]

doAction(ActionEnum.SYSO);

J’espère que ce court article vous aura convaincu qu’il est tout à fait possible de se passer des switch. Un code comprenant des switch et autres if () {} else if (){} est en général tout sauf simple et maintenable.
Dans Clean Code, Uncle Bob Martin conseille d’ailleurs d’encapsuler le code lié aux switch dans des fabriques abstraites, afin de ne pas les laisser polluer le reste du code.

Edit (03/08/2010) : dans le même domaine, vous pouvez lire cet article sur le Refactoring par la pratique.

Pouvez-vous me faire un rapport sur tous les ajouts et les modifications qui ont été faits sur la table des factures en production depuis 5 ans ?

Hibernate a vraiment pensé à tout, aujourd’hui nous allons parler de l’interface Interceptor et de son utilisation dans le but de faciliter l’audit du système d’information (ici la base de données).

L’interceptor hibernate

Cette interface fournit des méthodes qui interceptent différents événements de la session comme la suppression, l’ajout ou la modification de données.

Vous pouvez implémenter Interceptor directement, ou mieux : étendre EmptyInterceptor et n’en surcharger que les méthodes qui vous intéressent. Voici un exemple :

Attention cependant, auditer les insertions et les mises à jour peut ralentir votre application !

Pour rendre effective l’utilisation par Hibernate de votre Interceptor, passez-le en paramètre lors de la création de la session (sf correspond à la SessionFactory) :

Interceptors versus Triggers

Pour se rappeler de ce qu’est un Trigger SGBD, lire cet article !

Les triggers

Les Interceptors

Conclusion

Voilà, encore une façon supplémentaire de tracer ce que font vos utilisateurs. N’oubliez pas que les erreurs sont plus faciles à mettre sur le dos d’un autre quand il existe des preuves qui vont dans votre sens .

Pouvez-vous me faire un rapport sur tous les ajouts et les modifications qui ont été faits sur la table des factures en production depuis 5 ans ?

Mais bien sûr je n’ai qu’à faire haut haut bas bas gauche droite gauche droite b a, et le tour est joué ! Et en plus, je vous ai fait un café !

Bravo, j’ai pu démasquer des centaines de fraudes grâce à vous ! Vous êtes trop puissant Black Dynamite !

Cuz there aint no hope for dudes who deal dope!

* référence à Marina Orlova, qui m’a appris que l’etymologie pouvait être sexy.

Dans cet article, je vous propose quelque chose d’assez différent des sujets abordés habituellement. En lisant du code écrit par d’autres développeurs, je suis resté perplexe sur quelques méthodes. Après les avoir relues quelques fois, la façon d’écrire m’a fait sourire, comme quoi d’un développeur à l’autre les méthodes de réflexion et d’écriture de code varient fortement.

Je vous propose donc quelques extraits de code méritant le détour, ça donne des snippets assez drôles, cherchez l’erreur !

Continue comme ça

1
2
3
4
5
6
7
for (Object i : list) {

  if (condition) {

    doSomeStuff(someArguments);

    continue;

  }

  doSomeStuff(someOtherArguments);

}

continue, what else? (ce jeu de mots est © Pierre-Yves Ricau)

Tu peux pas test

Contexte : imaginez une méthode initialize(java.util.Properties) qui s’attend à la présence d’une propriété MY_PROPERTY pour l’utiliser lors de l’initialisation d’un objet :

1
2
3
4
5
public void initialize(Properties props) {

  if (props.getProperty(MY_PROPERTY)) {

    // ici on utilise cette propriété...

  }

}

Le test unitaire est tout naturellement :

1
2
3
4
5
6
  public void testNullProperty(){

    Properties properties = new Properties();

    assertNotNull(properties);

    assertNull("property must be null", properties.getProperty(MY_PROPERTY));

    myClassInstance.initialize(properties);

  }

Pour résumer, on teste si une instance fraichement créée est non-nulle, tout en vérifiant qu’elle ne contient pas encore la propriété… Quant à la méthode initialize() qui est censée faire l’objet du test, certes on l’appelle mais on ne fait aucune vérification dessus. Bon, après tout le test passe, c’est le principal non ?
Ce test n’est d’ailleurs pas isolé, plusieurs autres tests vérifient de la même façon la non-présence dans properties d’autres propriétés utilisées dans initialize() .

Double fail inversé

1
myVar = (myMap != null) ? "" : myMap.get(myField);

Non seulement on n’a pas la valeur attendue, mais en plus on aura forcément une NullPointerException si myMap vaut null .

True or false?

1
2
3
4
5
public boolean superComplexLogic(boolean value) {

    boolean ret= false;

    if((getValue2() && value) || (!getValue2() && !value)) ret=true;

    return ret;

}

Pourquoi faire simple ? Un return (getValue2() == value); aurait été tellement banal !

TODO != Tout doux

1
2
3
4
// TODO en lot 8

if ("TODO".equals("TODO1")) {

  // ...

}

Sympathique cette façon d’éviter que du code soit executé, non ?

100% de couverture de tests !

1
2
3
4
5
6
7
8
9
10
public enum MyEnum {

    MY_CONSTANT("O"),

    //...

}



// Et le test associé :

@Test

public void testMyConstant() {

    assertEquals("O", MyEnum.MY_CONSTANT);

}

Au moins, si on fait une faute de frappe en écrivant l’enum, ce test le verra tout de suite

L’opération a échoué avec succès !

1
2
//succes - Recuperer la liste à réemettre.

logger.logError(ServiceLogKeys.SUCCESS_CODE);

Conclusion

J’espère que ce petit moment de détente vous a plus, si c’est le cas nous allons essayer de motiver les troupes d’Excilys pour publier des articles collaboratifs de ce genre de temps en temps. Si vous avez aussi des exemples de LOLcode, n’hésitez pas à vous lacher dans les comms (attention aux clauses de non divulgation tout de même) .

Par ordre chronologique :

• février 2010 : version 6 de Liferay Portal en approche
• avril 2010 : Liferay Portal fête ses 10 ans
• mai 2010 : sortie théorique de Liferay IDE 1.0

Liferay pour la vie

Liferay Portal 6 annoncé

En février dernier, Paul Hinz a dévoilé l’information que la prochaine version serait numérotée 6 et non pas 5.3 comme nous avions pu le penser. En effet, depuis quelques temps déjà, Liferay Portal 5.2 (plus précisément 5.2.3) est la dernière version officielle. La numérotation en 5.3 était par exemple utilisée dans le Jira de Liferay pour désigner la version suivante corrigeant une anomalie. Depuis la numérotation dans Jira a bien sûr été corrigée . Ce choix vient du fait qu’après avoir revu l’ensemble des fonctionnalités et améliorations futures prévues dans la stratégie de développement du portail, il a été décidé que la release suivante profiterait d’un changement de numéro de version majeur.

Cette version avait pour nom de code Bunyan en interne et sera donc officiellement Liferay Portal 6.

L’annonce officielle postée sur le blog de Liferay mentionnait les éléments suivants comme étant majeurs et à surveiller :

Parmi ces éléments, on peut noter l’amélioration de l’intégration des workflows et pour ce faire nous devrions bénéficier du support de jBPM. Concernant la bibliothèque de documents, celle-ci devrait pouvoir s’intégrer avec Documentum, CMIS et Sharepoint par exemple.

Liferay Portal 6 va se baser sur des technologies JEE courantes et chercher à ajouter ou simplement améliorer leur prise en charge, au cœur du portail ou/et pour l’ouvrir aux systèmes externes :

• JPA et JMX seront intégrés, OAuth sera amélioré, le support de Maven devrait être presque natif
• les plugins pourront exposer des web services en JSON et SOAP
• intégration avec OpenOffice, Google Apps, Jasper, BIRT
• possibilité de changer de moteur de BPM (utiliser Intalio à la place de jBPM par exemple)
• intégration avec NetVibes, OpenSocial, SEO, CalDAV, SalesForce, Vaadin
• formulaires et listes dynamiques
• gestionnaires de tâches et de contacts

Premiers retours sur Liferay Portal 6 preview / RC

Dans un premier temps, cette version 6 n’a été mise à disposition que par l’intermédiaire d’une preview. Le site officiel n’en faisait pas mention, mais SouceForge et les Nightly Builds commençaient à diffuser ces premières ébauches à tester.

Deux mois plus tard, en avril, c’est au tour de la Release Candidate d’avoir été officialisée. Elle incluait de nombreux correctifs et la plupart des portlets finales qui manquaient dans la preview, dont la traditionnelle application de démarrage 7Cogs.

Depuis la sortie de la version RC de Liferay Portal 6, la page de téléchargement habituelle prépare les utilisateurs au changement à venir. En effet, vous pouvez toujours choisir de récupérer un bundle basé sur Liferay Portal 5.2.3 CE, mais vous pouvez également vous essayer à la RC. Une liste déroulante proposant les bundles mis à jour pointe ainsi sur la dernière version officielle de Liferay Portal 6.

La première version RC numérotée 6.0.1 semble souffrir d’un nombre important de retours d’anomalies. Ceci explique surement en partie le retard qui commence à grandir pour la release finale et aussi la longue durée depuis laquelle nous attendons la sortie de la RC2. Cette deuxième RC devrait débloquer la situation, espérons-le.

Notons quand même que la roadmap initiale prévoyait une sortie finale de Liferay Portal 6 entre février et avril 2010 pour respectivement les versions Community Edition et Enterprise Edition. Il est maintenant souhaitable que toutes ces corrections de bugs qui se sont ajoutées permettent d’obtenir un portail avec une meilleure finition comparé aux versions précédentes .

Liferay Portal a 10 ans

Le 23 avril dernier, Liferay nous a fait cadeau d’une belle newsletter intitulée ‘10 Years of Open Source: Liferay in 2010′. En effet, la société s’est construite sur son portail et a su évoluer en trouvant les partenaires de poids nécessaires. Maintenant elle continue son chemin en profitant de son expérience.

Je vous retranscris ici le contenu de leur message :

Cette année marque le 10ème anniversaire de Liferay Portal. Brian Chan a démarré le développement en 2000 et Liferay est très rapidement devenu la plateforme de premier choix pour construire des applications d’entreprises dynamiques et efficaces. Avec 3 millions de téléchargements, 250 000 déploiements et une communauté active d’environ 30 000 personnes, Liferay a connu une croissance explosive dans sa 11ème année.

Un éclat éternel ?

Cette année marque aussi le 6ème anniversaire de la société, basée sur l’open source, et Liferay célèbre plusieurs jalons :

• Des centaines de sociétés clientes comme Cisco Systems, Electronic Arts et Société Générale
• Plus de 60 partenaires dans le réseau international
• Reconnu deux ans de suite comme Visionnaire dans le Gartner’s Magic Quadrant
• Forte croissance des revenus et du support présent dans les bureaux d’Amérique du nord, d’Europe, du Brésil, d’Inde et de Chine.

Merci pour votre soutien et au plaisir de travailler à vos côtés en 2010 !

Si nous reprenons un peu l’historique, voici ce qu’on pourrait obtenir :

• 2000 : premiers développements par Brian Chan, pour proposer un portail d’entreprise pour les organismes à but non lucratif
• 2006 : création de la société Liferay Inc., et de la filiale Liferay GmbH en Allemagne
• 2007 : ouverture de nouveaux bureaux en Asie et en Espagne
• 2009 : création d’un bureau en Inde

La croissance de Liferay s’est faite aussi grâce à des partenariats :

• ICEsoft Technologies, en juillet 2007, pour incorporer la technologie Ajax
• janvier 2008 : recrutement du lead engineer de jQuery UI
• Sun Microsystems, en mai 2008, pour un accord d’échange technologique
• 2009 : Liferay intègre le comité de spécification de Oasis CMIS
• IT Mill Ltd., en octobre 2009, pour travailler autour de leur librairie de UI nommée Vaadin

Liferay IDE 1.0 en vue

Gregory Amerson a rejoint l’équipe Liferay à Los Angeles en février 2010. Son expérience de senior developer sur MyEclipse l’a propulsé au poste de software engineer en charge du développement de l’outillage autour du portail et plus spécifiquement basé sur Eclipse. La première release de Liferay IDE devait se faire suivant un plan de 2 mois aboutissant sur la publication de la version 1.0.

Le jour et la nuit

Depuis avril, le développement suit son court et les premiers builds sont testables pour les plus motivés. Six vidéos de démonstration ont été publiées et présentent certaines des fonctionnalités qui seront présentes de façon certaine dans la version finale :

1. Create new plug-in project
2. Portlet Project Deployment
3. New Portlet Wizard
4. New Hook Wizard
5. More Hook Wizard
6. Plug-in Package Editor

La date du 12 mai avait été donnée pour la sortie de la version 1.0 finale. Plus de 2 semaines plus tard, force est de constater que nous devons encore patienter un peu.

Dans les cartons de Liferay IDE

Liferay IDE 1.0 proposera la gestion du serveur Liferay Portal, la création d’un projet, des éditeurs pour les descripteurs spécifiques et des wizards de création d’artefact de portail, le tout conforme à l’état de l’art des pratiques que chaque développeur utilisant Liferay doit répéter sans cesse dans son environnement de développement personnel.

La page du wiki officiel qui présente Liferay IDE nous donne quelques éléments de détails :

Le but de Liferay IDE est de fournir l’outillage basé sur Eclipse le plus abouti qui soit pour l’environnement de développement de Liferay Portal à destination des versions 6.0 et supérieur.

Liferay IDE viendra complémenter l’existant d’une façon très similaire à ce que fait SpringSource Tool Suite pour la plateforme Spring.

Livrables produits sans aucune différence de fonctionnalité :

1. Liferay IDE All-in-one bundle (incluant par exemple un JRE, un pack Liferay, la JavaDoc, des packages complémentaires de sources du portail, etc.)
2. Liferay IDE plugins bundle pour Eclipse Galileo JEE (3.5.x)
3. Update site pour Eclipse Galileo

Priorités :

1. Pouvoir démarrer facilement sur la plateforme Liferay
2. Simplifier ou automatiser les tâches fréquentes et ennuyeuses
3. Intégrer le Liferay Plugins SDK
4. Développer, déployer et débugger les plugins Liferay facilement

Disponible entre autres pour la version 1.0 :

• Importer, créer et travailler sur des projets Eclipse de plugins Liferay directement
• Prendre en charge le Liferay Portal depuis l’IDE
• Nouveaux wizards pour automatiser les créations répétitives de contenus
• Assistance à la saisie
• Templates personnalisés

Prévu pour les versions suivantes notamment :

• Gestion avancée du Plugins SDK et du bundle Liferay Portal utilisés
• Projets pour les Theme et Layout Template
• Éditeurs améliorés et validation des structures saisies
• Gestion automatique des dépendances
• Log d’activité du serveur

Premiers retours sur Liferay IDE 1.0 preview

La communauté a fait part de son intérêt pour cet IDE qui était très attendu. Pour la version 1.0, Eclipse est la priorité absolue et donc seul ciblé. Par la suite, les autres IDE devraient pouvoir recevoir une prise en charge par le biais de plugins officiels. Un travail notable d’intégration pour NetBeans ayant déjà été entrepris (cf. Portal Pack), ce dernier devrait être géré rapidement. Quant à IntelliJ IDEA, il sera aussi supporté à l’avenir.

L’équipe reste à l’écoute des besoins des utilisateurs et par exemple, se montre intéressée lorsqu’est évoqué le “besoin” de gérer la prise en compte native de JSF 2.0 pour les portlets directement depuis l’IDE. D’autres idées émises concernent par exemple la gestion directe par l’IDE d’artefacts Maven spécifiques à Liferay pour donner suite au Liferay Maven SDK.

Pour tester la version de preview, Gregory Amerson a mis en place un update site à ajouter dans votre Eclipse :

http://gregamerson.com/liferay-ide/updates/latest/

Fin mai, seule la version 6.0.1 du portail (Liferay Portal 6 RC 1) est officiellement disponible au téléchargement depuis SourceForge. Ceci pose problème si vous tentez d’utiliser la version preview de Liferay IDE qui demande que votre portail soit au minimum en version 6.0.2. La seule solution semble donc être de se tourner vers les Nightly Builds du portail en attendant que la RC 2 soit publiée officiellement. L’url pour récupérer ces builds est :

http://releases.liferay.com/portal/nightly/

D’après Gregory Amerson, le build Liferay Portal 6 RC 2 sera publié d’ici peu et Liferay IDE 1.0 devrait suivre de près. Plus que quelques jours à attendre donc !?

Conclusion

Voici donc quelques actualités majeures dans le “petit” monde de Liferay qui méritaient qu’on s’y attarde un peu. Et puisque les sujets sont encore bien chauds, nous devrions voir arriver très rapidement les annonces des releases finales. Et encore d’autres surprises peut être ?

Pour terminer et ne faire que les mentionner, GateIn et eXo Platform sont les premiers à faire beaucoup parler d’eux ces derniers temps parmi les éditeurs de portails, donc Liferay a tout intérêt à se montrer entreprenant pour ne pas se faire distancer !

Références

• Billets de Paul Hinz : http://www.liferay.com/web/paul.hinz/blog
• Billets de Brian Chan : http://www.liferay.com/web/brian.chan/blog
• Wiki Liferay : http://www.liferay.com/community/wiki/
• Billets de Gregory Amerson : http://www.liferay.com/web/gregory.amerson/blog

Suite à la mise en place d’un environnement de développement Flex en Open Source, je vous propose aujourd’hui de simplifier l’utilisation de BlazeDS grâce à Spring BlazeDS Integration (Spring-flex).

La description suivante, traduite de l’introduction faite sur le site officiel, résume bien les buts recherchés :

Spring BlazeDS Integration est une réponse à une demande de la communauté qui souhaitait avoir une solution pour construire des RIA propulsées par Spring, utilisant Adobe Flex pour la technologie client. [...] Bien qu’il était possible d’utiliser BlazeDS pour se connecter à des services gérés par Spring, ce n’était pas réalisable de manière “naturelle” pour un développeur Spring, nécessitant d’avoir à maintenir une configuration XML BlazeDS séparée. Spring BlazeDS Integration change tout cela en transformant le MessageBroker de BlazeDS en un objet géré par Spring, ouvrant des perspectives vers une intégration plus complète qui suit le “Spring way”.

Dans cet article, nous allons voir les principes de base de Spring BlazeDS Integration : configuration, exposition des services et consommation par un client Flex. Un projet est réalisé en parallèle pour illustrer la théorie ; les exemples de code suivant en sont tirés. Le code source final est disponible à la fin de cet article. Si vous n’avez pas encore lu le précédent article, je vous invite à le faire car il explique de nombreuses notions qui seront réutilisées ici.

Mise en place de la webapp

C’est bien Mave(i)n(e)…

Une fois n’est pas coutume, nous allons utiliser Maven 2 pour créer le squelette d’application web qui sera utilisée par le client Flex :

1
mvn archetype:create -DgroupId=com.excilys.java -DartifactId=SimpleSpringFlex -DarchetypeArtifactId=maven-archetype-webapp

Retour aux sources

Ajoutons tout de suite les bonnes dépendances vers Spring-Flex :

1
2
3
4
5
<dependency>

  <groupId>org.springframework.flex</groupId>

  <artifactId>spring-flex</artifactId>

  <version>1.0.1.RELEASE</version>

</dependency>

Commençons par adapter le descripteur de déploiement web.xml :

1
2
3
4
5
6
7
8
9
10
11
12
13
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">

  <display-name>Simple Flex Remoting with Spring-Flex</display-name>

  <servlet>

    <servlet-name>dispatcher</servlet-name>

    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>

    <load-on-startup>1</load-on-startup>

  </servlet>



  <servlet-mapping>

    <url-pattern>/messagebroker/*</url-pattern>

    <servlet-name>dispatcher</servlet-name>

  </servlet-mapping>

</web-app>

Comme dans l’article précédent, nous mappons le pattern /messagebroker/* sur une servlet, sauf que maintenant ce n’est plus une MessageBrokerServlet, mais une DispatcherServlet Spring. Le travail de Spring va donc commencer ici. Profitons de la convention du framework qui ira chercher par défaut la configuration du conteneur Spring associée à cette servlet dans le fichier WEB-INF/dispatcher-servlet.xml :

1
2
3
4
5
6
7
8
9
10
11
12
<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

    xmlns:flex="http://www.springframework.org/schema/flex"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="

        http://www.springframework.org/schema/beans

        http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

        http://www.springframework.org/schema/flex

        http://www.springframework.org/schema/flex/spring-flex-1.0.xsd">



  <flex:messagebroker />

</beans>

Par rapport à une configuration classique, notez l’inclusion de l’espace de nommage “flex”, qui va rendre disponible la balise messagebroker. Celle-ci va nous permettre de créer un managed bean de type MessageBroker, qui va gérer les flux AMF (là aussi on profite de la configuration par défaut du bean, notamment pour le nom du fichier de configuration services-config.xml).

Exemple de Bean non managé par Spring

Création des services

Dans cette partie, nous allons faire du Java “classique”. Le but de la webapp créée au tout début de l’article est d’exposer des services à notre client Flex. Créons donc notre service, qui va permettre d’additioner deux nombres (calcul nécessitant de grosses ressources type cluster ) :

1
2
3
4
5
6
7
package com.excilys.java.springflex.service;



public class MathService {

    public int add(int a, int b) {

        return (int)((2*(double)a/b) * ((double)b/(int)Math.sqrt(4)) + (b << 2) / 4); // Addition standard.

    }

}

Exposition (gratuite) de services

Il nous reste maintenant à rendre ce service accessible à notre application Flex. En utilisant BlazeDS directement, il faudrait ajouter chaque service dans le fichier WEB-INF/flex/services-config.xml. Avec Spring-flex, nous allons pouvoir minimiser cette configuration :

1
2
3
4
5
6
7
8
9
10
11
12
<services-config>

  <services>

    <default-channels>

      <channel ref="my-amf"/>

    </default-channels>

  </services>

  <channels>

    <channel-definition id="my-amf">

      <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf"/>

    </channel-definition>

  </channels>

</services-config>

On se contente de dire que les services utiliseront par défaut le channel “my-amf”, avec l’endpoint /mesagebroker/amf. Pour exposer notre service, nous pouvons utiliser l’annotation @RemotingDestination :

1
2
3
4
5
6
7
//...

import org.springframework.flex.remoting.RemotingDestination;



@RemotingDestination

public class MathService {

  //...

}

Pour que ces annotations soient prises en compte, il faut bien évidemment utiliser la balise component-scan dans dispatcher-servlet.xml :

1
2
3
<bean xmlns:context="http://www.springframework.org/schema/context" ...>

  <context:component-scan base-package="com.excilys.java.springflex" />

</bean>

Appels depuis le frontend Flex

Nos services sont exposés, nous pouvons maintenant les consommer depuis du code Flex. Pour cela, nous utiliserons un RemoteObject de la même manière que dans l’article précédent. Le channel “my-blazeds” utilisera l’URL du DispatcherServlet :

1
2
3
4
<channel-definition id="my-blazeds" >

  <endpoint uri="http://localhost:8080/SimpleSpringFlex/messagebroker/amf"

      class="flex.messaging.endpoints.AMFEndpoint" />

</channel-definition>

Spring-Flex en action

Et après ?

Ajouter d’autres services (soustraction, multiplication, …) consiste à ajouter des méthodes dans MathService. Pour exposer d’autres classes de services, il suffit de les annoter avec un @RemotingDestination.

Si vos services  nécessitent une authentification préalable, il est possible de sécuriser les destinations avec Spring Security.

Enfin, pour la partie messaging, Spring BlazeDS Integration facilite l’envoi de messages entre clients Flex et/ou POJOs. Il est ainsi possible d’utiliser AMF ou JMS de manière similaire, grâce à une couche d’abstraction.

Nous venons de voir qu’une fois de plus, Spring nous propose un module assez simple d’utilisation qui permet de gagner en clarté de configuration et en rapidité d’exposition de services. La configuration XML est minimisée, les annotations font le reste. Et comme c’est bien pensé, ça s’intègre sans problème avec d’autres briques Spring liées par exemple à la sécurité. C’est-y pas beau çà ?

Code source

Pour bidouiller vous-même Spring-Flex, vous pouvez télécharger le code source du projet réalisé dans cet article.

Une fois n’est pas coutume, ce deuxième mardi du mois a été l’occasion pour les Javaïstes parisiens d’assister au Paris JUG, consacré cette fois aux processus de build, share et deployment. Pas de chance, la salle était déjà bien pleine quand je (Bastien) suis arrivé… vite, une chaise tout devant !

De mon côté (Pierre-Yves), ayant posé ma tente devant la salle la veille au soir, j’ai eu accès aux premiers rangs. Allez, je vous livre un petit secret : pour avoir un placement correct au Paris Jug, il faut arriver à 19h (ou être une JDuchess ). Je (Pierre-Yves) vais donc vous parler des trois premières présentations, et je (Bastien) continuerai avec les deux dernières.

Les secrets de fabrication du W3C

Par Alexandre Bertails

Qui connaît réellement le W3C ? En dehors des outils de validation et des spécifications HTML 5, peu d’entre nous en savent plus sur cet acteur historique du Web. Alexandre Bertails nous en dit plus, dans un temps imparti relativement court.

Saviez-vous que le site web du W3C vient d’être refait à neuf, après un an et demi de travail ? Ce n’est pas juste une CSS, le contenu et l’arborescence ont été revus, sans cependant casser aucun lien. Allez-y, visitez-le (bien plus joli qu’en 2008, 2002 et même 1996).

J’ai aussi découvert que le W3C est composé à 40% de français. Que les outils avec lesquels travaillaient les salariés n’étaient pas forcément orientés Web, mais que les choses ont bien évolué récemment.

On regrettera le flux permanent des retardataires (ça va, je (Bastien) le saurai pour la prochaine fois !), qui ont quelque peu perturbé notre attention à tous, sans toutefois départir Alexandre de ses moyens (et c’est tout à son honneur !).

DVCS

Par Sébastien Douche

Speaker hors pair, Sébastien Douche nous a donné envie de nous jeter à l’eau (pardon… facile celle-là) et de nous mettre immédiatement aux DVCS (Distributed Version Control System, système de gestion de versions distribué).

Auparavant, lorsqu’il intégrait un nouveau groupe de travail, Sébastien avait l’habitude d’y déployer sa boîte à outil habituelle : SVN, et Trac. Jusqu’au jour où il s’est retrouvé chef de projet sur un projet from scratch.

J’aime beaucoup la métaphore qu’il nous a donné : la maintenance d’une application, c’est du ski sur pistes, il y a des dizaines de développeurs qui sont passés avant toi et qui ont tracé la piste. Le développement à partir de zéro, c’est du ski hors piste, tu sais la direction que tu veux prendre, mais tu es en haut de la montagne, ya du brouillard, il faut se lancer, et tu n’as pas de repères immédiats.

Avec le temps, le projet, pourtant “agile”, a eu de plus en plus de mal à livrer dans les temps, et la qualité de travail s’est progressivement dégradée. Pourquoi ? Parce que les développeurs passaient leur temps à faire des micro-commit/micro-merge et à intégrer le travail des autres, au lieu de pouvoir se consacrer au développement des fonctionnalités.

C’est une sale habitude que nous donne SVN : merger le code est vécu comme une expérience difficile. On préfère donc commiter le plus vite possible pour que ce soient les autres développeurs qui aient à merger. Les micro-commit sont aussi bien moins difficiles à merger. Quand aux branches SVN, elles sont aussi faciles à créer que complexes à merger…

SVN ne sert plus au final qu’à faire de l’historisation, c’est un super “Annuler / Répéter”.

Les DVCS récents permettent à chaque développeur de travailler en local (fonctions d’historisation) et en isolation, et de pousser le code sur un repository central uniquement lorsque la fonctionnalité est terminée. Leur grande force est la flexibilité qu’ils introduisent, permettant à chacun de bosser comme il l’entend tout en respectant les règles d’organisation du groupe.

Il est aujourd’hui possible de passer à un DVCS en douceur, sur son poste de travail, en important un repository SVN qui peut rester le repository principal, mais en disposant des avantages d’un Git ou d’un Mercurial en local.

Sébastien en a aussi profité pour nous présenter la manière dont travaille son équipe : le repository central comporte uniquement du code “livrable” (au sens livraison de fin de Sprint). Chaque fois qu’une fonctionnalité a été codée par un développeur, une revue de code est réalisée par un autre développeur, une démo est réalisée, et si tout va bien alors seulement les modifications sont poussées sur le repository central.

Sa conclusion : si vous ne devez apprendre qu’une techno en 2010, ce n’est pas Scala, JEE 6, Maven 3… apprenez à utiliser un DVCS !

Git

Par David Gageot

Plutôt que de faire de sa présentation un énième tutoriel sur Git et tous les concepts associés, David Gageot a préféré nous montrer la puissance de Git en quelques exemple pratiques.

Tout d’abord, git bisect. Cette fonctionnalité permet d’automatiser la recherche du commit qui a créé une régression. Le fonctionnement est simple : on fournit à Git un script permettant de déterminer, pour une version donnée, si le bug est présent ou non. git bisect va ensuite réaliser une recherche dichotomique entre deux numéros de versions, et identifier très rapidement le commit coupable.

Cette fonctionnalité n’a pas grand chose à voir avec le fait que Git soit un DVCS (distribué), mais reste un argument de poids pour adopter cet outil. C’est aussi possible grâce à la rapidité avec laquelle un Git ou un Mercurial peuvent réaliser un checkout ou changer de version sur une copie locale.

David nous a ensuite montré un script qu’il a réalisé, qui permet de conditionner automatiquement le push vers le repository au fait que le build et les tests passent. Il peut donc tranquillement bosser et commiter pendant qu’en tâche de fond le build et les tests sont exécutés, et ainsi se passer d’un Hudson.

La présentation s’est terminée par des démonstration sur l’évolution de dépôts Git à l’aide de Gource, qui permet de représenter dans le temps les modifications effectuées sur un dépôt de sources, et le travail de chacun.

Le Gource du projet Linux

En conclusion, quelques conseils :

• testez Git le plus vite possible,
• n’essayez pas de faire du SVN avec Git, il faut oublier comment SVN fonctionne, désapprendre les mauvais réflexes,
• un bon moyen pour démarrer, c’est de jouer avec github,
• n’hésitez pas à utiliser Git dans le cadre de vos projets, au moins en local, il vous apportera une forte plus value même si votre équipe continue d’utiliser SVN.

Pause Buffet

Le buffet était gracieusement offert par Nicolas Martignole, suite à un défi lancé sur Twitter. Il en a profité pour faire de la pub pour l’eXpress Board, un job board pour les passionés. J’ai (Pierre-Yves) aussi pu croiser Emmanuel Bernard, apprenant ainsi que si l’équipe Hibernate n’utilise pas de DVCS pour le moment, ils songent à y passer, notamment pour faciliter l’intégration de contributions externes.

Build it with Maven 3!

Par Nicolas de Loof & Arnaud Héritier

Invités surprise, Fred et Jamy nous ont montré que Maven, c’est pas sorcier ! Certains se souviennent encore des migrations longues et périlleuses des Makefile vers Ant, puis vers Maven 1 et Maven 2. Cette fois, les développeurs du célèbre gestionnaire de build ont voulu éviter cela : la compatibilité de Maven 3 avec des projets en version 2 est en théorie de 99.99% (hormis maven site qui n’est pas encore au point).

Première rencontre avec Maven 3

Les mots-clé de la première release stable seront donc les suivants :

• compatibilité : en prenant n’importe quel projet Maven 2, sans aucune modification on pourra le builder avec Maven 3,
• modularité/extensibilité : le socle de l’application a été entièrement repensé (en évitant les problèmes de rigidité et de complexité de la version 2). Au menu, utilisation de Java 5, apparition d’APIs simples et intuitives, de la doc… Bref, de quoi faire des plugins sans se prendre la tête,
• Mercury : ce système voué à remplacer le mécanisme d’artifacts… a finalement été abandonné .

Maven 3 introduit la notion de build plan, qui permet de savoir à l’avance toutes les actions qui vont être effectuées dans un build (une sorte de contexte d’exécution). Ainsi, un plugin sera au courant de ce que feront les autres, donnant la possibilité d’avoir des builds intelligents (où les tests ne seront pas lancés deux fois par deux plugins différents par exemple).

Au niveau des descripteurs de build, la structure des pom.xml a été améliorée et Maven 3 devient polyglotte. On peut à présent écrire des descripteurs en groovy ou en python par exemple. Les exclusions globales de dépendances sont maintenant possibles (on va enfin pouvoir se débarrasser de cette *$#~ de dépendance sur un logger qui plante toujours… ).

Toujours dans les descripteurs, la notion de mixins est apparue :

Essentially it will be a POM consisting of plugins and configurations that can be externally parameterized. These mixins will be deployed to a repository and be referenced with a standard coordinate. Basically it will be an intelligent import with validation which will allow composition in your POMs.

On va pouvoir décomposer notre POM en différents morceaux, un peu à la manière des web-fragments.

Les builds parallèles vont bientôt faire leur apparition, pour ne pas que vos 7 autres cores s’ennuient (edit: Mathieu nous signale en commentaire que les builds parallèles sont déjà disponibles depuis la version 3.0-beta-1). Cette fonctionnalité sera très intéressante sur les serveurs d’intégration continue utilisant un modèle maitre/esclave (Hudson, pour ne citer que lui). Techniquement, le processus de build sera découpé en différentes phases qui se rejoindront en des points de synchronisation.

Mais au final, qu’apporte Maven 3 par rapport à Maven 2 à l’heure actuelle ? Rien, enfin presque :

• un shell (avec des jolies couleurs !) permet de faciliter les builds (notamment sous Windows),
• un gain de rapidité lors des builds.

Comme la migration de M2 vers M3 est très simple et rapide, nos deux speakers encouragent vivement les développeurs à tester Maven 3 chez eux, ne serait-ce que pour les gains en terme de rapidité de build. A vos pom, donc !

Deploy it with… DeployIt!

Par Guillaume Bodet & Benoit Moussaud

Guillaume et Benoit nous ont présenté les fondamentaux du bébé développé par XebiaLabs, DeployIt. Cet outil part du constat qu’un déploiement ne consiste pas en une simple copie d’EAR/WAR. Il y a généralement d’autres éléments à configurer (DataSources, JMS), des scripts SQL à lancer, des batches à mettre en place, etc.

DeployIt permet de gérer toutes ces étapes de manière intelligente et de faciliter l’installation d’une application. Il est repose sur trois briques principales :

• le cœur,
• des interfaces (Flex, console, Maven, Eclipse, dashboards…),
• des plugins permettant le support de JBoss, Apache, .NET etc.

La préparation d’une installation se fait en deux étapes. Dans un premier temps, on configure le Configuration Item Repository (CIR), qui est un référentiel d’informations sur les différents environnements de déploiement (test, performances, etc.). Ensuite, l’ensemble des opérations à effectuer est décrite dans des runbooks : déploiement d’un EAR, configuration d’une DataSource, installation d’un script SQL…

A partir de ces deux sources d’information, l’Intelligent Runbook Resolution Engine va se charger d’interroger les différents runbooks pour constituer un scénario de déploiement, en se basant sur les caractéristiques de l’environnement décrites dans le CIR.

Un des aspects intéressants dans DeployIt est sa faible intrusion :

• Il est agent-less, et va utiliser les moyens existants tels que ssh, sftp, scp.
• Il utilise les interfaces natives lorsqu’elles sont disponibles (wsadmin, JDBC…).
• Un plugin Maven permet de lancer les déploiements au sein d’un processus de build (au sens Maven) déjà existant dans le projet.

Seul bémol : DeployIt est un outil commercial, il existe une version gratuite mais qui n’intègre aucune notion de sécurité… XebiaLabs a ainsi la volonté de permettre aux gens de tester ce produit chez eux, tout en empêchant la possibilité de l’utiliser pour faire de vrais déploiements en production (sauf si vous êtes kamikaze).

Cependant, XebiaLabs songe à relâcher son outil en Open-Source. La majorité absolue des personnes présentes dans la salle a d’ailleurs voté positivement pour une telle action, en réponse à un sondage improvisé d’Antonio .

Conclusion

Ce Paris JUG fût riche en enseignements et en conférences de qualité. D’autres compte rendus ont été publiés sur le web : sur le blog du Touilleur Express, et sur le blog des JDuchess.

Le prochain Paris JUG aura lieu le 8 juin, avec une invitée à l’honneur : Holly Cummins.