Les DevopsDays Paris ont eu lieu ces jeudi 18 et vendredi 19 avril 2013. Nous y étions, et voici ce que nous en retiendrons : [SPOILER] Du positif ! [/SPOILER]

“Devops”, c’est quoi ? Tout le monde (ou presque) a du entendre ce buzz-word au moins une fois. Né de la concaténation de Developper et Ops (abréviation de operations), le devops n’est ni une méthode, ni un poste (même si certaines sociétés embauchent des devops). Devops, c’est avant tout une culture, une mentalité, une way of life. C’est aussi beaucoup de bon sens.

Tout part d’un constat simple : le but d’un développeur est de livrer des nouvelles fonctionnalités. Le but d’un opérationnel est d’avoir une plateforme stable. Une livraison implique toujours un risque d’instabilité, mais sans livraison, pas de nouvelles fonctionnalités. Devops, c’est une culture qui va amener les gens à prendre conscience de ce que fait l’équipe d’à coté, et essayer de prendre en compte les contraintes de chacun dans le but d’améliorer la qualité du produit/projet.

L’amélioration continue avec la boucle “Build, Measure, Learn” est un excellent point de départ pour amener la culture devops au sein d’une entreprise. C’est d’ailleurs sous cet angle que nous avons choisi de vous présenter les différentes conférences qui nous ont le plus marqués.

Conférences

Build

Comment l’ops a amélioré mon dev

“I don’t want to be called at night, so I call myself a developer”

Florian Gilcher nous explique pourquoi connaitre le point de vue d’un op permet d’améliorer la qualité d’un développement et de mieux gérer la complexité “accidentelle”. Prenons l’exemple d’un développeur qui ne s’occupe pas des problématiques ops. Il va écrire un programme qui va :

• lire des données (depuis différents formats)
• traiter les données
• écrire les résultats (dans différents formats)

un seul livrable mais une classe par action, tout est bon. Simple pour le dev, mais compliqué pour les ops : il faut tout redéployer (donc interrompre) à chaque changement, il peut y avoir des problèmes de scalabilité, etc.

En prenant en compte le point de vue des ops, le dev écrira plutôt un exécutable par tâche : pas besoin d’arrêter la lecture pour corriger le traitement, si une tâche est beaucoup plus gourmande en ressources, le monitoring permettra de le détecter et l’op d’ajouter plus de processus.

On arrive donc à un exemple peut-être légèrement moins simple pour le dev mais beaucoup plus facile à gérer pour les ops. Desormais, Florian se concentre plus sur la qualité “externe” de son appli (sa configuration, sa CLI, etc) que sur la qualité du code “interne”.
Florian nous explique également les problèmes d’une séparation stricte entre dev et ops. Cela devient difficile voire impossible de refactorer la plateforme : les choses vont devenir politiques très vite ! Et sans pratique, les compétences pour ce genre de refactoring risquent de disparaître.
Certaines parties du code risquent également de ne pas pouvoir bénéficier de revue de code, faute de gens pouvant le faire.

La culture devops permet de diminuer les frictions entre les dev et les ops, de partager la connaissance et de réfléchir à l’application dans sa globalité.

Success story @ GOV.UK

Kushal Pisavadia nous présente l’origine de gov.uk et comment les choses se sont déroulées jusqu’à aujourd’hui.

Le point de départ est un rapport de 2010 intitulé Directgov 2010 and beyond: revolution not evolution. Ce rapport constate que le site web du gouvernement britannique d’alors, DirectGov, n’est clairement pas adapté et préconise de ne pas le faire évoluer mais de le réinventer. Pour cela, le rapport propose :

• un centre d’excellence dans le gouvernement
• corriger la publication (il y avait des centaines de sites web indépendants)
• corriger les services proposés (trop complexes)
• devenir fournisseur de services pour d’autres sites (en proposant des API publiques)

Pour cela, gov.uk s’est donné comme objectif de se concentrer sur les besoins de l’utilisateur, de livrer rapidement et de tout mesurer. En été 2011 sort le site http://alpha.gov.uk/ s’appuyant sur ces principes. Le projet a joué la carte du libre en utilisant des logiciels libres mais aussi en libérant leur code source sur Github. Gov.uk utilise des outils comme capistrano, jenkins ou puppet pour accélérer les déploiements.

Cette vitesse est un vrai atout : 4h pour qu’un développement arrive en production, jusqu’à 20 déploiements par jour, … Ou encore, le dernier patch critique de ruby a été déployé seulement 1h30 après sa sortie !

Ce projet est clairement dans l’esprit devops, allant jusqu’à avoir une page à part entière dessus ! La page décrivant les bonnes pratiques pour développer un service en général est également très instructive.

Measure

Le territoire et la carte, une histoire de visibilité

Au cours de sa présentation, Pierre-Yves Ritschard fait une analogie : la plateforme est le territoire, le monitoring est sa carte. Or notre métier étant très abstrait, nous n’avons pas accès au territoire, seulement à la carte. C’est pourquoi nous devons absolument avoir une carte la plus précise possible (même si cette carte n’est pas le territoire).

Pierre-Yves prend l’exemple des serveurs dans les années 2000 et ceux de 2013. D’un côté, un LAMP (Linux, Apache, MySQL, PHP) et de l’autre HA_PROXY, un cluster de Nginx, Reddis, mysql, cassandra, PHP. Le nombre de serveur a explosé en 13 ans. En revanche, la plupart des outils de monitoring sont identiques : CPU, mémoire.

L’explosion du nombre de serveurs est en partie due à la complexité toujours plus grande des sites. Désormais, la page d’accueil d’un journal agrège des tweets, d’autres journaux, des tendances, des commentaires. C’est pourquoi il faut inventer de nouvelle manière de monitorer sa plateforme : “Extracting meaningful state data from heterogeneous event sources over time”. Il devient nécessaire de mettre en face des métriques traditionnelles d’autres événements : CPU et chiffre d’affaire en fonction du temps.

L’approche Event-Stream

Une des méthodes proposée par Pierre-Yves est l’approche Event Stream. Une grande quantité de petits producteurs vont générer des données pour quelques gros consommateurs.

Les producteurs de données devront normaliser et streamer les évènements. Les consommateurs vont consommer ces évènements en les agrégeant (ratios, sommes, …), les corrélant (mettre en rapport un opération de maintenance et le temps de réponse.) et décider (surveiller, alerter, ignorer, scaler).

Comment améliorer la visibilité dans tout ça ? Il faut trouver les bonnes métriques en partant du business(ex. la home du journal). Ensuite, descendre vers les métriques traditionnelles. Là encore, il conviendra de choisir les bons outils, impliquer tout le monde et challenger les gens. Une des conséquences sera l’amélioration de la qualité et la baisse du taux d’erreurs.

Learn

Produit vs Projet

Pourquoi internet regorge-t’il de produits qui fonctionnent et les DSI de projets qui échouent ? Rémy-Christophe Schermesser commence par nous rappeler ce qu’est un projet :

On appelle projet un ensemble finalisé d’activités et d’actions entreprises dans le but de répondre à un besoin défini dans des délais fixés et dans la limite d’une enveloppe budgétaire allouée.
wikipedia.fr

En revanche le produit c’est tout ce qui peut satisfaire un besoin. C’est donc beaucoup plus facile de rater un projet qu’un produit ! Il faut donc redéfinir la notion de succès pour un projet. Est-ce vraiment du temps, un budget, et un besoin ? Pour un produit, on prend en compte uniquement l’amélioration du travail des utilisateurs !

Dans la démarche produit, toute idée est bonne à prendre. L’appliquer à un projet est certainement une excellente idée. Mais comment réussir ? Build, measure, learn, là encore !

Une fonctionnalité n’a de la valeur que si elle est utilisée. Le but est de créer le Minimum Viable Product, puis de l’améliorer en allant à la rencontre des utilisateurs.

Un autre problème régulièrement rencontré dans les projets est la conduite du changement. Pourquoi Gmail peut changer la vue de création de messages, et pourquoi ne peut-on pas changer de place un bouton dans notre back-office ? Il est important de comprendre que l’utilisateur ne peut pas être laissé seul face à ce changement. L’apparition la première fois d’une aide comme gmail l’a fait pour la vue “nouveau mail” est une excellente idée (les devs pourront aller voir du coté de Chardin.js)

Ensuite, pour mesurer la satisfaction utilisateur, il faut savoir que les utilisateurs mentent aux questionnaires (voir l’exemple de la sauce tomate dans les années 50 aux USA). Ce n’est donc pas la bonne solution. Remy-Christophe propose plutôt de s’intéresser à la seule métrique impartiale et utile : le temps passé pour une tâche.

Enfin, apprendre ! Et apprendre à échouer ! Et échouer pour apprendre.

Conclusion : Think Product, Do project. La collaboration entre équipes est le secret.

L’apprentissage de la culture devops chez un dev

Fabrice Bernhard nous propose une conférence intitulée “Transforming Devs into Devops”. Le constat est que le business a besoin de rapidité. Dans la nature, ce n’est pas la grosse bête qui mange la petite, c’est la rapide qui mange la lente. C’est pourquoi il est important de limiter un maximum le gaspillage de temps : les méthodes agiles ont amélioré la communication MOA-MOE, le devops améliore la communication Dev-Ops.

Fabrice présente ensuite sa méthode en tant que directeur technique Theodo pour transformer un dev en devops. Prenez un développeur junior sorti d’école. La caricature veut qu’il utilise Filezilla pour modifier son portail étudiant, et le CPOLD+mail comme gestionnaire de sources. Saupoudrez ce dev junior avec du git, du SCRUM, du TDD et laissez mariner 2 mois à température sur une banquise GNU/Linux. Le dev junior va devenir un dev devops-friendly. Il faut ensuite l’amener à déployer sur une plateforme ayant suffisamment d’importance pour le responsabiliser. Fabric semble être le bon outil pour l’automatisation.

Attention cependant, un dev et de (bons) outils n’est pas devops. Il y a encore du chemin à parcourir. Fabrice parle de Pair Devopsing, de sensibilisation aux performances (en incluant dans la définition d’une tache terminée des temps de réponse, en affichant dans la salle des rapport de tests de performances), et surtout en partageant la responsabilité d’une plateforme stable.

Openspaces

Pour nous, c’était un mystère. C’est semble-t-il suffisamment intéressant pour y consacrer autant d’importance que les conférences. Et l’expérience nous montre que c’est effectivement très intéressant ! Le déroulement est simple : On commence par ouvrir les openspaces en prenant 1h30 pour construire un tableau avec des post-it contenant des thèmes de discussion proposés par l’assemblée. Chacun est libre de proposer un sujet (question, retour d’expérience, recette de piña colada), qui sera ensuite soumis à un vote, fusionné avec des sujets identiques.

Comme l’a dit un des organisateurs, ce n’est pas un concours de popularité, un sujet peut ne pas être choisi, voire l’auteur de la proposition peut se retrouver seul dans la salle. “Depuis quand n’avez vous pas pris 45 minutes pour vous introspecter ?”

Les discussions durent environ 45 minutes, les horaires de démarrage et de fin sont donnés à titre indicatif (dans la mesure du raisonnable, “show must go on”). Les organisateurs nous ont fortement incités à papillonner entre les différentes salles. Les règles qui sont en vigueur sont les suivantes :

• Whoever comes is the right people
• Whatever happens is the only thing that could have
• Whenever it starts is the right time
• When it’s over, it’s over

Et une règle d’or, celle des deux pieds : Si vous avez l’impression de ne rien apprendre, prenez vos deux pieds et allez ailleurs.

Il est très difficile de faire un résumé des différentes sessions, l’ambiance ressemblant beaucoup à une discussion dans un openspace (tiens donc !) où le sujet final est souvent loin de celui annoncé. Pour se faire une idée des thèmes abordés, voici les discussions auxquelles nous avons assisté.

Refactoring infrastructures

Une discussion sur la problématique d’un participant : un écosystème d’applications (discutant en HTTP) à repenser entièrement. Les conseils ont été de versionner les API et de refactorer morceau par morceau. On a également parlé d’améliorer les remontées de métriques vers les devs et évoquer la possibilité d’un tableau de bord centralisant monitoring, données métier, etc

Diffusion de la culture Devops dans l’entreprise

La question initiale venait d’un des participants qui voudrait mettre en avant la culture devops dans son entreprise, celle-ci n’étant “que” agile. La discussion a assez vite dérivé vers la problématique de conserver cette culture devops lors de la “deuxième génération” d’embauche : Il est facile de déplacer la responsabilité sur les devs de certaines choses (ce qui s’est passé pour un des participants). Ainsi, la culture s’entretient, et nécessite une surveillance de tous les instants (measure), et prendre des actions correctives en cas de soucis. C’est finalement un combat de tous les jours.

Comment être un meilleur dev java pour ses ops ?

En utilisant la règle des deux pieds, on se retrouve parfois à prendre une discussion en plein milieu. Ce qui donne (à la traduction en français près) : “… sécurité entre les ops qui partent du principe que tout est fermé et les devs pour qui tout est ouvert.”.

Les ops présents ont également exprimé leur besoin d’avoir accès (en ligne de commande) à l’état de santé de l’application (un health-check : en état de marche ou HS) pour le load-balancer. Il faut aussi pouvoir interagir avec l’application: changer le niveau de log sans avoir à la redémarrer ; si elle possède un cache en écriture, flusher ce cache pour pouvoir faire un backup (consistent).

Enfin, communiquer sur les problématiques de mémoire ! Xmx, Xms, … Les besoins en mémoire d’une application (sans parler du tuning de jvm) ne s’inventent pas.

retours d’expérience de devs et ops ayant vécu le passage devops

La principale chose à retenir est : communiquez ! Impliquez les ops tôt dans le projet !

Mini-jeu de Patrick Debois

Il s’agissait plus d’une expérience que d’un openspace proprement dit. Le but du jeu était d’analyser une infrastructure dans son ensemble pour ensuite dégager des indicateurs et des métriques à monitorer. Le jeu se déroule en groupe de 4-5. Une des personnes du groupe parle de son architecture, et les autres participants la questionnent pour identifier les métriques.

Notre groupe a plutôt ressemblé à un cours sur le monitoring, puisque l’infrastructure choisie était celle de @hgomez, dont on ne peut que vous recommander la présentation sur le monitoring qui a eu lieu à la DevoxxFr 2013 (les slides, en attendant la rediffusion sur parleys.)

Conclusion

Deux jours, c’est presque trop court ! Nous revenons avec des idées plein la tête, une vision transformée, et une féroce envie d’aller aux Paris devops !

Annexes

Les slides des ignites talks dont nous n’avons pas parlé, mais dont le format est parfait !

• http://zeroturnaround.com/labs/rebel-labs-release-it-ops-devops-productivity-report-2013/
• http://www.slideshare.net/devopsdays/what-if-devops-was-invented-by-coca-cola
• http://devopsdays.org/events/2013-paris/proposals/PerformancesPerpetuellesIgnite/ (Gatling roxx !)
• https://github.com/philandstuff/devopsdaysparis : Unit Testing puppet code

Pour le moment, peu de ressources sont disponibles, nous essayerons de maintenir la liste à jour !

Rappel sur les protagonistes

Play est un framework MVC de développement rapide pour Java et Scala, dont la version 2 est sortie le 13 mars 2012.
Comet est une approche permettant au serveur web d’envoyer des informations au navigateur web sans que celui-ci l’ait explicitement demandé.

Premier pas

Pour utiliser Play vous devez avoir au moins java 6. L’installation de Play est simple, une fois le zip téléchargé, il suffit de le décompresser dans un dossier où vous avez les droits de lecture et d’écriture (lancer play écrit des fichiers dans les dossiers de l’archive), ajouter le dossier de play dans votre PATH et vous êtes prêt à continuer.
Pour créer le projet, placer vous dans le répertoire où vous souhaitez créer le projet et tapez la commande suivante:

play new chatApp

 
Play vous demande un titre pour votre application, mettons par exemple “Chat application”, puis vous avez à choisir le modèle d’application, nous allons utiliser le modèle java. Play crée alors le dossier chatApp pour vous, si vous explorez son contenu vous y trouverez notamment les dossiers suivants:

• app/ qui contient le coeur de l’application séparé entre modèles (models/), vues (views/) et contrôleurs (controllers/)
• conf/ qui contient les fichiers de configuration dont application.conf, routes et messages (pour l’i18n)
• project/ qui contient les scripts de build sbt
• public/ qui contient les fichiers statiques (javascript, css, image, etc…)
• test/ qui contient les fichiers de test JUnit

L’utilisation d’eclipse

Bien que l’on puisse utiliser un simple éditeur de texte (Play gère la compilation et le déploiement), personnellement j’ai du mal à me passer de l’auto complétion, or Play s’intègre très facilement avec Eclipse, pour cela placez-vous dans le dossier de votre projet puis lancez la console Play:

play

 
et utilisez la commande suivante :

eclipsify

 
Vous pouvez alors importer le projet dans Eclipse. Si vous utiliser un autre IDE référez vous à cette documentation.

Attention ! Play utilise l’encodage UTF-8, assurez vous d’avoir correctement configuré votre éditeur.

Lancer le serveur

Pour lancer le serveur utilisez la commande suivante dans la console Play:

run

 
Vous pouvez alors ouvrir votre navigateur et aller à l’adresse http://localhost:9000/ pour constater que vous avez une belle page de démonstration. La question existentielle que vous devez vous posez c’est : “mais pourquoi ?”, un début de réponse se trouve dans le fichier conf/routes, plus précisement la ligne :

GET     /                           controllers.Application.index()

 
Celle-ci indique au serveur de rediriger un HTTP Get sur l’url / vers la méthode index de la classe Application qui ressemble à ça :

1
2
3
    public static Result index() {

        return ok(index.render("Your new application is ready."));

    }

Comme vous pouvez le constater celle-ci renvoie un objet Result qui represente la réponse HTTP à renvoyer au navigateur, ici ok (qui correspond au code HTTP 200) avec un contenu. Ce contenu est généré par un template compilé en une simple classe java avec une méthode render. Ce template est défini dans app/views/index.scala.html :

1
2
3
4
5
6
7
@(message: String)



@main("Welcome to Play 2.0") {



    @play20.welcome(message)



}

La première ligne indique la signature de la méthode, la suite peut être un mélange de code Scala préfixé par @, et du HTML, ici @main appelle le template défini dans main.scala.html et @play20.welcome génère le contenu de la page de démonstration. Le template main.scala.html définit la structure de la page :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@(title: String)(content: Html)



<!DOCTYPE html>



<html>

    <head>

        <title>@title</title>

            <link rel="stylesheet" media="screen" href="@routes.Assets.at("stylesheets/main.css")">

            <link rel="shortcut icon" type="image/png" href="@routes.Assets.at("images/favicon.png")">

            <script src="@routes.Assets.at("javascripts/jquery-1.7.1.min.js")" type="text/javascript"></script>

    </head>

    <body>

        @content

    </body>

</html>

Les instructions @routes.Assets.at permettent de pointer vers le contenu du dossier public.

Et si on commençait…

Pour commencer changeons simplement le retour de la méthode index pour ok(“Hello world”). Pour voir le changement, pas besoin de redémarrer le serveur, vous avez juste à rafraichir la page. Et si vous vous trompez ? Essayez d’enlever la parenthèse fermante par exemple, le serveur Play affiche une belle page vous indiquant l’erreur de compilation…
Pour notre application de chat, nous allons avoir besoin de trois actions : l’affichage de la page, l’envoi d’un message et la récupération des messages. On met à jour le fichier routes :

1
2
3
GET     /                           controllers.Application.index()

GET     /comet                      controllers.Application.comet()

POST    /ajax                       controllers.Application.ajax()

Toujours pareil, on recharge la page et on voit le résultat, et là PAF, ça ne compile pas, eh oui, le fichier routes lui aussi est compilé. Pour corriger cette erreur on ajoute à Application les méthodes suivantes :

1
2
3
4
5
6
7
    public static Result comet() {

        return TODO;

    }



    public static Result ajax() {

        return TODO;

    }

On rafraichit la page, victoire ! ça compile, on essaye /ajax ou /comet, et là, on a une belle page TODO. En fait, le serveur renvoie le code HTTP 501 not implemented.
Passons aux choses sérieuses, l’utilisation de Comet. Pour Play un résultat Comet est un résultat comme les autres :

1
2
3
4
5
6
7
8
9
    public static Result comet() {

        Comet comet = new Comet("parent.receiveMessage") {

            @Override

            public void onConnected() {

                // TODO

            }

        };

        return ok(comet);

    }

Vous remarquerez l’argument passé au constructeur indiquant la méthode javascript qui sera appelée par le navigateur ainsi que la méthode onConnected qui sera appelée lorsque le flux sera prêt.
Maintenant il nous faut nous occuper des messages, on va donc créer une classe Message (oui j’aime faire des surprises) :

1
2
3
4
5
6
7
8
9
10
package models;



import play.data.validation.Constraints.Required;



public class Message {



    @Required

    public String message;



}

Notez l’utilisation de l’annotation @Required qui permet à play de gérer la validation du formulaire. Pour tester la validation et récupérer le contenu, on utilise la classe Form (immutable) :

1
2
3
4
5
6
7
8
9
10
    public static Form<Message> messageForm = form(Message.class);



    public static Result ajax() {

        Form<Message> filledForm = messageForm.bindFromRequest();

        if (!filledForm.hasErrors()) {

            Message message = filledForm.get();

            // TODO utilisation du message

        }

        return ok();

    }

Il ne nous manque plus que le serveur de chat avec la classe ChatServer (encore une surprise) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
package models;



import java.util.ArrayList;

import java.util.List;



import play.libs.Comet;



public class ChatServer {



    public static ChatServer INSTANCE = new ChatServer();



    private List listeners = new ArrayList();



    public void addListener(Comet listener) {

        listeners.add(listener);

    }



    public void sendMessage(String message) {

        for(Comet listener : listeners) {

            listener.sendMessage(message);

        }

    }

}

Comme vous pouvez le constater notre serveur de chat se contente de renvoyer à tous les flux Comet le message reçu. Nous avons tous les composants, maintenant éditons la vue :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
@(messageForm: Form[Message])



@import helper._



@main("Chat application") {



    <ul id="messageList"></ul>



    @form(routes.Application.ajax()) {

        @inputText(messageForm("message"))

        

        <input type="submit" value="send">

    }



    <script>

        var form = $("form");

        form.submit(function(event) {

            event.preventDefault();

            $.ajax({

                type: "POST",

                url: form.attr("action"),

                data: form.serialize()

            });

            $("#message").val("");

        });



        var receiveMessage = function(event) {

            $("#messageList").append("<li>" + event + "</li>");

        }

    </script>



    <iframe class="invisible" src="/comet"></iframe>



}

 
L’import de helper._ permet d’utiliser les tags @form et @input pour créer le formulaire. On utilise JQuery pour transformer la soumission du formulaire en appel Ajax et effacer le contenu du champ. La classe css invisible sert juste à masquer l’iframe qui reçoit le flux Comet :

1
2
3
.invisible {

    display: None;

}

Au final, votre Application.java devrait ressembler à ça :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
package controllers;



import models.ChatServer;

import models.Message;

import play.*;

import play.data.*;

import play.libs.*;

import play.mvc.*;



import views.html.*;



public class Application extends Controller {



    public static Form messageForm = form(Message.class);



    public static Result index() {

        return ok(index.render(messageForm));

    }



    public static Result comet() {

        Comet comet = new Comet("parent.receiveMessage") {

            @Override

            public void onConnected() {

                ChatServer.INSTANCE.addListener(this);

            }

        };

        return ok(comet);

    }



    public static Result ajax() {

        Form filledForm = messageForm.bindFromRequest();

        if (!filledForm.hasErrors()) {

            ChatServer.INSTANCE.sendMessage(filledForm.get().message);

        }

        return ok();

    }



}

Et voilà, c’est fini, vous pouvez ouvrir plusieurs navigateur et envoyer des messages entre eux…

Conclusion

Les sources sont disponible sur github. Pour aller plus loin vous pouvez jeter un oeil dans le dossier samples de play, vous y trouverez des exemples en java et en scala, dont notamment une application de chat avancée utilisant les websockets avec chatRoom et robot. Et bien sur il y a la documentation (en anglais).

A bientôt pour de nouvelles aventures sur le blog Excilys…

Qu’est ce que je veux faire ?

Mon objectif principal est la présentation de résultats de recherche sous forme de tableau avec gestion de la pagination. Du grand classique!

Quelles sont mes contraintes ?

• Pour des raisons de performance et de bon sens, je veux que la pagination soit gérée côté serveur pour éviter de charger entièrement tous les résultats;
• J’aimerais que la navigation entre les différentes pages de recherche soit fluide;
• Enfin, j’aimerais en tant que développeur que ça marche et que ça soit relativement beau avec le minimum d’effort.

Comment je vais m’y prendre ?

Comme j’ai envie que ça soit beau sans faire trop d’effort, je pense très rapidement à jQuery.  Après une rapide recherche, j’opte pour un plugin très populaire de présentation de données tabulaires : dataTable. En effet, celui-ci permet en très peu de configuration de gérer la “présentation des résultats paginés” tout en déléguant la gestion de la pagination  au serveur : bingo!

Par contre, si j’opte pour cette solution les résultats à afficher devront être récupérés grâce à des requêtes AJAX. D’un côté ça m’arrange car ça me permet de coller à ma deuxième contrainte, qui était de rendre la navigation plus fluide;  mais d’un autre côté, ça m’embête un peu parce que je n’ai pas envie de rentrer dans les problématiques techniques d’AJAX.

Je fais donc ma petite enquête et me rends compte que Spring 3.x apporte un support intéressant pour AJAX censé faciliter la vie du développeur. Spring et jQuery, je signe sans hésitation et me lance dans l’aventure.

Présentation de l’exemple

Avant de commencer les choses sérieuses, voici un aperçu de la page des résultats paginés :

• L’exemple porte sur un écran de recherche d’articles de presse.  Un article possède un titre, un auteur, une date de publication et appartient à une rubrique;
• L’application “exemple” utilise Spring MVC (version 3.x) comme framework de présentation. J’utiliserai essentiellement les annotations comme élément de configuration (pour les contrôleurs notamment). Par souci de lisibilité, je n’aborderai pas  la configuration élémentaire de Spring MVC. Pour plus d’information concernant Spring MVC se référer à cette page.
• Dans le même esprit, je vais essentiellement me concentrer sur les éléments relatifs à la pagination en faisant l’impasse sur certaines “bonnes pratiques”. Ainsi les articles de presse seront stockés dans une liste static en mémoire et pas dans une base de données relationnelle avec gestion des transactions et tout le tralala. Amis puristes, vous êtes prévenus
• Les fragments de code présentés par la suite servent uniquement de support et sont intentionnellement incomplets. Vous pouvez toujours consulter les sources jointes à cet article pour avoir plus de détails.

Fonctionnement général

Voici un diagramme qui présente le fonctionnement général de l’affichage des résultats paginés :

[1] : dataTable envoie une requête AJAX au contrôleur Spring qui contient à la fois les données du formulaire de recherche ainsi que certaines informations nécessaires à la pagination comme l’index du premier prochain résultat (iDisplayStart) et le nombre maximum de résultats que l’on veut afficher par page.

[2] [3] Le contrôleur récupère le nombre total de résultats correspondant aux critères de recherche (sans prendre en compte la pagination) et récupère par la suite uniquement les résultats à afficher sur une page : il se sert pour cela des informations de pagination envoyées dans la requête AJAX.

[4] Spring retourne une réponse JSON contenant toutes les informations nécessaires à l’affichage des résultats.

[5] dataTable construit et affiche le tableau des résultats.

Mise en place

Coté Spring…

Dans l’introduction, j’ai mentionné le fait que Spring 3.x possédait un meilleur support pour AJAX. Ce n’est pas tout à fait juste car ce support n’est pas exclusivement destiné à AJAX même s’il en facilite grandement l’utilisation. Voici les principaux protagonistes :

• HttpMessageConverter: Dans le protocole HTTP le client et le serveur communiquent en échangeant des données textuelles. Cependant dans les méthodes des contrôleurs Spring, on peut avoir un objet d’un type spécifique comme argument ou comme type de retour. La sérialisation/dé-sérialisation de l’objet en/à partir d’un format textuel est réalisé par les objets implémentant l’interface HttpMessageConverter.

•  MappingJacksonHttpMessageConverter: En ce qui nous concerne, on aimerait bien avoir un objet qui convertisse  les requêtes contenant du JSON en un javabean et vice versa. C’est ce que permet de faire la classe MappingJacksonHttpMessageConverter. Cette implémentation de HttpMessageConverter est basée sur un framework puissant de gestion du format JSON : Jackson.

• @RequestBody : Placée sur un paramètre d’une méthode, cette annotation permet de convertir le corps d’une requête (body) HTTP en un type Java donné en utilisant le HttpMessageConverter approprié (fonction du type mime).

• @ResponseBody : Placée sur une méthode, cette annotation indique qu’il faut écrire directement l’objet de retour dans la réponse et non dans le modèle de la vue.  En fonction du type mime attendu, l’objet retourné sera converti dans le format approprié par le HttpMessageConverter associé au type mime. Dans notre cas, le type mime est application/json  et MappingJacksonHttpMessageConverter convertit l’objet de retour en texte au format JSON.

Pour pouvoir utiliser MappingJacksonHttpMessageConverter couplé avec @RequestBody et @ResponseBody il faut rajouter quelques éléments de configuration à Spring MVC :

1. Utiliser l’élement <mvc:annotation-driven/> dans le fichier xml de configuration de Spring. Ceci permet de configurer (entre autre) les différentes implémentations de HttpMessageConverter dont celle qui nous intéresse à savoir : MappingJacksonHttpMessageConverter.
2. Rajouter la dépendance : jackson-databind.jar (et toutes les dépendances transitives ). Avec Maven ça donne :

<dependency>

  <groupId>com.fasterxml.jackson.core</groupId>

  <artifactId>jackson-databind</artifactId>

  <version>2.1.1</version>

</dependency>

Une fois la configuration mise en place, i l ne reste plus qu’à implémenter le contrôleur dont voici les principaux éléments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
@Controller

@RequestMapping("articles/search.htm")

public class ArticleController {



    ...



    @RequestMapping(method = RequestMethod.POST)

    @ResponseBody

    public ArticleReponseJson search(@ModelAttribute(COMMAND_NAME)ArticleSearchBean searchBean,

                                     @RequestBody MultiValueMap<String, String>parametresAjax) {



        int count = articleService.count(searchBean);

        Integer debut = getIntFirstValue(parametresAjax, "iDisplayStart");

        Integer nbElements = getIntFirstValue(parametresAjax, "iDisplayLength");

        List<Article> listeArticles = articleService.search(searchBean, debut, nbElements);

        return prepareJsonResponse(listeArticles, count, parametresAjax);

    }



    private ArticleReponseJson prepareJsonResponse(List<Article> articles, int count,

                                                    MultiValueMap<String, String> parametresAjax) {



        ArticleReponseJson reponseJson = new ArticleReponseJson();

        reponseJson.setsEcho(getIntFirstValue(parametresAjax, "sEcho"));

        reponseJson.setiTotalDisplayRecords(count);

        reponseJson.setiTotalRecords(count);

        reponseJson.setAaData(articles);

        return reponseJson;

    }



    private Integer getIntFirstValue(MultiValueMap<String, String> parametres, String key) {



        Integer res = null;

        String s = parametres.getFirst(key);

        if (StringUtils.isNotEmpty(s)) {

            res = Integer.parseInt(s);

        }

        return res;

    }



    ...

}

Concernant le contrôleur, on peut noter les éléments suivants :

• La méthode est annotée par @ResponseBody afin que l’objet de retour soit directement sérialisé dans la réponse. Grâce à la configuration ci-dessus, l’objet sera sérialisé au format JSON avant d’être écrit dans la réponse.

• Les critères de recherche sont récupérés dans l’objet de commande ArticleSearchBean.

• Un des paramètres est annoté par @RequestBody ce qui permet de récupérer les paramètres au format JSON passés dans la requête (ceux qui seront envoyés par  dataTable pour gérer la pagination). On les récupère dans une MultiValueMap (extension d’une Map proposée par Spring permettant de stocker plusieurs valeurs pour une clé). Encore une fois, ceci est possible grâce à l’intervention “implicite” de MappingJacksonHttpMessageConverter.

• Une fois le nombre de résultats total et la liste des articles à afficher récupérés du service, on initialise un bean de type ArticleReponseJson  qui sera sérialisé pour former la réponse JSON :

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



    /* Parametre de controle */

    private Integer sEcho;



    /* Nombre total de résultats correspondant aux critères de recherche */

    private Integer iTotalDisplayRecords;



    /* Liste des resultats 

       Par défaut dataTable cherche les résultats dans une propriété nommée aaData.

       On peut configurer le nom de la propriété.

    */

    private List<Article> aaData = new ArrayList<Article>();



    ...



}

… puis coté jQuery…

Le plugin dataTable est très configurable au point de s’y perdre. Je vais présenter une configuration “très simple” qui met uniquement en évidence les propriétés relatives à la pagination.  Il faut toutefois garder à l’esprit que dataTable offre beaucoup de possibilités comme le filtrage des résultats par mot clé, le tri et bien d’autres encore.

Ceci étant dit, voici la configuration que j’ai retenue :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
function search(){

$("#resultats").dataTable({

    "bFilter" : false,

    "bInfo" : false,

    "bSort" : false,

    "sDom" : '<"#top"p>rt<"#bottom"p>',

    "oLanguage" : {

        "oPaginate" : {

            "sFirst" : "<<",

            "sLast" : ">>",

            "sNext" : ">",

            "sPrevious" : "<"

        }

    },

    "sPaginationType" : "full_numbers", //Style de la pagination

    "iDisplayLength" : 5, //Résultats affichés 5 par 5

    "bServerSide" : true, //Pagination gérée coté serveur

    "bProcessing" : true,//Affichage d'une icone pendant le chargement

    "bDestroy" : true,//La grille d'affichage est détruite avant chaque chargement

    "sAjaxSource" : "search.htm", //URL de recupération des résultats

    "fnServerData" : function(sSource, aoData, fnCallback) { // Définition de la requete AJAX

        $.ajax({

            "dataType" : 'json',

            "type" : "POST",

            "url" : sSource,

            "data" : aoData,

            "success" : fnCallback,

            "timeout" : 30000

        });

    },

    "fnServerParams" : function(aoData) { // Paramètres supplémentaires à ajouter au corps du POST

        $.each($("#form-search").serializeArray(), //Données du formulaire

                function(index, elt) {

                    aoData.push(elt);

                });

    },

    "aoColumns" : [ { //Définition des colonnes à afficher

        "mDataProp" : "titre"

    }, {

        "mDataProp" : "auteur"

    }, {

        "mDataProp" : "rubrique"

    }, {

        "mDataProp" : "datePublication"

    }

    ]

});

}

J’ai pris le soin de commenter les lignes relatives à la pagination. Pour une description plus détaillée des différentes options, veuillez vous référer à la documentation officielle du plugin dataTable.

et enfin coté JSP.

<html>

<head>

    <script type="text/javascript">

        $(document).ready(function(){

            search();



        });

    </script>

</head>

<body>

    <div id="contenu">

    <form:form id="form-search" commandName="searchBean" method="POST" >

        ...

    </form:form>



    <table id="resultats" width="100%">

        <caption>Liste des articles</caption>

        <thead>

            <tr>

                <th>Titre</th>

                <th>Auteur</th>

                <th>Catégorie</th>

                <th>Date de publication</th>

            </tr>

        </thead>

        <tbody>

            <!-- Contenu géré par dataTable -->

        </tbody>

    </table>



    </div>

</body>

On notera que seul le “squelette” du tableau a été déclaré dans la JSP : en effet, le contenu de la balise tbody est vide car c’est à la charge de dataTable de construire le contenu du tableau avec les résultats de recherches.

Pour aller plus loin

Comme mentionné plus haut, MappingJacksonHttpMessageConverter utilise en coulisse une librairie de gestion de JSON nommé Jackson. Celle-ci permet de configurer finement le mapping entre un champ JSON et une propriété Java. En ce qui nous concerne, on voudrait bien que la date de publication d’un article (de type java.util.Date) soit affichée dans un format lisible (ex : 2012-12-25). Ceci peut être réalisé en annotant la propriété datePublication de la classe Article par @JsonFormat(“yyyy-MM-dd”) : 

public class Article {

...



    @JsonFormat(pattern = "yyyy-MM-dd")

    public Date getDatePublication() {

        return datePublication;

    }



...

}

Liens :

• Spring 3.x
• Plugin jQuery datatable
• Jackson: Librairies de  gestion du JSON
• Archive contenant les sources de l’application exemple

Je me propose dans cet article de vous présenter un challenger méconnu à côté de Backbone.js ou de Angular.js.

Ember.js

Ember.js est un framework MVC en javascript dont le but est de créer des applications web se rapprochant des applications desktop, dites “single page web application”.

Pour voir quelques exemples d’applications en production réalisées avec Ember.js, rendez vous sur Groupon, Capitaine Train ou encore Travis CI.

L’idée derrière les “Single Page Web App” est grossièrement de télécharger l’intégralité de l’application à la première requête de l’utilisateur, puis de communiquer uniquement avec le serveur par requête Ajax pour manipuler les données via une API REST si possible. L’application “Ember” est également  découpée selon le fameux pattern MVC afin d’apporter une séparation des responsabilités côté client permettant une plus grande maintenabilité … enfin vous connaissez la musique.

Ember.js arrive lentement mais surement à maturité avec la version 1.0 qui se profile à l’horizon. Critiqué par le passé pour ses nombreux changements rendant certaines montées de version sportives, l’équipe de développement souhaite à présent stabiliser le code. Il est intéressant de savoir que Ember.js partage une certaine similarité de philosophie avec Ruby, ceci est dû à l’origine du projet ainsi qu’à ses membres avec notamment Yehuka Katz, développeur de Ruby on Rails et jQuery.

Les tâches effectuées par des applications web sont répétitives. Tout se résume souvent à récupérer des données depuis un serveur, les afficher à l’écran puis mettre à jour les informations lorsqu’elles changent. Voyons à présent quels sont les outils proposés par Ember.js pour nous faire gagner du temps et cesser de nous préoccuper de la génération du DOM.

A better JavaScript

Au delà du MVC que nous verrons par la suite, ember.js apporte un certain nombre d’améliorations au javascript qui apparaîtront pour certaines avec ECMA Script 6.

●     un système de classe :

●     les Mixins :

Les mixins  qui permettent de composer des aspects au sein d’objet.

On peut à présent appeler la méthode ‘hello’ sur les instances de Person.

●     Computed properties

Tout simplement une propriété dont la valeur est issue d’une fonction.

Il est à préciser que le résultat fullName est mis en cache pour éviter de recalculer à chaque fois les propriété et que ce cache est automatiquement invalidé lorsqu’une des propriétés en dépendance change.

A présent, passons en revu les différentes briques de l’application.

Application & Router

Commençons par l’élément central de l’application, à savoir l’objet Application qui est responsable de relier toutes les briques du MVC ensemble.

window.App = Ember.Application.create();

L’élément application permet de définir un namespace qui contiendra par la suite l’intégralité des objets composants Ember afin d’en limiter le scope. Lors de la création, le template root aussi appelé “application template” est rendu. Voici une spécificité de Ember, l’application ne possède qu’une seule page dont le contenu sera modifié en fonction de l’état courant.

L’élément {{outlet}} sert de point d’ancrage pour d’autres templates qui seront injectés par le router en fonction de la navigation de l’utilisateur dans l’application. On peut bien évidemment créer plusieurs outlet en les nommant, par exemple pour un footer dynamique:

On peut ensuite mapper une URL à un outlet spécifique et à son contrôleur. Ci-dessous, on configure le comportement de footerOutlet sur l’URL ‘/’ pour être managé par ‘footer’. Cela correspond à une convention qui indique à Ember qu’il doit binder cette zone avec footerController et footerView.

Je ne rentre pas plus dans les détails d’implémentation car l’API du composant Router est en train de subir quelques changements avec l’arrivée de la version 1.0.

La documentation est en pleine mise à jour et peut être trouvée ici .

View & Templating

La partie vue est généralement considérée comme l’interface utilisateur de l’application et se base sur l’association d’un template et d’un controleur au niveau du routeur.

Fini la concaténation de string pour générer du html (c’est vraiment mal), Ember utilise le système de templating Handlebars dont Yehuda Katz est également l’auteur. La création de ce moteur avait pour but d’améliorer certains aspect de Mustache.js.

Pour citer les améliorations majeures, on trouve:

●     La précompilations des templates pour de meilleures performances.

●     Ajout des fonctions helpers qui permettent de décorer un attribut.

Les valeurs affichées dans le template sont directement ‘bindées’ à celle du modèle. Ce qui se traduit par une mise à jour du template automatique au moindre changement dans le modèle.

Model

La partie modèle correspond aux structures de données de l’application et est responsable de la  notification de tout élément l’observant pour connaitre son état courant. Tous les éléments du modèle héritent de Object comme vu précédemment avec le système de classe.

En plus des computed properties, le type Object supporte le data binding pour partager des propriétés et l’observation de propriété pour être notifié lorsque une valeur change.

Voici un exemple :

Il est ainsi facile d’enrichir son modèle côté client et d’ajouter des traitements lors de l’interception d’événements.

Controller

Le contrôleur contient la logique associée aux actions de l’utilisateur effectuées sur la partie vue.

Cette couche n’est pas spécialement novatrice, il est cependant bon de savoir qu’il existe des contrôleurs spécialisés dans la gestion de collection. Cela représente un des principaux use case, voici comment afficher une liste facilement.

On peut par la suite facilement relié une vue à la collection contenu dans le contrôleur.

Ember-data

Jusqu’a présent, nous n’avons pas réellement abordé le sujet de la communication avec le serveur. Dans un premier temps, il est possible d’adopter le pattern ActiveRecord en ajoutant dans chaque objet du modèle des méthodes CRUD qui réalisent des requêtes Ajax via JQuery pour communiquer avec le serveur. Mais cette démarche se révèle vite fastidieuse et peu performante car il faut synchroniser soi-même les données à la main, gérer le cache pour ne pas harceler le serveur bref on se retrouve rapidement à développer un ORM en javascript…

C’est là qu’intervient le projet Ember-Data qui se propose de gérer tout la persistance de votre application. Pour l’instant c’est un projet à part entière, mais il devrait être intégré a la release 1.0 de Ember. Son but est donc de créer un ORM côté client pour décorréler le code applicatif client de la partie serveur, le but ultime étant de pouvoir remplacer le backend sans impacter le code client.

On retrouve donc les fonctionnalités usuelles d’un ORM :

●     gestion des méthodes CRUD

●     un système de transaction

●     un système de cache

●     synchronisation automatique avec validation et merge

L’architecture s’appuie sur une couche d’adapteurs / serialiseurs responsables de la communication avec les API serveur. Le projet est assez jeune et n’est pas encore prêt pour la production au dire de ses développeurs, je ne l’ai pas personnellement testé au delà du use case nominal mais il est assez prometteur.

Conclusion

En ce moment la concurrence est rude du côté de la jungle des frameworks MVC, il est donc essentiel de voir en quoi Ember.js se différencie de ses opposants. N’ayant pas de réelle expérience avec d’autres frameworks MVC javascript mon jugement peut manquer d’objectivité, cependant je pense que Ember est un des frameworks les plus riches qui existe actuellement pour réaliser des “single page application” complexes.

Selon moi voici ses points forts :

●     Grâce à son composant Router, il peut gérer différents états.

●     Il possède un système de binding puissant.

●     Ember n’est pas qu’une bibliothèque, mais un framework riche amenant son architecture.

●     Et enfin Ember-data qui sera une avancée importante pour la persistance.

Espérons que le passage en 1.0 permettra de stabiliser le projet qui subit régulièrement de gros changement. Si cet article vous a intéressé et que vous souhaitez aller plus loin avec les frameworks MVC je vous conseille ces ressources:

http://blog.remarkablelabs.com/2012/11/11-emberjs-resources-to-get-you-started

http://coding.smashingmagazine.com/2012/07/27/journey-through-the-javascript-mvc-jungle

http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne-of-js-2012/

Dans le cadre de la refonte d’une application extranet chez un client, j’ai été plus particulièrement chargé du développement des batchs. Les batchs à développer devaient tous réaliser des tâches similaires :

• transferts FTP de fichiers (upload et download)
• traitements sur les fichiers ainsi obtenus (redimensionnement d’images JPEG, parsing de fichiers XML)
• enregistrement des méta-données sur les fichiers ainsi manipulés en base de données.

Dans l’ancienne version de l’application, les batchs étaient développés grâce à un framework interne (vieillissant). J’ai donc recherché des frameworks de batch permettant de remplacer l’ancienne architecture tout en s’intégrant avec les composants utilisés dans la partie web de l’application (développée en Spring et Struts 1).

Choix du framework

Dans un souci de facilitation de la maintenance, le choix de Spring-batch s’est rapidement imposé. En effet, la plupart des composants (DAOs, services) nécessaires pour réaliser les tâches ci-dessus avaient déjà été développés sous la forme beans Spring utilisés par l’application web ; la principale tâche restant à accomplir étant le câblage de ces différents composants. Il était donc plus efficace et plus maintenable de réutiliser les composants existants et de les injecter dans les batchs via IOC.

Le développement a donc consisté à créer les classes composant la partie « front » des batchs et à gérer leur enchaînement.

Le but de cet article n’est pas de décrire de manière détaillée le fonctionnement de Spring-batch. Il s’agit plutôt de réaliser par étapes un petit tutoriel, la documentation officielle de Spring étant très complète mais peu adaptée à une prise en main rapide : http://static.springsource.org/spring-batch/reference/html-single/index.html

Ce tutoriel traitera surtout du développement de tâches pour lesquels un composant de Spring-batch n’existe pas déjà. En effet, ce framework propose des classes permettant de mettre en place rapidement (et généralement en ne manipulant que les fichiers de configuration Spring) des tâches récurrentes dans le domaine des batchs :

• parsing de fichiers XML pour insertion dans une base de données ;
• export de données d’une base vers un fichier plat ;
• …

Des exemples fonctionnels pour ces tâches sont disponibles sur le web, notamment dans la documentation officielle ; en revanche, il n’existe que très peu d’exemples de la mise en place de tâches “spécifiques” : dans le cas qui nous intéresse, ces tâches étaient par exemple l’upload/download de fichiers via FTP et de manipulation sur des fichiers images (en tant que fichiers, et donc sans lire leur contenu comme c’est le cas avec des fichiers CSV ou XML plus fréquemment manipulés par les batchs).

Vocabulaire utilisé

Avant d’identifier les composants à développer pour notre batch, un rappel du vocabulaire utilisé dans le domaine des batchs (et plus particulièrement de Spring-batch) est nécessaire :

Job : Un job désigne un traitement batch.

Step : Phase atomique d’un batch. Un job est composé de steps ; il s’agit d’une étape du batch. Un step encapsule les informations permettant de définir et de contrôler le déroulement du batch.

Tasklet : Tâche exécutée par un step, par exemple “Parser le fichier test.xml”, “Insérer un enregistrement en base de données”… Dans le cadre de Spring-batch, cela consiste en une implémentation de l’interface Tasklet. Un step n’exécute qu’une tasklet ; en revanche une même tasklet peut être exécutée par plusieurs steps.

Spring-batch propose un certain nombre de tasklets pré-définies, orientées par exemple vers la lecture et l’écriture de fichiers. Il est cependant possible de créer ses propres tasklets, c’est ce que nous allons faire au cours de cet article.

Problématique

Supposons que le batch à écrire doive réaliser les opérations suivantes :

• download de fichiers JPG d’un serveur FTP vers un répertoire temporaire ;
• redimensionnement des images et transfert dans un répertoire local ;
• enregistrement de métadonnées concernant ces images dans une base de données.

Implémentation

La première étape consiste à identifier quels sont les concepts utilisés ici, afin de mettre en place notre architecture de batch et de définir les interactions entre ces composants (enchaînements, conditions d’arrêt…)

L’ensemble du processus décrit ci-dessus correspond à un job ; en effet tous ces traitements sont liés et seule l’exécution de tous ces traitements permet de réaliser la tâche attendue.

Ce processus peut facilement être décomposé en plusieurs tâches élémentaires, qui seront représentées sous la forme de steps : chacune des trois opérations décrites sera configurée comme étant un step dans l’application context.

Chaque step sera par la suite implémentée sous la forme d’une tasklet. Toute tasklet utilisée dans un projet Spring-batch est une classe implémentant l’interface org.springframework.batch.core.step.tasklet.Tasklet.

Création de l’applicationContext

Nous allons commencer par créer un fichier applicationContext.xml basique, contenant le minimum de beans qui nous permettront ensuite au batch de s’exécuter. Trois beans doivent être créés :

• Un job launcher : Bean permettant l’exécution d’un batch. Dans notre cas, nous allons utiliser son implémentation la plus basique, SimpleJobLauncher.
• Un transaction manager : Dans notre cas, nous n’utilisons pas de transactions, mais tout job launcher doit posséder un composant permettant de gérer les transactions qui lui sont associées. Nous allons donc utiliser ici un ResourcelessTransactionManager, ce point n’étant pas le thème principal de l’article.
• Un job repository : Bean permettant de gérer la persistance des méta-données liées au batch.

Le fichier applicationContext.xml minimum sera donc le suivant :

Tasklet de download FTP : FTPTasklet

Cette tasklet a simplement pour objectif de télécharger via FTP les fichiers se trouvant dans un répertoire distant vers un répertoire local.

Aucune des tasklets pré-définies de Spring-Batch ne permet de mettre en place directement ce traitement, nous allons donc devoir écrire une tasklet spécifique pour cette opération. Nous allons donc implémenter notre propre classe FTPTasklet à partir de l’interface Tasklet proposée par Spring-Batch.

L’interface Tasklet est la plus générique possible pour implémenter une tâche de batch : elle ne possède qu’une seule méthode, execute, destinée à effectuer les traitements attendus :

La classe FTPTasklet est donc construite suivant le modèle ci-dessous :

Le code complet se trouve dans l’archive du projet liée à cet article. Le traitement de download est implémenté dans la méthode execute, en utilisant les informations de connexions injectées via IOC.

Une fois cette tasklet écrite, nous pouvons modifier le fichier applicationContext.xml pour définir un batch minimal l’utilisant. Cela consiste à modifier le job pour lui ajouter un step exécutant FTPTasklet :

Le batch peut alors être exécuté en utilisant la classe main org.springframework.batch.core.launch.support.CommandLineJobRunner, qui prend en paramètre le path du fichier applicationContext et le nom du job à lancer (ici myJob).

Lecture et redimensionnement des images : JPEGFileResizeTasklet

La deuxième tâche à créer pour notre batch est la tâche chargée du redimensionnement des fichiers JPEG précédemment récupérés.

On pourrait créer la tasklet chargée de lire et de redimensionner les images comme la tasklet de download FTP, en écrivant une classe implémentant l’interface Tasklet :

La configuration de la step correspondante serait alors la suivante :

Cependant, Spring-batch propose des classes prédéfinies permettant de réaliser ce traitement de manière beaucoup plus succinte.

En effet, la documentation met l’accent sur les classes permettant de parser des fichiers plats ou de lire des données dans une base afin d’en extraire des “items”. Ces items sont ensuite traités en “chunks” (ensembles d’items).

Les traitements effectués sur des chunks de données sont réalisés en implémentant trois interfaces fournies par Spring-batch :

• ItemReader : interface prenant en charge la lecture des chunks d’items à traiter ;
• ItemProcessor : traitement des items ;
• ItemWriter : écriture des items.

Les implémentations de ces trois interfaces sont ensuite enchaînées pour réaliser le traitement à effectuer sur les items (lecture – traitement – écriture).

Pour mettre en place notre traitement, il serait intéressant d’implémenter ces interfaces : de la même manière que ces classes sont par exemple implémentées par des classes du framework permettant de parser un fichier XML et d’en extraire des objets, nous pouvons les utiliser pour lire le contenu du répertoire d’entrée et d’en extraire des objets Resource.

Une implémentation d’ItemReader pour lire les fichiers d’entrée

Pour mettre en place notre tasklet traitant des chunks de fichiers JPEG, le premier composant à écrire est donc la classe de lecture des fichiers JPEG, implémentant l’interface ItemReader.

Spring-batch propose une implémentation particulière de l’interface ItemReader, ResourcesItemReader, permettant de lire des objets Resource dans un répertoire à partir d’un pattern de nom de fichier. Il n’est donc pas nécessaire de créer notre propre implémentation d’ItemReader ; il suffit de déclarer dans l’applicationContext de Spring un bean de classe ResourcesItemReader, qui lira les fichiers jpg placés dans un répertoire d’entrée. Dans notre cas, ce bean sera donc configuré de la façon suivante :

Et c’est tout ! Il nous reste à câbler cet item reader avec un itemProcessor qui traitera les items (ici le redimensionnement des images), puis avec un itemWriter pour insérer en base de données les informations concernant les images importées.

Une implémentation d’ItemProcessor pour redimensionner les images

Notre ItemProcessor va prendre en entrée les fichiers lus par l’itemReader, redimensionner les images et créer les objets métier Image correspondants.

Le fonctionnement d’un ItemProcessor étant spécifique au domaine du batch (ici le redimensionnement d’images JPEG), nous devons l’implémenter nous-mêmes. Dans notre cas, la méthode process de l’ItemProcessor prendra en entrée un objet de classe Resource (correspondant à un fichier lu par l’itemReader) pour créer une instance d’une classe de notre package model, représentant les données concernant l’image que nous enregistrerons ensuite dans la base de données :

Nos images JPEG sont maintenant redimensionnées. Il ne nous reste plus qu’à insérer les données les concernant dans la base de données en utilisant une implémentation d’ItemWriter.

Une implémentation d’ItemWriter pour insérer les images en base de données

L’interface ItemWriter de Spring ne contient qu’une méthode, write, prenant en entrée une liste d’objets.

Notre itemWriter est très simple : il se contente de récuperer les instances de ImageDTO créées par le processor et d’insérer les enregistrements correspondants en base de données.

Ce batch étant lié à un application web utilisant Spring IOC, il suffit d’injecter dans l’itemWriter le service déjà créé pour l’application web et de faire appel à sa méthode d’insertion afin d’alimenter la base de données.

Notre batch est à présent terminé. Seuls les traitements spécifiques à ce batch ont fait l’objet d’une implémentation spécifique : les services et DAOs précédemment développés dans le cadre de l’application web ont pu être réutilisés.

Conclusion

Cet article ne présente que quelques possibilités offertes par Spring-Batch que j’ai été amené à utiliser dans le cadre du projet sur lequel j’ai travaillé. Cependant, ce framework est très riche ; je n’ai par exemple pas évoqué les possibilités qu’il offre dans la gestion des transactions, le traitement par lots, un contrôle plus fin de l’enchaînement des tâches… Pour ces aspects, la documentation officielle est simple à prendre en main et des exemples plus détaillés sont disponibles dans le package de Spring-batch, je vous invite donc à aller y jeter un œil si le sujet vous intéresse.

Le projet Eclipse contenant le code utilisé dans cet article se trouve ici : spring_batch_tuto

Dans un précédent article, je vous avais donné quelques conseils pour améliorer l’expérience utilisateur de votre application web.

Depuis, le monde des Interfaces Homme-Machine a totalement été chamboulé par l’avènement des interfaces mobiles à travers notamment les formats téléphone, tablette et hybride.

Ces nouvelles interfaces apportent avant toute chose de nouveaux modes d’interaction mais elles s’accompagnent également de nouvelles contraintes qui viennent perturber votre démarche ergonomique jusqu’alors si bien huilée (n’est-ce pas).

Cependant l’enjeu reste strictement le même, à savoir satisfaire rapidement et efficacement le besoin des utilisateurs. Je vous propose donc de voir dans cet article quelques conseils spécifiques à ces nouvelles interfaces.

Les interfaces mobiles, des interfaces avant tout

Pour commencer, une interface mobile reste avant toute chose une IHM. Ainsi, tous les principes généraux énoncés dans mon précédent article restent valables. A savoir :

• Les personas
• La loi de proximité
• La loi de similarité
• La loi de Fitts
• Les tests utilisateurs

De plus, je vais m’intéresser ici uniquement à l’interface et à l’ergonomie des applications mobiles, les règles et conseils énoncés ci-dessous s’appliquent donc à n’importe qu’elle application mobile, qu’elle soit développée en code natif ou à l’aide d’une technologie cross-platform.

Dis-moi comment tu utilises ton mobile, je te dirai qui tu es

Pour rappel, la première étape du travail d’ergonome est d’identifier correctement et avec précision les utilisateurs cibles de son application.
Avant de passer aux conseils pratiques, nous allons donc voir dans cette première partie ce qui va caractériser de manière générale les utilisateurs d’une application mobile.

Des utilisateurs dans un monde de contraintes

Comme je le disais dans l’introduction, les interfaces mobiles ont apporté un grand nombre d’innovations mais également de nouvelles contraintes que les interfaces de bureau par exemple n’avaient pas.

Voici les plus significatives :

• Connexion internet peu fiable
• Performances limitées
• Taille d’écran réduite
• Une utilisation possible partout et à tout moment

Ces deux derniers points vont nous intéresser particulièrement d’un point de vue de la démarche ergonomique (les deux premiers points relevant plus de la technique).

Utilisateur mobile = un doigt + un oeil

Contrairement aux utilisateurs des applications accessibles depuis un poste fixe, assis tranquillement sur leur chaise devant leur écran, les utilisateurs des applications mobiles peuvent bien souvent se trouver au travail, dans une file d’attente, au super-marché en train de faire leurs courses ou encore devant la télévision.

Ce qui signifie que dans la plupart des situations, vous n’aurez pas toute l’attention de vos utilisateurs et que ceux-ci ne seront pas en mesure d’interagir pleinement avec votre interface.

Ce constat général sur les utilisateurs mobiles, Luke Wroblewski l’a résumé dans son livre Mobile First en utilisant la métaphore suivante :
Un doigt : car l’utilisateur tiendra généralement son mobile d’une seule main et qu’il utilisera un seul doigt (surement deux dans le cas des tablettes) avec plus ou moins de précision pour interagir avec votre interface.

Un œil : car votre utilisateur pourra se trouver un peu n’importe où avec de nombreuses sources de distraction aux alentours, vous n’aurez alors qu’une attention partielle de sa part.

C’est donc la première chose à garder à l’esprit quand on conçoit une application mobile.

Les trois comportements mobiles type

Pour terminer avec ce qui caractérise les utilisateurs mobiles d’une manière générale, voici les trois comportements ou besoins mobiles que Josh Clark a identifiés dans son livre Tapworthy, avec pour chacun le conseil à suivre :

“I’m local”

• Explication : Je suis à la recherche d’une information et j’en ai besoin MAINTENANT
• Exemple :Recherche d’une station de vélib, d’une adresse, du distributeur de votre banque préférée le plus proche
• Conseil : Donner rapidement l’information, le contenu doit prendre le pas sur la navigation. Miser également sur les accélérateurs, en effet le mobile est l’écran personnel par excellence, vous pouvez alors proposer la dernière recherche effectuée, enregistrer les préférences.

Micro-tasking

• Explication : Je veux rester à la page des mises-à-jour de certaines données / j’ai besoin que quelque chose soit fait maintenant et cela ne peut pas attendre
• Exemple : Réseaux sociaux (twitter, Facebook), virement bancaire
• Conseil : Tout ce qui est du ressort de l’efficience a énormément d’importance : les utilisations étant répétées, la moindre action en trop se ressent rapidement et gêne le confort d’usage donc attention aux pages inutiles (ex. pas d’écran promotionnel intempestif)

“I’m bored”

• Explication : Je m’ennuie, je souhaite tuer le temps
• Exemple : Articles, réseaux sociaux (oui encore) et surtout les fameux petits jeux vidéos
• Conseil : Ce cas est un  peu plus flexible que les deux précédents vu que l’utilisateur n’a rien d’autre à faire. Vous pouvez donc par exemple vous permettre d’avoir une navigation plus touffue ou des écrans moins essentiels (oui de la pub si vous voulez). Cependant ce n’est pas une raison pour négliger le confort d’utilisation ou d’oublier ce que l’utilisateur est venu chercher : une source de distraction.

Voilà, si vous ne perdez pas de vue que vos utilisateurs finaux ne vous donneront qu’une attention partielle, que leur interaction avec l’interface de votre application tactile pourra être paradoxalement limitée et qu’ils s’inscriront potentiellement dans l’un de ces comportements, vous aurez déjà pas mal débroussaillé leur profil type. Pour le reste il faudra faire plus ample connaissance, à l’aide des personas par exemple.

Conseils en vrac spécifiques aux interfaces mobiles

Maintenant que vous avez identifié un peu mieux les utilisateurs de votre application mobile, place à la liste (non exhaustive) des améliorations ergonomiques possibles :

Zone de sélection

Pour les éléments interactifs de votre interface, toujours prévoir une zone de sélection suffisamment grande pour les doigts de vos utilisateurs. Attention, comme le montre cet exemple, la représentation graphique n’a pas besoin d’être aussi grande, seule la zone de sélection réelle doit l’être.

 Zone de confort / zone d’inconfort

On appelle zone de confort la partie d’une interface graphique qui est aisément atteignable par l’utilisateur.
A l’inverse, la zone d’inconfort est la partie de l’interface qui demandera à l’utilisateur un effort supplémentaire pour atteindre un point précis.
Pour les interfaces sur écran fixe, manipulées à l’aide d’une souris, la zone de confort correspond aux quatre coins et au centre de l’écran. Pour les interfaces mobiles, ces zones dépendent du format de l’écran et de son mode d’affichage. Ainsi, en mode paysage, l’utilisateur arrivera à atteindre plus facilement les parties latérales de l’interface alors qu’en mode portrait ça sera plutôt le coin inférieur gauche pour un téléphone et les coins inférieur droit et supérieur gauche pour une tablette tactile (pour un droitier).
Une fois ces différentes surfaces identifiées, il est conseillé de placer dans la zone de confort les éléments importants de votre interface, typiquement les éléments interactifs qui subiront des actions répétées et à l’inverse, on placera dans la zone d’inconfort des éléments interactifs dont l’utilisateur doit réfléchir à deux fois avant de déclencher leur action, comme un bouton de suppression par exemple.

Aspect et présentation des éléments interactifs

• Soigner l’affordance (voir mon article précédent pour la définition de ce terme) des éléments interactifs de votre interface. En effet contrairement aux interfaces web par exemple les utilisateurs ne peuvent obtenir d’indices de la part des infobulles ou du survol de leur souris sur un élément de l’interface. Ainsi au premier coup d’œil, l’utilisateur doit savoir quelles zones sont cliquables.
• Essayer au possible d’avoir un nombre réduit de boutons par écran afin d’éviter une sélection erronée à cause d’une source de distraction extérieure.
• S’assurer d’avoir un espace suffisant entre les éléments interactifs rapprochés de vos écrans afin d’empêcher une éventuelle erreur de sélection. Par exemple, dans le cas ci-dessous les boutons Annuler et Valider sont bien trop proches alors qu’ils déclenchent des actions radicalement différentes !

Exemple d’espaces insuffisants entre des boutons

• Soigner l’intitulé des boutons de navigation pour ne pas trop solliciter la mémoire de l’utilisateur. Par exemple, plutôt qu’un libellé Retour (retour vers quoi ?), il est préférable d’indiquer le nom de la partie de l’application vers laquelle l’utilisateur va revenir (par exemple Accueil).

Pour gagner de la place dans les formulaires

L’espace horizontal pouvant faire défaut sur les interfaces mobiles, il est parfois difficile de mettre en place un formulaire, voici quelques clés pour gagner de l’espace :

• Inclure l’intitulé des champs de saisie au sein du composant (intitulé qui disparaît dès que l’utilisateur saisit quelque chose) :

• Préférer une présentation verticale plutôt qu’horizontale :

• Prendre en compte la hauteur du clavier virtuel quand celui-ci est visible (environ la moitié de l’écran) et bien prendre soin de laisser visible le champ qui est en train d’être rempli pour ne pas perturber l’utilisateur.

• La saisie par un clavier virtuel pouvant s’avérer fastidieuse sur ce type d’interfaces, il est préférable de  :
  •  Réduire au minimum le nombre d’informations que l’on demande à l’utilisateur.
  • Proposer des champs de saisie pré-remplis plutôt que des champs vides.
  • Proposer des mécanismes d’aide à la saisie comme de l’auto-complétion ou encore si le champ de saisie s’attend à recevoir un nombre, directement proposer le clavier virtuel numérique à l’utilisateur.

Conclusion

Voilà ce qu’il faut retenir de cet article : pour optimiser l’ergonomie de votre application mobile vous devez :

• Plus que jamais prendre en compte comment vos utilisateurs utilisent leur mobile et pourquoi.
• Mettre l’accent sur le contenu plutôt que sur la navigation.
• Maintenir un certain niveau de clarté et de concentration.

A bientôt pour la prochaine révolution dans le monde des IHM (peut-être une interface incorporée à l’oeil ^^)

Pour comprendre ce changement, revenons sur la manière traditionnelle dont les équipes de développement codent les applications.

Le développement d’application d’entreprise de manière traditionnelle

Dans un projet classique, le développeur doit savoir

• développer une application comprenant x entités ; définir des relations entre ces entités
• afficher des sous-ensembles de données et pouvoir les mettre à jour
• implémenter et déployer une application accessible par des utilisateurs appartenant à différents rôles
• restreindre l’accès à certaines données pour des utilisateurs n’ayant pas les autorisations suffisantes
• notifier tel module si telle action est faite
• effectuer des actions de manière récurrente (tous les jours / semaines)
• rendre l’application extensible et paramétrable

Les challenges ci-dessus resteront toujours à relever. Par contre ce qui suit va probablement changer :

• installer un outil de versioning tel que git, svn.
• mettre en place un outil d’intégration continue
• configurer un serveur d’applications (tomcat, jboss)
• installer une base de données
• mettre en place un système de messaging

Je vous entends déjà : mais c’est pas aux développeurs de savoir faire ça. Pourtant dans bien des cas pour développer et tester votre application, vous devez savoir mettre en place ces outils.

Ces dernières tâches peuvent prendre beaucoup de temps : il faut trouver des machines virtuelles pour héberger les différents outils, les sauvegarder, se documenter sur la configuration, rendre accessible ces outils à tous les collaborateurs par l’intermédiaire d’un vpn ou autre. Du coup c’est moins de temps passé sur la logique métier de votre application et donc une perte de productivité.

Qu’est ce que l’on trouve dans le cloud

Il y a  trois concepts bien distincts de cloud service. Ceux qui nous intéressent en tant que développeur sont le PaaS et l’ IaaS.

Avec une solution de type Insfrastructure as a service, la création de machine virtuelle se fait à la volée. Ensuite on est libre de faire ce que l’on veut avec. On peut créer des machines virtuelles pour faire office de production, de pré-production, de recette mais également pour héberger les outils de versioning, l’intégration continue, etc…

Avec un fournisseur de services type Platform as a service, le but est d’être capable de développer et déployer des applications très rapidement et de les rendre disponibles de manière fiable. On peut par exemple partir avec AmazonWS, Google App Engine, Force.com, Windows Azure, et bien d’autres encore. Le tout étant de choisir son fournisseur en fonction des technologies que l’on va utiliser.

Un des outils fondamentaux pour le développeur est son IDE. Amazon et Google proposent des plug-in Eclipse très pratiques permettant de développer, tester et déployer des applications dans leur cloud respectif. Il existe aussi des IDEs accessibles directement depuis un navigateur internet comme Cloud IDE ou bien Cloud9 IDE. Tout comme un IDE en local, il y a la complétion syntaxique, l’intégration du gestionnaire de source mais aussi le partage de workspace, un chat afin de faciliter le travail collaboratif dans une équipe de développement. La plupart des éditeurs proposent une application en local permettant de travailler en mode offline.

Le PaaS s’inscrit parfaitement dans la stratégie “DevOps”, éliminant la frontière qui existe entre développement et exploitation. Il n’y a plus besoin de trouver et de mettre en place un environnement de test, les développeurs n’ont plus besoin d’aller voir l’équipe d’exploitation avant de lancer les campagnes de tests et grâce à l’intégration continue, les développeurs peuvent maintenant tester à mesure qu’ils développent sans perdre de temps.

Qu’elles sont les limites du cloud ?

Tout n’est pas virtualisable. En effet, des composants qui génèrent d’important I/O peuvent être bridés par la virtualisation étant donnée que l’accès aux ressources physiques n’est plus direct mais géré par un hyperviseur. Par exemple, il est préférable de ne pas virtualiser les bases de données car elles génèrent beaucoup d’I/O disque quand elles sont grandement sollicitées.

Il y a également un manque de standardisation. En effet, de nombreux fournisseurs donnent accès à des API propriétaires qui couplent une partie du code au service utilisé. Plus l’application utilise les services mis à disposition, plus la probabilité qu’elle devienne complètement dépendante de celle-ci augmente. Il faut donc faire attention à bien prendre en compte dès le début la portabilité des applications d’une plateforme à l’autre pour ne pas être coincé chez un fournisseur.

La gestion du offline peut aussi être problématique. Si toutes les données et tous les services sont en ligne, que se passe-t-il lorsqu’il n’y a plus d’accès à internet ?  Il faut penser à prévoir la possibilité de rapatrier des données en local.

Enfin, le principal reproche fait à ces services est la gestion des données. Toutes les entreprises ne sont pas prêtes à externaliser leurs données sur les serveurs d’un tiers. Cependant les solutions de cloud privé ou même hybride permettent de palier à ces problématiques.

En conclusion, on voit bien que le cloud computing va faire évoluer les challenges du développeur. De part la facilité de mise en place d’environnements de développement, de test et de production, l’amélioration du travail collaboratif, le développeur perd moins de temps dans la configuration et se concentre sur le métier et l’expérience utilisateur. De plus, les applications dans le cloud sont par définition accessibles à travers tous terminaux reliés à internet : pc, tablette et smartphone. Le développeur doit donc être capable d’interfacer les applications avec ces terminaux.

Nous pouvons distinguer deux types de requêtes reçues par nos sites web, celles demandant de la restitution d’information (GET) et celles désirant altérer l’état de l’application (POST, PUT, DELETE). D’un côté “on lit”, d’un autre “on écrit”.
Qu’est-ce que votre application fait le plus avec les données, en lire ou en écrire ?
Pour un blog par exemple, la lecture d’articles est largement plus demandée par les utilisateurs que la soumission de nouveaux articles à publier, survenant moins souvent.
Cette observation pourrait-elle influer sur la façon de coder nos applications ?

En général lorsque nous concevons une application, nous veillons soigneusement à ce que son code soit organisé quel que soit le traitement demandé, lecture ou écriture. Ainsi une requête pour afficher un article de blog manipulera certainement un objet de domaine Article dont un ou plusieurs champs seront utilisés pour afficher le contenu à lire à l’écran.
D’un autre côté lorsque l’utilisateur créera un nouvel article ce sera également ce même objet du modèle qui sera manipulé mais peut-être en utilisant d’autres champs non utilisés en lecture.
Pour quelle raison abstraire la donnée dans un objet unique si les usages sont différents ?

Le modèle d’architecture que je vous propose de découvrir est né de l’idée qu’il ne faut pas un mais plusieurs modèles pour abstraire un domaine métier complexe et que ce choix favorise la performance et la maintenance des applications. En particulier il préconise de séparer les composants de lecture de ceux d’écriture: le modèle de lecture n’est pas le même que celui utilisé pour l’écriture.

Le modèle d’architecture Command Query Responsibility Segregation (CQRS)

La définition de CQRS est plutôt simple, c’est un modèle d’architecture séparant en deux couches distinctes les traitements de restitution de données (Queries) de ceux les modifiants (Commands).

Le schéma suivant illustre la différence entre ce modèle et une architecture 3-tiers beaucoup utilisée en entreprise:

Là où les traitements de lecture et d’écriture passent par les mêmes couches sur une architecture 3-tiers, étudions ce que ça nous apporte de les séparer.

Des Queries pour restituer les données

Diagramme “Queries”

L’accès direct aux données depuis la couche de Présentation permet de récupérer, via des queries spécialisées par écran, les données à afficher et seulement celles-ci.

Le stockage se doit donc d’être dé-normalisé pour refléter au plus près le format de la donnée affichable et limiter les transformations applicatives. Des vues SQL ou une base noSQL sont par exemple tout à fait adaptées à cette utilisation.

Ce modèle de lecture est mis à jour lorsque l’état de l’application change, concrètement lorsque l’application reçoit des commandes.

Des Commandes pour modifier l’état de l’application

Diagramme “Commands”

Dans la couche domaine on maintient l’état de l’application dans une base de stockage pouvant être différente de celle utilisée par les queries, comme le montre le diagramme à droite.

Pour altérer cet état la couche présentation soumet des commandes au domaine en encapsulant le changement demandé.

Dans l’exemple ci-dessus, la commande PerformTransferCommand, qui est un simple POJO, place les trois paramètres dans un contexte propre à l’action à réaliser exprimée par le nom de la classe de commande: effectuer un transfert d’argent compte à compte. Le nom de classe est un verbe conjugué à l’impératif pour bien signaler qu’il s’agit d’un ordre donné au système pour effectuer un traitement.

L’intention utilisateur est transportée à la différence d’un appel de méthode de service où les données ne sont pas liées à un contexte particulier. Le code gagne ainsi en clarté et la maintenance est facilitée.

L’usage de la commande peut également permettre d’améliorer la réactivité de l’application. En effet si besoin est, désynchroniser le travail métier de celui de la couche présentation est facilement envisageable en rendant le command bus asynchrone sans avoir à modifier le code métier ou le controller.

Pour faciliter encore plus l’intégration des composants CQRS comme le command bus nous disposons en java du framework Axon. Celui-ci à la particularité de s’intégrer rapidement dans les projets Spring grâce au namespace axon proposé.

Ici on déclare le command bus qui sera géré comme un bean Spring et donc injectable dans tous nos controlleurs. La seconde ligne <axon:annotation-config /> active un BeanPostProcessor qui permet de configurer les command handler par annotation.

Lorsque la commande est envoyée depuis la couche présentation, un command handler la réceptionne et applique la logique métier en persistant les modifications d’états du modèle d’écriture.

Contrairement à la partie query le domaine a tout intérêt à être modélisé dans une structure normalisée (une base de données relationnelle par exemple) car il assure la cohérence de l’état de l’application.
Ce modèle utilisé pour l’écriture est donc différent de celui utilisé en lecture par les queries. Il nous reste à voir comment les deux modèles synchronisent leurs données.

Des évènements de domaine pour mettre à jour les données utilisées par les Queries

Diagramme évènements

Pour maintenir la synchronisation entre les données de lecture et l’état réel de l’application, le domaine prend la responsabilité supplémentaire d’émettre des évènements notifiant que l’état de l’application a changé. La couche d’accès aux données réceptionne alors les évènements et met à jour la base de lecture en conséquence.

Axonframework propose que les entités du domaine étendent la classe abstraite AbstractAnnotatedAggregateRoot pour bénéficier de la méthode apply() qui permet d’émettre les évènements vers la couche query:

Et l’annotation @EventHandler permet d’attraper simplement les évènements côté query afin de mettre à jour le modèle de lecture en fonction des demandes réalisées:

Lorsque beaucoup d’évènements sont générés, Axon propose un mécanisme de snapshots qui permet de grouper plusieurs évènements en un seul afin d’alléger le nombre d’échanges avec la couche de lecture.

Dans certains cas il n’est pas nécessaire de mettre à jour en temps réel les données de lecture et l’utilisation d’évènements permet de paramétrer cela facilement. Par exemple un évènement pourrait être placé dans une file d’attente et être traité à une heure où l’activité de l’application est au plus bas afin de conserver la performance de lecture en horaire de pointe.

Conclusion

Grâce à un accès rapide aux données affichables et préparées en amont de toute demande utilisateur, la force de CQRS est particulièrement révélée pour les applications dont la sollicitation en lecture est plus élevée qu’en écriture. La partie lecture pouvant être isolée dans son propre composant, elle pourrait facilement être instanciée sur plusieurs serveurs load-balancés afin d’assurer le traitement d’un nombre important de demandes d’affichage. L’architecture nous fait ainsi bénéficier d’une scalabilité horizontale intéressante et c’est cette performance que vise CQRS en premier lieu.

De par les commandes et les évènements qui enrichissent le domaine, CQRS tend agréablement à compléter l’approche Domain Driven Design et nous aide à concevoir des applications dont le code colle encore plus au métier, ce qui augmente aussi la qualité de l’application.
En effet, côté écriture, l’usage de commandes contextualisées facilite la maintenance pour réaliser des évolutions ou des correctifs. Lorsqu’une action change, l’impact est localisé sur son command handler et les contentions avec les autres actions sont faibles.

Mais malgré ses atouts le modèle CQRS reste très peu utilisé en entreprise. Son principe n’est pas aussi compliqué qu’il n’y paraît au premier abord mais il change tout de même radicalement la façon de travailler de beaucoup de développeurs habitués au modèle en couches traditionnel. Du coup l’utiliser sur un projet nécessite une certaine période d’adaptation et d’apprentissage du concept. Heureusement Axonframework aide beaucoup à faire le premier pas grâce au support qu’il apporte, surtout si vous utilisez déjà Spring sur votre projet.

Pour aller plus loin

• Stocker le modèle d’écriture dans un event store, “l’event sourcing”
• Des transactions BASE côté écriture et ACID côté lecture
• Exemple d’application DDD CQRS
• La présentation de Jérémie Chassaing à devoxx france

Avant de rentrer dans le vif du sujet, voyons quelques chiffres clés de l’événément.

Devoxx 2012 c’est :

• 3400 participants,
• un peu plus de 190 speakers,
• 188 slots dont 16 University, 24 Tools in action, 10 Labs, 25 BOF, 24 Quickies et 89 Conferences (sans compter les keynotes, code story, hackergaarten…)

Cette année seulement 6% des talks traitaient d’Android contrairement à l’an passé (2011) où l’OS représentait 9% des sujets. Un chiffre en baisse mais tout de même plus important que Devoxx France 2012 où seulement 3% des sujets concernaient Android. On espère voir davantage de bonhommes verts lors du Devoxx UK 2013, dont l’annonce a été faite lors de la keynote de bienvenue, et Devoxx France 2013.

Conférences

Au total, 11 slots étaient consacrés à Android : 2 BOF, 3 Tools in Action, 1 University, 1 Labs et 4 Conférences. Les talks étaient principalement animés par des googlers dont Richard Hyndman, Nick Butcher, Xavier Ducrohet ou encore Romain Guy et Chet Haase…

Le duo de choc : Romain Guy et Chet Haase

Vous avez probablement déjà entendu parler de Romain Guy et de Chet Haase. Ils font tous deux partie chez Google de l’équipe en charge de l’UI toolkit d’Android. Leurs talks sont toujours très agréables à suivre et très intéressants.
Ils nous ont proposé 3 talks au total pour ce Devoxx, 2 techniques et un plus orienté marketing avec présentation du smartphone Nexus 4, de la tablette Nexus 10 et des nouveautés de la version 4.2 d’Android, qu’ils ont d’ailleurs officiellement sortie pendant l’événement.
L’un des 2 talks techniques n’était autre que “For butter and worse” qu’ils avaient déjà présenté lors du Google I/O en avril dernier, durant laquelle ils présentent les améliorations et optimisations qu’ils ont apportées à l’UI pour qu’elle soit plus réactive et plus fluide dans la version 4.1 (Jelly Bean) de l’OS. Ils exposent également des bonnes pratiques à respecter pour garder une application aussi fluide que possible et les outils utiles au débuggage de l’UI. La présentation du Google I/O est d’ores et déjà disponible. Pour la version Devoxx, il va falloir attendre encore un peu.

Open sourcez vos projets!

C’est l’un des messages que Jake Wharton, créateur d’ActionBarSherlock et développeur chez Square*, a essayé de faire passer lors de sa conférence “Bootstrapping Android Apps with open source”.

Il nous a fait part d’un très grand nombre de librairies open source sur lesquelles Square s’est appuyé pour développer leur(s) application(s) et qui ont, pour la majeure partie, été développées par leurs soins.

Voici la liste des librairies en question :

• ActionBarSherlock : rétro-compatibilité de l’action bar apparue avec la version 3.0 (Honeycomb)
• NineOldAndroids : rétro-compatibilité de l’API d’animation apparue avec Honeycomb,
• Retrofit : client REST type-safe pour Android et Java,
• Tape :  une FIFO basée sur les fichiers pour Android et Java,
• Dagger : système d’injection de dépendances pour Android et Java,
• Roboelectric : exécutait les tests unitaires sur votre JVM pour gagner du temps,
• Robotium : tests d’intégration à la Selenium,
• ViewPagerIndicator, OkHttp, Pollexor, MockWebServer, PonyCrossing, Fest, Mockito, Spoon (pas encore disponible mais qui permettrait de faciliter l’exécution des tests d’intégration).

*Square propose un système de paiement par carte à partir d’un smartphone.

Diet Driven Development avec AndroidAnnotations

Ce n’est pas en spectacteur mais en speaker que j’ai pu participer à ce “Tools in action” consacré à AndroidAnnotations. Avec Pierre-Yves Ricau avons construit le talk autour de 2 parties, la première était consacrée à la présentation du projet et les motivations de sa création et la deuxième à un live refactoring d’une application existante à la façon AndroidAnnotations. Vous trouverez le code source de l’application refactorée sur github.

Rendez-vous sur Parleys

Toutes les vidéos des talks seront disponibles sur Parleys, vous pourrez ainsi les (re)voir. Il va tout de même falloir être patient car les vidéos sont rarement disponibles avant 1,5 ou 2 mois après l’événement. En attendant, vous pouvez toujours aller jeter un oeil aux interviews des “googlers” dont celle de Chet Haase et Romain Guy enregistrée lors de l’évenement.

Credit photo : dotJs

Dès l’introduction, nous avons été prévenus que le dotJs n’était pas une simple conférence technique mais que celle-ci s’apparentait plus au style des conférences TED où la transmission d’idée et de passion prime sur la technique. Cela s’est vérifié dans l’après midi car la matinée fut assez technique pour le plus grand bonheur des développeurs présents.

Je vais à présent revenir sur les présentations qui m’ont le plus marqué.

Addy Osmani –  Chrome développeur relation pour Google.

La présentation à débuté par une démonstration des outils disponibles  dans Google Chrome pour faciliter le développement d’application web à travers une étude de cas d’optimisation d’un site web. Malgré les bonnes idées et techniques pour trouver de potentielles fuites mémoires et fluidifier le rendu des pages, j’ai été un peu déçu car cela correspondait exactement à une excellente présentation de Patrick Dubroy déjà disponible ici.

Le temps passé sur cette première partie, ainsi que les problèmes de wifi ralentissant la démonstration, n’ont laissé que très peu de temps pour présenter l’outil Yeoman dont il est le créateur.

Yeoman est un outil qui peut notamment:

• ‘scaffolder’ rapidement une application moderne avec HTML5BP, TwitterBootstrap…
• gérer les dépendances externes pour en finir avec le copier coller manuel.
• compiler automatiquement Coffeescript et Compass

Pour plus d’information, voir le site officiel de Yeoman ainsi que l’excellent blog de Addy Osmani.

Jeremy Ashkenas - Créateur de Backbone.js,Underscore.js & CoffeeScript

Jeremy Ashkenas a parlé des langages symbiotiques, sujet qu’il connait parfaitement en tant que créateur de CoffeeScript. Un langage symbiotique peut être défini comme un langage étant “compilé” sous forme de code source d’un autre langage, donc dans le cas du CoffeeScript vers le javascript.

Cependant, dans le cas du CoffeeScript on parle plus de “transpiling” que de compilation car le CoffeeScript reste très proche du javascript et en conserve la sémantique. Une liste plutôt exhaustive des langages compilés/transpilés vers javascript est disponible sur le wiki de Coffeescript ici. De nombreux projets récents comme Dart de Google ou encore TypeScript de Microsoft tentent de construire des langages de plus haut niveau dont la syntaxe et la sémantique s’éloignent du javascript et sont plutôt prometteurs.

Jeremy termine sa présentation par une remarque intéressante à garder en tête lors de l’utilisation de langages symbiotiques, ceux-ci ont deux audiences. Le code généré pour la plateforme cible, ici le javascript, n’est pas seulement destiné à une machine. En effet il doit aussi pouvoir être compris par un développeur javascript.

Brian Leroux – Membre de l’équipe PhoneGap

Une fois de plus, Brian Leroux à mis en lumière les bizarries du langage Javascript dans une présentation pleine d’humour. Retrouvez ici les assertions que Brian Leroux à présentées et testez les vous même dans votre console javascript.

Pour les faineants, voici quelques une de mes bizarreries préférés:

A propos des opérations sur les nombres décimaux

Les associations String – Number

Sans oublier les tableaux

Vojta Jína – Membre de l’équipe AngularJS et créateur de Testacular

La plupart des spectateurs attendait une présentation technique sur Angular.js ou encore sur Testacular. Mais Vojta Jina à décidé de présenter trois grands développeurs pour nous montrer comment nous pouvons nous en inspirer pour réaliser nos projets.

A travers l’histoire de Ryan Dahl (créateur de NodeJs), John Resig (créateur de Jquery) et Dennis Ritchie (créateur de Unix et du C), Vojta Jina à dégagé trois idées importantes:

• réutiliser l’existant en assemblant et en s’inspirant du travail des autres.
• résoudre ses propres problèmes d’abord car il y a de grandes chances qu’ils soient partagés par d’autres personnes.
• et bien sur le classique: être passionné.

Jacob Thornton (fat) – Co-createur de Twitter Bootstrap

Jacob Thornton à lui aussi décidé de ne pas faire de présentation technique mais à décidé de retracer avec beaucoup d’humour l’histoire de l’Open Source. De Richard Stallman à Linus Torvald, Jacob finit par introduire un nouveau concept issue de son expérience personnelle avec les projets Open Source.

“The cute puppy syndrome”

Le “syndrome du chiot mignon” pour les francophones, correspond à la sensation que l’on a au début de chaque projet: on aime travailler sur son projet, d’autres personnes s’y investissent également, tout se passe bien. Mais au bout d’un certain temps, ce petit projet mignon se transforme en énorme Saint-Bernard projet dont il faut prendre soin constamment. Il devient envahissant en terme de temps passé à faire du support, correction de bugs …

On a soudain l’envie d’abandonner son gros projet à quelqu’un d’autre et d’adopter un nouveau petit chiot. Je vous laisse réfléchir sur cette métaphore canine et je précise que je ne cautionne pas les abandons d’animaux

Cette présentation au format One-man show est arrivée à point nommé en cloture d’une longue journée riche en apprentissage.

Pour conclure cette article, bien que j’aurais aimé davantage de présentations techniques, le DotJs a tenu toutes ses promesses et je remercie toute l’équipe pour son organisation. Pour info, suite au succès de cette année une nouvelle édition sera organisée en 2013.

Toutes les photos de la journée sont disponibles. http://svay.com/photos/2012-11-30_dotjs/