Je suis devenu un adepte du framework Play!. Je ne le pratique pas depuis longtemps, seulement depuis 10 mois environ. Mais la courbe d’apprentissage est vraiment rapide. Une semaine est suffisante pour être à l’aise et être autonome. J’ai la modeste prétention, dans cet article, de montrer 2 ou 3 trucs qui font de ce framework une nouvelle manière de voir le web en Java.

Pour commencer, Play! est très simple à installer. Il suffit de décompresser le zip dans un répertoire, et de créer une variable PLAY_HOME qui pointe sur ce répertoire. Play! a uniquement besoin de Java comme pré-requis pour fonctionner. Et c’est tout ! Pour rappel, la plupart des autres frameworks web Java ont au moins besoin d’un serveur d’application…

Comme Play! embarque un serveur web, il se suffit à lui-même. Cette notion est appelée “full-stack”. Elle signifie que Play! est autonome à la fois dans son mode de développement en proposant tout ce qu’il faut pour faire une application web, de la couche présentation à l’accès aux données, et également lors de l’exécution des applications Play! qui tournent grâce au serveur web intégré.

Play! propose de nombreuses fonctionnalités peu répandues dans le monde du web en java. Par exemple, le code modifié est pris à chaud par le serveur web, il suffit de rafraîchir le navigateur pour voir sa modification ! La gestion d’erreur est également poussée. Lorsqu’une exception se produit, l’erreur s’affiche très clairement dans le navigateur. Comme le montre l’image suivante :

Le développement rapide est une des caractéristiques de Play! On passe beaucoup plus de temps à coder qu’à faire de la configuration ou de l’installation. Et ce n’est pas tout, Play! propose beaucoup de moyens d’accélérer le développement. Je vais donc vous en montrer quelques uns. Je ne compte pas énumérer tout ce qui fait que Play! permet de développer rapidement, mais seulement donner un aperçu.
Play! propose sur son site, une documentation très complète, ainsi qu’un tutoriel bien fait qui permet de se familiariser avec les notions principales du framework. Si on peut paraître sceptique devant tant de d’enthousiasme, faire le tutoriel permettra à quiconque de se rendre compte de la rapidité avec laquelle le développement se fait avec Play!.

Arborescence

Ceux qui connaissent Ruby on Rails et Grails ont déjà les bases pour Play!. Par exemple, l’arborescence des répertoires est très similaire :

Les répertoires ont des noms explicites, par exemple le répertoire public permet au serveur web de renvoyer des ressources directement, telles que des images ou des scripts.
Le répertoire conf contient les fichiers de configuration comme son nom l’indique. Par défaut, Play! en crée trois :

• Un pour l’application de l’application et du serveur web
• Un pour définir les URL de l’application
• Un dernier contenant les messages de l’application

D’autres fichiers de configuration peuvent être créer dans ce répertoire, notamment pour chaque langue gérée par votre application.

La puissance dans le fichier de configuration

Application.conf est un fichier similaire à un fichier properties. Il est créé par Play! lors de la création d’une application. Il contient plein de valeurs essentielles pour configurer le serveur web, telles que le port à utiliser, le nom du cookie. Il contient également des propriétés permettant de configurer l’application comme la base de données, la configuration JPA, du cache…

Le gros avantage de ce fichier, est qu’il peut être l’unique fichier de configuration de l’application, et ce quel que soit l’environnement sur lequel est déployé la web app ! En effet Play! intègre un système qui permet de surcharger des valeurs dans le fichier de configuration. Lors du lancement de l’application, il suffit de préciser un paramètre supplémentaire sur la ligne de commande pour choisir les propriétés à appliquer. Comme ce n’est sûrement pas clair, voici un exemple :

%integration.application.mode=dev
%production.application.mode=prod
application.mode=dev

Le fichier ci-dessus est un extrait d’un fichier de configuration application.conf. Il contient 3 fois la même propriété nommée application.mode. Certaines sont suffixées ce qui permet de donner une valeur précise selon si l’application est lancée en intégration ou en production. Par défaut, la valeur sera celle de ligne 3 si le paramètre n’est pas indiqué. C’est super pratique et très bien pensé !

Le rechargement à chaud du code et de la conf

La propriété que j’ai montré dans l’extrait du fichier application.conf dans le paragraphe précédent, est une clé très spéciale, qui permet encore à Play! de se distinguer. Elle permet d’indiquer au framework que l’application est en mode développement ou production. La distinction est très importante pour le développeur, et pour la sécurité de l’application.

Le mode dev permet au développeur un gain de temps maximum. Lors du développement, un changement sur un fichier de code ou de configuration sera pris à chaud par le framework. Un rafraîchissement de la page du navigateur, et c’est pris en compte ! C’est tout simplement du bonheur de développer dans ces conditions.
Le mode production interdit, bien entendu, le rechargement du code à chaud, mais il permet également de précompiler les fichiers java et les fichiers de templates (qui sont les fichiers permettant l’affichage des pages web). Les performances sont donc meilleures en mode production qu’en mode développement.

Sans état !

Play! est un framework sans état. Cela signifie qu’aucune session n’est conservée du côté du serveur. Cette philosophie est à l’opposée de la plupart des frameworks java bâtis sur la norme servlet. Cela permet à Play! de se rapprocher de la philosophie initiale du protocole HTTP où chaque requête est indépendante de la précédente, donc sans état. Le framework sait qui effectue la requête grâce au cookie.
Du côté serveur, il faut donc repenser sa manière de gérer les requêtes sans état. Par exemple, si des objets doivent être stockés pour être utilisés lors des requêtes suivantes, il faudra utiliser un cache ou la base de donnée directement. D’ailleurs à propos du cache, Play! intègre un cache directement basé sur EhCache.
Le fait que Play! soit sans état permet d’avoir une architecture scalable. Cela permet aussi au framework de gérer très facilement les requêtes de type REST qui sont également des requêtes sans état.
Encore une bonne raison d’essayer Play!.

Exemple d’URL de type REST

Allez, je vous donne un exemple de REST implémenté dans Play!. L’exemple suivant permet d’effacer une personne de l’application.
L’unique page de l’application affiche une liste de personnes. La seule action possible est d’en effacer une :

Le fait de cliquer sur le lien delete appelera une URL définie dans le fichier de configuration routes dont voici l’extrait concerné :

DELETE        /person/{id}         Application.deletePerson

Ce fichier définie une URL de type REST. Elle signifie qu’une URL de type /person/348 avec la méthode HTTP DELETE appelera la méthode Application.deletePerson avec le paramètre 348.
Lorsqu’on affiche la page d’accueil, la log indique :

21:00:57,315 INFO  ~ URL called : GET localhost/

Ensuite, une fois que nous cliquons sur le lien delete :

21:06:24,937 INFO  ~ URL called : DELETE localhost/person/2

Evidemment, l’affichage des personnes fonctionne tel qu’attendu :

Le code java est extrêmement simple. Voici la méthode affichant l’URL et la méthode HTTP pour chaque requête HTTP :

@Before
static void printHttpInfos() {
	Logger.info("URL called : %s %s", request.method, request.domain + request.path);
}

Et voici le code java permettant la suppression d’une personne :

public static void deletePerson(long id) {
	Person.<Person> findById(id).delete();
	index();
}

Je ne vais pas vous décrire ce que fait chaque ligne de code. Je voulais simplement montrer à quel point il est facile de faire des choses qui sont plus compliquées sans Play!. Encore une fois, n’hésitez pas à aller faire le tutoriel sur le site de Play!, on y apprend toutes les bases et notamment ce que je viens de vous montrer.

Les tests

Dans un framework moderne, la prise en charge des tests est indispensable, et Play! n’y échappe pas. Les tests Play! sont basés sur deux librairies très connues : JUnit et Selenium.
En lançant le serveur en mode test, les tests peuvent être lancés via une page dédiée sur l’application web. C’est très pratique pour lancer manuellement des tests via le browser.
D’autre part les données de tests peuvent être initialisées grâce à un fichier YAML. Voici le fichier utilisé pour initialiser les données du paragraphe précédent (dans mon cas je l’ai utilisé pour initialiser la base de données de mon application) :

Person(test1):
    firstName: Florian
    lastName: Boulay

Person(test2):
    firstName: Antonio
    lastName: Goncalves

Person(test3):
    firstName: Antoine
    lastName: Ramponi

Play! permet de créer 3 types de tests :

• Les tests unitaires : les classes doivent hériter de la classe UnitTest. C’est l’équivalent d’un test JUnit classique.
• Les tests fonctionnels : les classes doivent hériter de la classe FunctionnalTest. Ce sont des tests d’intégration avec l’application web.
• Les tests de validation : ce sont des tests Selenium.

Les tests fonctionnels

Je vais faire un petit zoom sur les tests dits fonctionnels.

Pour cela j’ai un peu modifié l’exemple utilisé précédemment afin d’avoir plus de cas de tests possibles. La mini application web ne comporte toujours qu’une seule page, mais elle est désormais composée de 2 listes : une liste d’employés disponibles, et une des employés d’astreinte. L’interface ressemble à ceci :

Le fait de cliquer sur on call permet de faire passer la personne d’astreinte en la mettant dans la seconde liste. Le fait de cliquer sur free permet de faire l’inverse.

Comme dit précédemment les classes de test doivent hériter de la classe FunctionnalTest. De plus, le serveur doit être lancé en mode test. Voici un exemple de test fonctionnel permettant de tester l’unique page de cette application. La première méthode teste l’état initial, c’est-à-dire les 3 personnes qui sont présentes dans la liste des employés disponibles. La seconde méthode teste le passage d’une personne de la première liste à la seconde en cliquant sur le lien on call :

public class EmployeesTest extends FunctionalTest {

	@Before
	public void setUp() {
		Logger.debug("Reloading all data");
		Fixtures.deleteAll();
		Fixtures.load("data.yml");
	}

	@Test
	public void testStartState() throws Exception {
		Response response = GET("/");
		// test the 200 status
		assertIsOk(response);
		String httpBody = getContent(response);
		assertTrue(httpBody.length() > 0);
		// test that 3 <li> are returned
		assertContentMatch("(?s)<ul>\\s*" +
							"<li>Florian Boulay.*" +
							"<li>Antonio Goncalves.*" +
							"<li>Antoine Ramponi.*" +
							"</ul>", response);
	}

	@Test
	public void testOnCallPeople() throws Exception {
		// make Antonio Goncalves on call
		Person antonio = Person.find("byFirstName", "Antonio").<Person> first();
		Response response = PUT("/person/onCall/" + antonio.id, "text/html", "");
		// test the 302 response
		assertStatus(302, response);
		String httpBody = getContent(response);
		assertTrue(httpBody.length() == 0);
		java.net.URL locationHeader = new java.net.URL(response.getHeader("location"));
		response = GET(locationHeader.getPath());
		// test the 200 response
		httpBody = getContent(response);
		assertTrue(httpBody.length() > 0);
		assertContentMatch("(?s)<ul>\\s*" +
							"<li>Florian Boulay.*" +
							"<li>Antoine Ramponi.*" +
							"</ul>", response);
		assertContentMatch("(?s)<ul>\\s*" +
							"<li>Antonio Goncalves.*" +
							"</ul>", response);
	}

}

Voici les quelques logs générées :

00:39:21,725 DEBUG ~ Reloading all data
00:39:21,777 INFO  ~ URL called : GET localhost/
00:39:22,469 DEBUG ~ Reloading all data
00:39:22,505 INFO  ~ URL called : PUT localhost/person/onCall/8
00:39:22,525 INFO  ~ URL called : GET localhost/

L’API simple

Ce qui est très agréable au quotidien avec Play! est la facilité d’utilisation des API disponibles. Je n’ai pas montré beaucoup de code dans cet article, mais vous pouvez constater la simplicité de lecture du code fait avec Play!. Cela permet comme presque tout le reste, d’avoir une marge de progression rapide, d’être opérationnel bien plus vite qu’avec d’autres framework web… Mais tout ça, je l’ai déjà dit. Je vais plutôt vous montrer quelques lignes utilisant l’API de Play!, vous pourrez vous faire une idée bien plus facilement qu’avec un long discours.

// récupérer la requête HTTP courante
Request request = Http.Request.current();

// récupérer l'EntityManager 
EntityManager em = JPA.em();

// faire un appel rapide à un web service
HttpResponse response = WS.url("http://www.w3schools.com/webservices/tempconvert.asmx?op=FahrenheitToCelsius").get();

// récupérer toutes les entités Person (entité au sens objet du modèle de donnée)
List<Person> findAll = Person.findAll()
// compter le nombre d'entités Person
long count = Person.count();
// faire des requêtes simple sur l'entité Person
List<Person> allAntos = Person.find("byFirstNameLike", "anto%").fetch();
// etc......

Petit mot de la fin

Cet article touche à sa fin. J’aurais tellement voulu vous en montrer plus comme la validation super simple, les templates HTML, comment répondre au client en fonction du format qu’il demande (XML, JSON….), mais c’est déjà assez long. Je profiterai d’un prochain article pour me concentrer sur un aspect plus précis du framework.
J’espère avoir convaincu les quelques sceptiques à propos du framework Play!

Ressources

Site officiel du framework Play! : http://www.playframework.org/
Le google group très actif : http://groups.google.com/group/play-framework
Le repository git du code source de Play! : https://github.com/playframework/play
Le premier livre sur Play! : http://www.the-play-book.co.uk/

The post Ce que j’aime dans Play! first appeared on In Fine - Le Blog.

Les fondamentaux

En java, la comparaison s’effectue principalement en utilisant 3 méthodes qui n’ont pas les mêmes buts :

1. L’opérateur == est utilisé pour comparer les types primitifs et les objets. Il compare uniquement les références. Cela signifie que l’opérateur retournera “true” uniquement si les 2 objets comparés sont les mêmes en mémoire.
2. La méthode ‘equals()’ permet de comparer 2 objets. Toutes les classes ont une méthode ‘equals()’ héritée de la classe Object. Cette méthode compare la valeur de 2 objets. S’ils représentent la même chose, alors la méthode doit renvoyer “true”. Cette méthode est plus difficile qu’il n’y paraît à implémenter. Je pourrais revenir dessus ultérieurement dans un prochain article.
3. La méthode ‘compareTo()’ permet de comparer 2 objets comme la méthode ‘equals()’. Contrairement à ‘equals()’, les classes ne définissent pas toutes cette méthode. Pour cela il faut hériter de l’interface Comparable. Cette méthode est utilisée pour pouvoir trier les objets l’implémentant. Si les 2 objets sont égaux, alors la méthode doit renvoyer 0 ; si un object O1 est considéré précédent un autre object O2 alors il faut renvoyer -1, si O2 précède O1 alors il faut renvoyer 1.

int i = 5, j = 5, k=8;
Integer int1 = new Integer(42) ;
Integer int2 = new Integer(42) ;
String str1 = "Blog";

java.util.Date t1 = new java.util.Date();
Thread.sleep(1000l);
java.util.Date t2 = new java.util.Date();

System.out.println (i == j); // print true
System.out.println (int1 == int2); // print false
System.out.println ("Blog".equals(str1)); // print true
System.out.println (str1 == "Blog"); // déconseillé mais écrit true
System.out.println (t1.compareTo(t2)); // print -1

Les comparaisons faites avec ‘equals()’ ou ‘compareTo()’ entre une variable et une constante doivent être réalisées comme à la ligne 13 de l’exemple précédent, c’est-à-dire qu’il faut comparer la constante avec la variable à tester. Ceci permet d’éviter une potentielle NullPointerException si l’on faisait ‘str1.equals(“Blog”)’.

Le cas particuliers des enum

Depuis java 5, les enum ont été introduits dans java. Les enum pourraient faire l’objet d’un article complet, mais il est bon de savoir que les enum ont été créés pour être comparés avec l’opérateur ‘==’. N’hésitez donc pas à les utiliser ! En plus d’être très lisibles, ils sont performants à l’usage.

Les performances unitaires

Si on a le choix, quel opérateur/méthode utiliser pour faire la comparaison ? Un des critères de choix peut être la performance. Sur une application où les comparaisons sont très nombreuses, il peut être judicieux d’optimiser les comparaisons et donc de choisir en connaissance de cause.

Voici le petit programme qui m’a permis de tester les performances de chacun. Dans la boucle j’ai utilisé une des instructions en commentaire à chaque test :

long start = System.currentTimeMillis();
for (long l = 0; l < 2 << 60; l++) {
    // "1".equals("1");
    // if ("1" == "1") ;
    // "1".compareTo("1");
}
long end = System.currentTimeMillis();
long timePassedInMs = end - start;
&#91;/sourcecode&#93;

Sans surprise les résultats sont les suivants :
<ul>
	<li><strong>==</strong> : 978 ms de moyenne</li>
	<li><strong>equals()</strong> : 991 ms de moyenne, soit 1.35 % que ==</li>
	<li><strong>compareTo()</strong> : 1004 ms de moyenne, soit 2.62% de plus que ==</li>
</ul>
Quelques remarques sur ces résultats :
<ol>
	<li>La première instruction de la méthode 'equals()' de la classe String est de tester que les 2 objets comparés ont la même référence grâce à l'opérateur ==. La différence de temps entre == et 'equals()' s'explique donc uniquement par l'appel de la méthode et le retour de cette méthode. La différence vient aussi en partie du fait que la JVM va inliner la méthode 'equals()' et que ceci prend un certain temps.</li>
	<li>'compareTo()' de la classe String effectue plusieurs boucles et de nombreux tests. Il est tout à fait logique qu'elle soit plus lente que les 2 autres comparateurs. Elle n'est pas optimisée pour gagner du temps comme l'est 'equals()'.</li>
</ol>
Ces quelques tests montrent bien que faire un == est plus rapide que l'appel d'un 'equals()', même si dans le cas de la classe String la différence est faible. Si vous avez le choix, privilégiez donc le == à 'equals()', même si les performances ont l'air très proches. Il peut arriver que vous utilisiez du code que vous ne pouvez pas modifier (API, framework, librairie partagée...) et dans ce cas la méthode 'equals()' peut être mal écrite et donc bien plus lente qu'elle ne l'est pour la classe String. Mais la question est la suivante : comment faire pour avoir le choix entre == et 'equals()' ? Je vais essayer de vous montrer une manière d'avoir le choix un peu plus loin dans ce post, après vous avoir expliqué un peu plus en détail comment fonctionne la classe String.

Nous laissons de côté 'compareTo()' pour la fin du post, car elle n'a pas la même utilité que les 2 autres méthodes de comparaison.
<h2>Le cas de la classe String</h2>
Comme nous l'avons vu au début du post, les String doivent être comparés à l'aide de la méthode 'equals()'. Cependant il est tentant de vouloir utiliser l'opérateur == plus rapide et renvoyant quasiment tout le temps le même résultat que la méthode 'equals()'.

La classe String a beaucoup de particularités : c'est la seule classe que l'on peut initialiser sans appel explicite à un constructeur ou méthode statique ; elle possède des opérateurs surchargés... et d'autres spécificités encore. Une de ses particularité est que la JVM garde un pool d'instances des objets String. Ainsi, si deux String sont initialisés avec la même valeur, alors la JVM utilisera le même objet. Mais ce n'est pas vrai dans tous les cas. Regardons cet exemple :

[sourcecode language="java"]
final String TEST_VALUE = "infine";

String inPool = "infine";
String inPool2 = "in" + "fine";
String noPool = new String("infine");
String suffix = "fine";
String noPool2 = "in" + suffix;

System.out.println(inPool == TEST_VALUE);  // true
System.out.println(inPool2 == TEST_VALUE);  // true
System.out.println(noPool == TEST_VALUE);  // false
System.out.println(noPool2 == TEST_VALUE);  // false

En voyant les résultats, vous comprenez pourquoi il ne faut pas utiliser l’opérateur == pour la comparaison de String, le résultat est trop incertain. Lorsqu’un objet String est créé en utilisant l’opérateur new (comme pour un objet “normal” en fait), alors la JVM ne renvoie pas un objet String du pool, mais crée un nouvel objet (cas de l’objet “noPool”). De plus, si un objet String est calculé à l’exécution, par une concaténation par exemple, alors il n’est pas créé à partir du pool (cas de l’objet “noPool2”).

Pour se rendre compte de la manière dont le compilateur gère les String, voici un extrait du bytecode généré obtenu avec la commande javap :

0:	ldc	#16; //String infine
2:	astore_1
3:	ldc	#16; //String infine
5:	astore_2
6:	ldc	#16; //String infine
8:	astore_3

Dans cet extrait, nous voyons que 3 variables font référence au même objet String valant “infine” (matérialisé par la référence #16). Ces 3 variables sont dans le code précédent TEST_VALUE, inPool et inPool2. Elles sont déclarées différemment mais le compilateur ne crée qu’une seul référence dans le pool de String de la JVM.

Si on souhaite forcer la récupération d’un objet String à partir du pool, alors il faut utiliser la méthode ‘intern()’. Reprenons l’exemple ci-dessus, mais en utilisant la méthode ‘intern()’ :

final String TEST_VALUE = "infine";

String inPool = "infine";
String inPool2 = "in" + "fine";
String noPool = new String("infine");
String suffix = "fine";
String notPool2 = "in" + suffix;

System.out.println(inPool == TEST_VALUE);  // true
System.out.println(inPool2 == TEST_VALUE);  // true
System.out.println(noPool.intern() == TEST_VALUE);  // true !
System.out.println(notPool2.intern() == TEST_VALUE);  // true !

Pour en savoir plus, n’hésitez pas à chercher String literal pool dans votre moteur de recherche préféré.

Étude de cas : == doit renvoyer la même chose que equals()

La classe String arrive bien à faire que dans certains cas == et ‘equals()’ renvoient le même résultat. Nous allons donc essayer de faire mieux ! Nous allons donc partir d’un exemple simple dans lequel == et ‘equals()’ ne sont pas interchangeables. Enfin, nous allons modifier le code afin d’utiliser == pour chaque comparaison, ceci dans le but d’avoir de bonnes performances, et une meilleure gestion de la mémoire.
Bien entendu, nous pourrions gagner des performances de plein de manières différentes, mais ce n’est pas le but de cet article.

Présentation du code existant

Voici une classe permettant de gérer des couleurs RGB. Elle est donc composée de 3 attributs pouvant avoir une valeur comprise entre 0 et 255 chacun. Voici une partie du code de la classe avec son constructeur :

public class RgbColor {

    private final int green;
    private final int red;
    private final int blue;

    public RgbColor(int green, int red, int blue) {
        super();
        this.green = green;
        this.red = red;
        this.blue = blue;
    }

    // ...other methods, including hashcode() and equals()
}

Comme nous le voyons, cette classe possède un unique constructeur. Il est donc possible de créer autant d’objet de type RgbColor que nous voulons, et s’ils sont identiques nous seront obligés de les comparer avec ‘Equals()’ car chaque objet RgbColor sera différent.
Ce constructeur est l’équivalent du ‘String test = new String(“test”)’ vu précédemment dans ce post. Un appel crée toujours un objet.

Pool de gestion des instances

La version améliorée ajoute une nouvelle méthode statique. Cette méthode permet de créer un objet s’il n’existe pas encore dans le pool, ou alors de renvoyer l’objet existant si il a déjà été créé auparavant. Ce pattern est appelé static factory pattern, et est très bien décrit dans le livre Effective Java de Josh Bloch.

public class RgbColor {

private final int green;
private final int red;
private final int blue;
// pooling
private static Map pool = new ConcurrentHashMap();

/**
* Values must be between 0 and 255.
*
* @param green
* @param red
* @param blue
* @return
*/
public static RgbColor getColor(int green, int red, int blue) {
if (!isAllowedColorValue(green) || !isAllowedColorValue(red) || !isAllowedColorValue(blue)) {
throw new IllegalArgumentException(“Allowed color value is between 0 and 255”);
}
// same key as hashcode
int key = green << 16 | red << 8 | blue; if (pool.containsKey(key)) { return pool.get(key); } RgbColor color = new RgbColor(green, red, blue); pool.put(key, color); return pool.get(key); } private static boolean isAllowedColorValue(int color) { if (color < 0 || color > 255) {
return false;
}
return true;
}

private RgbColor(int green, int red, int blue) {
super();
this.green = green;
this.red = red;
this.blue = blue;
}

@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
RgbColor other = (RgbColor) obj;
if (blue != other.blue)
return false;
if (green != other.green)
return false;
if (red != other.red)
return false;
return true;
}

@Override
public int hashCode() {
return green << 16 | red << 8 | blue; } // ...other methods } [/sourcecode] La méthode statique 'getColor()' permet de gérer un pool de toutes les instances de la classe RgbColor. De plus le constructeur est devenu privé, ce qui oblige l'utilisateur de cette classe à construire un object avec la méthode 'getColor()'. Contrairement à la classe String, tous les objets seront donc comparable avec l'opérateur == car un objet unique est créé par triplet rouge, vert, bleu. Elle est l'équivalent de la construction d'un object String sans constructeur : String test = "test"; Je ne vous joins pas de classe de test, mais les performances sont désormais améliorées car toutes les instances de RgbColor sont comparables avec l'opérateur ==. La mémoire est également mieux gérée car toutes les instances se retrouvent dans le pool. On pourrait encore améliorer cette classe, en remplaçant la 'ConcurrentHashMap' par une SoftHashMap par exemple, avec un peu d’adaptation du code.

Fichiers joints
Code source utilisé pour faire ce post : Archive zip

The post “==”.equals(“equals()”) first appeared on In Fine - Le Blog.

Mise à jour du 6 décembre 2010 :CloudBees a levé 4 millions de dollars. Plus de détails sur le blog de CloudBees.

Devoxx 2010 s’est tenue toute cette semaine à Anvers. Entre 2 présentations de Brian Goetz, Joshua Bloch ou Mark Reinhold, je suis allé voir quelques personnalités du monde java afin d’en savoir plus sur leur actualité et leurs impressions.

Stephan Janssen

Créateur du BeJUG et de Devoxx. Je suis allé le voir pour avoir quelques détails sur l’organisation d’un tel évènement.

Bonjour Stephan, peux-tu présenter Devoxx à ceux qui ne connaissent pas ?
Devoxx est une conférence annuelle qui est organisée par le Java User Group belge. C’est déjà la neuvième édition. Quelques statistiques : 3000 personnes qui viennent de 40 pays, et cela dure 5 jours à Anvers dans le deuxième plus grand complexe de cinéma d’Europe.

Comment expliques-tu le succès de Devoxx ?
D’abord le prix qui est vraiment pas cher, moins de 500€ pour 5 jours. On a aussi des rock stars qui viennent ! On a des personnes comme Joshua Bloch, Romain Guy etc. Le lieu aussi avec des écrans géants est vraiment chouette.

Penses-tu que Devoxx se déroulera ailleurs dans un futur proche ?
L’autre endroit possible est le Heysel à Bruxelles, mais le problème est que nous devons créer des salles nous-mêmes, ce qui aurait pour conséquence que le prix de l’entrée doublerait. Je préfère “less is more”.

As-tu eu le temps d’assister à quelques sessions ?
Oui, j’en ai vu quelques sessions. Ca roule bien, mais heureusement on également parleys où toutes les sessions seront diffusées.

Merci
Merci

Sacha Labourey

Après une carrière chez JBoss, Sacha a créé une société CloudBees.

Bonjour Sacha, quelle est la raison de ta venue à Devoxx cette année ?
Manger des sandwichs, et boire des coca zero principalement ! Mais surtout présenter CloudBees, ma société.

Présente nous CloudBees.
CloudBees est une société qui vit dans les nuages, et qui vise à rendre les développeurs à nouveau en contrôle de l’informatique, qui a été trop longtemps volé par ces messieurs de l’IT.
Le désir est de pouvoir faire totalement faire ses développements dans le cloud, ensuite les tests unitaires et le Q&A de manière générale, et ensuite la mise en production. Donc l’unité sur laquelle on se focalise en tant que développeur sera vraiment l’application, on ne se soucie plus du tout de l’IT, on ne soucie plus du tout de virtual machine, de java virutal machine, d’operation system, de storage, de backup, tout ça doit disparaître. On se focalise sur l’application, et nous on fera le reste.

CloudBees est uniquement destiné aux applications java ?
Aujourd’hui on est orienté sur la machine virtuelle java, ça peut être scala, jRuby ou autre chose. Aujourd’hui la majorité utilise java malgré sa mort annoncé jour après jour, c’est quand même un écosystème extrêmement saint et fort, mais rien dans l’infrastructure qu’on est en train de mettre en place en terme de process, en terme de provisionning et autre ne dépend réellement de java. C’est suffisamment générique, mais il faut choisir ses guerres, la notre c’est celle de java pour l’instant.

Pour terminer, quelles sont tes impressions sur Devoxx 2010 ?
J’ai pas encore eu le temps d’aller voir des sessions, mais je retrouve tout à fait l’esprit JavaPolis de l’époque, donc ça se passe très bien, et on est à peine mieux respecté qu’à JavaOne donc ça fait toujours plaisir.

Merci beaucoup Sacha.
Merci !

Nicolas Leroux

Nicolas est expatrié aux Pays-Bas où il travaille en tant que développeur pour la société Lunatech. Il est également un des contributeurs les plus actifs du framework Play!. C’est à ce titre que je suis allé le voir.

Bonjour Nicolas, quelle est la raison de ta venue à Devoxx cette année ?
Pour voir les conférences, faire du networking et aussi pour promouvoir Play! bien sûr.

Il n’y a pas de session sur Play! cette année, en avez-vous proposé une ?
Nous avions proposé une vraie session Play!, pas dans le BoF. Vue la concurrence acharnée qu’il y a à Devoxx, on a été refusé, c’est pas grave, l’année prochaine on réessaiera.

Play! 1.1 est sorti il y a un peu moins d’un mois, quelles sont les prochaines étapes ?
Il y en a beaucoup ! Il y a plusieurs axes de travail. Guillaume Bort est en train de travailler sur une partie qui s’appelle Evolution, qui permet de migrer ses bases de données très facilement.
Personnellement, quand j’ai cinq minutes, je travaille sur un meilleur binding entre JSON et java. Après il a plein d’autres choses à faire. Ce que j’aimerais faire, c’est un conteneur pour JBoss.
Comme c’est actuellement le cas pour Glassfish.
Erwan Loisant est train d’améliorer les librairies clientes pour faire des requêtes à des web services et Peter Hilton travaille sur la documentation

Y a-t-il une roadmap pour la version 1.2 ?
Elle est pas encore définitive, mais la roadmap peut être consultée sur le site playframework.org qui a un lien sur le bug tracker qui est Lighthouse, et là on peut voir la roadmap.

Merci Nicolas, à l’année prochaine pour une session officielle de Play!
Ou alors si vous avez l’occasion d’aller à Paris pour voir Zenexity, c’est des petits gars sympas et ils vous expliqueront tout !

The post Devoxx 2010, vu de l’intérieur first appeared on In Fine - Le Blog.

Cet article fait suite au précédent article sur la conférence Agile France. Je vais ici vous présenter ma 2eme journée.

C’est par un temps indigne d’un 1er juin que s’est déroulée la dernière journée de la conférence. Les différentes sessions sont toutes plus intéressantes les unes que les autres, et faire un choix s’est avéré difficile. Comme pour le précédent article, je vais détailler une session en particulier.

9h00 : Self-help for Self-organizing Teams

Keynote par Esther Derby

Typologie : modèle

Le propos d’Esther, au cours de cette keynote, était de montrer que les équipes, pour être heureuse, ont besoin d’être autogérées.

Esther commence avec un constat. Quels sont les points communs des membres des équipes heureuses ?

• Ils ont un but commun
• Leur travail est interdépendant et leur compétences sont complémentaires
• L’équipe ne doit pas être trop grande. Cinq membres est la valeur idéale
• Les membres ont une histoire commune

A partir de ce constat, Esther nous a dressé les moyens à mettre en œuvre afin qu’une équipe ait assez d’autonomie pour être heureuse, et donc productive.

10h00 : Comment écrire du code testable

par Florence Chabanois

Typologie : bonnes pratiques

Cette présentation a pour but de nous indiquer les pièges à éviter lors de développements, afin de pouvoir tester unitairement chaque composant développé. Commençons par définir la finalité du test unitaire : il s’agit de tester chaque composant développé tout en simulant au maximum les conditions qui peuvent être rencontrés sur un environnement de production. Pour pouvoir tester les composants, il faut qu’ils soient séparables. L’idée est donc d’avoir le moins de dépendance possible d’un composant vers un autre, ou plus simplement d’une classe vers une autre. Cela s’appelle, plus généralement, un couplage faible ; contrainte qui est censée être adoptée également entre les applications elles-mêmes.

Le TDD est une méthode de développement qui a pris son essor avec la montée en puissance des méthodes agiles. Il s’agit de bâtir l’application à partir des tests, qui seront donc développés avant le code métier. Florence va donc nous énumérer les cas typiques que nous pouvons rencontrer afin de suivre 2 principes fondamentaux pour avoir du code testable :

• Isolation des composants
• Simplicité du code

Constructeur cher

Il faut éviter les constructeurs qui prennent trop de paramètres. C’est difficile à tester car les dépendances sont trop nombreuses, et l’intérieur du constructeur est difficilement testable. Pour y remédier, il faut faire de l’injection de dépendance. Cela permet lors de la construction de l’objet, d’y injecter des mocks par exemple. Il faut respecter le principe de responsabilité unique : un objet doit n’être responsable uniquement que de sa logique métier.

Instanciation directe

La création d’un objet avec un “new” entraîne un couplage fort entre deux composants. Les “new” doivent être utiliser uniquement dans des factory. Encore une fois, l’injection de dépendance remédie au problème, en externalisant les dépendances.

Bloc statique

Encore une fois, le bloc statique entraîne un couplage fort entre deux composants. Il est donc très difficile de tester un bloc statique. Il est donc préférable de supprimer les blocs statiques et de les remplacer par de l’injection de dépendance. Le couplage devient ainsi faible.

Dynastie de classes

Lors d’héritage de nombreuses classes, il peut s’avérer que les classes filles soient difficiles à tester car un couplage fort est fait avec la ou les classes mères. De plus les tests ont tendances à être fait en double. Afin de changer cela, il est préférable d’utiliser la composition de classes et de limiter l’héritage au polymorphisme.

Etats globaux

Maintenir des états partagés entre instances d’une même classe est un comportement très difficile à tester. Les singletons et les méthodes statiques sont à éviter autant que possible, car cela induit des dépendances cachées. Il est préférable de les remplacer par de l’injection de dépendances.

Annuaire de service

Un peu comme à chaque problème énuméré, l’annuaire de service implique des dépendances cachées. Il faut le remplacer par de l’injection de dépendances au maximum.

Interrogation de collaborateurs

Sous ce nom abscons, se cache en fait l’utilisation de méthodes à partir d’objets passés en paramètres de méthodes. Cela implique un couplage fort avec les objets passés en paramètres, et donc le test est plus difficile à initialiser. Cette fois la solution n’est pas l’injection de dépendance ! En fait il faut utiliser le principe de connaissance minimale (dit Loi de Demeter). En clair, cela signifie remplacer les paramètres d’une méthode qui sont des objets complexes, par des types primitifs. La méthode est donc très facilement testable, le couplage devient faible et aucune dépendance n’est à initialiser.

Classe hyperactive

Ces classes sont les classes utilitaires. Ce sont les classes qu’on retrouve dans chaque projet, et qui permettent de gérer les fichiers XML, les logs, la sécurité…. Elles portent souvent un nom qui se termine par “utils” ou “helper”. Ce genre de classe est difficile à maintenir, la lisibilité y est souvent mauvaise. Afin de pourvoir tester facilement ces classes, il faut identifier les responsabilités, créer de nouvelles classes, et déplacer les méthodes de la classe fourre-tout vers ces nouvelles classes.

Méthode trop chargée

Ces méthodes sont celles que l’on voie régulièrement et qui font des longueurs qui donne le vertige. Quelques milliers de lignes est certainement trop pour une méthode. Ce genre de méthode est difficile à maintenir, très difficile à tester, et est trop sensible aux évolutions. Pour dégrossir ce genre de méthode, il faut en créer de nouvelles qui prendront en charge une partie du code de la grosse méthode. Les codes seront donc bien plus faciles à faire et à maintenir. Déléguer une partie du travail à d’autres classes est également faisable.

Mélange des objets valeurs et des objets services

Cette fois c’est clair. Il s’agit de laisser aux objets valeurs le soin d’être instancié et de conserver un état. Les objets service doivent toujours être injectés et jamais instanciés. C’est lui qui crée généralement les objets valeurs.

11h30 : Bâtir une communauté de développeurs par l’agile

par Bénédicte Taillebois, Matthieu Demay, Jean-Sébastien Hedde et Guillaume Persinette-Gautrez

Typologie : retour d’expérience

Une équipe d’Astria est venu nous présenter leur mise en place de process agiles depuis environ 2 ans. Cette présentation est faite par quatre personnes : la directrice des systèmes d’information, et trois informaticiens (je n’ai pas trouvé de meilleur terme).

La présentation a été découpée en quatre grandes phase pour décrire les avancées qui ont été apportées à tout le pôle informatique d’Astria.

Tout a commencé quand deux équipes ont découvertes qu’elles avaient eu chacune une problématique semblable, et qu’elles l’avaient résolu chacune de leur côté. De ce constat, une bibliothèque commune est née. Aujourd’hui elle existe encore, et contient 50000 lignes de codes. Chacun dans le service informatique peut y contribuer car elle est transverse. De cette bibliothèque est né un espace de discussion, où les gens concernés se réunissent une fois par semaine pour parler de besoins commun dans cette bibliothèque. De plus une règle a été acceptée par tout le monde : la règle des 2 pieds. Dans un espace commun mis en place à cette occasion, lorsque des gens se réunissent pour divers sujets, si quelqu’un ne se sent pas concerné, il peut partir à tout moment.

Cette première phase a commencé à bâtir de nouvelles méthodes de travail dans le service, mais tout n’est pas encore parfait notamment au niveau du process de livraison. Dans l’espace commun, un dashboard est créé permettant de lister les tâches communes en cours. Les livraisons pénibles sont améliorées avec la création d’un automate de livraison qui s’impose comme un standard pour toutes les applications. Une classique intégration continue est mise en place.

La troisième phase a été l’occasion de mettre en place un partage de connaissances. Des dojos hebdomadaires de développement sont mis en place. Afin de communiquer plus efficacement, les flux RSS ont remplacés les mailing list trop polluantes. Enfin, une présentation nommée “les cafés du jeudi” est créée ; il s’agit de faire la publicité sur la machine à café d’une présentation courte (moins d’un heure) qui a lieu le jeudi.

La dernière phase a été pour toutes ces personnes impliquées dans l’améliorer permanente des process et des connaissance, d’avoir un nouveau souffle. Le point transverse commençant à perdre de son intérêt, une rétrospective y est ajoutée afin de lui redonner de l’attrait. Un jeu est créé afin de noter les idées proposer par d’autres personnes.

12h30 : Tests d’acceptation de Workflows automatisés avec Concordion

par Jean-Baptiste Vilain et Gabriel Le Van

Typologie : retour d’expérience

Cette session fut l’occasion de revenir sur la mise en place de l’outil de tests Concordion par la société. Cette présentation ne comporte aucun détails technique, sa durée étant courte. Concordion est un framework de test qui se greffe au dessus de Junit, pour les tests Java.

Jean-Baptiste et Gabriel utilisent le terme “tests d’acceptation” en tant que traduction de l’anglais “acceptance tests”. Le terme “tests de validation” aurait pu fonctionner.

A partir d’une application dont la recette est difficile à faire, ils ont voulu améliorer la partie tests. Différentes frameworks ont été étudiés, et Concordion a été choisi pour la documentation qu’il apporte, et le fait qu’il s’intégrait bien dans l’environnement de développement de l’équipe. L’équipe pratiquait déjà l’XP, mais les aucun tests unitaire ou d’intégration n’est présent dans l’application.

Ce qui a été le plus difficile dans la mise en place de Concordion, a été de convaincre toutes les équipes qui sont parties prenantes. Un PoC a été réalisé, et a convaincu une bonne partie de équipes, aussi bien les équipes qui font la recette car elles ont une application a tester est bien plus fiable, que les décideurs car la mise en place des tests n’est pas un gouffre financier.

Les résultat ont bien entendu été probants. Ce PoC a entraîné une généralisation à l’ensemble des modules du projet, puis à tous les autres projets de la société.

Il y a quelques points négatifs à cette mise en place. D’abord les coûts de maintenance des tests représente un effort supplémentaire. D’autre part, il est difficile pour les personnes dans un environnement non-agile d’être impliquées dans la maintenance de ces tests (maîtrise d’ouvrage par exemple). Les points positifs sont plus nombreux que les négatifs. Concordion fournit une documentation à chaud. La collaboration avec l’équipe de recette a été grandement améliorée. Un domain specific language est en train d’émerger.

14h30 : L’agilité comme facteur de réussite d’un projet au forfait

par Guillaume Leborgne

Typologie : retour d’expérience

Guillaume nous présente comment l’agilité a pu faire réussir un projet au forfait. Ce projet consistait à migrer une application existante vers des nouvelles technologies en y intégrant quelques nouvelles fonctionnalité.

Scrum a été mis en place, avec des sprints de deux semaines. Un espace collaboratif a été mis en place entre le client et le prestataire, de type SharePoint. Une intégration continue a été mise en place.

Quelques difficultés ont été rencontrées. Le client a eu du mal à s’adapter à une approche incrémentale. Lors des premières versions livrées, il était difficile pour le client de comprendre les parties à tester et les parties qui n’étaient volontairement pas encore développées. Il a fallu trouver le niveau de souplesse adéquat pour respecter les demandes du client, et les contraintes d’un forfait.

De nombreux points positifs sont au bilan de ce projet. Le client a été très fortement impliqué. Le prestataire a, grâce à l’espace collaboratif, été très transparent sur l’état d’avancement du projet. L’application a été testable rapidement, et a pu être testé progressivement, ce qui a allégé la recette finale.

Au final, l’agilité a permis de répondre dans les délais à la migration de cette application. La version finale a été livrée avec seulement deux semaines de retard, sur un projet de plus de 6 mois. Le client est entièrement satisfait, à la fois par le logiciel, et par la méthode de travail apporté par l’agilité. En production, l’application a rencontré très peu d’anomalies.

15h00 : Le modèle d’acquisition des compétences de Dreyfus

par Emmanuel Hugonnet

Typologie : modèle

Emmanuel nous présente, au cours de cette présentation, le modèle de Dreyfus. Ce modèle catégorise le niveau de compétence qu’un individu a sur un sujet. Les niveau sont les suivants :

• Le novice
• Le débutant avancé
• Le compétent
• L’efficace
• L’expert

Toute la présentation s’est axée sur la description de chacun des niveau et des interactions possibles entre personnes de niveaux différents. Emmanuel nous donne également quelques conseils pour que nous tendions vers l’expertise, car ce type de compétence est rare et possède pleins d’avantages, comme le fait d’être non délocalisable.

16h30 : Comment être agile dans sa communication

par Eric Bezançon

Typologie : bonnes pratiques

Cette courte présentation avait pour but de nous donner des conseils pour communiquer au mieux en faisant de belles présentations. Eric est consultant Agile, Scrum et expert en communication.

Communiquer signifie délivrer un message. Ce qui est difficile lorsque l’on sait quelque chose, est de communiquer ce savoir. Le secret est donc de se mettre au niveau des gens qui n’ont pas ce savoir afin d’adapter le message qu’on leur transmet.

Une bonne communication se résume en 6 grands principes que je ne vais pas détailler :

• simplicité
• inattendu
• concret
• crédibilité
• émotion
• histoire

Pour faire une bonne présentation (powerpoint par exemple), il faut être créatif. Afin de la préparer, il faut éteindre son ordinateur, et faire un story board, par exemple avec des post-it. Lors de la construction de la présentation, il faut utiliser des visuels forts, tels que des images, des photos, et peu de textes. Il ne faut pas répéter ce qui est dit à l’oral.

17h00 : Le secret de la Rétrospective

par Jacques Couvreur et François Bachmann

Typologie : bonnes pratiques

Cette présentation était entièrement axé sur une mise en pratique. La salle a été séparé en 2 groupes, et à l’aide d’un jeu de carte, chacun a endossé un rôle sur un projet fictif. Le projet est la mise en place de Noël. Les rôles sont nombreux, tels que le père noël qui n’a qu’une envie, faire plaisir aux enfants. Les enfants n’hésitent pas à demander tout et n’importe quoi comme cadeau de noël. Les rennes doivent s’assurer que les cadeaux arrivent à destination et dans les temps. Les nains ont pour tâche la fabrication des cadeaux. Les elfes doivent vérifier la conformité des cadeaux par rapport à ce que les enfant ont demandés, etc.

A travers ces différents rôles, facilement assimilables à ceux que l’on peut avoir dans un projet informatique, Jacques et François nous ont distillé les meilleures pratiques sur la rétrospective. Un de leur conseil par exemple, est de mettre en place une petite liste d’actions a effectué à la fin de la rétrospective. Lors de la prochaine rétrospective, il faut voir quel est l’état de ces tâches. Si rien n’a été fait, alors il ne faut en ajouter de nouvelles.

Fin de la conférence

Conférence très variée, cadre agréable, temps radieux, cette conférence m’a permis de connaître des domaines auxquels je ne me serai pas intéressé si je n’étais pas venu. L’agilité reste le fil conducteur de chaque présentation, et heureusement qu’il ne s’agit pas que de présentations de XP ou Scrum !

Je retiendrai sûrement bon nombres d’idées à appliquer au quotidien chez mon client. Le plus dur n’est pas de vouloir le faire, ni de se lancer, mais de convaincre une DSI qui n’est pas habituée aux méthodes agiles, et qui ne souhaite pas vraiment y adhérer. Voilà ce que je cherchais également, des conseils chez des anciens de l’agilité, qui ont réussi à imposer dans leur projet les méthodes agiles. Nous verrons dans quelques mois si cela a porté ses fruits pour moi.

Bibliographie

Pragmatic Programmer : http://www.pragprog.com/

Concordion : http://www.concordion.org/

Génération de personnages (pour les présentations par exemple) : http://www.weeworld.com/

Ancienne présentation sur le modèle de Dreyfus : http://www.slideshare.net/ehsavoie/le-modle-dacquisition-de-comptences-de-dreyfus

Présentation de Florence Chabanois – Comment écrire du code testable : http://www.slideshare.net/foucha/comment-crire-du-code-testable?from=ss_embed

The post Conférence Agile France 2010 : Jour 2 first appeared on In Fine - Le Blog.