Tout d’abord au rythme où vont les inscriptions, les organisateurs prédisent une augmentation de 30% de la fréquentation. De mon côté c’est fait, je suis inscrit pour toute la semaine comme l’an dernier. Cette année la conférence sera certainement différente. Je ne sais pas si vous avez lu les derniers blogs la semaine dernière, mais il y a du rififi entre Oracle et Google. Il y a quelques semaines, Oracle Corporation a décidé d’attaquer Google par rapport à 7 brevets utilisés au sein de la plateforme Android. Google a annoncé la semaine passée qu’il ne participera pas à la conférence JavaOne qui a lieu mi-septembre. Les conférences prévues par les speakers de Google ont été annulé (Josuha Bloch ou Romain Guy par exemple).

James Gosling, l’un des fondateurs du langage Java, a lancé une campagne de tee-shirt « Java: just free it » à destination d’Oracle, afin de sauver le langage de la main-mise de l’éditeur de base de données américain. Et le plus fun c’est que James Gosling est prévu pour faire une conférence de clôture à Devoxx à la fin de cette année. La lettre d’information croustille en promettant une présentation « un-censored ». Cela va certainement rattraper l’an passé, où James Gosling n’avait rien pu nous dire.

Parmi les présentateurs intéressants, on annonce la présence de Martin Odersky, le père du langage Scala, de Ben Alex le fondateur du projet Spring ROO et de Claus Isben, l’un des commiters d’Apache Camel les plus actifs.

La liste des personnes de la communauté Java n’est pas encore complète mais voici d’autres noms :

* Mark Reinhold (JavaSE 7 Keynote)
* Roberto Chinnici (JavaEE 7 Keynote)
* Martin Odersky (Scala Founder)
* Ben Alex (ROO Founder)
* Brian Goetz (Project Lambda)
* Joe D’Arcy (Project Coin)
* Graeme Rocher (Grails Founder)
* Steve Freeman (Agile-holic)
* Claus Ibsen (co-Founder Camel)
* David Geary (JSF/GWT Rock Star)
* Kito Mann (JSF Rock Star)
* Costin Leau (Spring Guru)
* Guillaume Laforge (Groovy Lead)
* Bill Venners (Scala Rock Star)
* Paul Sandoz (JAX-RS lead)

Ce sera aussi l’occasion de rencontrer l’ensemble des Java User Group, qui participent activement chaque année à Devoxx.

A bientôt et bonne rentrée.

Les lecteurs du Touilleur Express sont des passionnés. Est-ce que les passionnés gagnent plus que les autres ? Aucunes idées, mais nous allons avoir une première idée grâce à ce sondage. La rentrée s’annonce chargée, le marché repart plutôt fort après un début d’année plus calme qu’en 2009.

J’ai aussi pris en compte les indépendants et les freelances dans ce sondage, afin de mesurer le nombre d’indépendant par rapport au nombre de salarié. J’ai aussi pris en compte la différence entre salarié en SSII et salarié d’une entreprise, d’un éditeur ou d’un client final.

N’hésitez pas à faire passer l’adresse de cette page via Twitter, à vos amis informaticiens ou travaillant dans le monde informatique.

Vous pouvez me faire part de vos remarques par email ou via Twitter.

Maven

Voyons comment créer un petit projet simple avec JPA. J’utilise Apache Derby, une base en mémoire qui permet de tester du code simple sans avoir besoin d’une vraie base Oracle ou MySQL. Du côté des dépendances, je vous déconseille slf4j-simple. Prenez plutôt slf4j-log4j12 afin de pouvoir contrôler la verbosité des logs d’Hibernate. J’utilise Apache Derby 10.5.3.0, et j’ai ajouté le repository de JBoss.

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.letouilleur.sample</groupId>
    <artifactId>sample</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>Articles du Touilleur Express</name>
    <url>http://touilleur-express.fr/</url>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.3.1</version>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                </configuration>
            </plugin>
        </plugins>
    </build>

    <repositories>
        <repository>
            <id>jboss</id>
            <name>JBoss repository</name>
            <url>http://repository.jboss.org/maven2</url>
        </repository>
    </repositories>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>r06</version>
        </dependency>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-entitymanager</artifactId>
            <version>3.3.2.GA</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.derby</groupId>
            <artifactId>derby</artifactId>
            <version>10.5.3.0</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-entitymanager</artifactId>
            <version>3.5.1-Final</version>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
            <version>1.5.6</version>
        </dependency>
    </dependencies>

</project>

Persistence

Dans le répertoire test\resources\META-INF j’ai placé un fichier persistence.xml. Je déclare explicitement mon entité org.letouilleur.sample.Instrument

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0"
             xmlns="http://java.sun.com/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">

    <persistence-unit name="testPU" transaction-type="RESOURCE_LOCAL">
        <provider>org.hibernate.ejb.HibernatePersistence</provider>
        <class>org.letouilleur.sample.Instrument</class>
        <exclude-unlisted-classes>true</exclude-unlisted-classes>
        <properties>
            <property name="hibernate.connection.url" value="jdbc:derby:memory:unit-testing-jpa"/>
            <property name="hibernate.connection.driver_class" value="org.apache.derby.jdbc.EmbeddedDriver"/>
            <property name="hibernate.dialect" value="org.hibernate.dialect.DerbyDialect"/>
            <property name="hibernate.hbm2ddl.auto" value="create"/>
            <property name="hibernate.connection.username" value=""/>
            <property name="hibernate.connection.password" value=""/>
        </properties>
    </persistence-unit>
</persistence>

Test avec JPA

Pour tester l’entité, j’ai fait le choix d’écrire le minimum de code et de ne pas utiliser Spring. J’ai créé une classe abstract pour tout ce qui est mise en marche du contexte de persistence, puis un test simple pour valider la création de mon entité. Pas de DAO non plus, l’EntityManager est un DAO à part entière non ?

Le test de base:

package org.letouilleur.sample;

import junit.framework.TestCase;
import org.apache.derby.impl.io.VFMemoryStorageFactory;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
import java.io.File;
import java.sql.DriverManager;
import java.sql.SQLNonTransientConnectionException;
import java.util.logging.Logger;

/**
 * A simple Persistence Unit test.
 *
 * @author Nicolas Martignole
 * @since 5 août 2010 21:53:10
 */
public abstract class PersistenceTest extends TestCase {
    private static Logger logger = Logger.getLogger(PersistenceTest.class.getName());
    private EntityManagerFactory emFactory;
    protected EntityManager em;

    public PersistenceTest(){

    }

    public PersistenceTest(String testName) {
        super(testName);
    }

    @Override
    protected void setUp() throws Exception {
        super.setUp();
        try {
            logger.info("Starting in-memory database for unit tests");
            Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
            DriverManager.getConnection("jdbc:derby:memory:unit-testing-jpa;create=true").close();
        } catch (Exception ex) {
            ex.printStackTrace();
            fail("Exception during database startup.");
        }
        try {
            logger.info("Building JPA EntityManager for unit tests");
            emFactory = Persistence.createEntityManagerFactory("testPU");
            em = emFactory.createEntityManager();
        } catch (Exception ex) {
            ex.printStackTrace();
            fail("Exception during JPA EntityManager instanciation.");
        }
    }

    @Override
    protected void tearDown() throws Exception {
        super.tearDown();
        logger.info("Shuting down Hibernate JPA layer.");
        if (em != null) {
            em.close();
        }
        if (emFactory != null) {
            emFactory.close();
        }
        logger.info("Stopping in-memory database.");
        try {
            DriverManager.getConnection("jdbc:derby:memory:unit-testing-jpa;shutdown=true").close();
        } catch (SQLNonTransientConnectionException ex) {
            if (ex.getErrorCode() != 45000) {
                throw ex;
            }
            // Shutdown success
        }
        VFMemoryStorageFactory.purgeDatabase(new File("unit-testing-jpa").getCanonicalPath());
    }

}

Le test InstrumentJPATest me permet de tester la création de mon entité :

package org.letouilleur.sample;

/**
 * A simple JPA integration test to demonstrate equals and hashCode issues.
 *
 * @author Nicolas Martignole
 * @since 5 août 2010 22:24:29
 */
public class InstrumentJPATest extends PersistenceTest {
    public void testPersistence() {
        try {
            em.getTransaction().begin();

            Instrument instrument = new Instrument("FR1234567890");

            em.persist(instrument);
            assertTrue(em.contains(instrument));

            em.remove(instrument);
            assertFalse(em.contains(instrument));

            em.getTransaction().commit();

        } catch (Exception ex) {
            em.getTransaction().rollback();
            ex.printStackTrace();
            fail("Exception during testPersistence");
        }
    }

}

Entité

Nous sommes maintenant prêt à créer notre Entité. Je vous propose 2 versions : une simple et une différente avec Google Guava.

Dans la spécification JSR-317 de JPA2, notez les points suivants :

Extrait de la spécification JSR-317:

The entity class must be annotated with the Entity annotation or denoted in the XML descriptor as an entity.

The entity class must have a no-arg constructor. The entity class may have other constructors as well. The no-arg constructor must be public or protected.

The entity class must be a top-level class. An enum or interface must not be designated as an entity.

The entity class must not be final. No methods or persistent instance variables of the entity class may be final.

If an entity instance is to be passed by value as a detached object (e.g., through a remote interface), the entity class must implement the Serializable interface.
Entities support inheritance, polymorphic associations, and polymorphic queries.
Both abstract and concrete classes can be entities. Entities may extend non-entity classes as well as entity classes, and non-entity classes may extend entity classes.
The persistent state of an entity is represented by instance variables, which may correspond to Java- Beans properties. An instance variable must be directly accessed only from within the methods of the entity by the entity instance itself. Instance variables must not be accessed by clients of the entity. The state of the entity is available to clients only through the entity’s methods—i.e., accessor methods (get- ter/setter methods) or other business methods.

En résumé:
- votre Entité peut soit utiliser une annotation, soit être configurée via XML
- elle doit avoir un constructeur public ou protected sans argument
- la classe doit être une « top-level class », il n’est pas possible d’utiliser un enum ou une interface.
- la classe ne doit pas être finale
- nécessité d’implémenter l’interface Serializable si l’object doit être détaché

package org.letouilleur.sample;

import javax.persistence.*;
import java.io.Serializable;

/**
 * Instrument is a simple JPA for http://touilleur-express.fr
 *
 * @author Nicolas Martignole
 * @since 5 août 2010 21:47:50
 */
@Entity
public class Instrument implements Serializable {
    @Id
    @GeneratedValue
    private Long id;

    @Column(nullable = false,length = 12)
    private String isin;
    @Column(nullable = true,length = 150)
    private String description;

    // Required for JPA2

    protected Instrument() {
    }

    public Instrument(final String isin) {
        this(isin,null);
    }

    public Instrument(final String isin, final String description) {
        if (isin == null) {
            throw new NullPointerException("ISIN cannot be null");
        }
        this.isin = isin;
        this.description = description;
    }

    public Long getId() {
        return id;
    }

    public String getIsin() {
        return isin;
    }

    public String getDescription() {
        return description;
    }

}

Notez l’absence de setter. Il n’est pas nécessaire d’en déclarer car j’utilise (et je préfère) la déclaration des annotations sur les propriétés plutôt que sur les méthodes. Cela permet de regrouper au début de mon fichier l’ensemble des annotations, et de ne pas devoir chercher d’éventuelles contraintes

Ajoutons les méthodes toString, equals et hashCode. Etant donné que l’ISIN est une clé métier, je vais m’en servir pour gérer l’identité de mon Entité. Je modifie aussi le constructeur afin d’utiliser la classe Preconditions de Google Guava. Cela me permet d’alléger le test sur l’ISIN. Pensez-y lorsque vous avez une méthode avec 5 ou 6 arguments obligatoires. Guava est pratique et permet d’économiser du code.

Pour la partie equals et hashCode, je m’appuie sur l’ISIN qui est une clé métier. Cela m’arrange bien, pas besoin de gérer l’id qui peut être null tant que l’entité n’est pas persisté.

package org.letouilleur.sample;

import com.google.common.base.Objects;

import static com.google.common.base.Preconditions.*;

import javax.persistence.*;
import java.io.Serializable;

/**
 * Instrument is a simple JPA for http://touilleur-express.fr
 *
 * @author Nicolas Martignole
 * @since 5 août 2010 21:47:50
 */
@Entity
@Table(uniqueConstraints = @UniqueConstraint(columnNames = {"ID", "ISIN"}))
public class Instrument implements Serializable {
    @Id
    @GeneratedValue
    private Long id;

    @Column(nullable = false, length = 12, name = "ISIN")
    private String isin;
    @Column(nullable = true, length = 150)
    private String description;

    // Required for JPA2
    protected Instrument() {
    }

    public Instrument(final String isin) {
        this(isin, null);
    }

    public Instrument(final String isin, String description) {
        checkNotNull(isin, "Isin cannot be null");   // Google Guava
        this.isin = isin;
        this.description = description;
    }

    public Long getId() {
        return id;
    }

    public String getIsin() {
        return isin;
    }

    public String getDescription() {
        return description;
    }

    @Override
    public String toString() {
       // Google Guava
        return Objects.toStringHelper(this).add("id", getId()).add("isin", getIsin()).add("description", getDescription()).toString();
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Instrument that = (Instrument) o;
        return Objects.equal(that.isin, isin);   // Google Guava
    }

    @Override
    public int hashCode() {
        return Objects.hashCode(isin); // Google Guava
    }
}

Soyons fou

Prenons une autre approche un peu différente. Si je vous montre d’abord le code du test unitaire, réfléchissez sur l’implémentation de la classe InstrumentV2 afin qu’elle passe le test unitaire. Vous verrez, c’est un exercice intéressant.

package org.letouilleur.sample;

import junit.framework.TestCase;

import java.util.List;

public class InstrumentV2UnitTest extends TestCase {

    public void testShouldCreateAndFindAnEntity() {

        InstrumentV2 instrument = new InstrumentV2("FR123456");
        InstrumentV2 instrument2 = new InstrumentV2("US94394949");

        InstrumentV2.persist(instrument);
        InstrumentV2.persist(instrument2);

        List<InstrumentV2> results=InstrumentV2.findAll() ;
        assertEquals(2,results.size());

        assertEquals(instrument, InstrumentV2.find("FR123456"));

    }

}

A la lecture du code, nous voyons donc des méthodes statiques déclarées sur l’entité. A votre avis qu’est-ce que cela donne ? Et bien c’est faisable. Il y a plusieurs approches différentes, mais j’ai fait cela à ma manière, avec un bloc static pour créer le contexte de persistence. Je pense que l’annotation @PersistenceContexte ne servira à rien, mais je la laisse là.

package org.letouilleur.sample;

import com.google.common.base.Objects;

import javax.persistence.*;
import java.io.Serializable;
import java.sql.DriverManager;
import java.util.List;

import static com.google.common.base.Preconditions.checkNotNull;

/**
 * Instrument is a simple JPA for http://touilleur-express.fr
 *
 * @author Nicolas Martignole
 * @since 5 août 2010 21:47:50
 */
@Entity
@NamedQuery(name = "byIsin", query = "FROM InstrumentV2 I WHERE I.isin=:pisin")
@Table(uniqueConstraints = @UniqueConstraint(columnNames = {"ID", "ISIN"}))
public class InstrumentV2 implements Serializable {
    @Id
    @GeneratedValue
    private Long id;

    @Column(nullable = false, length = 12, name = "ISIN")
    private String isin;
    @Column(nullable = true, length = 150)
    private String description;

    @PersistenceContext
    static EntityManager em;

    static {
        System.out.println("--- Initializing context ---");
        try {
            Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
            DriverManager.getConnection("jdbc:derby:memory:unit-testing-jpa;create=true").close();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
        try {
            EntityManagerFactory emFactory = Persistence.createEntityManagerFactory("testPU");
            em = emFactory.createEntityManager();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }

    // Required for JPA2

    protected InstrumentV2() {
    }

    public InstrumentV2(final String isin) {
        this(isin, null);
    }

    public InstrumentV2(final String isin, String description) {
        checkNotNull(isin, "Isin cannot be null");
        this.isin = isin;
        this.description = description;
    }

    public Long getId() {
        return id;
    }

    public String getIsin() {
        return isin;
    }

    public String getDescription() {
        return description;
    }

    @Override
    public String toString() {
        return Objects.toStringHelper(this).add("id", getId()).add("isin", getIsin()).add("description", getDescription()).toString();
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        InstrumentV2 that = (InstrumentV2) o;
        return Objects.equal(that.isin, isin);
    }

    @Override
    public int hashCode() {
        return Objects.hashCode(isin);
    }

    public static InstrumentV2 find(String isin) {
        Query q = em.createNamedQuery("byIsin").setParameter("pisin", isin);
        return (InstrumentV2) q.getSingleResult();
    }

    public static void persist(InstrumentV2 instrument) {
        checkNotNull(instrument);
        em.getTransaction().begin();
        em.persist(instrument);
        em.getTransaction().commit();
    }

    @SuppressWarnings("unchecked")
    public static List<InstrumentV2> findAll(){
        return em.createQuery("from InstrumentV2").getResultList();
    }
}

Si vous voulez tester, n’oubliez pas d’ajouter la class InstrumentV2 dans la déclaration de persistence du fichier persistence.xml. Et vous verrez, cela marche très bien !

C’est une approche similaire, quoiqu’un peu plus compliquée, qu’utilise Play! Framework. Attention, Play utilise un système d’enrichissement du code à la compilation qui permet de donner une implémentation des méthodes type find, save, delete, mais certainement pas quelque chose avec un bout de code static comme je l’a fait ici.

Je rigole car vous vous êtes dit : « tiens il ne parle pas de Play!« . Et alors que Madame vous tartine le dos pendant que vous lisez ce billet sur votre iPad sur la plage, PAF au moment où vous ne vous y attendez pas, je vous reparle de Play… Avouez que je vous ai bien eu non ?

Allez, je vais vous laisser tranquille, passez de bonnes vacances.

Règle 1 : respectez les pièces rares
Règle 2 : protéger avec une bâche
Règle 3 : prenez des radiographies du patient
Règle 4 : commencez par ce qui n’est pas cher
Règle 5 : utilisez des scanners pour détecter les peintures cachées
Règle 6 : mettez en place un suivi
Règle 7 : pensez au futur

Règle 1 : respectez les pièces rares
Dans chaque logiciel, dans chaque application que j’ai vu, il y a un petit coeur qui bat. Il y a souvent quelques classes particulièrement compliquées, dont l’historique sur Subversion est très chargé. Mon premier conseil : respectez le travail de vos anciens. Imaginez qu’à l’époque où ce code a été construit, ils n’avaient pas les outils, les blogs et l’information dont vous disposez. Soyez donc humble et ne critiquez pas à tort et à travers la qualité du code ou son architecture de l’époque. Avec un peu de chance, un EJB 2.1 Statefull codé en Facade avec des EJB 2.1 Stateless derrière prendra de la valeur avec les années… ou pas.

Plus sérieusement, il y a des parties de code qu’il convient de respecter. L’historique des bugs corrigés raconte une histoire, l’évolution du logiciel et les problèmes rencontrés par l’équipe. Je conseille de passer du temps avec les développeurs encore présent, et de bien faire attention à ne pas effacer ces fichiers, qui racontent une histoire.

Un bug corrigé c’est un bug corrigé…. Sur des problèmes compliqués comme le pricing d’une Option, croyez moi vous ne faîtes pas le fier.

Règle 2 : protégez avec une bâche
Lorsque vous vous lancerez dans du refactoring, il est important d’isoler votre travail du reste du projet. Identifiez clairement les dépendances et les limites de votre travail, et dîtes-vous : je m’arrêterai là. Utilisez par exemple mvn dependency:analyze et mvn dependency:tree pour regarder le couplage de vos modules, si vous utilisez Maven. Il est très important de définir le périmètre des classes ou des packages sur lesquel vous allez intervenir, et de vous y tenir. Sans quoi vous vous retrouvez à réécrire le gestionnaire de clic de la souris alors que vous aviez commencé à modifier une JTable…

Règle 3 : prenez des radiographies du patient
Peut-être la règle la plus importante : blindez le code existant avec des tests unitaires via JUnit, des mocks avec Mockito. Sachez qu’il est possible de mocker des classes concrètes avec EasyMock Class Extension 2.2 depuis fin 2007. Je préfère Mockito qui est plus léger et qui force à coder ses tests à la sauce Given/When/Then.

Les tests pour moi sont la radiographie du patient. C’est la garantie que votre amélioration ne casse pas le logiciel. Faites des tests d’intégration avec Fit par exemple, ou FitNess. Bref c’est de la non-régression, le B.A Ba du bon développeur.

Enfin si vous faîtes du tuning, prenez des mesures avant de commencer à modifier une ligne de code. Combien de temps pour traiter en moyenne un fichier de 50 000 lignes ? Combien de temps pour charger la 3ème page de la liste des produits ? Pensez à prendre scrupuleusement des notes et des chiffres avant de toucher quoique ce soit. Cela s’applique aussi au temps nécessaire pour compiler votre projet par exemple. Bref pensez chiffres.

Règle 4 : commencez par ce qui n’est pas cher
Ce qui est cher est risqué. Ce qui a plus de valeur par contre, c’est quelque chose de très compliqué que l’on peut corriger très rapidement. Première idée que j’ai en tête : passez à Java 6. Cela ne coûte rien, ou très peu. N’attendez pas que quelqu’un vous « autorise » à le faire. Le pilote de l’avion c’est vous. Le chirurgien c’est vous. Faîtes-le, allez voir le client ou les gens du métier, montrez-leur que le logiciel tourne mieux, et laissez-le ensuite s’occuper du psycho-rigide qui ne veut pas passer à Java 6 alors que vous êtes en Java 1.4. Vous pouvez lui faire peur en expliquant que Java J2SE 5 n’est plus supporté par SUN Microsytems depuis le 3 novembre 2009 afin qu’il se bouge un peu.

Ce qui ne coûte pas cher mais qui est un peu plus risqué, c’est les mises à jour des librairies. Vérifiez que vous êtes à jour quant aux différentes versions de vos Jars. Ce matin, nous avons trouvé un bug dans Hibernate 3.2.6 avec IBM WebSphere, et le lookup du Transaction Manager. En passant à une version plus récente d’Hibernate, le problème est résolu.

Ce qui demande un peu d’effort, c’est la partie Build. Si vous êtes avec Apache Ant et que vous en êtes content, restez avec celui-ci. Ne migrez pas à Maven ou Gradle pour être dans l’air du temps ou pour faire plaisir à un consultant. Si par contre votre build est un tas fumant et qu’il faut 23 minutes pour compiler le projet avec Maven 1, que personne ne sait vraiment comment cela marche… jetez tout. C’est ce que nous avons fait fin 2008 sur un projet avec 15 développeurs. Le build total est passé à 9mn, imaginez le temps gagné par développeur chaque jour.
Maven 2.2.x tourne vraiment bien, et il est rapide. Testez-le aussi, mais attention aux coûts cachés plus tard : il faut s’adapter à Maven afin d’en tirer le meilleur parti, plutôt que de le tordre et d’essayer de le faire marcher selon les noms de ses répertoires, et de son organisation.

Règle 5 : utilisez des scanners pour détecter les peintures cachées
J’ai l’image de ces 2 scientifiques, qui radiographient la Joconde et qui trouvent des traits de dessin de Leonard de Vinci. Imaginez leur surprise et leur joie…
Bon pour nous c’est un peu moins fun, mais attendez de voir où je veux vous emmener. Je vous conseille de tester des outils de profiling et de monitoring, afin d’identifier les points noirs de votre application. Que ce soit en terme de mémoire, comme en terme de CPU, mon préféré est yourKit que j’ai découvert chez Reuters avec Jean-Paul Schemali (spéciale dédicace) et aussi JProfiler, que j’ai beaucoup utilisé. Ces outils sont payants, mais croyez-moi, ils valent la dépense grâce à ce que vous allez économiser.

Sinon les outils de la JVM HotSpot de SUN Microsystems permettent aussi de regarder ce qu’il se passe à l’intérieur de l’application, et de corriger le tout.

Dans la série des autres scanners que j’utilise, je conseille FindBugs pour auditer le code source, et voir les bugs éventuels de l’application. Si vous voulez aller plus loin, vous pouvez installer et utiliser Sonar, j’en parle au point 6.
Un outil comme PMD est aussi gratuit et open-source. Il permet d’auditer l’ensemble du code, de signaler le code mort qui n’est jamais appelé, de vous informer des duplications et d’éventuels bugs.

Enfin je conseille aussi de nettoyer les classes : effacez le code en commentaire. De ma propre expérience, 9 fois sur 10 lorsque je décommente du code dans une classe, il ne compile plus. Le reste de la classe a changé, ou il ne sert à rien. Soyez sans pitié : effacez le code et utilisez le gestionnaire de version pour sauver vos anciennes versions. Rien ne se perd de cette façon.

Pensez aussi à nettoyer les dépendances Maven ou Ant, et à vous assurer que vous avez réellement besoin de toutes ces librairies. Avec Java 6 les choses ont changé, prenez le temps de nettoyer le code puis d’effacer les anciennes librairies.

Règle 6 : mettez en place un suivi
Une fois votre application modernisée, ou plutôt avant même d’y avoir touché, mettez en place des outils de suivi de la qualité du code, de la couverture des tests, de la performance en mémoire et CPU… Bref installez une Tour de contrôle avant de faire de l’archéologie.

Sans hésiter, installez Sonar afin de mettre votre dette technique sous contrôle. Il demande un peu d’efforts pour être correctement réglé, mais ce que j’aime beaucoup c’est le suivi. Il vous donnera un indicateur de progrès. Et il sera là aussi pour signaler aux développeurs qu’il surveille la qualité de votre produit.

Donc mettre en place un suivi du patient, afin de s’assurer qu’il ne revienne pas sur la table d’opération toutes les 3 semaines.

Règle 7 : pensez au futur
J’ai en tête la célèbre phrase du wiki C2 sur la page Code for the Maintainer :
« Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live. »
Ce qui donne
« Code toujours comme si tu savais que la personne qui maintiendra ton code est un psychopathe violent qui sait où tu habites… »

En fait il faut être eco-responsable. Vous faîtes du tri sélectif ? Et bien codez proprement. Pensez que ce sera peut-être vous dans 6 ans qui serez appelé pour corriger un problème sur votre logiciel. Ou peut-être votre fils qui aura trouvé votre nom sur Google dans un projet open-source Lambda dans 15 ans… Bref codez pour être fier de montrer votre programme à votre fils dans quelques années.

Conclusion
Je me demande si les projets et les applications passent la barre des 10 ans dans le monde Java. Je ne parle pas d’autres langages, je parle que de Java. Avec les projets ou les produits sur lesquels j’ai travaillé, j’ai déjà la réponse. Je sais ce qu’ils sont devenus. J’ai eu par contre à reprendre du code de nombreuses fois, et à faire ce travail de mise à jour, sans tout casser. Il y a donc une compétence « Docteur Love, maître du Lifting » à acquérir pour faire un bon développeur dans le monde Java.

Il n’y a pas de mauvais frameworks Webs. Selon votre projet je vous encourage à tester différentes approches et à évoluer selon vos besoins fonctionnels. Essayez aussi de prototyper avec un outil comme Balsamiq ou iRise Studio par exemple.

Pensez incrément lorsque vous faîtes du Web. Essayez de construire par petites étapes votre solution, et faites valider par l’utilisateur final les écrans. Le plus important : un logiciel qui marche et une interface qui répond à la demande du client. C’est cela qui doit vous guider pendant votre développement.

And now… JSF 2 and Play! Framework

Si vous souhaitez suivre le code de cet article, je vous encourage à suivre le petit tutorial que j’ai écris sur NetBeans 6.9. Cela vous permettra de générer rapidement une petite application en JSF 2 et Java EE 6 pour la partie Bean. Vous pouvez télécharger le code complet de la partie JSF ici afin de pouvoir suivre simplement la discusssion.

Pour écrire cet article, j’ai écris la partie Play! Framework après la partie JSF 2.0. Je vous guiderai donc sur la partie Play! Framework.

Création d’une application avec Play! Framework
- Télechargez Play! Framework sur le site de Play!
- Décompressez l’archive, ajoutez ensuite le répertoire de play à votre PATH.
- Ouvrez un terminal, dans un répertoire de test, tapez « play » afin de vérifier qu’il est bien installé. J’ai utilisé la version 1.0.3

macbook-pro-de-nicolas-martignole:NetBeansProjects nicolas$ play
~ _ _
~ _ __ | | __ _ _ _| |
~ | '_ \| |/ _' | || |_|
~ | __/|_|\____|\__ (_)
~ |_| |__/
~
~ play! 1.0.3, http://www.playframework.org
~ framework ID is macbookpro
~
~ Usage: play cmd [app_path] [--options]
~
~ with, new Create a new application
~ run Run the application in the current shell
~ help Show play help
~


- Tapez ensuite « play new micromarket » afin de créer une application de test


macbook-pro-de-nicolas-martignole:NetBeansProjects nicolas$ play new micromarket
~ _ _
~ _ __ | | __ _ _ _| |
~ | '_ \| |/ _' | || |_|
~ | __/|_|\____|\__ (_)
~ |_| |__/
~
~ play! 1.0.3, http://www.playframework.org
~ framework ID is macbookpro
~
~ The new application will be created in /Users/nicolas/NetBeansProjects/micromarket
~ What is the application name? micromarket
~
~ OK, the application is created.
~ Start it with : play run micromarket
~ Have fun!
~
macbook-pro-de-nicolas-martignole:NetBeansProjects nicolas$

- Placez vous dans le répertoire micromarket puis tapez play run et vérifiez que la page de démarrage de Play! se lance sur http://localhost:9000/

Bravo, vous avez créé une application Play.

Entité JPA
Vous pouvez prendre l’entité JPA MicroMarket du projet NetBeans et la placer dans le répertoire de Play!, cela fonctionne. En effet, il utilise JPA et Hibernate, donc pour lui, cela ne change pas grand chose. Voici le code initial de l’entité MicroMarket avant modification :

package org.letouilleur.demo;

import java.io.Serializable;
import javax.persistence.Basic;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.NamedQueries;
import javax.persistence.NamedQuery;
import javax.persistence.Table;

/**
 *
 * @author nicolas
 */
@Entity
@Table(name = "MICRO_MARKET")
@NamedQueries({
    @NamedQuery(name = "MicroMarket.findAll", query = "SELECT m FROM MicroMarket m"),
    @NamedQuery(name = "MicroMarket.findByZipCode", query = "SELECT m FROM MicroMarket m WHERE m.zipCode = :zipCode"),
    @NamedQuery(name = "MicroMarket.findByRadius", query = "SELECT m FROM MicroMarket m WHERE m.radius = :radius"),
    @NamedQuery(name = "MicroMarket.findByAreaLength", query = "SELECT m FROM MicroMarket m WHERE m.areaLength = :areaLength"),
    @NamedQuery(name = "MicroMarket.findByAreaWidth", query = "SELECT m FROM MicroMarket m WHERE m.areaWidth = :areaWidth")})
public class MicroMarket implements Serializable {
    private static final long serialVersionUID = 1L;
    @Id
    @Basic(optional = false)
    @Column(name = "ZIP_CODE")
    private String zipCode;
    @Column(name = "RADIUS")
    private Double radius;
    @Column(name = "AREA_LENGTH")
    private Double areaLength;
    @Column(name = "AREA_WIDTH")
    private Double areaWidth;

    public MicroMarket() {
    }

    public MicroMarket(String zipCode) {
        this.zipCode = zipCode;
    }

    public String getZipCode() {
        return zipCode;
    }

    public void setZipCode(String zipCode) {
        this.zipCode = zipCode;
    }

    public Double getRadius() {
        return radius;
    }

    public void setRadius(Double radius) {
        this.radius = radius;
    }

    public Double getAreaLength() {
        return areaLength;
    }

    public void setAreaLength(Double areaLength) {
        this.areaLength = areaLength;
    }

    public Double getAreaWidth() {
        return areaWidth;
    }

    public void setAreaWidth(Double areaWidth) {
        this.areaWidth = areaWidth;
    }

    @Override
    public int hashCode() {
        int hash = 0;
        hash += (zipCode != null ? zipCode.hashCode() : 0);
        return hash;
    }

    @Override
    public boolean equals(Object object) {
        // TODO: Warning - this method won't work in the case the id fields are not set
        if (!(object instanceof MicroMarket)) {
            return false;
        }
        MicroMarket other = (MicroMarket) object;
        if ((this.zipCode == null && other.zipCode != null) || (this.zipCode != null && !this.zipCode.equals(other.zipCode))) {
            return false;
        }
        return true;
    }

    @Override
    public String toString() {
        return "org.letouilleur.demo.MicroMarket[zipCode=" + zipCode + "]";
    }

}

A cet instant, je vais vous proposer une approche un peu différente. J’insiste lourdement sur le fait que ce n’est pas obligatoire mais intéressant. Play! propose d’utiliser une approche orientée DDD où les objets du domaine ne sont pas anémiques, mais capables d’effectuer des services simples. Pour cela, le pattern que j’utilise est de donner une référence à ce que l’on appelle le « Repository » dans DDD, et de l’injecter dans mon Entité. Grâce à une classe générique, dans laquelle l’EntityManager sera injecté, et dans laquelle je vais déclarer mes méthodes standards type CRUD, toutes mes Entités pourront alors exécuter du code d’accès au Repository.

Ce que nous allons voir n’est pas mieux ou moins bien que l’approche services/par couche que vous connaissez tous. J’ai envie de vous dire de laisser tomber les couches et de grandir pour faire un bon mot.

Play! propose (n’impose pas) d’étendre soit la classe JPASupport, soit la classe Model, afin que l’accès à l’EntityManager soit injecté par le framework. C’est un couplage fort, mais sur la modélisation du domaine ce n’est pas un souci. Je n’ai pas vu de projets avec de l’héritage d’Entité, et j’ai souvent vu que les problèmes de composition ou d’agrégation étaient résolus sans faire appel à de l’héritage de classes.

J’effectue d’abord 3 modifications : le package, un import en plus et l’extends :

// Fichier micromarket/app/models/org/letouilleur/demo/MicroMarket.java
// dans le répertoire de l'appli Play!
// Changement 1
package models.org.letouilleur.demo;

import java.io.Serializable;
import javax.persistence.Basic;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.NamedQueries;
import javax.persistence.NamedQuery;
import javax.persistence.Table;

// Changement 2
import play.db.jpa.*;

@Entity
@Table(name = "MICRO_MARKET")
@NamedQueries({
    @NamedQuery(name = "MicroMarket.findAll", query = "SELECT m FROM MicroMarket m"),
    @NamedQuery(name = "MicroMarket.findByZipCode", query = "SELECT m FROM MicroMarket m WHERE m.zipCode = :zipCode"),
    @NamedQuery(name = "MicroMarket.findByRadius", query = "SELECT m FROM MicroMarket m WHERE m.radius = :radius"),
    @NamedQuery(name = "MicroMarket.findByAreaLength", query = "SELECT m FROM MicroMarket m WHERE m.areaLength = :areaLength"),
    @NamedQuery(name = "MicroMarket.findByAreaWidth", query = "SELECT m FROM MicroMarket m WHERE m.areaWidth = :areaWidth")})

// Changement 3
public class MicroMarket extends JPASupport implements Serializable {
    private static final long serialVersionUID = 1L;
    @Id
    @Basic(optional = false)
    @Column(name = "ZIP_CODE")
    private String zipCode;
    @Column(name = "RADIUS")
    private Double radius;
    @Column(name = "AREA_LENGTH")
    private Double areaLength;
    @Column(name = "AREA_WIDTH")
    private Double areaWidth;

    public MicroMarket() {
    }

    public MicroMarket(String zipCode) {
        this.zipCode = zipCode;
    }

    public String getZipCode() {
        return zipCode;
    }

    public void setZipCode(String zipCode) {
        this.zipCode = zipCode;
    }

    public Double getRadius() {
        return radius;
    }

    public void setRadius(Double radius) {
        this.radius = radius;
    }

    public Double getAreaLength() {
        return areaLength;
    }

    public void setAreaLength(Double areaLength) {
        this.areaLength = areaLength;
    }

    public Double getAreaWidth() {
        return areaWidth;
    }

    public void setAreaWidth(Double areaWidth) {
        this.areaWidth = areaWidth;
    }

    @Override
    public int hashCode() {
        int hash = 0;
        hash += (zipCode != null ? zipCode.hashCode() : 0);
        return hash;
    }

    @Override
    public boolean equals(Object object) {
        // TODO: Warning - this method won't work in the case the id fields are not set
        if (!(object instanceof MicroMarket)) {
            return false;
        }
        MicroMarket other = (MicroMarket) object;
        if ((this.zipCode == null && other.zipCode != null) || (this.zipCode != null && !this.zipCode.equals(other.zipCode))) {
            return false;
        }
        return true;
    }

    @Override
    public String toString() {
        return "org.letouilleur.demo.MicroMarket[zipCode=" + zipCode + "]";
    }

}

Ensuite, éditez le fichier micromarket/conf/application.conf de Play! afin d’activer une base de données. Nous allons utiliser une base en mémoire. Pas besoin de s’embêter avec le schéma, car Play! va créer une table MicroMarket identique à notre spécification, sans même avoir besoin de relancer le serveur.

A cet instant, si vous sauvez et que vous rechargez votre page, Play! compile le code, et vous serez notifié d’éventuelles erreurs. Pour l’instant nous n’avons pas d’entrées dans notre base, ni de page. Il faut continuer.

Allons encore plus loin. Les NamesQuery sont utilisables, mais je vais utiliser des fonctions de Play! afin d’avoir le support de la pagination intégré, sans devoir écrire cette logique dans une autre classe. Cela équivaut au code utilisant PaginationHelper de la classe MicroMarketController. Je n’invente rien. Avec ce que je vous montre nous n’avons pas besoin de déclarer ce système de PaginationHelper comme dans la version JSF, puisque c’est Play! qui vous le donne. Deuxième modification : je passe en public les attributs, puisque les getters/setters ne me servent à rien ici.

L’entité au final est donc encore plus simple :

package models.org.letouilleur.demo;

import java.io.Serializable;
import javax.persistence.Basic;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.Table;

import play.db.jpa.*;
import java.util.*;

@Entity
@Table(name = "MICRO_MARKET")
public class MicroMarket extends JPASupport implements Serializable {
    private static final long serialVersionUID = 1L;
    @Id
    @Basic(optional = false)
    @Column(name = "ZIP_CODE")
    public String zipCode;
    @Column(name = "RADIUS")
    public Double radius;
    @Column(name = "AREA_LENGTH")
    public Double areaLength;
    @Column(name = "AREA_WIDTH")
    public Double areaWidth;

    public MicroMarket() {
    }

    public MicroMarket(String zipCode) {
        this.zipCode = zipCode;
    }

    @Override
    public int hashCode() {
        int hash = 0;
        hash += (zipCode != null ? zipCode.hashCode() : 0);
        return hash;
    }

    @Override
    public boolean equals(Object object) {
        // TODO: Warning - this method won't work in the case the id fields are not set
        if (!(object instanceof MicroMarket)) {
            return false;
        }
        MicroMarket other = (MicroMarket) object;
        if ((this.zipCode == null && other.zipCode != null) || (this.zipCode != null && !this.zipCode.equals(other.zipCode))) {
            return false;
        }
        return true;
    }

    @Override
    public String toString() {
        return "org.letouilleur.demo.MicroMarket[zipCode=" + zipCode + "]";
    }

    /** Retourne la liste des MicroMarket en utilisant la méthode find hérité de JPASupport
      * zipCode : critere de recherche
      * page: numéro de la page à charger, si vous affichez un tableau paginé par exemple
      * length: taille de la page, par exemple 10 pour charger 10 entrées
      */
    public List<Micromarket> findByZipCode(String zipCode, int page, int length) {
        return  find("from MicroMarket m where m.zipcode like :p").bind("p",zipCode).fetch(page,length);
    }

   //.. autre finder
}

Voilà, comme vous pouvez le constater, ce n’est pas une révolution, simplement une approche différente pour le domaine.

La partie Java EE 6

Pour commencer, je vais regarder comment fonctionne la page qui donne la liste des Entités, avec la pagination. Dans la version JSF, nous avons un ManagedBean, la class MicroMarketController. Celui-ci utilise un EJB Stateless, MicroMarketFacade, qui donne accès à l’EntityManager, un DAO en quelque sorte.

public abstract class AbstractFacade<T> {
    private Class<T> entityClass;

    public AbstractFacade(Class<T> entityClass) {
        this.entityClass = entityClass;
    }

    protected abstract EntityManager getEntityManager();

    public void create(T entity) {
        getEntityManager().persist(entity);
    }

    public void edit(T entity) {
        getEntityManager().merge(entity);
    }

    public void remove(T entity) {
        getEntityManager().remove(getEntityManager().merge(entity));
    }

    public T find(Object id) {
        return getEntityManager().find(entityClass, id);
    }

    public List<T> findAll() {
        javax.persistence.criteria.CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
        cq.select(cq.from(entityClass));
        return getEntityManager().createQuery(cq).getResultList();
    }

    public List<T> findRange(int[] range) {
        javax.persistence.criteria.CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
        cq.select(cq.from(entityClass));
        javax.persistence.Query q = getEntityManager().createQuery(cq);
        q.setMaxResults(range[1] - range[0]);
        q.setFirstResult(range[0]);
        return q.getResultList();
    }

    public int count() {
        javax.persistence.criteria.CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
        javax.persistence.criteria.Root<T> rt = cq.from(entityClass);
        cq.select(getEntityManager().getCriteriaBuilder().count(rt));
        javax.persistence.Query q = getEntityManager().createQuery(cq);
        return ((Long) q.getSingleResult()).intValue();
    }

}

Sa spécialisation en classe MicroMarketFacade est super simple et propre :

package org.letouilleur.demo;

import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

@Stateless
public class MicroMarketFacade extends AbstractFacade<Micromarket> {
    @PersistenceContext(unitName = "WebApplication1PU")
    private EntityManager em;

    protected EntityManager getEntityManager() {
        return em;
    }

    public MicroMarketFacade() {
        super(MicroMarket.class);
    }

}

Jusqu’ici, on voit qu’avec 2 classes et Java EE 6 vous pouvez faire l’équivalent de ce que vous avez l’habitude de faire avec Spring par exemple. Je trouve le code simple et efficace.

JSF et la partie ManagedBean

Attention là c’est un poil plus compliqué. La classe MicroMarketController est un ManagedBean JSF, capable de gérer la pagination. Le moins que l’on puisse dire, c’est que ce n’est pas simple.
Pour être plus équitable, j’ai retiré la pagination, et l’on voit alors que le code est simple, pas plus compliqué que la version Play! Framework. La version originale est plus complexe, avec la gestion de la pagination et un Converter pour retenir l’élément sélectionné. S’il y a possibilité de critiquer JSF, c’est sur cette partie, que je vous laisse regarder dans le fichier original.

package org.letouilleur.demo;

import javax.ejb.EJB;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.convert.Converter;
import javax.faces.convert.FacesConverter;
import javax.faces.model.DataModel;
import javax.faces.model.ListDataModel;

@ManagedBean (name="microMarketController")
@SessionScoped
public class MicroMarketController {
    private DataModel items = null;
    @EJB private org.letouilleur.demo.MicroMarketFacade ejbFacade;

    public MicroMarketController() {
    }

    private MicroMarketFacade getFacade() {
        return ejbFacade;
    }

    public String prepareList() {
        recreateModel();
        return "List";
    }

    public DataModel getItems() {
        if (items == null) {
            items = new ListDataModel(getFacade().findAll());
        }
        return items;
    }

    private void recreateModel() {
        items = null;
    }

}

Et si nous écrivions le controleur de la version Play ? Vous êtes prêt ?

Ouvrez la class app/controllers/Application.java et ajouter une nouvelle méthode static list comme ci-dessous:

// CODE PLAY dans app/controllers/Application.java
package controllers;

import play.mvc.*;
import models.org.letouilleur.demo.MicroMarket;
import java.util.List;

public class Application extends Controller {

    public static void index() {
        render();
    }

    public static void list() {
	    List listOfMicroMarkets=MicroMarket.findAll();
        render(listOfMicroMarkets);
    }
}

Voilà, c’est tout.

La vue

Si vous le voulez bien, terminons par la vue. Pour Play c’est assez simple, voir un peu simpliste. Créez une page list.html dans le répertoire views/Application. La page portant le même nom que la méthode du contrôleur, elle sera chargée automatiquement par Play!

#{extends 'main.html' /}
#{set title:'List of MicroMarket' /}
List of MicroMarket

#{list items:listOfMicroMarkets, as:'currentMicroMarket'}
${currentMicroMarket.id} ${currentMicroMarket.zipCode} ${currentMicroMarket.radius} ${currentMicroMarket.areaLength} ${currentMicroMarket.areaWidth} 
#{/list}

Si vous sauvez cette page et que vous testez… petit déception. Il n’y a rien dans notre base de données. Comment tester ? Et bien nous allons créer un Bootstrap (comme avec Grails) afin de charger un fichier YAML. Ce fichier contiendra 3 entrées pour tester.

Créez un fichier BootStrap.java dans le répertoire app de Play:

import play.Play;
import play.jobs.*;
import play.test.*;

import models.*;
import models.org.letouilleur.demo.*;

@OnApplicationStart
public class BootStrap extends Job {

    public void doJob() {
        if (Play.mode == Play.Mode.DEV) {
            Fixtures.load("test-data.yml");
        }
    }

}

Ensuite créez un fichier test-data.yml dans le répertoire conf:

models.org.letouilleur.demo.MicroMarket(m1):
    zipCode: 95051.0
    radius: 255.59
    areaLength: 689.856
    areaWidth: 478.479    

models.org.letouilleur.demo.MicroMarket(m2):
    zipCode: 33740.0
    radius: 12.59
    areaLength: 389.52
    areaWidth: 528.41    

models.org.letouilleur.demo.MicroMarket(m3):
    zipCode: 89211.0
    radius: 120.3
    areaLength: 39.856
    areaWidth: 452.52    

Relancez le serveur, et chargez alors la page pour lister nos entrées (http://localhost:9000/application/list). Hop voilà la liste des entrées de la base. Notez que la page est moche par rapport à la version JSF.

La version JSF est plus complète, mais on va revenir là dessus à la fin:

Et pour terminer, regardons le code la partie JSF, dans le fichier List.xhtml. J’ai retiré la pagination afin d’alléger la page :

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core">

    <ui:composition template="/template.xhtml">
        <ui:define name="title">
            <h:outputText value="#{bundle.ListMicroMarketTitle}"></h:outputText>
        </ui:define>
        <ui:define name="body">
        <h:form styleClass="jsfcrud_list_form">
            <h:panelGroup id="messagePanel" layout="block">
                <h:messages errorStyle="color: red" infoStyle="color: green" layout="table"/>
            </h:panelGroup>
            <h:outputText escape="false" value="#{bundle.ListMicroMarketEmpty}" rendered="#{microMarketController.items.rowCount == 0}"/>
            <h:panelGroup rendered="#{microMarketController.items.rowCount > 0}">
                <h:dataTable value="#{microMarketController.items}" var="item" border="0" cellpadding="2" cellspacing="0" rowClasses="jsfcrud_odd_row,jsfcrud_even_row" rules="all" style="border:solid 1px">
                    <h:column>
                        <f:facet name="header">
                            <h:outputText value="#{bundle.ListMicroMarketTitle_zipCode}"/>
                        </f:facet>
                        <h:outputText value="#{item.zipCode}"/>
                    </h:column>
                    <h:column>
                        <f:facet name="header">
                            <h:outputText value="#{bundle.ListMicroMarketTitle_radius}"/>
                        </f:facet>
                        <h:outputText value="#{item.radius}"/>
                    </h:column>
                    <h:column>
                        <f:facet name="header">
                            <h:outputText value="#{bundle.ListMicroMarketTitle_areaLength}"/>
                        </f:facet>
                        <h:outputText value="#{item.areaLength}"/>
                    </h:column>
                    <h:column>
                        <f:facet name="header">
                            <h:outputText value="#{bundle.ListMicroMarketTitle_areaWidth}"/>
                        </f:facet>
                        <h:outputText value="#{item.areaWidth}"/>
                    </h:column>
                    <h:column>
                        <f:facet name="header">
                            <h:outputText value=" "/>
                        </f:facet>

                    </h:column>
                </h:dataTable>
            </h:panelGroup>
            <br />
        </h:form>
        </ui:define>
    </ui:composition>

</html>

Alors pour enfoncer le clou, je propose de piquer la CSS de JSF, de mettre un tableau HTML simple, et de voir ce que cela donne. Play! Framework utilise le langage Groovy comme moteur de template dans la vue. Cela rend plus simple l’écriture des pages, mais ne permet pas de se faire aider lors de la création des pages, comme avec JSF dans NetBeans. Il y a donc un risque d’erreur. La bonne nouvelle, c’est que vous n’avez pas à arrêter Play! pour voir vos modifications. Il suffit de recharger la page dans votre navigateur.

Et le code HTML associé :

#{extends 'main.html' /}
#{set title:'List of MicroMarket' /}

<h2>List of MicroMarket</h2>
<P>Play! Framework</P>

<table border="0" cellpadding="2" cellspacing="0" rules="all" style="border:solid 1px">
<thead>

<tr class="">
   <th scope="col">ZipCode</th>
   <th scope="col">Radius</th>
   <th scope="col">AreaLength</th>
   <th scope="col">AreaWidth</th>
</tr>
</thead>
<tbody>
#{list items:listOfMicroMarkets, as:'currentMicroMarket'}
<tr class="jsfcrud_${currentMicroMarket_parity}_row">
	<td>${currentMicroMarket.zipCode}</td>
    <td>${currentMicroMarket.radius}</td>
    <td>${currentMicroMarket.areaLength}</td>
    <td>${currentMicroMarket.areaWidth}</td>
</tr>
#{/list}
</tbody>
</table>

Analyse des 2 approches

Que pensez-vous de la partie vue de la version JSF ? Objectivement, j’ai l’impression d’écrire en tag JSF du code HTML. Je sais la puissance de JSF et que je peux gagner du temps, mais au prix d’une complexité dont je n’ai pas besoin dès le départ. Côté Play! Framework, les tableaux paginés et triés existent aussi, grâce aux librairies de jQuery. D’ailleurs, le code généré par JSF utilise aussi la librairie jQuery. Au final cela ne change pas grand chose dans le navigateur. Donc je préfère la simplicité de Play! Framework à l’approche complète de JSF, mais il faut reconnaître que JSF sera en mesure de construire des interfaces plus riches que Play!, qui reste très basique.

Côté serveur, la partie Entité et DAO ne change pas beaucoup. La philosophie est différente, mais cela correspond à une manière de coder. Le ManagedBean et son Converter dans la version complète est lui aussi un peu compliqué. Pourquoi avoir un DataModel (regardez le code de la méthode List) alors qu’une List d’entité ferait l’affaire ?

Conclusion

Après avoir vu tout ce code, on voit bien la différence d’approche. Il n’y a pas de vainqueur, il y a deux approches différentes. Côté Model et Controleur, c’est du pareil au même. A part l’approche orientée DDD de Play! nous n’avons pas vu de grosses différences. Côté vue, j’ai le choix entre JSF qui me permet d’écrire plutôt une application type client riche, ou Play! qui me laisse me débrouiller avec ma page HTML.

La conclusion ?

C’est parce que Play! Framework est proche de ce que nous avons déjà l’habitude de faire que je vous recommande de regarder. Il vous faudra quelques heures à peine pour vous en servir, et vous serez surpris. Productivité, plaisir et impression d’avancer.

Références:
Le code du projet Play! zippé et du projet JSF sont disponible ici: http://touilleur-express.fr/divers/jsf/.

Pour vous accompagner durant ce vol, installez vous confortablement, prenez le pack de 178Mo de NetBeans 6.9 pour ne pas perdre de temps avec un IDE des années 90, et en avant l’aventure.

Ce que je souhaite faire, c’est vous montrer comment écrire en quelques minutes une application Web légère, à la mode de Play! Framework, mais en travaillant avec Java EE 6.

Une fois NetBeans démarré, créez un nouveau projet, et sélectionnez « Java Web/Web Application ».

(Cliquez sur l’image ci-dessous pour l’afficher en grand)

Je garde le nom proposé par NetBeans de « WebApplication1″, je décide d’utiliser le serveur GlassFish et d’utiliser Java EE 6. Ecran suivant, j’active Hibernate et JSF2 car nous allons en avoir besoin dans quelques minutes.

(Cliquez sur l’images pour l’afficher en grand… oui je l’ai déjà dit ci-dessus)

L’environnement est pré-configuré avec une base Apache Derby.
Cliquez sur Finish, NetBeans créé un projet prêt à être déployé.

Générer une Entité, un Controleur et une Facade
Je vous propose de vous montrer comment générer des pages type CRUD en quelques minutes, le tout avec NetBeans, sans taper une ligne de code.

Dans l’onglet « Services » en haut à gauche, cliquez sur Databases > jdbc:derby://localhost:1527/sample. Clique droit, et sélectionnez Connect… Vous verrez alors différents catalogues. Sélectionnez « APP », puis dans Table vous verrez qu’il y a plusieurs Tables préconfigurées : CUSTOMER, DISCOUNT_CODE, et d’autres. Nous avons donc de quoi générer des Entités.

Cliquez sur l’onglet « Projects » en haut à droite, puis sur le répertoire « Source Packages », faites un clique droit sur ce répertoire pour sélectionner ensuite « Entity Classes from Database » dans le menu contextuel :

Après avoir sélectionné « jdbc/sample » dans la liste DataSource, sélectionnez une des Tables. J’ai pris MICRO_MARKET. Sur l’écran suivant, créez un package org.letouilleur.demo puis cliquez sur « Finish ». Le code de l’Entité généré est très complet :

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */

package org.letouilleur.demo;

import java.io.Serializable;
import javax.persistence.Basic;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.NamedQueries;
import javax.persistence.NamedQuery;
import javax.persistence.Table;

/**
 *
 * @author nicolas
 */
@Entity
@Table(name = "MICRO_MARKET")
@NamedQueries({
    @NamedQuery(name = "MicroMarket.findAll", query = "SELECT m FROM MicroMarket m"),
    @NamedQuery(name = "MicroMarket.findByZipCode", query = "SELECT m FROM MicroMarket m WHERE m.zipCode = :zipCode"),
    @NamedQuery(name = "MicroMarket.findByRadius", query = "SELECT m FROM MicroMarket m WHERE m.radius = :radius"),
    @NamedQuery(name = "MicroMarket.findByAreaLength", query = "SELECT m FROM MicroMarket m WHERE m.areaLength = :areaLength"),
    @NamedQuery(name = "MicroMarket.findByAreaWidth", query = "SELECT m FROM MicroMarket m WHERE m.areaWidth = :areaWidth")})
public class MicroMarket implements Serializable {
    private static final long serialVersionUID = 1L;
    @Id
    @Basic(optional = false)
    @Column(name = "ZIP_CODE")
    private String zipCode;
    @Column(name = "RADIUS")
    private Double radius;
    @Column(name = "AREA_LENGTH")
    private Double areaLength;
    @Column(name = "AREA_WIDTH")
    private Double areaWidth;

    public MicroMarket() {
    }

    public MicroMarket(String zipCode) {
        this.zipCode = zipCode;
    }

    public String getZipCode() {
        return zipCode;
    }

    public void setZipCode(String zipCode) {
        this.zipCode = zipCode;
    }

    public Double getRadius() {
        return radius;
    }

    public void setRadius(Double radius) {
        this.radius = radius;
    }

    public Double getAreaLength() {
        return areaLength;
    }

    public void setAreaLength(Double areaLength) {
        this.areaLength = areaLength;
    }

    public Double getAreaWidth() {
        return areaWidth;
    }

    public void setAreaWidth(Double areaWidth) {
        this.areaWidth = areaWidth;
    }

    @Override
    public int hashCode() {
        int hash = 0;
        hash += (zipCode != null ? zipCode.hashCode() : 0);
        return hash;
    }

    @Override
    public boolean equals(Object object) {
        // TODO: Warning - this method won't work in the case the id fields are not set
        if (!(object instanceof MicroMarket)) {
            return false;
        }
        MicroMarket other = (MicroMarket) object;
        if ((this.zipCode == null && other.zipCode != null) || (this.zipCode != null && !this.zipCode.equals(other.zipCode))) {
            return false;
        }
        return true;
    }

    @Override
    public String toString() {
        return "org.letouilleur.demo.MicroMarket[zipCode=" + zipCode + "]";
    }

}

La Table Micro_Market a pour PRIMARY_KEY une clé technique de type NUMERIC. Comme je le disais sur Twitter hier soir, NetBeans 6.9 génère les méthodes hashCode() et equals() en se basant sur l’id technique, pour peu évidemment qu’il soit présent. Moi je trouve que c’est une bonne chose.

J’en ai parlé en 2009 lorsque j’avais testé SpringFuse et plus récemment dans un article en juin, peut-être pas assez complet je pense.

Générer des pages CRUD avec JSF 2.0
Pour continuer, voyons comment générer quelques pages comme list, create, edit et delete avec JSF. L’approche proposée par NetBeans est simple, elle utilise une Facade sous la forme d’un EJB Stateless et un Controleur, sous la forme d’un ManagedBean.

Cliquons à nouveau sur le répertoire « Source Package » et sélectionnons « New>JSF Pages from Entity Classes ». Sélectionnez alors votre entité, puis sur l’écran suivant précisez où vous souhaitez stocker la partie Session, les pages JSF et enfin le répertoire pour les pages. Dans la zone JSP Pages Folder je n’ai rien précisé.

NetBeans génère une Facade, un Contrôleur et quelques pages JSF. Je vous présenterai les différences d’approche entre la version JSF 2 et une version Play! Framework dans un deuxième article.

Test final
Il est temps de démarrer le serveur et de tester. Cliquez sur « Run Main Projet » (F6). GlassFish se lance rapidement et la page d’accueil permet de sélectionner l’option  »

En quelques minutes, NetBeans génère un petit projet complet avec une Entity, une partie JSF simple, et quelques pages type CRUD, ce qui donne une bonne base de départ. J’aime l’aspect couteau-suisse de NetBeans : simple, propre, facile à mettre en oeuvre. Pour débuter avec Java EE 6, je pense que c’est un bon outil, qui permet d’aller à l’essentiel sans perdre de temps à installer ou configurer quoique ce soit.

A tester donc !

Dans le prochain article : comparaison de l’approche JSF 2 par rapport à Play! Framework

Références
Introduction to JavaServer Faces 2.0 with NetBeans

Cher Oracle

Je suis développeur Java. Dans la vie, mon métier consiste à coder des logiciels en utilisant Java, un langage porté par SUN Microsystems depuis des années. Depuis que tu as racheté SUN Microsystems, je comprends très bien que tu fasses des efforts pour porter le langage et la communauté. Mais aujourd’hui je t’écris pour te faire part de ma vive déception. Je reste poli, mais le cœur y est…

Lorsque je développe, j’ai souvent besoin de regarder la documentation du langage Java. Pour cela, le plus simple est simplement de passer par Google. Je saisie le nom d’une Classe dans la zone de recherche et je m’attends alors à trouver la Javadoc. Cela me permet aussi lorsque j’écris des articles sur ce Blog, de donner des références à mes lecteurs afin de leur permettre de trouver de l’information.

Il y a quelques jours, j’ai constaté que tu avais décidé de rediriger les URLs des adresses des pages de la documentation du langage Java.
Je t’explique:
- lorsque tu tapes « IndexOutOfBoundsException » dans Google afin de retrouver rapidement la documentation de cette classe Java, historiquement nous tombions sur l’URL suivante :

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IndexOutOfBoundsException.html

- mon souci aujourd’hui c’est que cette URL est redirigée vers une obscure URL sur le site d’Oracle:

http://download.oracle.com/docs/cd/E17476_01/javase/1.5.0/docs/api/java/lang/IndexOutOfBoundsException.html

Au nom de la communauté des développeurs Javas, j’aimerai donc que tu reviennes aux URLs classiques, celles que je connais depuis 1996, et qui n’avaient jamais changé jusqu’à aujourd’hui

Bien à toi,

Nicolas

Références:
Dear Oracle, can we have our nice javadoc URLs back?.
Twitter fight for #E17476.
Parlez-en via Twitter à John Clingan, PM de GlassFish qui est conscient du problème.

Je vais continuer à travailler sur ce sujet. A priori je devrai en parler sous la forme d’une Keynote à la conférence Soft-Shake à Genève à la rentrée. C’est une conférence sur Java, l’Agilité, le développement iPhone et le développement en général. J’aimerai aller voir aussi quelques Java User Group à partir de la rentrée, pour parler développement, passion et vous rencontrer.

En attendant, merci encore une fois à Octo Technology et en particulier à Pierre Piezzardi qui m’a aidé, et retenu pour cette session de 2010.

La vidéo:
(Ouvre la vidéo dans une autre fenêtre)

Les slides:

Neal Ford, Crédit photo : USI 2010 album sur Flickr.com

De l’importance de la communication
Après cette première partie, Neal Ford nous parle maintenant de la communication. Plus importante que la technologie, nous allons voir que la communication est l’un des points clés pour réussir des projets.

Neal demande à la salle si nous avons déjà fait partie de projets qui se sont plantés. Rires, quelques mains se lèvent. Il demande ensuite si la raison de l’échec était le mauvais choix d’une technologie, ou une mauvaise communication ? L’ensemble répond : la communication.

Il est donc plus facile de planter un projet car vous communiquez mal, que parce que vous avez pris un framework exotique au lieu de prendre un framework standard.

Les projets se plantent souvent à cause des gens. La communication entre les gens devient très importante. Nous sommes des créatures massivement communicantes. Notez qu’en prison, la plus grosse punition est d’aller au mitard. De ne plus pouvoir communiquer avec d’autres humains… Dingue non ? Pensez aussi aux gens que l’on met « au placard »… Nous avons besoin de communiquer. C’est vital.

Alistair Cockburn explique dans un graphe que la qualité de la communication avec les outils modernes est très inégale.

Pour travailler, nous sommes bien plus efficace devant un tableau blanc qu’au téléphone, ou même pire, via un document Word. Le pire des processus de communication est le papier écrit. Et le drame, c’est que c’est l’un des plus utilisés dans les Entreprises. C’est marrant, mais la semaine dernière je suis allé chercher un grand tableau blanc pour notre équipe, et je l’ai installé dans notre bureau… Croyez-moi cela marche.

Neal Ford explique que c’est pour cette raison, qu’il est illusoire de croire qu’une spécification technique envoyé à des développeurs en Inde donnera le logiciel escompté. C’est une perte de temps et d’argent. Cela ne fonctionne pas.

Cela va plus loin. Nous avons même une capacité limitée à communiquer et faire autre chose en même temps. Vous ne vous êtes pas demandé pourquoi il est dangereux de téléphoner et conduire en même temps ? Pourtant vous avez le droit de parler avec votre voisin, vous pouvez écouter la radio, mais on vous interdit de téléphoner en même temps. Or pour ceux qui ont essayé (moi le premier) vous vous rendrez compte que la communication au téléphone est moins bonne que lorsque vous avez la personne à côté de vous. Cela vous demande même un effort plus important pour comprendre. Et cet effort vous déconcentre de la route. C’est bien là la preuve que les canaux de communications demandent plus ou moins d’efforts.

Un document écrit est aussi très destructif, car la possibilité de donner son retour n’existe pas ou peu, par rapport à une communication face à face. Bien entendu, ces documents sont souvent écrits à la suite de réunions, où nous nous sommes vus… Mais souvent le développeur n’aura pas eu l’opportunité de discuter avec le client, et de poser quelques questions simples. Il est donc primordial pour réussir un projet de prendre en compte ce facteur de communication.

Le manifeste Agile propose 4 valeurs clés, dont l’une est exactement ce que Neal Ford vient d’expliquer.
Les quatre valeurs fondamentales Agiles sont :
– Davantage l’interaction avec les personnes que les processus et les outils.
– Davantage un produit opérationnel qu’une documentation pléthorique.
– Davantage la collaboration avec le client que la négociation de contrat.
– Davantage la réactivité face au changement que le suivi d’un plan.

Voir l’article original en Anglais : http://agilemanifesto.org/

Neal Ford présente ensuite un projet supporté par ThoughWorks au Malawi. Ce projet permet à des infirmières de transmettre via SMS des bilans de santé, alors que les moyens de communications sont très mauvais, et que la vie est très dure. Ce projet RapidSMS, est un projet open-source réalisé pour l’UNICEF en Python.

La communication dans ce projet est vitale, et elle permet de sauver des vies.

Le Feedback
Martin Fowler attaque maintenant la deuxième partie de sa présentation. Pourquoi certains projets réussissent bien ? Il souhaite nous parler de l’importance du retour d’information, le feedback en Anglais.

Martin nous montre une photo d’un gâteau. Réalisé avec une approche prédictive, tout le monde sait qu’il faut respecter la recette en cuisine pour réussir. Ma grand-mère me disait de mettre 75g de farine, et de ne pas poser de questions. La cuisine est une alchimie intéressante. Si vous avez une recette pour 4 et que vous voulez faire un gâteau pour 8, il ne faut pas doubler les quantités. En effet, lorsque vous doublez les quantités, vous avez toutes les chances de planter votre gâteau. Curieusement, la cuisine est bien plus compliquée que ce que nous pensons. Et bien le développement logiciel, c’est pareil. Il ne sert à rien d’ajouter 2 développeurs en pensant que vous irez 2 fois plus vite. Parfois même, vous irez 2 fois moins vite, car il faudra former ces nouveaux arrivants…

Martin nous montre une photo de gâteau donc, et une photo de pomme de douche. Quelles différences y-a-t-il entre une pomme de douche « chaud-froid » et un gâteau ? Et bien une histoire de retour, de feedback.

La cuisine est un processus défini alors que régler une douche est un processus adaptatif/empirique.

La cuisine suit un plan précis, une recette. Et le feedback ne sera fait qu’à la fin. Peut-être que votre gâteau sera raté, peut-être qu’il sera excellent, vous ne le saurez qu’à la fin. Au contraire, si vous prenez une douche dans un Hôtel, et que vous devez régler la température, vous allez utiliser un feedback permanent pour adapter la température. C’est l’approche Agile.

Cette illustration nous permet de comprendre qu’il existe 2 types de processus, et que cela fait partie de notre vie quotidienne. Dans le cas d’un processus empirique (la douche) nous examinons le résultat final pour adapter le signal d’entrée. Dans le cas d’un processus défini, si je suis la recette à la lettre j’aurai toujours le même gâteau, je serai capable de reproduire à l’identique la même chose.

Or chaque développement de chaque projet est différent et donc l’approche prédictive ne semble pas une bonne chose. Par contre pour mélanger des ingrédients chimiques dans une usine, vous serez d’accord qu’un processus défini est primordial, pour des raisons de sécurité. Pour le développement d’un logiciel, Martin Fowler nous demande de bien réfléchir avant de choisir une méthode de développement.

Si vous prenez l’approche empirique (la douche) pour construire votre logiciel, il est donc très important de mettre en place un système de feedback. C’est pour cette raison que les équipes Agiles s’installent des murs de post-it, des Kanban, des indicateurs visuels et toutes sortes de trucs sympas : pour avoir du feedback disponible à tout moment.

Martin Fowler montre la photo d’un immeuble de 20 étages en Chine. On voit qu’au 15ème, les fenêtres sont couvertes de post-it. C’est l’étage de ThoughWorks, facilement identifiable de la rue… Rires dans la salle.

L’intérêt d’un Kanban est que ce tableau est lisible par tout le monde. Ecrit clairement, il donne une vision de l’avancement du projet. Tout le monde peut y participer, et donc doit pouvoir y accéder facilement.

Feedback sur la construction du logiciel
Martin Fowler insiste ensuite sur l’importance de donner un indicateur sur l’avancement de la construction du logiciel. Nous devons savoir où nous en sommes en terme de développement du logiciel.

L’intérêt d’afficher sur le mur le planning de son projet est primordial. Martin Fowler explique qu’il lui arrivait auparavant d’aller dans des équipes de développement, et de constater que les développeurs n’avaient pas accès au planning global du projet. Mettez en place un tableau avec les prochaines semaines de développement, cela permettra de donner plus de visibilité et donc de sens, au travail de chacun.

A propos des outils électroniques, les équipes de développement préfèrent utiliser un vrai tableau plutôt qu’un logiciel. Je confirme : ne vous jetez pas sur un outil, privilégiez une solution simple à base de post-it et de fiches bristols. Cela fonctionne très bien.

Dans ce qui est de donner du feedback, Martin rappelle que le seul moyen de voir un progrès dans le développement d’un logiciel, c’est d’avoir un logiciel qui marche. Cela veut aussi dire, un logiciel déployé et testé.

Le processus de construction de votre logiciel est très important. Certains projets aiment bien utiliser des Lava Lampes rouges ou vertes pour signaler que la construction du logiciel fonctionne, ou non. A titre personnel, j’ai mis en place cette pratique à la BNP il y a un an et nous avions une Lava Lampe rouge que nous allumions pour signaler un « Build failed ». C’était sympa.

Neal Ford parle ensuite de CCBoard, un tableau de bord de construction de projets. Ce logiciel open-source permet d’afficher le status de toutes vos builds.

Faire de l’intégration continue c’est compiler, tester, packager, déployer, retester et valider un logiciel. Cela demande un effort, qui permet cependant de réduire à zéro l’effort de « release » d’un logiciel. Si vous êtes capable de construire à tout moment votre logiciel, et de le packager, vous comprendrez que faire « une release » devient facile.

A propos des pratiques de développement logiciel, Martin Fowler parle du Pair Programming. Il a été observé que lorsque 2 développeurs travaillent en même sur un écran, les deux n’utilisent pas la même partie de leur cerveau. Celui qui tape le code sur le clavier est dans la réalisation, alors que celui qui est assis à côté est dans la réflexion, la beauté du code et la vision globale. Celui qui code est le pilote, et celui qui est à côté est le navigateur. Cela permet de réaliser du code de meilleur qualité.

Martin utilise l’image d’un jardin de la Renaissance, tiré d’un château de la Loire. Puis ensuite l’image d’un jardin tropical, tiré d’un parc en Angleterre. D’un côté l’ordre, la clarté. De l’autre le chaos, le foutoir apparent. Et pourtant ces 2 jardins sont beaux. Ils correspondent à deux approches : l’une procédurale, l’autre artistique. Tout ceci pour illustrer qu’il faut des deux pour faire un monde. Et il nous encourage à mélanger ces 2 approches lorsque nous codons, en faisant du Pair Programming par exemple.

Dernière partie
« La perfection n’est pas ce que nous visons, mais ce que nous faisons à tout moment ». Cette phrase de Kent Beck résume l’approche eXtrem-Programming, où l’on fait de tout, mais très bien et en permanence.

L’introspection est alors important. Chaque semaine, l’équipe doit réfléchir et s’assurer de s’améliorer en permanence. Si une équipe ne change pas ses pratiques régulièrement, et qu’au bout de 12 mois vous la retrouvez dans le même état, c’est qu’elle a cessé de progresser. Et c’est un indicateur qu’il manque peut-être des pratiques de rétrospectives.

Neal Ford ensuite à propos de la communication et du retour, nous raconte un peu ses expériences passées. Dans les équipes de développement qu’il a croisé, il a remarqué que les équipes aiment bien laisser trainer des petits jeux, des casse-têtes ou des Rubbik’s Cub. Cela permet en fait de décompresser et de mobiliser d’autres parties du cerveau. Il y a 5 ans, je me souviens que nous avions un petit panier de basket, et que nous faisions des tournois, histoire de lever le nez du code de temps en temps…

Neal Ford dit clairement que mettre des développeurs face à un mur pour coder, n’est pas une bonne idée. Il faut stimuler leur créativité. Il y a des entreprises qui mettent en place des règles et qui vous interdisent d’afficher des photos personnelles, des posters de cinéma, ou de vous balader en tee-shirt « My bozz rebooted » dans les couloirs… Pensez à ces photos des locaux de Google, où à l’excès inverse, les gens peuvent avoir un peu tout et n’importe quoi dans leur espace de travail… La notion de « Cubicle » est cependant très américaine, et c’est un aménagement de bureaux peu utilisé en France.

Ce qu’il faut retenir, c’est qu’il important de traiter les développeurs comme des créatifs. Ils doivent pouvoir aménager leur espace de travail librement. Mettez des tableaux blancs, laissez-les s’installer et s’approprier leur bureau. Si vous n’avez que des prestataires qui viennent de SSII, croyez-moi c’est possible. Nous avions une lava-lampe, j’avais acheté une petite plante verte, nous avions nos posters Scrum, le tout en évidence à côté de la cafétéria, et personne ne nous a jamais dit d’arrêter.

A propos de la construction des logiciels, Neal Ford raconte une histoire sympa. Dans une des équipes où il a travaillé, le logiciel d’intégration continue joue une petite musique de 3 secondes lorsque la compilation fonctionne. C’est très pratique, car cela permet de vous signaler que vos derniers commits fonctionnent, sans vous déranger. Vous entendez vos 3 secondes de musique, et vous pouvez continuer. Chaque développeur avait sélectionné une chanson ou un bruit, et donc pouvait savoir que son commit était passé. Sympa non ?

Ensuite, lorsque le build cassait, une autre chanson se mettait en marche. Dans son équipe c’était « Oups I did it again ! » de Brittney Spears. Et d’entendre cette chanson mettait une bonne ambiance. Toute l’équipe se mobilisait pour aller réparer le logiciel immédiatement.

Neal Ford montre ensuite une photo d’une équipe de développement. On voit une énorme peluche de Kangourou assise sur le fauteuil à côté du développeur. Celui qui a le « Stuff Kangoroo » est responsable du build pour la journée. Lorsque la chanson de Brittney se met en marche, son travail est alors de chercher le développeur et de s’assurer que le logiciel est réparé rapidement. C’est un peu un rôle barbant, donc ce rôle tourne. Et celui qui a cassé le build récupère alors le « Stuff Kangoroo ». Et ainsi de suite…

Notre travail peut être amusant, et sérieux. Derrière cette peluche « pas sérieuse » il y a une pratique très précise de génie logicielle, celle de fixer tout de suite la construction du logiciel. Et ça marche ! Alors n’hésitez pas à aller chez Toyr’us et d’acheter un énorme Ours en peluche, et de le donner à l’équipe de développement. J’ai repéré une peluche de « Sully » du dessin animé « Monstres et compagnie » et je compte bien l’embarquer pour notre projet actuel.

Neal Ford montre enfin une page de Wiki généré automatiquement par l’outil de construction, sur laquelle les développeurs peuvent aussi écrire. Ce carnet de bord quotidien raconte la journée passée. A quelle heure Nicolas a commité son code… a quelle heure la compilation s’est terminée, puis les tests. Ensuite on voit que Pierre a annoté la page et qu’il a marqué un détail sur l’installation… Bref un carnet de bord, comme en marine, mais généré en partie automatiquement.

Conclusion
En conclusion, Neal Ford reprend la question du départ : « Pourquoi le développement Agile fonctionne-t-il si bien ?« . Et bien grâce au Feedback, grâce à la communication, et aussi parce que nous percevons le métier de développeur différemment. Nous pensons que la réflexion est aussi importante que la réalisation. Et nous pensons aussi que le développement est fun !

Avant tout, je présente rapidement les deux speakers. Martin Fowler est d’origine anglaise, c’est un geek de 47 ans qui a participé au Manifeste Agile, a co-écrit des livres d’excellentes qualités sur le refactoring avec Kent Beck, et c’est surtout un conférencier de renom. Neal Ford est américain, Geek de 48 ans, passionné par la technologie, auteur de plusieurs livres comme l’excellent « The Productive Programmer« , il travaille aussi chez ThoughtWorks avec Martin Fowler.

Neal Ford débute la présentation en nous apostrophant, afin de nous demander si nous savons pourquoi certains logiciels marchent, pas comment ils marchent. Martin Fowler explique qu’une phrase anglaise célèbre dit : « Plan your work, work your plan« . Cette approche prédictive est intéressante. Un plan est une prédiction de ce que l’on souhaite, plutôt une prévision. Et pour aller plus loin, le succès d’un projet dans ce cas, serait de dire que vous avez respecté votre plan à la lettre. Le succès des projets est défini sur la base d’une prévision. Cette approche prédictive est intéressante dans certains domaines, mais elle doit être discutée lorsque l’on parle de développement logiciel. Elle ne fonctionne que si vous êtes en mesure de préparer un ensemble clair et indiscutable de demandes, et que cet ensemble n’évolue pas dans le temps.
Reconnaissez tout d’abord que c’est difficile. Il est assez difficile de tout prévoir, et de tout planifier. Et ce, d’autant plus que le projet est long.

Martin demande aux chefs de projets qu’il rencontre, si les exigences sont stables. Et c’est plutôt rare. Un sondage dans la salle remplie de près de 500 personnes montre aussi qu’en général, les demandes évoluent ou sont précisées alors que le développement a débuté. Presque personne n’a de demande stables. La communauté de l’approche traditionnelle le sait très bien. Alors ils cherchent à stabiliser et à figer les requierements. Ils mettent un point d’honneur à vous rendre la vie difficile si vous souhaitez changer quelque chose.

Dans le monde Agile, nous savons que le changement est une composante du développement logiciel. Cela nous permet de nous en servir comme d’un avantage, plutôt que de le subir. Nous avons développé des techniques pour absorber le changement, tout en délivrant le logiciel. La première de ces techniques, est de séparer la phase de recueil des exigences, de la phase d’implémentation. Pour parler de Scrum, nous avons une étape de capture des requierements, c’est l’alimentation du Product Backlog. Et nous avons par ailleurs un cycle de développement, qui travaille sur un périmètre stable. Vous voyez que nous avons bien besoin de figer à un moment donné les demandes, mais nous le faisons sur une petite période de 2 à 3 semaines.

How do we do this ?
Nous passons d’une approche prédictive à une approche adaptative. Le secret de l’Agilité c’est que l’on ne peut prévoir tout, mais que par contre on sait s’adapter. D’où ce mot « Agile » finalement. Faire de l’Agile ce n’est pas jeter des plannings. Au contraire, nous serons en mesure de donner un planning chaque semaine. Nous serons en mesure de prédire avec précision les 2 semaines qui arrivent.

Ensuite, pour réussir il ne faut pas uniquement appliquer des méthodes Agiles et penser que cela va réussir. Il faut absolument prendre de bonnes pratiques de programmation. Tests unitaires, intégration continue, refactoring, vous les connaissez tous je pense. Martin propose de relire un papier publié il y a 10 ans, remis au goût du jour en 2004, que chaque Architecte Agile devrait connaître : « Is Design Dead ?« . Faire de l’Agilité ce n’est pas jeter le Design à la poubelle. Au contraire.

Martin Fowler raconte qu’il va parfois dans certaines entreprises qui sont passées d’une approche classique à une approche Agile. Et les projets ne réussissent pas mieux. L’Agilité permet même de se planter plus vite en fait. Il rappelle l’importance des techniques de programmation et de développement telles que celles de l’eXtreme Programming. Faire de l’Agile sans changer sa méthode de travail ne permet pas de réussir mieux. A méditer lorsqu’un consultant de 19 ans de McKissé vous vend de l’Agilité… alors qu’il n’a jamais programmé.

Donc pour résumer cette première partie : passez de l’approche prédictive à l’approche adaptative.

La seconde distinction
Une photo de Taylor nous rappelle qu’au XXe siècle la vision du Taylorisme visait à séparer l’exécution d’une tâche de sa définition. Ecoutez bien ce qui va suivre, moi j’ai adoré. Il y a 100 ans, nous pensions que pour être plus effectif, il fallait que des gens pensent à ce qu’il faut faire, et que d’autres réalisent cette tâche. C’est le métier d’Ingénieur ou d’Architecte, ce métier où tu penses à ce qu’il faut faire. Mais dans le développement informatique, nous avons juste oublié la partie « réalisation », la partie « artisanale ». Et c’est pour cette raison que de très bons scientifiques, en mesure de penser, sont de très mauvais exécutants. Personne ne leur a appris à programmer.

Vous savez pourquoi il faut le faire, mais vous ne savez pas comment faire…
N.Martignole

L’approche traditionnelle du développement logicielle essaye de séparer ceux qui conçoivent de ceux qui réalisent. Cette vision fonctionne si les gens qui réalisent sont prévisibles. S’ils suivent à la lettre le processus standardisé, comme un ouvrier finalement, oui cette approche devrait marcher. Alistair Cockburne explique que les gens ne sont pas prédictibles :

In the title, [of his article] I refer to people as « components ». That is how people are treated in the process / methodology design literature. The mistake in this approach is that « people » are highly variable and non-linear, with unique success and failure modes. Those factors are first-order, not negligible factors. Failure of process and methodology designers to account for them contributes to the sorts of unplanned project trajectories we so often see.
[Alistair Cockburn non-linear]

Dans l’approche traditionnelle, nous pensons que les processus vont nous aider. Cela va plus loin, car certaines approches (Model Driven Architecture) proposent de retirer la possibilité de développer, pour plutôt générer du code. La génération automatique de code permettrait d’économiser du temps. Cette approche essaye de combattre le caractère imprévisible de l’être humain. Générer un logiciel par modélisation c’est mettre un terme au chaos de la programmation classique.

Je pense à titre personnel que l’approche MDA permet de déplacer la complexité, mais qu’elle ne peut pas être une solution pérenne pour développer des projets de bout en bout. Lorsque nous aurons compris que la programmation d’un logiciel complet ne peut pas être automatique, nous aurons fait un grand pas.

Les développeurs sont donc les personnages les plus importants dans le développement logiciel. Or ils ne sont pas prévisibles, il est donc stupide de voir les gens comme des ressources. L’utilisation du jour/homme fait beaucoup de tord à notre industrie. Je connais personnellement des personnes qui font en 1 journée ce que d’autres font en 20 jours. Et je me mets dans les 20 jours. Et inversement, je peux faire des choses en 1 journée qui demanderaient 20 jours à un autre développeur. Nous ne sommes pas égaux devant les problèmes de programmation. Nous ne pouvons donc pas prévoir la fin d’un projet en divisant le nombre de jours par la « quantité de ressources disponibles« . Mettez-vous cela dans le crâne une fois pour toute.

Alors comment cela fonctionne-t-il ? Martin Fowler explique que nous devons prendre un groupe de développeurs, mettre en place quelques règles, puis ensuite s’adapter et faire des rétrospectives afin de progresser. Il est contre-productif d’utiliser des processus et de la standardisation, cela tend à niveler par le bas les niveaux des équipes.

People comes first, and they chosse their own process they follow, not the opposite.

En résumé, Martin Fowler a parlé de l’attitude par rapport au planning, et de l’attitude par rapport aux gens.

Fin de la première partie
Retrouvez la suite de cette KeyNote dans un deuxième article demain