Un Chti café

Brancher Nexus sur Active Directory (LDAP)

2012-01-27T17:34:00.003+01:00

Après avoir perdu un peu de temps à configurer Nexus sur Active Directory par l'intermédiaire du protocole LDAP, Je vous propose de vous faire partager mon expérience sur le sujet et en français

Mon besoin était le suivant :

Mettre en place un Nexus.
Mettre en place un système d'authentification pour l'administration du Nexus.
Réutiliser le référentiel d'utilisateur de l'entreprise.
Ne pas ouvrir l'administration de Nexus à tous les utilisateurs présents dans l'AD mais seulement à un groupe.

Une documentation très bien faite est mise à disposition par Sonatype Ici.

Le problème n'est pas dans la qualité de la documentation mais se brancher sur un AD par l'intermédiaire de LDAP n'est jamais simple : beaucoup d'options, de paramétrages, des contenu dans les référentiels LDAP très différents.

Etape 1 : Obtenir un accès

Avant de commencer, il faut obtenir un utilisateur/mot de passe qui soit capable de naviguer en lecture au sein de l'AD. En général, il faut créer ou faire créer un utilisateur générique par lequel vos applicatifs (comme Nexus) viendront interroger votre AD.

Une fois cet utilisateur en poche (ça peut prendre du temps à avoir ce genre de choses...) , je vous conseille de le tester avec un browser LDAP. Je me suis servi d'Apache Directory Studio. Il est Open Source et c'est une application RCP. Bref, il fait plutôt bien le job.

Il vous suffit donc de créer une connexion (host et port de l'AD, user, password) et hop vous pouvez naviguer à l'intérieur.

Il faut aussi créer un groupe AD et y rattacher les utilisateurs à qui vous souhaitez donner l'accès à l'administration de Nexus. Votre AD possède peut être déjà un groupe qui correspond à la population qui vous intéresse. Vous pouvez dans ce cas le réutiliser. Pour la suite de l'article, nous appellerons ce groupe "equipe-de-developpement".

Mais ça n'est pas fini...

Etape 2 : Obtenir une bonne vision de l'arborescence de l'AD

Le plus important et de récupérer l'adresse LDAP racine dans laquelle tous les utilisateurs se trouvent. Nous l’appellerons pour la suite de l'article "l'adresse racine utilisateur".

par exemple : CN=Users,DC=votreDomaine,DC=com

Mais ça n'est pas fini...

Etape 3 : configurer la partie LDAP de Nexus

Connectez-vous en admin sur Nexus et déplacez-vous dans la partie Security > "LDAP Configuration" accessible depuis le menu latéral gauche. C'est parti pour la partie conf :

Connection : (permet de définir les paramètres de connexion à l'AD)

Protocol : Ldap
Hostname : adresse de l'AD (le même que vous avez utilisé avec botre browser LDAP).
Port : port de l'AD (en général c'est 389).
Search Base : c'est l'adresse par défaut à partir de laquelle le requêtage LDAP se fera une fois connecté. Remplissez le avec l'adresse racine utilisateur.

Authentication : (permet de définir la manière dont Nexus s'authentifie sur l'AD)

Authentication method : Choisir "Simple Authentication"
SASL Realm : laisser vide.
Username : le username de votre utilisateur générique ayant accès en lecture à AD.
Password : le password de votre utilisateur générique ayant accès en lecture à AD.

Vous pouvez faire un "check authentication". Si tout est ok vous devez avoir un "LDAP connection and authentication test completed successfully." Ça veut dire que votre Nexus sait se connecter à votre AD.

User Element mapping : (permet de définir la manière dont Nexus va vérifier si un user existe)

Base DN : laisser vide (si vous avez bien renseigné dans la partie connection que l'adresse par défaut de requêtage est bien l'adresse racine utilisateur).
User Subtree : à cocher.
Object Class : Saisir "Person", c'est le type d'objet LDAP contenant les utilisateurs.
User ID Attribute : Il faut indiquer le nom de l'attribut LDAP qui contient les logins utilisateurs AD. Saisir : "sAMAccountName"
Real Name Attribute : Il faut indiquer le nom de l'attribut LDAP qui contient le nom complet des utilisateurs AD. Saisir : "displayName".
E-Mail Attribute : Il faut indiquer le nom de l'attribut LDAP qui contient l'adresse mail des utilisateurs AD. Saisir : "mail".
Password Attribute : Il faut indiquer le nom de l'attribut qui contient le mot de passe des utilisateurs AD. Laisser vide (c'est un attribut par défaut).

Group Element Mapping : (permet de définir la manière donc Nexus va récupérer la liste des groupes).

Group Type : Saisir "Dynamic Groups". Il y a 2 types de groupes LDAP : un groupe dynamique correspondant à un attribut dans un objet "user" LDAP. Un groupe statique, c'est le contraire, c'est la référence à une liste d'utilisateurs dans un objet LDAP "group". Avec AD, à priori, quand un groupe est créé il l'est en statique et dynamique. Autant donc choisir dynamique car il y a beaucoup moins de configuration ;-).
Member Of Attribute : Il faut indiquer le nom de l'attribut LDAP dans lequel un groupe dynamique est défini. Saisir : "memberOf".

Vous pouvez faire un "Check User Mapping". Si tout est ok, Nexus vous affiche un début de liste d'utilisateurs qu'il a réussi à requêter.

N'oubliez pas de faire "save" :-)

Mais ça n'est pas fini...

Etape 5 : Mapper votre groupe AD avec un rôle NEXUS.

Il faut maintenant configurer à Nexus pour que les utilisateurs de votre groupe AD equipe-de-developpement correspondent à un rôle dans Nexus, par exemple "Administrateur Nexus".

Déplacez-vous dans la partie "Roles" accessible depuis le menu latéral gauche :

Sélectionner "Add" > "External Role Mapping"
Realm : choisir "LDAP"
Role : La liste des rôle LDAP de votre AD doit être présente. choisir votre groupe equipe-de-developpement
Ajouter ensuite le Rôle associé en cliquant sur "add"
Cocher le "Nexus Administrator Role"
Cliquer sur OK

Mais ça n'est pas fini...

Etape 6 : activer l'authentification LDAP pour Nexus

Il faut maintenant simplement activer l'authentification par LDAP. Je dis "simplement", mais j'ai cherché un bout de temps avant de comprendre pour tout ça ne marchait pas ;-).

Déplacez-vous dans la partie "Administration" > "Server" accessible depuis le menu latéral gauche :

Dans la partie "Security Settings": déplacer "OSS LDAP Authentication Realm" de "Available Realms" vers "Selected Realms".

That's all...

Agilité par contamination

2012-01-13T10:25:00.000+01:00

Lorsqu'on souhaite mettre en oeuvre Scrum la première fois, il est souvent dit de mettre en place la totalité du framework et dans un second temps de l'adapter quand l'ensemble des acteurs possèdent le recul nécessaire (pour justement l'adapter favorablement). Cette mise en place totale a pour but de ne pas tomber dans les fameux "Scrum But", souvent cause de l'échec de la mise en place de Scrum. Les "Scrum But" pour simplifier représentent les entorses au framework (Exemple : c'est le ScrumMaster qui fait les estimations et affectent les tâches, oui ça c'est de la très grosse entorse ;-)).

Je vous propose ici de vous raconter un de mes retours d'expérience sur le sujet qui est très différent de l'approche dont je viens de vous parler.

Il y a bientôt un an, j'ai intégré une équipe de développement chez un éditeur logiciel qui ne pratiquait pas "l'agilité". Ce nouvel environnement me paraissait idéal pour mettre en place Scrum couplé avec un peu d’Extrême Programming pour plusieurs raisons :

une petite structure (moins de 25 personnes).
une équipe de développement de moins de 6 personnes.
une forte croissance.
la volonté de développer une nouvelle version d'un produit.

Il faut avouer que Scrum est très déroutant dans ces pratiques quand on ne les a jamais mises en oeuvre. Comme je ne m'appelle pas Jeff Sutherland (un des papas de Scrum) et que je ne suis pas un extrémiste (enfin j'estime ne pas l'être, ce qui est différent, je vous l'accorde), je n'ai pas forcé pour la mise en place de Scrum.

En revanche, je travaillais sur un sujet isolé et avec une liberté totale sur ma façon de travailler. J'ai donc fait du Scrum et de l'Xp seul (ok ce n'est pas vraiment du Scrum). Tiens ça me fait penser à Jean Jacques.

Hey hop, c'est parti, je récupère un tableau en carton, j'ai un mur juste derrière moi, impeccable, ça sera mon scrum board. Un petit tour par la compta : "Heu, vous auriez des post-its? Ha, vous n'avez que cette couleur, ok ça ira très bien pour commencer. Vous pouvez en commander d'autres? et de plusieurs couleurs?".

Un ou deux jours passent...

Réaction 1 : "Ha c'est comme ça que tu travailles?"
Réaction 2 : "C'est jolie tous ces post-its derrière toi, c'est quoi, ça marche comment?"

Côté pratique d'ingénierie, pas d'intégration continue, pas de DVCS (en tous cas pas celui que je voulais :-)), pas de suivi de qualité, pas de déploiement continu. Ok, qu'à cela ne tienne, "Just Do It". C'est parti pour mettre en place une forge logicielle complète sur une machine virtuelle dans un coin de serveur (apache, jenkins, git, sonar, maven, ...).

Réaction 3 : "C'est quoi l'intégration continue?"

J'avais maintenant tous les outils que je souhaitais pour développer. C'est parti. Les semaines passent, les post-its s'entassent...

Réaction 4 : "C'est pas mal ton tableau avec les post-its pour voir l'avancement du travail"

A force de question et de discussion autour de Scrum avec l'équipe de développement, je me propose de leur faire une présentation de Scrum. C'est parti pour une présentation de 2h très conviviale. L'objectif est de faire découvrir les principes du framework. Rien de plus.

Réaction 5 : "C'est vraiment très différents, ça n'est pas du tout aujourd'hui notre façon de travailler, ça fait un peu peur"

Les semaines passent... et qu'est-ce que je vois sur le bureau du collègue à côté de moi, le livre "Scrum" de Claude Aubry. Je lui dis que c'est un super bouquin qu'il a bien fait de l'acheter.

Réaction 6 : "C'est ma compagne qui me l'a acheté car je lui avais parlé de la présentation que tu avais faite"

Alors là je suis scotché!

Les semaines passent... et un gros sujet à traiter par toute l'équipe nous tombe dessus. On ne sait pas par quel bout le prendre. Je propose aux membres de l'équipe qui connait le mieux le sujet de faire un mind map pour modéliser le travail à effectuer ainsi qu'une réunion tous ensemble où l'on ajuste le Mind Map pour tous obtenir une bonne vision de ce qu'on va devoir faire. J'extrais ensuite le contenu du Mind Map dans un fichier Excel.

Réaction 7 : "C'est un peu comme un Backlog ce fichier Excel, non?"

Je l'ai ensuite renommé en "Backlog".

Réaction 8 : "Par quoi on commence?"

Je propose de refaire une réunion avec toute l'équipe pour qu'on priorise les sujets/tâches tous ensemble pour traiter les tâches les plus urgentes.

Réaction 9 : "On priorise tout, tout de suite?"

Je propose alors de faire un point tous ensemble toutes les semaines et de prioriser/reprioriser les sujets.

Réaction 10 : "On migre les applis existantes sur git"?

Yes!

Réaction 11 : "Comment on fait pour rajouter un Job dans Jenkins"?

Yes! Je te montre!

Les semaines passent... et je discute avec le directeur général. Il m'apprend qu'il s'est documenté sur Scrum et les méthodes Agiles qu'il trouve ça très intéressant et qu'il souhaite qu'on fasse des petites réunions tous les matins.

Aujourd'hui, nous ne pouvons pas dire que nous "faisons du Scrum" mais tous ce qui est mis en place nous aident réellement au quotidien. L'utilisation d'un backlog et la réalisation du Daily Scrum du matin sont maintenant une évidence. J'espère que cette démarche (non préméditée) de contamination va se poursuivre.

Alors que je pensais que Scrum ne pouvait fonctionner sur le principe du tout ou rien, je me rends compte que l'agilité progressive est un succès dans notre cas.

Vous en pensez quoi?

Cassandra pour les développeurs Java

2011-12-13T10:52:00.000+01:00

Hier soir, au Ch'ti JUG il y a eu une double session sur NoSQL.

Steven Noels a présenté en première partie Lily, une solution d'indexation basé sur HBase.
En deuxième partie, j'ai effectué une présentation de "Cassandra pour les développeurs Java" où j'y ai abordé les principaux concepts de Cassandra, présenté Hector et cassandra-unitl e tout avec un peu de live coding.

Voici les slides de cette présentation :

Cassandra pour les développeurs java

View more presentations from jsevellec

Ça a été une bien belle soirée et un after bien sympa et convivial :

@bientôt à une autre session du Ch'ti Jug!

Cassandra : Les problématiques à traiter lorsqu'on développe une application java

2011-10-04T17:13:00.001+02:00

Cassandra fait parti de la famille des bases de données NoSQL. C'est une base de données dont on entend de plus en plus parler dès que l'on est confronté à devoir gérer de gros volumes de données, à être très performant et à vouloir monter en charge facilement.

De part sa conception, Cassandra a été nativement pensé pour être hautement distribué, hautement performant et avec une forte capacité de montée en charge.

Cassandra est une très belle implémentation du modèle p2p. Tous les noeuds au sein d'un Cluster Cassandra ont le même rôle. Il n'y a pas de notion de maître/esclave...

Bref, Je ne vais pas vous énumérer les avantages à utiliser Cassandra car d'autres l'ont déjà très bien fait avant moi. Vous trouverez sur le wiki de Cassandra un ensemble de liens vers des présentation qui décriront les concepts clés autour de Cassandra. Juste un dernier mot pour vous dire que Cassandra va bientôt sortir en v1.0.

Une fois votre choix arrêté : "ok, on part sur Cassandra", quelles sont les problématiques auxquels vous allez être confronté lors de sa mise en oeuvre? Je vais tenter d'apporter quelques réponses... C'est parti!

Design de votre modèle de données :

Une des premières choses à faire quand on commence à travailler avec Cassandra, c'est d'oublier tout ce qu'on vous a dit et ce que vous faisiez avec une base de données relationnelle : Le maître mot est dénormalisation.

Cassandra propose un modèle orienté "Column Family" inspiré par BigTable de Google. Je vous conseille dans un premier temps de bien comprendre le modèle de Cassandra (Keyspace, ColumnFamily, Column, SuperColum, Counter) avant de vous lancer. La documentation de DataStax sur le sujet ainsi que l'article sur le wiki sont un bon point départ.

Une fois le modèle de Cassandra compris, il faut axer la réflexion sur la façon dont vous allez requêter vos données. Le système de requêtage de Cassandra est limité (pas de jointures par exemple...). Il faut donc commencer par là pour être sûr de pouvoir faire ce que l'on veut faire.

Installer et paramétrer un cluster Cassandra

La force de Cassandra est de fonctionner avec un grand nombre de noeud dans un cluster. Le plus gros cluster dont j'ai entendu parler (dans cette interview de Jonathan Ellis) serait constitué de 400 noeuds... Juste énorme. Sans aller jusque là, il faut malgré tout rapidement vous familiariser avec le fonctionnement et l'administration d'un cluster Cassandra. Bref, il faut mettre les mains dedans. Je vous conseille cet article, cette video ou encore cette documentation DataStax décrivant la mise en oeuvre rapide d'un cluster cassandra. Cassandra fonctionne aussi en Single Node, cela peut toujours servir en terme de développement mais j'y reviendrai plus tard.

Il vous faut aussi comprendre le fichier de configuration principal de chaque noeud Cassandra : cassandra.yaml. Voici sa documentation.

Si vos serveurs acceptent le packaging Debian, Je vous conseille fortement d'utiliser celui proposé par Cassandra. Il vous permettra très rapidement de l'installer et surtout de le mettre à jour facilement!

Il faut aussi un peu de moyens... Pour pouvoir faire des tests sur votre cluster, il faut un environnement machines permettant de mettre en valeurs les capacités de Cassandra. Cela permet aussi pour vous rassurer avec des tests de performances valables avant d'arriver dans un environnement de production. La virtualisation de plusieurs noeuds sur un ("petit") serveur ne permettra pas de faire des tests de performances concluants.

Administrer et monitorer un cluster Cassandra

Cassandra fournit nativement un ensemble d'outils permettant d'administrer votre cluster :

cassandra-cli : c'est l'utilitaire en ligne de commande permettant de lire/ecrire dans votre cluster
nodetool : c'est l'utilisaire en ligne de commande permettant de monitorer et administrer les noeuds du cluster

En plus de ça, DataStax propose une application Web de monitoring et d'administration de votre cluster Cassandra : OpsCenter. C'est vraiment un superbe outil. Il y a une version gratuite pour le développement. J'ai cru comprendre (mais je me trompe peut être) qu'il y aura bientôt aussi une version production gratuite mais qui ne l'est pas pour le moment.

Gérer le "Eventuellement Consistant"

Cassandra propose un modèle "Eventuellement Consistant". Ces mots doivent normalement mettre la puce à l'oreille à n'importe quel développeur et faire un peu peur.

Pour faire simple, selon le théorème CAP, il n'est pas possible d'avoir à la fois de la consistance (Consistency) , de la disponibilité (Availability) et une résistance au morcellement (Partition tolerance). Il n'est possible que d'en avoir 2 sur 3. Cassandra a choisi de mettre l'accent sur le "A" et le "P" et d'offrir la possibilité de choisir son niveau de consistance. Il est donc possible d'avoir un consistance forte avec Cassandra mais au détriment d'une dégradation du temps de latence (car il faut demander à plus de noeud dans le cluster de se mettre d'accord sur la valeur d'une donnée lors d'une lecture par exemple).

Il y est donc possible de choisir parmi plusieurs niveaux de consistances. Voici une documentation sur le site de DataStax sur le sujet pour vous guider dans votre choix.

Lock

Cassandra ne sait pas faire de Lock. C'est un inconvénient lié à son architecture. Il ne permet donc pas d’empêcher plusieurs clients de lire ou d'écrire un ensemble données portant sur les mêmes clés de votre modèle au même moment. Ce qui peut être fortement gênant, il ne faut pas le nier... Dans ce cas : "la réponse est ailleurs".

Il n'est pas impossible de faire du lock sur vos données mais en utilisant un système externe qui va gérer cela. Zookeeper va vous permettre de faire cela. C'est un système de synchronisation distribué de type sémaphore qui va vous permettre de faire des locks. Zookeeper n’entraîne pas de SPOF car il fonctionne aussi en cluster. Cage est une libraire Java qui s'appuie sur zookeeper et propose un système de lock basé sur des chemins. Voici un article qui vous explique en détail son utilité pour compléter l'utilisation de Cassandra.

Transaction

Ok, vous faites du lock mais lock ne veut pas dire transaction... Cassandra assure une atomicité des données au niveau d'une même clé (même dans des columnFamily différentes). En revanche, comment faire si vous avez besoin d'une atomicité de données sur plusieurs clés car vos données sont fortement couplés et que vous ne pouvez pas faire autrement.

La réponse est "Just do it (yourself)". Une des approches est de mettre en oeuvre un système de transaction log dans une columnFamily dédiée. Le principe est donc :

de logger la transation en sérialisant les données qui ont besoin d'être atomiques (json, xml, ...) et en insérant le résultats de la sérialisation en une fois dans une colonne d'une columFamily.
effectuer votre traitement en insérant vos données dans votre modèle.
de marquer ou supprimer la log de la transaction une fois le traitement terminé.

Ce système vous donne alors la possibilité de rejouer la log de la transaction si un souci est survenu pendant votre traitement. Ce système est abordé dans cette présentation (à partir du slide 24).

Comment dialoguer avec Cassandra

Cassandra expose toute son Api cliente via Thrift. L'utilisation native de thrift est déconseillée car c'est plutôt une Api de bas niveau s'adressant à des clients développeur plutôt qu'à des applications clientes.

Il faut donc choisir votre client pour vous adresser à Cassandra : Ils sont listés ici.

En java, il en existe plusieurs. Hector semble clairement le plus utilisé et le plus configurable. C'est celui que j'utilise.

Environnement de développement

Si vous utilisez maven, la plupart des librairies dont vous avez besoin sont mavenisées et disponibles dans les repository centraux (l'exception est Cage qui nécessite de déclarer un repository spécifique).

Vous aimez faire des tests unitaires et du TDD, pas de problèmes, c'est possible et ça se fait même très bien. Il est possible de lancer Cassandra et Zookeeper de façon "embedded" dans votre JVM.

Il est même possible si vous le souhaitez de lancer Cassandra de façon embarquée et d'y charger des données avant d’exécuter vos tests unitaires. Je vous propose d'aller jeter un oeil du côté de cassandra-unit si vous souhaitez faire ça.

Ecosystème en évolution permanente

Que ce soit sur les fonctionnalités de Cassandra, son outillage, son écosystème, il y a beaucoup de changements, d'évolutions et d'améliorations.

De grosses et nouvelles fonctionnalités apparaissent constamment. Par exemple, il y a quelque mois, entre la version 0.7.8 et la 0.8.0, un langage de requêtage le "CQL" est apparu et très prochainement Cassandra sort en version 1.0... Ça va très vite.

Il faut globalement rester en veille sur les blogs, twitter, les mailing list (Cassandra et Hector par exemple) pour voir ce qui se fait, ce qui sort. La communauté autour de Cassandra est grossissante et est très réactive.

Ne pas avoir peur de défaire
Comme les choses changent et évoluent, Il ne faut pas avoir peur de jeter un peu, de modifier souvent, de refactorer beaucoup votre code. C'est dû soit à une évolution de compréhension de Cassandra qui vous fait dire qu'il faut mieux faire autrement, soit à l'apparition d'une nouvelle fonctionnalité soit à un lecture sur un blog...

Il n'y a pas de secret, ma meilleure arme pour gérer ses changements sont : mes tests unitaires et mes tests d'intégrations et ça se passe bien!

Pour aller plus loin

Vous pouvez aller jeter un oeil dans le code source de Cassandra sous svn ici ou sur le miroir sous Git ici.

Vous pouvez aller lire la documentation sur le wiki sur l'architecture interne de Cassandra ici et voir cette vidéo.

Vous pouvez contribuer en commençant ici.

Pour Conclure

Utiliser Cassandra comme backend pour stocker vos données à un réel impact sur votre façon de développer votre application. C'est quelque part assez normal dans le sens si vous utilisez Cassandra, c'est que vous avez normalement beaucoup de données à gérer et qu'il faut de toute façon obligatoirement prendre ça en compte pour développer votre application...

Une fois les efforts produits, quel plaisir de rajouter un noeud dans le cluster pour monter en charge...

En fait, Cassandra, c'est très "DevOps" :-).

CassandraUnit : a Java test framework to develop with Cassandra

2011-08-10T22:06:00.002+02:00

Hi everyone,

Let me present you CassandraUnit!

Why?

I work for few months on a new Java application with a Cassandra database backend.

As I'm A TDD Lover, I'd like to developp in a pure TDD Style combined with continuous integration system like Jenkins.

The difficulty when using a database backend is how to write isolated unit Test. One of solutions is to :

first : embed an instance of your database in your unit test.
next : load data into your database to setup your unit test.
finally : execute your test with your data.

In a Relational database world, there is some tools to help you like DBUnit. As Cassandra is a relatively young product (but so beautiful :-)), I didn't find some tools to help me doing what I want.

CassandraUnit is born.

What does it do?

CassandraUnit, for now, does :

embed and start a Cassandra instance in your code if you want.
load data from a dataset (xml).

A very little example?

create an xml dataset like that "simpleDataSet.xml" :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<keyspace xmlns="http://xml.dataset.cassandraunit.org">

    <name>beautifulKeyspaceName</name>

    <columnFamilies>

        <columnFamily>

            <name>beautifulColumnFamilyName</name>

            <row>

                <key>key10</key>

                <column>

                    <name>name11</name>

                    <value>value11</value>

                </column>

                <column>

                    <name>name12</name>

                    <value>value12</value>

                </column>

            </row>

            <row>

                <key>key20</key>

                <column>

                    <name>name21</name>

                    <value>value21</value>

                </column>

            </row>

        </columnFamily>

    </columnFamilies>

</keyspace>

create a JUnit test case witch extends AbstractCassandraUnit4TestCase :

package org.cassandraunit;



import static org.hamcrest.Matchers.is;

import static org.hamcrest.Matchers.notNullValue;

import static org.junit.Assert.assertThat;



import org.cassandraunit.dataset.IDataSet;

import org.cassandraunit.dataset.xml.ClassPathXmlDataSet;

import org.junit.Test;



public class AutomaticallyStartAndLoadSimpleDataSetTest extends AbstractCassandraUnit4TestCase {



    @Override

    public IDataSet getDataSet() {

        return new ClassPathXmlDataSet("simpleDataSet.xml");

    }



    @Test

    public void shouldHaveLoadASimpleDataSet() throws Exception {

        assertThat(getKeyspace(), notNullValue());

        assertThat(getKeyspace().getKeyspaceName(), is("beautifulKeyspaceName"));

    }



}

And now?

It was just a very little example. CassandraUnit allows to make more complex dataSet (Super column, type definition, ...).

I've just published it on github. It is published under LGPL v3.0 license.

The first release will be available on maven central repository in the coming hours.

As it's the first release, It probably still missing a lot of functionnality but it was time for me to published it.

You want to go further?

and it's normal :-)

Here you can find more informations :

the github repository and doc (not a lot but a lot of tests) of the framework : https://github.com/jsevellec/cassandra-unit
the github repository of examples is available here : https://github.com/jsevellec/cassandra-unit-examples

You can follow it on twitter @cassandraunit

I hope it will help you as it helps me every day on my project.

Il est beau mon scrum board

2010-12-31T17:46:00.001+01:00

Le scrum board est un élément central au niveau d'un projet agile. Il est déjà fort utile sur des projets dit "non agile". Dans un contexte agile, c'est tout simplement INDISPENSABLE. Cela ne sert à rien d'en dire plus à ce sujet!

J'ai déjà pu lire des débats sur la forme qu'il doit prendre surtout dans des contextes un peu complexe d'équipes distribuées où il peut devenir numérique. Dans mon cas, sur un projet avec une équipe centralisée, on est resté très KISS : un simple tableau blanc aimanté de 2m * 1m est impeccable.

Scrum Wall

Vous parler seulement de notre Scrum board est trop réducteur. Il faut que je vous parle de notre "Scrum Wall". Un tableau blanc est un peu juste pour tout ce dont nous avions besoin. Comme nous avions de la place, nous ne nous sommes pas privé.

Voici donc notre Scrum Wall :

La photo est prise après la fin du projet, le partie tableau blanc est un peu vide :-).

Il est constitué (en partant du porte manteau, de gauche à droite) :

d'un A4 de rappel sur le daily Scrum :

Cette feuille n'était pas là au début, je l'ai rajoutée en cours de projet. Avec l'habitude du projet, nous oubliions parfois les fondamentaux. Ca fait toujours du bien de les avoir sous les yeux pendant notre Daily Scrum :-), même de dire que "je n'ai pas rencontré de problème particulier".

La partie gauche du tableau blanc :

La partie gauche du tableau blanc est purement réservée au sprint. Dans cette partie se trouvent 4 colonnes :

- To do

- In progress

- QA

- Done.

J'ai dû rajouter une feuille en dessous car je n'arrivais pas à tout faire tenir sur une colonne pour un sprint. Haaa... ces équipes hyperproductives, je vous jure :-). La dernière colonne de cette partie hébergeait un ensemble de zones qui ont évoluées au cours du temps. Nous avons commencé avec :

- identification du sprint (numero et contenu)

- technique (problèmes)

- organisationnel (problèmes)

- RE7 (remontées d'infos suite à la recette)

Pour au final terminer avec :

- identification du sprint (numero et contenu)

- corbeille (permet de faire le ménage quand la colonne "Done" devient trop remplie sans pour autant enlever les tâches du sprint en cours du Scrum Board).

- Actions après rétro (actions à effectuer sur le sprint par rapport à la rétro précédente).

- Problèmes (tous)

- Stockage des aimants : il faut bien les mettre quelque part. Au lieu de les retrouver dans la zone des problèmes organisationnel par exemple...

La partie droite du tableau blanc :

C'est l'espace "temporaire", il sert un peu à ce qu'on veut. Comme vous pouvez le voir, comme la photo a été prise après la fin du projet, l'emplacement est déjà "squatté" pour un autre projet. Cette espace permettait de réfléchir ensemble, d'expliquer, de schématiser, d'y mettre les horaires de la prochaine démo et de la prochaine rétro.

La partie droite du mur :

C'est le "A3 du projet". L'objectif est de proposer une vue synthétique du projet (la vision, les enjeux, la méthodologie, l'architecture globale, un mot sur Scrum, ...).

Et il manque??? Le burndown du Sprint que nous mettions entre le tableau blanc et le A3 du projet mais qui n'est plus là au moment des photos que j'ai prises.

Et en bonus, au dessus du tableau blanc, nous y avons mis des goodies que nous avions sur le projet, les cartes postales envoyées par les membres de l'équipe en congés,...

Beau et "clean"

Que vient donc faire la notion du "beau" dans un projet Scrum?

Le principe d'affichage est à double tranchant. Il offre d'une part une transparence sur le projet et d'autre part justement, on ne peut rien cacher. Les apparences sont trompeuses mais elles ne laissent pas forcément une bonne impression :

Vous y croyez vous si la personne qui possède cette chambre est bibliothécaire? C'est possible mais c'est dur à croire avec cette seule vision:-)

Vue de l'équipe : Le Scrum board est le seul outil qui permet aux membres de l'équipe de travailler ensemble de façon efficace sans se marcher dessus. De plus, c'est aussi cette même équipe qui s'en sert quotidiennement. le désordre attire le désordre et inversement!

Vue de l'extérieur, Scrum souffre parfois de son image. Les clichés ont parfois la vie dure :

-Le framework Scrum est parfois vue comme une méthode de gestion de projet exotique mais qui n'est pas applicable. On en arrive même à préférer ne pas dire qu'on fait du Scrum...
- "C'est quoi cette bande de rigolos qui joue avec des pos-its."
- "Et en plus ils font un poker au boulot"

- "Cela manque de rigueur"

- On a parfois du mal à comprendre que le fun peut faire partie du boulot.

Si on associe à cela un Scrum Wall qui n'est pas "clean", on a dû mal à projeter un image de qualité logiciel sur ce qu'on livre...

Il faut donc que le Scrum Wall soit beau!

CQFD

Des astuces

Un "A3 projet" de qualité : Sa réalisation est un exercice délicat qui nécessite de prendre du recul et du temps mais il est la carte de visite de votre projet vu de l'extérieur. Il facilite aussi l'intégration d'un membre dans l'équipe ainsi que la présentation du projet.
De la couleur : N'hésitez pas utiliser des couleurs différentes pour vos post-its d'un sprint à l'autre. En revanche, sur un sprint, essayez de vous y tenir.
Des couleurs et des tailles différentes : Utilisez des post-its de tailles et de couleurs différents permet d'identifier rapidement des fonctions différentes. Nous utilisons par exemple des pos-its carré (76mm*76mm) pour décrire une User Story et des petits post-its rectangulaire (38mm*51mm) d'une autre couleur pour les tâches.
Utilisez un stylo feutre pour écrire. Ca augmente la lisibilité.

Une petite illustration :

en haut : BAD / en bas : GOOD

Eviter d'avoir le post-it qui rebique : http://www.bouzin-agile.fr/?post/2010/10/15/Evitez-d-avoir-le-post-it-qui-rebique
Notez vos initiales sur les tâches en cours (ou un autre moyen d'identifier une personne sur une tâche en cours).
Faites le ménage régulièrement sur le Scrum Board: Est-ce que ce schéma est encore utile, est-ce que le problème est toujours d'actualité, ...

Voici quelques illustrations de notre projet :

Un début de sprint (d'une semaine) :

Un sprint en cours (de 15jours, nous avons fait évoluer la durée de nos sprints) :

(Nous remontions la colonne de gauche au fur et à mesure des Users Storys terminées en haut).

Sur ce, bonne année à tous!

Intégration continue : "have fun" :-)

2010-12-28T11:41:00.001+01:00

Je trouve que l'intégration continue est une pratique incontournable sur un projet de développement. Comme je l'avais déjà expliquée ici, la mise en place d'une démarche d'intégration continue peut ne pas prendre au niveau d'un projet de développement. Ce n'a pas été le cas sur le dernier projet auquel j'ai participé:

Un défi technique : tout doit être buildé

La mise en place d'une démarche d'intégration continue est d'abord un défi technique (en tous cas, ça peut l'être). Dans le cadre du projet dont je vous parle, nous avons un ensemble de plateformes de développements ayant des processus de builds différents (exemple : application jEE, application Iphone, application Android).

Le premier défi est donc de réussir à faire fonctionner le système d'intégration continue sur des plateformes hétérogènes. Le but est d'éviter que des membres de l'équipe plus ou moins spécialisés sur une ou deux plateformes et que celles-ci ne soient pas testées par l'intégration continue, seraient "à l'abri".

Notre serveur d'intégration continue est Hudson et notre gestionnaire de sources est Subversion. Un couple qui fonctionne bien.

Nous n'avons pas de soucis pour mettre en place l'intégration continue sur les applications jEE car nous utilisons maven pour les builder.

En ce qui concerne la plateforme Android, nous utilisons maven pour builder et signer l'application. L'intégration dans Hudson n'a pas posé de problème.

Le build Iphone est celui qui a été le plus complexe par rapport aux autres à mettre en place. Au final, avec un slave Hudson sur un de nos IMac et google comme ami pour trouver ça, ça s'est malgré tout fait assez rapidement.

Une fois de plus l'important est que tout soit buildé. Pour être transparent, on peut noter malgré tout des deltas sur le contenu des builds selon les plateformes. Par exemple, sur la plateforme Iphone, seul une compilation est effectuée alors que sur les applications jEE, il y a compilation, exécution des tests unitaires, execution des tests d'intégrations et déploiement.

Hudson notifie tous les membres de l'équipe par mail sur un build failed ou fixed.

Un défi organisationnel : elle doit être adoptée par toute l'équipe

L'intégration continue c'est aussi et surtout une démarche et un fonctionnement d'équipe!

Comme je l'ai déjà dit, il ne sert à rien d'avoir une superbe plateforme d'intégration continue si un build cassé n'entraîne pas une mobilisation de l'équipe pour résoudre le problème. Même si normalement l'intégration continue est un outil pour aider l'équipe, il est parfois vu comme un outil "gênant".

Pour motiver l'équipe, il faut ajouter du fun :-). Le fun sur notre projet, pour simplifier, c'est d'être un peu ridicule le temps de corriger un build cassé. Voici notre règle : si tu casses l'intégration continue, c'est toi qui porte le chapeau jusqu'à ce que le build soit réparé. Et quand on dit porter le chapeau, c'est au sens propre et il y a même le choix :

Personne n'y a échappé sur le projet. Comme vous allez pouvoir le constater, il y a des têtes à chapeau ou pas.... On retiendra le "ou pas" dans l'équipe... :-). Juste pour repositionner le contexte, nous évoluions à cette époque sur un open space de 30 à 40 personnes qui n'étaient pas concernées par ce projet...

Au passage, merci à tous les membres de l'équipe d'avoir accepté que je publie les photos.

Je vous laisse découvrir ce que cela peut donner :

Bon ok, je commence par moi :

Une version sobre, discrete, ça passe presque inaperçu :

Une version plus "je vous jure que c'est pas moi" :

Une version "pair programming", assez rare à obtenir :

version "total style" :

version "j'assume" et en plus en vidéo :

version "faire abstraction, je suis au téléphone avec le client" :

version "represent" :

Au delà de ça, on va vu des comportements très intéressants émerger au niveau du projet :

Le temps de découverte du build cassé était très court : C'était en général un des membres de l'équipe qui venait gentiment déposer le chapeau sur la tête de la personne qui a cassé le build (le dernier commiteur). On devait être, la plupart du temps, en dessous des 30 secondes après que la notification par mail du "build failed".
Des temps de résolution de build cassé assez court aussi. De l'ordre de 15 minutes. C'est qu'en plus, ils grattent et ils tiennent chaud ces chapeaux :-)
Le fun, c'est contagieux : Il se trouve que le projet voisin du notre sur l'open space faisait aussi de l'intégration continue, le principe du ridicule a été réutilisé, je dirais même amélioré... Je vous laisse juger par vous même :

Je crois qu'au final je préfère nos chapeaux :-).

Tout ça pour dire

que l'intégration continue n'a pas été vécue comme une contrainte au niveau de l'équipe. Bien au contraire :

c'était un moyen d'améliorer la qualité sur le projet (notamment la qualité des commits)
c'était un moyen d'avoir du fun sur le projet et le fameux "team spirit".

Scrum Box : la caisse à outil d'un projet Scrum

2010-12-23T12:09:00.002+01:00

Avez-vous déjà remarqué la rapidité avec laquelle vos pos-its, vos stylos et autres fournitures disparaissent sur votre bureau. C'est d'autant plus gênant sur un projet utilisant Scrum car justement assez gourmand en fournitures.

Pour éviter ça, j'ai créé sur notre projet la "Scrum Box" :

C'est quoi donc "une Scrum box"? :
On peut la voir comme la caisse à outil Scrum de notre projet.

Qu'est-ce qu'elle contient :

Un assortiment de bloc de post-it carré 76mm*76mm. "les standards"
Un assortiment de bloc de pos-it rectangulaire 38mm*51mm. "les petits"
Un assortiment de marqueur pour tableau blanc.
Un assortiment de marqueur pour paper board.
Un ou deux stylos feutre.
Une dizaine de stylos à bille.
Un jeu de carte de Planning Poker.
l'adaptateur vga de mon mbp pour le video projecteur.

Elle doit être identifiée en tant que telle et porter le nom du projet!

Qui s'en sert?

L'équipe et uniquement l'équipe! Il peut y avoir des dérogations si c'est demandé gentiment :-)

Quand s'en sert-on?
Au quotidien, tous les membres de l'équipe viennent y piocher des post-its, prendre des stylos, et choses assez cool : les remettre une fois utilisé.

Et plus particulièrement lors des rituels de début de de fin de sprints : Nous effectuons le sprint planning, la démo et la rétro dans une salle un étage en dessous de celui où nous travaillons. Dans cette box, j'ai quasiment tous ce qu'il me faut pour mener ces rituels.

Est-ce vraiment utile?
Oui! C'est une évidence sur notre projet. On n'y prette même plus attention.
On peut se poser la question de savoir si ça permet de ne pas se faire piquer les fournitures par d'autres collègue sur d'autres projets, hé bien oui ça marche et pourtant la box est en libre service et juste en carton.

Avec elle, impossible d'avoir oublié son stylo lors d'un sprint planning!

Cela me permet d'avoir un stock intermédiaire et dédié au projet de fournitures. Elle permet d'être "toujours prêt". Il y a déjà pas mal de chose à préparer et à transporter lors d'un rituel de début ou de fin de sprint (entre le portable, son chargeur, le video projecteur, des éléments pour faire la démo, ...), la box simplifie le transport de toutes les fournitures :-).

En tant que ScrumMaster sur le projet, ca a été un réel obstacle en moins pour moi ou pour les autres membres de l'équipe. Evidemment, il faut relativiser, il y a d'autres obstacles plus importants et plus compliqués à enlever sur un projet :-).

De retour!

2010-12-23T09:56:00.000+01:00

J'ai délaissé un peu ce blog ces dernier temps. Ce n'est pas une volonté délibérée de ma part mais c'est plus dû à un manque de temps.

Je travaille depuis 6 mois sur un projet passionnant à Norsys où j'interviens en tant que ScrumMaster. Vous trouverez plus d'infos sur ce projet ici. Il y a deux facteurs principaux qui en font pour moi un projet très intéressant :

Une liberté de choix technologique : Sur ce projet, tout est centré sur le but à atteindre et non sur le comment l'atteindre.
"Have fun": Le facteur humain est super important. Une équipe motivée, un vrai "team spirit", la mise en oeuvre de Scrum/XP et c'est le pied! Notre Daily Scrum a même été diffusé sur M6 Capital :-).

Les idées de posts ne manquent pas sur ces différents sujets! Promis, Je m'y mets!

Intégrer un nouveau membre dans une équipe projet

2010-03-08T15:11:00.000+01:00

On m'a récemment demandé si j'avais des suggestions ou des idées sur l'intégration d'un nouveau membre dans une équipe projet.

J'ai évidemment directement suggérer de faire du Pair programming. Le pair programming est une des pratiques de eXtreme Programming

Les bénéfices du pair programming ne sont plus à démontrer mais cette pratique est particulièrement intéressante dans le cadre de l'intégration d'un nouvel arrivant dans une équipe :

L'intégration se fait par l'exemple mais dans des conditions réelles.
Le nouveau membre a tout de suite une vision de comment faire concrètement.
Le risque de "laisser" le nouveau travailler seul n'existe plus. (Principe du "je ferme les yeux, ça va passer, ça va passer...")
Pour le membre de la paire qui fait déjà parti du projet, il va devoir reprendre du recul par rapport à ce qu'il fait pour pouvoir répondre aux questions. Prendre du recul, c'est toujours favorable.
Le nouveau membre se sentira membre de l'équipe beaucoup plus rapidement.
Le nouveau membre sera "opérationnel" beaucoup plus rapidement.
Cela permet de ne pas se retrouver avec le nouveau membre, le jour de son arrivée, assis à un bureau sans rien faire sans login mot de passe et sans poste de travail... (si si, je vous vois sourire, ça arrive tout le temps, il doit d'ailleurs y avoir une "loi" derrière tout ça, c'est à creuser :-)).

Le principal argument qu'on peut entendre en général pour ne pas faire du pair programming :

"Ça va me couter du temps et donc de l'argent car ça va monopoliser un membre de l'équipe."

La réponse à cela est "c'est pas faux" pour ne pas dire "c'est pas vrai" :-) :

L'intégration d'un nouveau membre dans une équipe à un coût. Il faut l'accepter. Cela n'a rien à voir avec le fait de faire du pair programming.
Ce coût est beaucoup moins facile à quantifier quand on laisse le nouveau membre se débrouiller car il est dilué (qualité moyenne des premières réalisations, temps de "parasitage" du nouveau membre envers l'équipe lorsqu'il aura besoin de savoir quelque chose, temps passé à corriger les anomalies découvertes des premières réalisations, ...)
Le membre de l'équipe qui va travailler en pair programming avec le nouveau n'arrête pas de développer, il va juste développer un peu moins vite (mais à contrario c'est directement quantifiable :-)).
Faire du pair programming, ne veut pas dire de faire que du pair programming. Il peut être intéressant d'alterner pendant la durée d'intégration les phases de travail en paire et les phases en autonomie. Cela peut permettre au nouveau membre de monter sa plateforme de développement, de "digérer" la phase de travail en paire, de lire des documentations, de trouver une date pour payer son coup...

Pair programming se dit en français programmation en binôme.

Coding Dojo en entreprise

2010-03-01T17:51:00.009+01:00

J'organise avec Thomas, Guillaume et Jay (amis, collègues et membres de la direction technique de Norsys) des Coding Dojos en interne. J'ai réalisé avec Guillaume un document descriptif / retour d'expérience sur l'organisation de ce type d'évènement. En voici une adaptation :

Un Coding Dojo, Qu'est-ce que c'est ?

Un Coding Dojo est une réunion où un ensemble de personnes se retrouvent pour travailler sur un défi de programmation de façon collective. Un défi de programmation est un problème à résoudre ou un besoin à implémenter.

Chaque coding DOJO se porte sur un sujet particulier qui est décliné en un exercice à réaliser. Il représente le challenge de programmation du DOJO.

Un Coding Dojo permet de mettre en œuvre différentes techniques de programmation notamment lié à l'extrême proggramming :

Pair Programming.
TDD.
…

On pourrait assimiler un Coding Dojo à un Coding party. Ce n'est pas le cas. L'objectif n'est pas de réussir à résoudre le défi de programmation mais plutôt de d'apprendre de façon collective sur la manière d'y arriver.

Un Coding Dojo, Pourquoi faire?

"Si je veux apprendre le Judo, je vais m'inscrire au dojo du coin et y passer une heure par semaine pendant deux ans, au bout de quoi j'aurai peut-être envie de pratiquer plus assidument. Si je veux apprendre la programmation objet, mon employeur va me trouver une formation de trois jours à Java dans le catalogue 2004. Cherchez l'erreur. "

Laurent Bossavit, président de l'association XP-France (Extreme Programming).

Le constat de départ est que trop de développeurs utilisent uniquement leur travail (et leurs réalisations professionnelles) comme terrain d'entraînement pour parfaire leurs techniques. Le principe d'un Coding dojo est de proposer un espace sûr pour que les développeurs puissent expérimenter, tester et apprendre en dehors du cadre d'un projet.

Les personnes qui participent à ce type de réunion doivent le faire par envie et pour améliorer leurs compétences en programmation.

Les principales motivations qui doivent pousser les personnes à participer à un Coding Dojo sont :

l'envie d'apprendre.
l'envie de partager.
l'amélioration continue.

Les caractérisitiques d'un Coding Dojo
Le coding DOJO doit être "un lieu sûr " :

Tous les niveaux de compétences en programmation sont acceptés.
Seule une personne volontaire peut participer à un Coding Dojo.
Ce n'est pas une compétition.
L'erreur est humaine.
Il n'y a pas de jugement.
Le Coding Dojo doit être un moment convivial.
Tout le monde doit participer.

Voici un ensemble de points qui caractérisent un Coding Dojo :

Chacun doit pouvoir s'améliorer à son rythme.
Le but n'est pas de terminer l'exercice mais bien d'apprendre.
Il permet un apprentissage continu/régulier.
Il permet un apprentissage par petits pas.

Il existe 2 types de Dojos :

le kata.
le randori.

Qu'est-ce qu'un Kata?
PRINCIPE :

Le kata est une des formes de Coding Dojo. C'est une démonstration en live de la réalisation d'un défi de programmation en partant de zéro.

image provenant de Dojo@SP (São Paulo)

Un présentateur (un seul programmeur ou un binôme) présente sa solution du défi. Il explique continuellement son cheminement et il affiche sa progression en déroulant continuellement les tests. Le défi est réalisé en entier en TDD (Test-Driven Development). L'interactivité avec le reste du groupe est primordiale.

Le but n'est pas de trouver la meilleure solution mais de comprendre la solution proposée par le présentateur.

CHARTE :
La pratique du TDD appliquée au Kata pour le présentateur (ou binôme) est la suivante :

Rédaction d'un test.
Le test est au rouge (en echec). Si le test ne passe pas, le présentateur doit expliquer aux participants la raison de l'échec. il doit mettre en œuvre le code permettant de réussir le test.
Le test est au vert (réussite). Le présentateur peut souligner de bonnes ou de mauvaises pratiques. La salle peut interrompre le présentateur dans le seul cas où il ne comprend plus le déroulement de la solution.…
Refactoring du code.

Toute restructuration doit être expliquée
et ainsi de suite…

Qu'est ce qu'un Randori
PRINCIPE :

Le randori est l'autre forme de Coding Dojo. L'objectif est d'implémenter une solution de façon collaborative pour un défi. Le principe de base est que tout le monde effectue les rôles de pilote et co-pilote pendant la session.

image provenant de Dojo@SP (São Paulo)

Le binôme de développement est composé d'un pilote qui a le clavier et d'un co-pilote qui implémentent une solution pour le défi en respectant la démarche TDD (Test-Driven Development). Le binôme est changé toutes les 5 à 7minutes par une rotation :

le pilote retourne parmi le reste du groupe.
le co-pilote devient pilote.
une personne du groupe devient co-pilote.

CHARTE :

La pratique du TDD appliquée au randori pour chaque binôme (durée 5 à 7 minutes) est la suivante :

Rédaction d'un test.
Le test est au rouge (en echec). Le binôme de développement à la main. Si le test ne passe pas, le pilote doit expliquer aux participants la raison de l'échec. Les participants n'interviennent que si le binôme le demande. Le binôme doit mettre en œuvre le code permettant de réussir le test.
Le test est au vert (réussite). Les participants peuvent intervenir pour proposer des améliorations, faire des remarques, poser des questions…
Refactoring du code.

Toute restructuration doit être discutéé et avoir l'accord de la majorité des participants.

et ainsi de suite…

Du coté de l'organisation...
QUI PEUT PARTICIPER?
Toutes les personnes qui adhèrent aux principes d'un Coding Dojo.

QUI PEUT ORGANISER?

Toutes les personnes qui adhèrent aux principes d'un Coding Dojo qui ont envie d'organiser ce type d'évènement.

LES CONTRAINTES D'ORGANISATION :

Pour organiser un Coding Dojo, il faut :

Un lieu.
Une date.
Une durée fixe est définie avant le Coding Dojo.
Un sujet + langage de programmation.
Un mode de fonctionnement kata ou randori.

LA LOGISITIQUE À PRÉVOIR:

D'un point de vue logistique il faut :

Que les participants possèdent une adresse mail pour les communications qui précédent et suivent une session.
Une salle.
Une table (au moins).
Des chaises pour l'ensemble des participants
Un video projecteur.
Un ordinateur portable.
Un paper board ou white board.
Des post-its.
Des stylos.
Un appareil photo (optionnel)
Une Caméra (optionnelle)

Exemple : Un Dojo à Norsys
AVANT :
Il faut :

Choisir une date.
Choisir le lieu.
Choisir le sujet (soit par un vote public, soit par un choix au niveau des organisateurs).
Réserver les éléments logistiques nécéssaires (video projecteur, salle, …).
Préparer un système d'inscription en ligne et de choix de sandwich(doodle ou formulaire google docs).
Envoyer l'annonce du Dojo (date, lieu, contenu, lien vers le système d'inscription.
Solliciter les personnes qui doivent préparer des choses pour la session pour s'assurer qu'il n'y ai pas de malentendu.

JUSTE AVANT :

Envoyer un mail de rappel aux inscrits avec le choix de leur sandwich.
Gérer la commande de sandwich.
S'assurer que les éléments logistiques réservés sont bien disponibles.

PENDANT :

12h00-12h30 : arrivée progressive des participants. Préparation de dernière minutes. Distribution des sandwichs et récupération de l'argent.
12h30-13h30 : Coding Dojo.
13h30-14h00 : Discussion autour du Dojo. Rangement . Départ progressif des participants.

APRÈS :

Mettre à disposition le code de la session.

Difficultés

Un coding Dojo réprésente malgré tout un défi d'organisation :

Cela prend du temps.
Il faut résoudre les difficultés logistiques en amont d'une séance.
Il faut se mettre d'accord sur un sujet et ça n'est pas toujours évident.
Durant la séance : Ne pas oublier que l'ojectif premier est d'apprendre et non pas de terminer l'excercice. Il faut trouver un bon equilibre entre le développement l'échange.
1 heure, c'est très court. Le souhait de de développer le plus possible et de faire participer tout le monde.
Travail collaboratif. Il faut faire des choix dans un temps restreint et dans le cadre d'une rélfexion commune.

Quelques références :

http://www.slideshare.net/ehsavoie/agile-tour-2009-coding-dojo-kata-atdd (Merci à Emmanuel de m'avoir m'autoriser à réutiliser ses schémas et photos)
http://codingdojo.org/
http://linuxfr.org/2008/12/19/24813.html
http://clubagile.org/
http://groups.google.com/group/nord-agile/

A vous de jouer :-)

Bench de framework web service java : Axis2 vs Cxf vs Spring ws

2010-02-11T14:37:00.005+01:00

C'est quoi un framework web service? :

Les frameworks web service java ont pour objectif de s'affranchir des problématiques techniques liées à la mise en oeuvre d'un web service pour permettre de se concentrer sur le traitement qui doit être réalisé par celui-ci et de simplifier son appel. Dans les grandes lignes, ils permettent :

coté client : de générer les classes à partir d'un WSDL permettant de créer une grappe d'objet correspondant au message SOAP du web service de façon transparente.
coté serveur : de récupérer une requête HTTP SOAP, de transformer le contenu du message en une grappe d'objets, d'appeler une méthode java correspondant à la requête puis de récupérer l'objet en retour de l'appel de la méthode et de le transformer en réponse HTTP SOAP.

Plusieurs méthodes de développement sont associées à ces frameworks :

Contract first : définir un contrat d'échange et ensuite de s'appuyer sur ce contrat pour développer le service à l'aide du framework.
Code first : développer un service java et ensuite s'appuyer sur le framework pour qu'il expose la méthode sous forme de web service.

Ces deux méthodes font débats et je ne vais pas m'attarder dessus dans le cadre de ce bench dont ce n'est pas l'objet. J'y reviendrai peut être dans un autre billet...

Les frameworks testés :
Je me suis attardé sur les frameworks les plus connus :

Apache Axis2 (version 1.5.1)
Apache Cxf (version 2.2.5)
Spring ws (version 1.5.9)

Objectif du bench:
L'objectif du bench est de mesurer le temps passé dans les couches techniques des frameworks web services en dehors du réel traitement que doit effectuer le web service et cela différent niveau de charge. Le tout est de pouvoir mesurer l'overhead engendré par les frameworks web services par rapport à un appel direct de méthode en java et de comparer cet overhead. Le bench se focalise sur les temps de traitements coté serveur :

Caractéristiques du bench :

les web services exposés :

J'ai mis en place le même web service avec les 3 frameworks dans 3 webapps indépendantes. Les temps de réponses sont mesurés coté client. Pour que les temps de réponse coté client correspondent à l'overheard technique coté serveur, le traitement métier est inexistant : Le service java ne fait que renvoyer l'objet récupérer en paramètre :

La requête en entrée ainsi que la réponse en retour sont représentatifs d'un "vrai" web service (dans le sens ou ce n'est pas un simple hello world) :

60 données unitaires
3 niveaux de profondeur
requête SOAP de 3.75 Ko

Du coté du client :

J'ai mis en oeuvre un injecteur http maison multithreadé et basé sur commons-httpclient qui envoie directement la requête SOAP prédéfinies et mesure les temps de réponse. J'ai d'abord fait des tests avec SoapUI en local sur mon poste mais je ne voulais pas "pollué" les résultats en saturant le poste client et j'ai donc décidé de mesurer les temps de réponse client à partir d'un serveur plus puissant que mon poste et dédié au bench.

Du coté du serveur :

J'ai déployé les 3 webapps dans un JBoss 5.1.0 "out of the box" s'appuyant sur une JVM Sun 1.6.0_18. J'ai simplement augmenté la taille de la JVM.

procédure du bench :

J'ai monté en charge les uns après les autres chacun des web services exposés avec : 10, 50 et 100 clients (threads) simultanés effectuant chacun 2000 appels. Le test est répété 4 fois pour vérifier la stabilité des temps de réponse sur plusieurs essais.

Résultats :

Voici le tableau détaillé :

Dans le cadre de ce bench, CXF est donc le framework le plus performant suivi d'assez prêt par Spring ws. Axis2 est clairement moins performant indépendamment du niveau de charge coté serveur.

Conclusion :

J'ai été confronté à quelques problèmes de déploiement sur JBoss à cause de librairies utilisées à la fois par les frameworks et par JBoss avec Axis2 et Spring ws. Sur cet aspect là, la communauté et la documentation autour de Spring permettent de résoudre rapidement le problème alors que pour Axis2, il a fallu creuser un peu plus.

JBoss : permettre les accès distants

2010-02-09T09:11:00.002+01:00

Depuis la version 4.2 de JBoss, la configuration de l'accès aux services réseaux est mappé sur le 127.0.0.1 (la machine en local). Cela rend JBoss complètement hermétique à toutes connexions distantes à ses services. Cette nouvelle configuration a pour objectif de sécuriser le JBoss.

Pour autoriser des accès distants au services de JBoss, il faut alors démarrer le serveur l'option -b en précisant l'ip que vous désirez autoriser.

Voici la commande de lancement pour autoriser toutes les ips (qui est la configuration par défaut des versions antérieures de JBoss) :

run.sh -b 0.0.0.0

Formation certifiante Scrum Master avec Jeff Sutherland

2009-10-16T14:00:00.000+02:00

J'ai participé à la formation certifiante Scrum Master du 1er et 2 Octobre dernier organisé par Xebia à Paris La Défense avec Monsieur Jeff Sutherland (le papa de Scrum).

Je ne peux que trop vous conseiller de faire cette formation!

J'étais déjà convaincu par ce peut apporter Scrum (couplé avec XP par exemple), et après la formation, ça ne s'est pas arrangé.

Il faut par contre, à mon avis avoir, déjà débroussailler le terrain sur Scrum et les grands concepts pour assister à cette formation. Je vous conseille par exemple : "Scrum and Xp From the trenches" de Henrik Kniberg. C'est une bonne première approche. Le livre est disponible gratuitement en version numérique. Prenez la version original en anglais, ça vous aidera aussi si vous voulez assister à la formation qui est en anglais :-).

Pour en revenir à la formation, Jeff ne s'attarde pas plus que ça sur les grands concepts en début de formation. Il les aborde tout au long de la formation. En revanche, il insiste plus sur ces retours d'expériences et sur le fait que cette méthode, pardon ce framework, est sacrément efficace. Jeff est un bon évangéliste sur le sujet :-). Les références sont quand même Google, Apple ainsi que de très grand groupe.

J'ai bien aimé la partie concernant les projets en échecs et qui disent utiliser Scrum et qui en grattant très légèrement ne l'utilise pas vraiment, voir pas du tout.

J'ai bien aimé le planning poker avec l'application sur mon Iphone :-). C'est totalement "In".

J'ai bien aimé le léger focus sur le rôle de Product Owner qui est très très très important.
Il nous a d'ailleurs posé la question : "Who is the best Product Owner in the World?" la réponse ici. J'adore...

J'ai bien aimé enfin le fait qu'on ai réellement le temps de poser toute nos questions. pas de langue de bois.

Les mises en situation tout au long des 2 jours de la formation sont très intéressantes. Le XP game en fin de formation est top.

La prochaine session en France est normalement prévu le 3 et 4 décembre 2009. Vous trouverez plus de détails ici.

J'ai rarement vu une formation où tout le monde veut prendre sa petite photo avec le formateur à la fin de la formation. C'est peut être une preuve de la qualité de la formation... ou pas... bon ok j'ai été faible, j'ai la mienne aussi...

Bon maintenant le problème, c'est que je ne vois pas comment je vais faire rentrer Scrum chez mon client autrement qu'en allant voir le CEO :-).

Le ch'ti Jug du 21 Septembre

2009-10-16T10:51:00.009+02:00

Avec un peu de retard, mais il vaut mieux tard que jamais, voici un petit retour sur le Ch'ti Jug du 21 Septembre sur Bean validation et Hibernate Search.

La salle était pleine malgré le lieu de la session (assez éloigné du centre de Lille...).

Je ne suis pas forcément très objectif sur la qualité de cette session vu que je faisais partie des organisateurs coté Norsys. Voici en revanche un retour d'Arnaud Bailly sur la session sur son blog.

La soirée s'est poursuivie par le petit coup à boire classique de fin de session et par un resto sur Lille pour les irréductibles :

Les slides de la présentations sont disponibles sur le blog du cht'ti Jug ici.

La session a été filmée par Arnaud Buisine (qui a passé pas mal d'heures aussi sur le montage...). Voici la vidéo en preview :

Je tenais à remercier Emmanuel pour la qualité de sa présentation. Ainsi que Didier, Tom, Pascal, Mathilde et Denis pour leur aide précieuse!

ps : Servir de la bière à partir d'une pompe à bière à 5 bar de pression dans des gobelets en plastique, c'est très très sport :-)

Ch'ti Jug : session du 21 Septembre

2009-09-07T16:33:00.003+02:00

Ca y est les inscriptions pour la session du Ch'tiJug hébergée par Norsys sont ouvertes!

http://chtijug.org/session-21-septembre-hibernate-search-validation-norsys/

C'est effectivement Emmanuel Bernard, leader technique chez JBoss sur Hibernate Annotations, Hibernate EntityManager, Hibernate Search et Validator, qui animera la présentation.

Si vous désirez y participer, n'hésitez pas à vous inscrire assez rapidement car les places sont limitées et ont l'air de partir assez vite...

Un Ch'ti Jug chez Norsys

2009-08-10T11:20:00.003+02:00

Une session du Ch'ti Jug va être effectuée chez Norsys (Région Nord) dans les locaux d'Ennevelin à la rentrée le 21 Septembre. Ils en parlent ici.

Emmanuel Bernard viendra parler de JPA2, Bean Validation et Hibernate Search.

Plus d'informations viendront par la suite notamment sur le blog du Ch'ti Jug. Restez à l'affut...

Ch'ti Jug sur Maven2

2009-06-16T08:53:00.004+02:00

A cause du nom de mon blog, je suis obligé d'en parler :-).

J'ai participé hier à la 2ème session du ch'ti Jug dont le sujet était sur Maven2.

C'était Arnaud héritier qui animait la présentation. Il parle d'ailleurs de sa future intervention au Ch'ti Jug ici.

La présentation d'Arnaud était de qualité. Je n'ai pas forcément appris énormément de choses nouvelles sur Maven en revanche, je retiens que je suis d'accord avec lui sur les bonnes pratiques autour de Maven et que je vais dans le bon sens :-).

La petite touche d'humour est que j'ai gagné une licence IntelliJ IDEA, l'IDE dont on dit beaucoup de bien, en répondant à une question sur Maven : De quel projet est-il issu?... "and the answer is..." Turbine.

J'ai été étonné de l'affluence à la présentation. Pour une 2ème session, nous étions dans les 70 personnes "selon la police" :-). Quand on compare ce nombre aux affluences du Jug de Paris par exemple, c'est prometteur pour la suite de ce Jug régional!

Norsys, une réunion d'agence "Agile"

2009-04-17T10:14:00.008+02:00

Hier soir a eu lieu la classique réunion d'agence de Norsys Région Nord dans les locaux d'Ennevelin.

La réunion avait l'originalité d'être présentée comme une réunion d'agence "Agile". Ça mérite bien un billet pour en parler.

Pour bien repréciser le sujet, il n'existe pas réellement de réunion "Agile" c'est pour cela que dans le titre du billet Agile est entre guillemet... En revanche, l'originalité de la réunion réside dans la réutilisation de certains concepts et de certaines méthodes Agiles pour organiser son déroulement.

Voici les différents points d'organisations intéressants :

Ce sont les salariés qui ont choisi parmi un ensemble de thèmes (business, stratégie 2009, les méthodes Agiles, RH, informations sur le groupe Norsys...) ceux qui allaient être débattus pendant la réunion.
Chaque thème devait être présenté en 10 minutes, pas plus, pas moins.
L'utilisation du powerpoint pour présenter un thème était quasiment interdit pour favoriser d'autres modes de restitution visuels et originaux.

L'ensemble des salariés a donc été sollicité par mail en amont de la réunion pour choisir des thèmes. Lors de la réunion, pendant un premier "sprint", les thèmes retenus par mail ont été abordés et 2 thèmes ont été retenus en live pour être présenté dans un second sprint. Un pot convivial a été organisé après la réunion.

Les présentateurs ont utilisé des moyens originaux pour rendre fun la restitution des thèmes abordés (rappelons que le coté fun fait évidemment parti des méthodes Agiles) :

interview.
proposition de sujets par paper board/post-it.
réutilisation du principe de "TODO", "IN PROGRESS" et "DONE" sur un tableau pour présenter l'avancement d'un thème.
réalisation d'un "Dessinez c'est gagné" numérique "videoprojeté" (cf photo) pour trouver les sujets d'un thème.
Diffusion d'une vidéo pour présenter un thème.
réalisation d'une petite exposition dans une salle annexe pour présenter un thème.

remarques diverses :

La réunion a rassemblé une grande majorité des salariés hier soir.
Nos chers commerciaux n'ont pas réussi à respecter les 10 minutes pour présenter la partie business :-).
La réunion était très vivante et participative.
La réunion a été Fun!
L'agence est maintenant en rupture de stock de paper board et de post-it :-).
Les modes de restitutions des thèmes ont été très originaux.

Dans tous les cas, ça changeait de l'ordinaire et il fallait le souligner.

Migration Maven 2 : 3ème épisode : retour d'expériences

2009-03-26T17:11:00.006+01:00

Il est vrai que je n'avais pas fait de 3ème épisode concernant ce sujet de migration de maven1 vers maven2.

Voici alors le 3ème épisode de la migration plutôt sous la forme d'un retour d'expérience... tintintin...

La migration a été effectuée sur 2 gros projets J2EE avec des processus de build assez complexe. L'utilisation de maven2 est effective depuis maintenant quelques mois. Voici en vrac quelques remarques par rapport à des ajustements effectués après la migration :

delta au niveau du contenu des archives j2ee. Les archives j2EE ont tendance à prendre de l'enbonpoint (gestion des dépendances transitives, repository différents) : bien définir les exclusions et scopes.
changement de comportement du build suite à l'apparition d'une nouvelle version du plugin : fixer la version de tous les plugins.
confusion possible avec les fichiers de conf maven1 : une fois que l'utilisation maven2 est bien intégrée, faire le ménage sur les anciens fichiers de conf maven1 qui "polluent" le gestionnaire de sources.

Maven1 est en train d'être oublié par les équipes de développement, preuve que la migration est un succès.

Retouche photo en ligne : Pixlr

2009-03-09T15:45:00.004+01:00

Dans le cadre d'un développement orienté web, si vous avez besoin de faire des petites retouches photos, je vous conseille d'utiliser Pixlr. C'est un bon compromis entre une interface simple et conviviale et un nombre de fonctionnalités déjà assez important (Pixlr prend en charge la gestion des calques par exemple).

Le tout est réalisé en Flash et propose des raccourcis clavier. On oublie même que c'est une interface "web". Il ne faut même pas s'inscrire...

Les virtuoses du photoshop seront surement déçus mais pour un outil gratuit et en ligne, c'est assez surprenant.

Voici l'adresse du site :
http://www.pixlr.com

Causes d'échec de l'Intégration continue

2009-02-10T11:01:00.009+01:00

Dans certain cas, aux yeux d'une équipe de développement, l'intégration continue se limite à recevoir un mail quand le "build" de l'application échoue. Le problème est que l'intégration continue ne se limite pas seulement à ça...

Il ne faut pas oublier que l'intégration continue n'est pas qu'un outil mais bien un ensemble de pratiques autour de l'ingénierie logicielle. Dans un de ces articles, Martin Fowler présente les pratiques d'intégration continue sur son site.

Voici quelques causes probables d'échecs sur la mise en place d'une démarche d'intégration continue :

un manque de connaissances de l'ensemble des pratiques d'intégration continue par l'équipe (y compris les managers).

une mise en place d'un serveur d'intégration continue au niveau d'une équipe projet sans communiquer, informer sur les bénéfices de ce type de démarche et intégrer les principes de fonctionnement que cette mise en place entraine.

Si la volonté de mettre en place ce type de démarche ne vient pas de l'équipe , il faut alors présenter et communiquer autour de la démarche. Il ne faut pas oublier que ce type de pratique est fait pour les équipes de développements et pour leur permettre de travailler efficacement ensemble.

L'intégration continue est avant une histoire de communication. Cela doit être une culture au niveau du projet. Il faut rendre "fun" la pratique de l'intégration continue!

Supprimer les EJbs par Spring

2009-01-29T11:23:00.018+01:00

J'ai procédé chez mon client à la réalisation d'une étude sur la suppression des EJBs Sessions sur un de leur applicatif java.

Pourquoi supprimer les EJBs Sessions?

Pour simplifier l'architecture logicielle de l'applicatif.
Pour simplifier la plateforme de développements.
Pour simplifier le processus de construction de l'application.
Pour augmenter la productivité des développeurs.
Pour banaliser l'infrastructure serveur (pas de différenciation serveur métier et serveur présentation).

Qu'apportent les Ejbs Sessions au niveau de l'applicatif?

La possibilité de séparer sur des infrastructures différentes la partie présentation et la partie métier. Cette possibilité n'est plus exploitée du fait de leur volonté de banaliser l'infrastructure serveur.

La possibilité d'appeler la couche Ejbs ( couche "métier") depuis d'autres applications. Ce choix d'interfaçage n'a pas été retenu et il sera pris en charge par la mise en place de Web Services.

La gestion des transactions. C'est la problématique intéressante qui reste à traiter... avec Spring évidemment...

L'intégration de Spring pour prendre en charge la gestion des transactions est réellement facile. Il existe 2 possibilités :

de façon déclarative dans le fichier de conf Spring.
Par annotation.

Après avoir testé les 2, j'ai choisi de le faire par annotations. L'inconvénient est d'être intrusif en rajoutant les annotations "@Transactional" dans le code. En revanche, cela augmente la lisibilité au niveau du code. Dans tous les cas, je crois qu'il n'y a pas de mauvaises façons de faire avec Spring mais dans tous les cas des façons "simplifiantes". Voici le lien vers la documentation de Spring qui m'a aidé concernant la gestion des transactions.

Dans le cadre du projet concerné, l'environnement de développement se base sur un simple serveur web Tomcat alors qu'en production, c'est un serveur d'application JBoss. L'applicatif à aussi la particularité d'utiliser un ensemble de datasources.

J'utilise alors un transaction manager différent selon l'environnement :

Dans l'environnement de développement avec Tomcat, je ne pouvais pas me servir du transactionManager proposer par Spring (org.springframework.jdbc.datasource.DataSourceTransactionManager) car il ne gère qu'une seule source de données. Un article sur le site javaworld explique comment mettre en place un "ChainedTransactionManager" qui s'appuie ensuite sur le transactionManager de spring et permet de gérer plusieurs datasources. Voici un extrait de conf spring correspondante :

 <!-- aop pour la gestion des transactions -->
<tx:annotation-driven transaction-manager="txManager" />

<!-- recuperation des datasources en jndi -->
<jee:jndi-lookup id="datasource1" jndi-name="jdbc/ds1" />
<jee:jndi-lookup id="datasource2" jndi-name="jdbc/ds2" />
<jee:jndi-lookup id="datasource3" jndi-name="jdbc/ds3" />
<jee:jndi-lookup id="datasource4" jndi-name="jdbc/ds4" />

<!-- declaration du transaction manager -->
<bean name="txManager" id="txManager" class="com.springsource.open.db.ChainedTransactionManager">
<property name="transactionManagers">
<list>
 <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
  <property name="dataSource" ref="datasource1" />
 </bean>
 <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
  <property name="dataSource" ref="datasource2" />
 </bean>
 <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
  <property name="dataSource" ref="datasource3" />
 </bean>
 <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
  <property name="dataSource" ref="datasource4" />
 </bean>
</list>
</property>
</bean>

Dans l'environnement de production avec Jboss, pas de soucis, j'utilise le transaction manager JTA de spring (org.springframework.transaction.jta.JtaTransactionManager). Voici l'extrait de la conf Spring correspondante :

 <!-- transaction manager JTA -->
<bean name="txManager" class="org.springframework.transaction.jta.JtaTransactionManager" />


<!-- aop pour la gestion des transactions -->
<tx:annotation-driven transaction-manager="txManager" />

Maven et les dépendances transitives

2008-11-14T09:58:00.002+01:00

Une des évolutions de maven2 par rapport à maven1 concerne la gestion de dépendances transitives : La définition d'une dépendance au niveau d'un projet entraîne la récupération des dépendances de cette dépendance et ainsi de suite...

Sur de gros projets, la gestion des dépendances avec Maven est quasiment indispensable. J'ai même dû mal à comprendre qu'on puisse faire sans.

Avec les dépendances transitives, on se retrouve vite à récupérer la terre entière et à avoir des dépendances qui utilisent des dépendances transitives communes mais dans des versions différentes...

On voit apparaître des exceptions du type "NoClassDefFoundError" à l'exécution et c'est là que le casse tête commence...

Voici ce que j'utilise pour résoudre ce genre de problème :

la commande du plugin maven "dependency" pour découvrir les dépendances en double :
```
mvn dependency:tree
```

La mise en place de tags d'exclusion au niveau des pom.xml pour permettre de définir une dépendance mais d'exclure certaines de ces dépendances transitives :

<dependency>
 <groupId>yourDependencyGroupId</groupId>
 <artifactId>yourDependencyArtifactId</artifactId>
 <version>yourDependencyVersion</version>
 <exclusions>
   <exclusion>
     <groupId>ExcludedTransitiveDependencyGroupId</groupId>
     <artifactId>ExcludedTransitiveDependencyArtifactId</artifactId>
   </exclusion>
 </exclusions>
</dependency>

Scrum fait peur

2008-11-07T13:56:00.010+01:00

Et plus largement les méthodes Agiles.

C'est le constat que je peux faire dans le contexte dans lequel j'évolue.

Je me suis longtemps dit qu'en effet, se lancer dans un premier projet en Scrum peut faire peur alors que l'on n'a jamais fait cela auparavant. En revanche, lorsque le contexte le permet, que des gens compétents sur le sujet y participent et qu'il n'y a pas réellement de risques à faire "un essai" ( :-) les experts comprendront...) , j'ai plus de mal à comprendre...

Une des grosses évolutions par rapport à des méthodes de gestion de projet dites "traditionnelles" (ou plutôt celles qui ne fonctionne pas ou peu) concerne le métier de chef de projet qui n'existe plus car il est remplacé/transféré par le rôle du ScrumMaster.

En se mettant un peu à la place d'un chef de projet, il est plus facile de comprendre (mais pas forcément d'accepter) leurs points de vue. Imaginons qu'on vienne vous dire que votre façon de travailler depuis des années soit totalement remise en questions, que des retours d'expériences vous démontre que c'est presque une évidence et que vous n'y avez pas pensé. Cela ne doit pas être évident à encaisser...

Messieurs les chefs de projets, je vous le dit :
Scrum ça n'est pas l'avenir, c'est tout de suite! Allez-y!

Juste pour le fun, une petite tendance à la google :

en bleu : rational unified process
en rouge : Scrum agile

Comme le précisez Claude Aubry sur son blog dans ce billet en 2007, il faut faire attention à ne pas créer un Buzz autour de Scrum et le transformer en une méthode un peu originale et à la mode. Scrum c'est avant tout un ensemble de pratiques simples et pragmatiques à mettre en œuvre pour réussir un projet.

Une métaphore de Scrum

2008-11-03T09:35:00.004+01:00

Le Touilleur Express vient de publier une métaphore permettant d'expliquer les grands concepts autour de Scrum.

Pour Simplifier, Scrum : c'est une machine à laver. J'adore.

Je vous laisse aller lire le billet du Touilleur Express sur le sujet pour avoir plus d'infos.

Retour sur... l'Agile Tour 2008 à Lille

2008-10-17T16:42:00.004+02:00

L'Agile Tour 2008 à fait escale mardi dernier à Lille.

Pour résumé :
- les locaux de l'école d'ingénieurs Telecom Lille1 était impeccable pour l'évènement.
- l'organisation était sans faille.
- les sessions (soit orientées "présentation" soit orientées "atelier") étaient de grande qualité.

J'ai été surpris de voir que le public semblait majoritairement connaître les grands principes autour des méthodes Agiles. Ce n'est peut-être qu'une impression liée au public des sessions auxquelles j'ai assisté...

Le seul reproche que je puisse faire : c'était trop court! En même temps, ce n'est que la première édition. Il ne faut pas être trop gourmand...

En tous cas pour une première, c'était vraiment bien!

Vivement l'année prochaine! Enfin je l'espère.

Iphone, la belle bête

2008-10-08T15:21:00.003+02:00

Je suis l'heureux possesseur d'un Iphone 3G depuis quelques semaines (merci chérie...).

L'Iphone pour moi c'est :
- un bel objet.
- un gadget perso.
- un outil pro.
- une ergonomie incroyable.
- un Ipod.
- un téléphone conviviale.
mais c'est surtout : internet dans la poche.

Il fallait le dire. C'est chose faite...

J'ai dû recevoir 2 MMS dans ma vie dont un juste après l'obtention de l'Iphone... et la c'est le drame.

Heureusement j'ai été voir le fameux MMS sur le site d'Orange avec l'Iphone. Et Hop, ça c'est fait.:-)

Agile Tour 2008

2008-10-06T13:36:00.003+02:00

Un grand rendez-vous à ne pas manquer!!!

L'Agile Tour "Le rendez-vous francophone de l'agilité" (http://www.agiletour.com/) passe par Lille le 14 Octobre Après-midi.

Pour ceux que ça intéresse (débutant, amateur ou professionnel), il est possible de s'inscrire sur le site.

Voici le wiki de la session de Lille : http://wiki.agiletour.com/At2008Lille

Java, Moteur de template : Freemarker

2008-08-28T17:29:00.004+02:00

Voici un moteur de template efficace : Freemarker

Le concept et de concevoir un template (un modèle contenant des "variables") :
inputTemplate.ftl :

<html>
<head>
<title>les Contacts</title>
</head>
<body>
<div>
</div>
Les contacts de ${carnet.proprietaire.prenom} ${carnet.proprietaire.nom}
<div>
<table>
<tr>
<td>nom</td>
<td>prenom</td>
</tr>
<#list carnet.lesContacts as unContact>
<tr>
<td>${unContact.nom}</td>
<td>${unContact.prenom}</td>
</tr>
</#list>
</table>
</div>
</body>
</html>

Construire une structure objet contenant les valeurs des variables à remplacer dans le template :

  Map root = new HashMap();

/* structure agenda */
Map agenda = new HashMap();
root.put("carnet", agenda);

/* structure proprietaire (dans agenda) */
Map proprietaire = new HashMap();
agenda.put("proprietaire", proprietaire);

/* remplissage de la structure proprietaire */
proprietaire.put("nom", "Dupont");
proprietaire.put("prenom", "Jean");

/* structure contacts (dans agenda */
List lesContacts = new ArrayList();
agenda.put("lesContacts", lesContacts);

/* remplissage des contacts */
Map unContact = new HashMap();
lesContacts.add(unContact);
unContact.put("nom", "Bond");
unContact.put("prenom", "James");

unContact = new HashMap();
lesContacts.add(unContact);
unContact.put("nom", "Woman");
unContact.put("prenom", "Cat");

Fusionner le template et la structure objet dans un fichier de destination :

   InputStreamReader fileTemplate = new InputStreamReader(ClassLoader
   .getSystemResourceAsStream("inputTemplate.ftl"));
 Configuration cfg = new Configuration();
 cfg.setObjectWrapper(new DefaultObjectWrapper());
 Template temp = new Template("inputTemplate.ftl", fileTemplate, cfg);

 Writer out = new OutputStreamWriter(System.out);
 temp.process(root, out);
 out.flush();
 out.close();

C'est évidemment un exemple assez simple mais les possibilités offertes par Freemarker sont très larges.

Pour plus d'informations : http://freemarker.sourceforge.net/

Java: Scanner un répertoire

2008-08-27T08:25:00.004+02:00

Dans la cadre du développement de plugin maven 2, récupérer un ensemble de fichier selon certains critères peut être intéressant :
- récupérer un sous ensemble de fichiers source java.
- récupérer un ensemble de properties.
- ...

Plexus est là! Cette librairie est déjà largement utilisée par les plugins maven 2.

La classe DirectoryScanner vous permettra de faire ça.
Il faut lui spécifier :
- un répertoire de base.
- des patterns d'inclusions et d'exclusions (en options) du style "**/**.properties".
puis appeler la méthode scan() et récupérer ensuite un tableau avec l'ensemble des chemins des fichiers correspondant à la recherche.

Pour plus d'informations, tout est dans la javadoc de la classe.

wonderfull!

requête XPath en java

2008-08-21T10:21:00.003+02:00

Une solution simple (à mon goût) existe pour récupérer une valeur ou un attribut dans un fichier Xml en java sans avoir à le parcourir complètement avec Sax ou avec Dom.

Voici un petit exemple de mise en œuvre des APIS XPATH de java 1.5 s'appuyant sur Sax :

Voici le fichier XML source :

<?xml version="1.0" encoding="ISO-8859-1"?>
<level1>
 <level2 level2-attribute1="valueOfLevel2-attribute1">
  <level3 level3-attribute1="valueOfLevel3-attribute1">
   <level41>valueOfLevel41</level41>
   <level42>valueOfLevel42</level42>
  </level3>
 </level2>
</level1>

le code "technique" :

...
import java.io.InputStream;
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathExpression;
import javax.xml.xpath.XPathExpressionException;
import javax.xml.xpath.XPathFactory;
import org.xml.sax.InputSource;

...
 
 public static String executeXpath(InputStream sourceXml, String xPathQuery)
   throws XPathExpressionException {

  // creation de la source sax
  InputSource source = new InputSource(sourceXml);

  // creation de la requete XPTAH
  XPathFactory xPathFactory = XPathFactory.newInstance();
  XPath xpath = xPathFactory.newXPath();
  XPathExpression xPathExpression = xpath.compile(xPathQuery);

  /* execution de la requete xPath sur le fichier XML */
  String resultat = (String) xPathExpression.evaluate(source,
    XPathConstants.STRING);

  return resultat;

 }
 ...
}

La mise en œuvre :

public static void main(String[] args) {

      try {
          /* recuperation du flux xml */

          InputStream xml = null;
          String result = null;
          String xPathQuery = null;

          /* exemple 1 */
          xml = Main.class.getResourceAsStream("/fichier.xml");
          xPathQuery = "/level1/level2/@level2-attribute1";
          result = XpathHelper.executeXpath(xml, xPathQuery);

          System.out.println("xpathQuery : " + xPathQuery
                  + "---> resultat : " + result);

          /* exemple 2 */
          xml = Main.class.getResourceAsStream("/fichier.xml");
          xPathQuery = "/level1/level2/level3/level41";
          result = XpathHelper.executeXpath(xml, xPathQuery);

          System.out.println("xpathQuery : " + xPathQuery
                  + "---> resultat : " + result);
      } catch (XPathExpressionException e) {
          e.printStackTrace();
      }

  }

Le résultat en console :

xpathQuery : /level1/level2/@level2-attribute1---> resultat : valueOfLevel2-attribute1
xpathQuery : /level1/level2/level3/level41---> resultat : valueOfLevel41

Le tout a le mérite d'être assez simple, élégant et performant.

Migration Maven 2 : 2ème épisode : la procédure

2008-07-23T09:47:00.012+02:00

Suite de la migration... Comme je le précisais dans le première épisode dans ce post. J'ai procédé à la migration de gros applicatifs J2EE de maven 1 vers maven 2.

Une fois devant l'écran, un peu comme un écrivain, c'est un peu la page blanche : Par où commencer???

Je vais m'efforcer de vous décrire la procédure que j'ai appliquée:

Maitriser et comprendre l'applicatif et le processus de build maven 1 existant :

Avant tout, je pense qu'il faut bien connaître l'applicatif ainsi que le processus de build à migrer, en tous cas d'un point de vue technique. Cette connaissance va permettre de déceler les points sur lesquels il va falloir mettre l'accent plus particulièrement (où ça va coincer :-))
Dans mon cas, il se trouve que quasiment chaque projet java (l'applicatif est composé d'un ensemble de projets java) est muni de son project.xml mais surtout est quasiment toujours accompagné d'un fichier maven.xml. Pas de chance, il y a pas mal de spécificités de build qui ont été mises en œuvre : génération de code source en tout genre, concaténation de fichiers, exécution de tâches ant diverses et variées,...

Posséder une plateforme "témoin" :

Un des principales objectifs est de réussir à fournir, avec un processus de build différent, les mêmes livrables j2EE (un ear et plusieurs wars dans mon cas). Je me suis installé l'ensemble de la plateforme de développement et effectué des builds avec le processus de build maven 1 existant. Ce système permet d'avoir un environnement "témoin" permettant d'effectuer des comparaisons entre l'ancien build et le nouveau build. Concrètement, ça revient à récupérer 2 fois les projets de sources sur le poste:
- les projets de sources maven 1 "témoin".
- les projets de sources sur lesquels travailler pour effectuer la migration maven 2.

Migrer les dépendances

Dans un premier temps, il faut analyser et lister les dépendances dont le projet a besoin. Un bon vieux tableur facilite le travail. Pour chacune de ces dépendances, il faut vérifier si elle est disponible dans un repository maven 2 sur la toile grâce à ce site par exemple. Pour celles qui n'existent pas, il faut les installer dans le repository maven 2 de l'entreprise (s'il n'y en a pas, c'est un travail à faire... et pourquoi pas aussi mettre en œuvre Archiva , oulaaa, je m'emballe!) :

mvn deploy:deploy-file -Durl=file://C:\m2-repo \
                    -DrepositoryId=some.id \
                    -Dfile=your-artifact-1.0.jar \
                    [-DpomFile=your-pom.xml] \
                    [-DgroupId=org.some.group] \
                    [-DartifactId=your-artifact] \
                    [-Dversion=1.0] \
                    [-Dpackaging=jar] \
                    [-Dclassifier=test] \
                    [-DgeneratePom=true] \
                    [-DgeneratePom.description="My Project Description"] \
                    [-DrepositoryLayout=legacy] \
                    [-DuniqueVersion=false]

Mettre en place un premier pom.xml

Dans le cadre d'applicatif j2EE découpé en un ensemble de projets Java/Maven, il est difficile de migrer l'ensemble des POM en une seule fois. Il est important de procéder de façon itérative et de se concentrer sur la migration d'un des projets (simple en terme de build si possible) pour commencer.

Capitaliser et centraliser le build

Les possiblités en terme d'héritage et de gestion "multi module" de Maven permettent :
- de réutiliser comportement de Pom en définissant des Pom parent, grand-parent, ...
- de piloter l'ensemble des projets en définissant un Pom multimodule.

En conservant à l'esprit ce type de pratique, j'ai progressivement procédé à des refactorings de Pom au fur et à mesure de la mise en place des Pom des projets. Voici une version simplifiée de mon arborescence de Pom :

pom "base"
pom projet utilitaire
...
pom "webapp"
  pom webapp1
  pom webapp2
  ...
pom "ejb"
  pom ejb1
  pom ejb2
  ...

Migrer les spécificités maven 1 : "exit maven.xml"

Une fois le comportement global du build définit, les spécificités de build maven 1 viennent vite bloquer le processus de migration, notamment en ce qui concerne la génération de code qui a un impact sur la compilation (ça compile si le code a été généré sinon non...).
Voici quelques exemples de spécificités :
- génération des classes techniques ejb avec ejbDoclet de XDoclet : cette génération était pilotée en Maven 1 par le lancement de tâche Ant. Le plugin maven2 antrun a permis de faire la migration.
- génération d'un fichier par concaténation d'un ensemble de fichiers : La concaténation était effectuée en jelly... La seule solution était de mettre en place un plugin maven 2 qui effectue le travail.

Rester zen...

Une fois passé le cap du "BUILD SUCCEFULL" (qui , d'ailleurs, fait bien plaisir), le gros du travail est effectué. Le reste correspond a des ajustements mais des ajustements qui font d'ailleurs perdre pas mal de temps. Dans mon cas , le build du projet dans son ensemble prend dans les 10 minutes. Pour tester une modification, une seule solution : reBUILDER! Il faut savoir être patient et se dire que si on devait le faire soi-même on mettrait 3h pour faire un seul build...

Comparer les livrables j2EE entre le build maven 1 témoin et le nouveau build maven2

Les principaux ajustements à effectuer pour obtenir des contenus de livrables (ear et wars) identiques concernent les dépendances dans les archives war et ear. Avec maven 2 et la transitivité des dépendances, j'ai dû ajuster les choses en terme de versions et de porter de jars pour finalement obtenir des dossiers de "lib" identiques.

Tester les nouveaux livrables

Il faut ensuite déployer les nouveaux livrables pour valider que l'application fonctionne toujours... et procéder à des ajustements en terme de fichiers de conf J2EE notamment ceux propres au serveurs d'applications (ex : weblogic.xml, jboss-web.xml, ...).

Une fois ce cap franchi, on pense avoir quasiment terminé... mais il reste des choses à faire...
Ha, mon build vient de se terminer, la suite dans le prochain épisode...

Migration Maven 2 : 1ère épisode : Le contexte

2008-07-15T14:45:00.010+02:00

Je me suis attelé ses derniers jours (voir mois) chez mon client à entreprendre la migration de gros applicatifs maven 1 vers maven 2. Je vais essayer de vous faire profiter d'un retour d'expérience sur le sujet car je n'ai pas trouvé de méthodes miracles de migration.

Je vais y consacrer un certains nombres de billets. Le dossier est assez touffu...

Pour commencer, voici le contexte des applicatifs qui doivent être migrer :

applicatifs j2EE multi module (ear contenant un ensemble d'ejb sessions + mutli war).
héritage de projet maven.
utilisation du multi-projet.
changement du type de packaging (simple jar, ejb-jar ou ejb-jar-client) en fonction de propriétés au moment du build.
génération des classes techniques des ejbs avec xdoclet (ejbdoclet).
génération de classes techniques type "delegate" pour simplifier l'appel aux ejbs avec xdoclet (template doclet).
génération des sites projets.
utilisation de l'intégration continue avec continuum.
dans les 8000 fichiers au contrôle de source (sources + ressources).
une dizaine de minutes à attendre pour faire un build complet.
entre 5 et 20 développeurs par applicatifs.
déjà en production pour certains applicatifs.
application de type stratégiques.

Avant tout on peut se demander pourquoi? Voici les arguments que j'ai pu trouver à part de dire qu'il faut le faire :-) :

Pour permettre d’utiliser les nouvelles fonctionnalités de Maven2 (transitivité des dépendances, profile, scope, …).
Pour profiter des modifications effectuées sur les fonctionnalités existantes (gestion multiprojet, héritage).
Pour profiter des améliorations de performances que propose maven 2 (consommation mémoire pendant le build, temps de build …).
De simplifier les scripts de build.

Je détaillerai par la suite la démarche de migration qui a été mise en œuvre dès que j'ai un peu de temps entre 2 builds :-).

La suite dans le prochaine épisode...

Vista et Flavie

2008-06-17T11:30:00.002+02:00

Quand vous êtes triste ou déprimé... n'oubliez pas de regarder cette (vieille) pub de Flavie Flament qui présente Windows Vista. Ensuite tout ira mieux pour vous!! Un grand moment de publicité :-)

Maven : war dépendant d'un autre war

2008-06-02T11:24:00.006+02:00

Comment utiliser la gestion de dépendances de maven entre war.

La problématique posée était la suivante : comment capitaliser et partager des éléments communs dans plusieurs applications web. Ce type de besoin provient en fait à l'existence d'un "framework" proposant des composants communs chez mon client pour permettre de réutiliser des jsp, des scripts Javascripts, des tlds, des images, ... on va l'appeller le "framework war"

Le but pour moi est de récupérer dans les sources de mon application web dans le répertoire racine de la webapp, l'ensemble des composants du framework war.

En cherchant un peu, on peut voir que le plugin war de maven propose un goal war:inplace qui semblerait coller à mon besoin!!! cool!!

Je définis alors en dépendance de mon application web mon framework war :

<?xml version="1.0"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>fr.sevellec.test</groupId>
<artifactId>my-application-webapp</artifactId>
<packaging>war</packaging>
<name>my application de test pour le fwk</name>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>fr.sevellec.fwk</groupId>
<artifactId>fwk-war</artifactId>
<version>1.0</version>
<type>war</type>
</dependency>
</dependencies>
</project>

En plus de la définition des dépendances, il faut préciser le comportement du goal war:inplace :

<!-- plugin WAR -->
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.0.2</version>
<executions>
<execution>
<id>inplace</id>
<phase>generate-sources</phase>
<goals>
 <goal>inplace</goal>
</goals>
</execution>
</executions>

<configuration>
<warSourceDirectory>webapp</warSourceDirectory>
<dependentWarExcludes>
WEB-INF/web.xml,META-INF/**,WEB-INF/classes/**,WEB-INF/lib/**,WEB-INF/conf/**
</dependentWarExcludes>
<warSourceExcludes>/webapp/WEB-INF/lib/**</warSourceExcludes>
<useCache>false</useCache>
</configuration>
</plugin>

La complexité ensuite réside dans les ressources existants à la fois dans mon application web et à la fois dans mon framework war (par exemple, web.xml, struts-config.xml,...). Si j'execute la commande war:inplace, les ressources du framework war vont venir écraser les ressources existantes qui auraient été modifiées. Il faut alors mettre en place un système d'exclusion comme on peu le voir dans la configuration du plugin war :

<dependentWarExcludes>
WEB-INF/web.xml,META-INF/**,WEB-INF/classes/**,WEB-INF/lib/**,WEB-INF/conf/**
</dependentWarExcludes>

J'ai défini des dépendances au niveau de mon framework war. Je les récupère par transitivité dans le war de mon application web. Super! En revanche, l'utilisation du goals war:inplace rapatrie l'ensemble des dépendances transitives de mon framework war dans le dossier WEB-INF/lib de mon application web. Ce comportement me pose problème car en utilisant eclipse/sysdeo/tomcat ou eclipse/wtp/tomcat pour faire du développement en mode "exploded", la gestion du chargement des librairies est déléguées au plugin sysdeo ou WTP. La présence des librairies dans WEB-INF/lib pendant le développement perturbent le comportement des plugins sysdeo ou WTP.
Pour supprimer ces librairies génante en mode "exploded", j'ai utilisé le plugin ant-tun de maven et exécuté un delete... Je sais, ce n'est pas forcément très élégant mais ça à le mérite de fonctionner :

<!-- plugin ANT -->
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
<executions>
    <execution>
        <phase>generate-sources</phase>
        <configuration>
            <tasks>
                <delete dir="${basedir}/webapp/WEB-INF/lib" />
                <delete dir="${basedir}/webapp/WEB-INF/classes" />
                <delete dir="${basedir}/webapp/META-INF" />
            </tasks>
        </configuration>
        <goals>
            <goal>run</goal>
        </goals>
    </execution>
</executions>
</plugin>

L'ordre de déclaration des plugins dans le pom.xml de ma webapp à une importance. Il faut déclarer le plugin war avant le plugin ant car les goals des 2 plugins s'exécutent dans la même phase.

Google I/O : une démo Android

2008-05-30T14:39:00.004+02:00

Voici une petite démo de plus de la plateforme Google Android provenant de la conférence google I/O à San Francisco:

Continuum, Maven2 et Clearcase

2008-05-28T13:53:00.006+02:00

C'est possible!

Faire de l'intégration continue en utilisant le trio Continuum / Maven2 / Subversion est bien répandu. Le trio maintenant bien huilé...

Il se trouve que chez mon client, le système de gestion de contrôle de source est le produit d'IBM : Rational Clearcase.

Dans le cadre de la mise en oeuvre d'un serveur d'intégration continue, il a alors fallu faire fonctionner le trio Continuum / Maven2 / Clearcase. C'est au moment de commencer qu'on ressent un grand moment de solitude... Le but du jeu est de permettre à Continuum par l'intermédiaire de Maven de faire un "update" des sources pour vérifier si des choses ont changées et relancer une commande de build Maven.

Une particularité de Clearcase, qui reste un outil très puissant (mais un peu usine à gaz à mon gout), concerne la façon dont il structure son arborescence de sources sous forme de composants.

La difficulté principale réside dans la définition de l'url du SCM dans chacun des pom des projets.

Voici la procédure de mise en oeuvre :
*rajouter un fichier de conf clearcase sur le serveur d'intégration continue dans le fichier MAVEN_HOME/conf/clearcase-settings.xml avec ce contenu :

<clearcase-settings>
<useVWSParameter>false</useVWSParameter>
<clearcaseType>UCM</clearcaseType>
</clearcase-settings>

*rajouter l'url scm dans chacun des pom de vos projets :

 <scm>
 <connection>scm:clearcase:load \<My_Vob\My\Project\Dir>:/<PVOB_Name>:<View_Name></connection>
</scm>

où :
- My_Vob\My\Project\Dir : nom du vob dans lequel se trouve le projet + chemin d'accès à la racine du projet.
- PVOB_Name : nom du PVOB. le PVOB correspond au nom du projet racine dans le project explorer du client Clearcase.
- View_Name : nom de la vue Clearcase

*Il faut ensuite importer le pom du ou des projets dans continuum

*Il faut enfin définir des commandes maven de build dans chacun des projets. Attention! Il faut modifier le champs "Nom du fichier POM*" : au lieu de :

pom.xml

il faut préciser le chemin relatif d'accès au fichier + le nom du fichier. Il faut renseigner le champ de cette façon :

<My_Vob\My\Project\Dir\>pom.xml

Garbage Collector

2008-05-26T13:52:00.003+02:00

Si vous cherchez des infos concernant le Garbage Collector en Java ainsi que les différents algorithmes existants voici un ensemble de liens qui peuvent vous être utile :

Monitorer le Garbage Collector avec JConsole

2008-05-26T11:33:00.008+02:00

Il est possible de monitorer le Garbage Collector d'une JVM de façon distante sans posséder d'outils complexe.
Voici ce dont vous avez besoin :

avoir accès à la JVM du Garbage Collector que vous voulez monitorer.
avoir un jdk >=1.5 permettant d'utiliser la JConsole. JConsole est un client JMX intégré dans le jdk à partir de la version 1.5.

L'ojectif est d'ouvrir le connecteur JMX de la JVM pour permettre à la JConsole de s'y connecté. Une fois connecté, la JConsole nous donne toutes les informations utiles sur le Garbage Collector.

Voici la procédure en 2 étapes :

Ouvrir le connecteur de la JVM : Il faut démarrer la JVM en lui passant des options de lancement supplémentaires :

-Dcom.sun.management.jmxremote.port=<port>

-Dcom.sun.management.jmxremote.authenticate=false

-Dcom.sun.management.jmxremote.ssl=false

Lancer JConsole: Le programme se trouve dans le répertoire /bin de votre JDK :

Renseigner le champ JMX URL avec une url du type :

service:jmx:rmi:///jndi/rmi://<host>:<port>/jmxrmi

Se connecter.
Aller dans l'onglet "Memory" :

Une combobox permet de choisir le graphique désiré en temps réel permettant de voir les différents espaces mémoires de la JVM et la façon dont le Garbage Collector les gère.

Outils de génération de PDF

2008-03-12T14:36:00.013+01:00

Dans le cadre d'un de mes précédents projets, j'ai dû réaliser une veille concernant les outils de génération de PDF

En voici une synthèse :

J'avais identifié à l'époque différents outils/frameworks:

PDFBox
IText
FOP
Birt
JasperReport
Open Office

Cette liste n’est pas exhaustive mais les outils citées ci-dessus font partis des plus connus.

- PDBOX : http://www.pdfbox.org/

PdfBox est une simple librairie java à inclure dans une application. C’est un ensemble d’APIs utilisable pour manipuler un document au format PDF.

Il permet de récupérer une instance d’un document PDF pour y récupérer l’ensemble de ces caractéristiques (type du document, contenu du document, …). Il est possible de fusionner un document pdf existant avec des données de grâce aux variables présentes dans le document pdf appelé « formulaire » et grâce aux APIs de la librairie.

L’outil est assez limité en terme de fonctionnalités. Son utilisation est conseillée dans le cadre d’introspection dans un document PDF ou pour générer des pdfs à partir de modèles très rigides (exemples : un courrier type sur lequel il faut juste remplacer un nom, un prénom et une adresse).

- IText : http://www.lowagie.com/iText/

IText est une simple librairie java à inclure dans une application. C’est un ensemble d’APIs utilisable dans un environnement d’exécution pour créer ou manipuler un document au format PDF.

Il fonctionne sur le même principe que PDFBOX mais offre beaucoup plus de fonctionnalités. Il permet notamment de générer un document pdf « from scratch » avec du texte et des images dynamiques ainsi que de fusionner des données de type texte avec un modèle de document (lui-même au format pdf).

L’avantage de l’outil est de pouvoir générer facilement et sans modèle un pdf. Il pourrait être intéressant d’utiliser l’outil si les pdfs à générer sont fortement variabilisés (peu de données statiques) et où il y a peu de valeur ajoutée à devoir d’abord concevoir un modèle puis développer le moyen de réaliser la fusion avec les données.L’outil sait tout faire, il faut simplement le développer en Java.

-FOP: http://xmlgraphics.apache.org/fop/

FOP correspond à un ensemble de librairies java. Il est plus complexe mais offre de nombreuses fonctionnalités. Il permet entre autre de générer des documents au format PDF. C’est un outil fortement orienté vers le langage XML.

FOP consiste à générer une représentation des données brutes à éditer au format XML. Il faut ensuite appliquer une première transformation qui va permettre de fusionner ces données brutes avec un modèle (qui est au format XML). Le fichier ainsi obtenu est une représentation de l’édition à effectuer au format XML. Il faut enfin appliquer la transformation FOP permettant de générer le format de sortie désiré (PDF, HTML, …).

L’avantage de l’outil est de gérer des modèles au format XSLT (feuille de transformation au format XML). La modification d’un modèle revient donc à éditer un fichier XML. L’utilisation classique de cet outil est de partir des données et de leur appliquer des transformations successives permettant d’aboutir au résultat final attendu. La grande flexibilité de l’outil est un atout. En revanche pour mettre en place l’édition d’un document, il faut concevoir la représentation XML des données brutes et la feuille de transformation XSLT. Il faut donc maîtriser ce langage de transformation qui est assez verbeux.

-BIRT: http://www.eclipse.org/birt/

Birt est un outil de reporting. Il intègre à la fois un éditeur graphique de modèle (intégrer dans eclipse avec une perspective de « report modeling ») ainsi qu’un moteur de génération d’impression permettant de le rendre autonome dans une application.

Il faut appréhender l’outil en deux temps :

L’outil de reporting : Cet outil est intégré dans la plateforme de développement d’eclipse. Il permet de façon graphique de concevoir le modèle à éditer par la suite. L’éditeur graphique est en fait un générateur de XML qui est le format de sauvegarde du modèle.

Le moteur de génération : Il permet de fusionner le modèle demandé avec les données du contexte au moment de l’exécution (provenant d’une BD ou d’objet java).

Cet outil est fortement orienté pour faire du reporting à partir de source de données. Les possibilités de génération d’état sont donc très vastes. L’utilisation classique de cet outil consiste, dans un premier temps, à concevoir le modèle grâce à l’éditeur et, dans un second temps, d’intégrer le modèle dans l’application cible grâce aux APIs fournit par le moteur de génération.

- JasperReport: http://jasperforge.org/sf/projects/jasperreports

Jasper Report est un moteur de génération de report intégrable dans des applicatifs java/j2EE. Il est associé à IReport qui est un outil de conception de modèle pour JasperReport.

Comme pour Birt l'outil est décomposable :

L’outil de reporting IReport : Cet outil est une application graphique (client lourd) permettant de concevoir de façon graphique (WYSIWYG) les modèles de report. Le format de stockage des modèles conçus est le XML. Il existe aussi maintenant un plugin eclipse IReport qui permet d’éditer des modèles dans l’environnement eclipse.

Le moteur d’exécution JasperReport : Il permet de fusionner le modèle demandé avec les données du contexte d’exécution et générer le report sous différent format.

Les formats de restitution sont variés (pdf, html, xml, csv, excel). Le moteur d’exécution est une simple dépendance à embarquer dans l’application. La documentation est claire sur le Web et les apis d’utilisation du moteur d’exécution sont simples à utiliser. L’outil est bien évidemment orienté pour faire du reporting en connexion directe avec une BD.

- Open Office: http://www.openoffice.org/

L’outil permet de créer des modèles de document grâce à l’éditeur classique d’open office. Les possibilités de mise en pages sont alors celles proposés par l’éditeur de texte. Les APIs d'utilisations sont complexes. il faut faire un réel effort pour s'approprier l'outil et le mettre en oeuvre car il est plus complexe que les autres. Ils offrent en revanche beaucoup de possibilités.

Conclusion

Il n'est pas possible de définir le meilleur outil d'impression/génération de pdf. Ils ont tous des philosophie de mise en oeuvre différentes. On peut noter que JasperReport et Birt sont des outils plus orientés vers le reporting alors qu'IText est propose des APIs plus bas niveau permettant la génération de PDF. Il faudra faire un choix en fonction de son besoin...

résumé apple, google et votre entreprise

2008-03-12T11:44:00.006+01:00

Je suis obligé de relayer le post du blog de fredcavazza concernant un dessin résumant les produits google, apple et les applications d'entreprises.

c'est tellement vrai :

Téléphone Google android

2008-02-29T11:54:00.004+01:00

J'attends avec impatience la sortie de téléphones avec la plateforme Android de google.

Grâce aux Mobile World Congress 2008, on voit quelques prototypes de constructeurs faire leur apparition!!!

Voici une vidéo d'un prototype de Texas Instrument :

Impressions : Google Android MWC 2008
envoyé par JournalduGeek

Javascript vers applet Java

2008-02-29T10:11:00.004+01:00

Dans ce post, j'expliquais qu'il était possible de faire un pont entre le monde java dans un applet et du javascript.

Il est aussi possible de faire ça dans l'autre sens, cad, appeler une méthode java dans une applet à partir d'une fonction javascript. Voici un petit exemple de mise en oeuvre :

1 : test/myApplet.java

package test;

import java.applet.Applet;

public class MyApplet extends Applet {

  public void init() {
      super.init();
      System.out.println("init something");
  }

  public void jsCall(String hello) {
      System.out.println("this method is called by a js function and say :"
              + hello);
  }

}

2 : test-call.html

<html>
<head>
<title>test applet</title>
<script type="text/javascript">
  function callJavaMethod() {
      document.javaToJavascriptApplet.jsCall('hello world');
  }
  </script>
</head>
<body>
<applet id="javaToJavascriptApplet" code="test.MyApplet.class" mayscript
  width="0" height="0" codebase="bin/"> </applet>

<input type="button" value="Call a java applet method"
  onclick="callJavaMethod();">

</body>
</html>

Il ne reste plus qu'à lancer la page html, cliquer sur le bouton et observer la console java de l'applet :

init something

this method is called by a js function and say :hello world

Maven 2, recherche de jars

2008-02-28T10:28:00.004+01:00

J'utilise et abuse de maven dans les projets java notamment chez mon client. Comment faisait-on d'ailleurs avant la création de cette outil???

Ce qu'on peut parfois lui reprocher, c'est la perte de temps qu'occasionne la définition des dépendances dans le pom : la recherche de dépendances sur les repositorys distant sur le net prend un temps fou même si le système de dépendance transitive permet d'alléger la déclaration des dépendances dans le pom.

Un collègue m'a présenté un site qui me permet maintenant de gagner beaucoup de temps sur cette recherche :

http://www.mvnrepository.com/

Le site propose un système de recherche permettant de trouver une dépendance :

Une fois la dépendance trouvée et dans la bonne version, il fournit le bout de code xml à rajouter pour la déclarer dans le pom! magique!

SoapUI : testeur de web service

2008-02-20T15:05:00.004+01:00

Je travaille chez mon client à la mise en oeuvre d'architecture d'intégration, notamment SOA et EDA avec des ESBs.

Je viens de terminer une phase de test de montée en charge dans lequel nous avons mis à l'épreuve plusieurs ESBs Open Source du marché.

Plusieurs de nos scénarios concernées la mise en oeuvre d'échanges synchrones à base de web services avec un ESB comme "proxy" intermédiaire. Nous avons développé un injecteur maison permettant de simuler une charge synchrone (appel massif de web services) ou asynchrone (écriture massive de messages JMS).

J'ai néanmoins découvert un outil très sympa : SoapUI
L'outil permet à partir d'un WSDL d'appeler un web service. Ce que je trouve très intérressant dans l'outil c'est la génération d'un message SOAP par défaut qui permet d'appeler le web service. Pour ceux qui n'ont pas eu WSDL en seconde langue au lycée, c'est très appréciable! :-)

En creusant un peu sur les fonctionnalités de l'outil, j'ai découvert qu'en plus de faire des tests unitaires, il permet aussi de mettre en place des tests de charge (multi threading) avec la possibilité de mettre en place tout un ensemble d'assertions.

Architecture Ebay

2008-02-20T11:29:00.002+01:00

Vous êtes vous déjà poser la question :"Heu, Ebay, comment ça marche???".

Quand on lit les chiffres annoncés par Ebay en terme de volume de traitement, c'est incroyable.
J'en prends un au hasard : 28 milliards de requête SQL par Jour!!! En novembre 1999, Ebay atteint les limites physiques de croissances des serveurs de Base de données...

On se doute bien qu'avec se genre de problématique, des réflexions sur l'architecture mise en place (et son évolution) est primordiale.

Voici un PDF sur l'architecture d'EBay que j'ai trouvé sur ce post :
http://www.highscalability.com/ebay-architecture
(Le nom du site plante déjà un peu de décor)

google, c'est plus fort que toi

2008-02-20T11:10:00.004+01:00

Il n'y a pas encore si longtemps (bon quelques années quand même), quand j'expliquais que j'avais fait une recherche en allant sur le moteur de recherche google on me répondait "goo quoi??"

Tout le monde connait aujourd'hui ce moteur de recherche. Le plus incroyable c'est de voir l'ensemble des services que propose aujourd'hui google.

L'histoire de google est relativement courte mais elle est incroyablement bien remplie!!

Applet java vers Javascript

2008-02-18T17:11:00.003+01:00

Le concept de devoir faire un pont entre le monde java dans une applet et le monde javascript peut paraitre bizarre mais il peut s'expliquer...

Alors imaginons pour commencer une application j2EE en client léger typée AJAX. Rajoutons-y ensuite des besoins fonctionnels propres à des centres téléphoniques (call center, hotline) comme le fait d'identifier un client automatiquement par son numéro de téléphone dans une application au moment où l'appel sonne sur le poste téléphonique...

Il existe multiple choix architecturaux pour mettre en place ce type de système.

Une réponse est de faire du polling AJAX pour tester l'arrivée d'un appel. J'ai d'ailleurs expliquer comment faire du polling coté client dans ce post.

Une autres réponses possibles est d'intégrer une applet dans le navigateur qui va écouter l'arrivée des appels et notifier l'application dans le navigateur par l'appel d'une fonction javascript.

C'est à ce moment que cette documentation peut vous être utile :
http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/java_js.html

JEE vs .Net, piqure de rappel

2008-02-14T17:59:00.002+01:00

Voici un post comme je les aime...

SOA et EDA

2008-02-14T17:11:00.004+01:00

SOA est sur toutes les lèvres. A tel point que trop de SOA peut parfois tuer le SOA :-). Certains responsables informatiques ont maintenant peur de l'entendre ou de le prononcer.

Je travaille actuellement sur les architectures d'intégrations et notamment celles autour des ESBs. La plupart des présentations que j'ai pu voir sur les ESBs les définissent comme une infrastructure permettant de "faire du SOA". "Faire du SOA" implique de mettre en oeuvre des architectures où un applicatif appelle un service d'un autre applicatif de manière synchrone (pour simplifier...). Cette démarche implique alors une dépendance en terme de disponibilité entre les 2 systèmes. Elle implique aussi de déporter les exigences en terme de temps de réponse de l'application consommatrice vers l'application qui fournit le service.

C'est normalement à ce moment que le responsable des applicatifs en production vous dit :"heuuu et comment je fais si je veux que mes applicatifs soit indépendants en terme de disponibilité pour pouvoir continuer à travailler si un d'entre eux crash?..."

EDA permet ce genre de fonctionnement. EDA, pour Event Driven Architecture, propose des échanges asynchrones de messages unitaires (ayant seul un sens métier au sein du SI) au fil de l'eau. Ce type d'architecture permet de rendre indépendant les applicatifs en terme de disponibilités et de performance, tout en offrant la possibilité de diffuser les messages au fil de l'eau dans le SI. La plupart des ESBs permettent de faire de l'EDA même si en général le focus est mis sur les partie SOA qu'offre le bus.

Je pense, et je crois que je ne suis pas le seul (enfin j'espère...), que ces 2 types d'architectures font partis d'un SI moderne.

Vous en pensez quoi???

Voici d'ailleurs un blog intéressant :
http://soa-eda.blogspot.com/
Le nom du blog est assez porteur de sens...

Polling Ajax coté client

2008-02-14T10:14:00.008+01:00

Le besoin de faire du Push Http vers un browser est de plus en plus présent.

Une méthode consiste à poller à interval régulier depuis le browser une url pour vérifier l'arrivée d'un nouvel évènement. Voici un exemple coté client de mise en place en utilisant la librairie Ajax Prototype (Ca sert à rien de réinventer la roue à chaque fois) :

/* fonction de lancement du poll http */
function launchPolling() {
new PeriodicalExecuter(executePoll, 5);
}


/* lors de chague poll */
function executePoll() {
var url = 'your url...';
new Ajax.Request(url, {
method: 'get',
contentType: 'application/xml',
onSuccess: function(transport) {
try {
var response = transport.responseText;
if ((response != '') {
  /* do something... */
}
} catch(e) {
alert(e.message);
}
transport=null;
}
});
}

Il existe aussi maintenant une évolution sur ce type de polling qui consiste à poller moins fréquemment. Le serveur, sur réception d'une requête de polling, attend avant de retourner une réponse. Ce modèle de programmation s'appelle COMET et est décrit dans un post très intéressant de Thomas Recloux à cette adresse :
http://blog.tartachuc.org/2008/02/12/comet-push-http/

GWT en entreprise, oui et reOui!

2008-02-13T02:56:00.000+01:00

La version 1.0 de GWT est apparu en mai 2006. Déjà à l'époque je trouvais ce framework web en avance sur son temps. Il m'avait réconcilié avec le développement d'IHM Web que je trouvais trop longue et fastidieuse surtout au moment où je devais mettre les mains dans du javascript pour faire une bidouille... beurk!!

Il s'est maintenant fait sa place parmi la multitude de framework Web aujourd'hui disponible.

Si on me demande aujourd'hui si GWT, pour faire du client léger et portable, peut fonctionner dans un contexte d'application d'entreprise, je dit OUI! En tous cas, je vote POUR intégrer le framework dans la réflexion de choix d'un framework web d'entreprise (si une entreprise à ce type de réflexion...:-)).

GWT, dès sa sortie, se voulait extensible. Encore fallait-il que la mayonnaise prenne et que des librairies graphiques apparaissent. C'est maintenant chose faite!
Pour n'en citer qu'une, prenons par exemple.... heu... il y en a tellement... allez : GWT Ext qui est maintenant en vers 2.0.1.

On peut aussi noter une communauté très active autour de ce framework ce qui est un argument majeur aux yeux des directions informatiques pour permettre de minimiser le risques de se retrouver seul au monde avec un framework bugé et qui n'évolue pas.

Ce qui peut ralentir l'intégration de GWT en entreprise :

La méconnaissance du framework... (genre, "il y aura de la pub dans mon application si vous utilisez GWT", si si on ne rigole pas... c'est du vécu...).
L'inertie des technologies dans les entreprises. Combien d'entreprises travaillent encore en jdk 1.4.x? (heu je ne dis pas que la version 1.4 c'est pas bien mais sun à commencé son processus de fin de vie sur cette version. Il serait temps de migrer!) Plus les services informatiques sont conséquents, plus il est difficile de mettre en place de nouvelle choses... comme des framework web moderne...

Arrêter une JVM dans une console avec Ctrl C, mais qui pense au serveur??

2008-02-12T16:16:00.000+01:00

Que ce soit sous windows ou Linux, tout le monde connait bien le ctrl C pour arrêter un serveur ou/et une jvm qui est lancé en mode console.

Voici une façon de gérer ça proprement coté serveur au moment ou la JVM s'arrête.
http://java.sun.com/j2se/1.5.0/docs/guide/lang/hook-design.html

Cela peut permettre d'arrêter proprement votre programme et de faire un peu de ménage...

Présentation de GWT en 60 slides

2008-02-11T17:34:00.000+01:00

Voici une présentation très intéressante de GWT. J'aime beaucoup l'aspect prise de recul sur la techno. C'est bien d'arriver à se faire comprendre par d'autres personnes que des geeks...

http://www.ongwt.com/post/2008/02/04/Presentation-%3A-Introduction-to-Google-Web-Toolkit

merci onGwt

Ouverture de mon blog

2006-12-22T11:54:00.000+01:00

Salut à tous,

Bon ben voilà, ça y est j'ai mon blog... Va falloir que je trouve quoi y faire maintenant...