mercredi 29 avril 2009

Première session le 13 mai sur Java EE 6

Première session le 13 mai sur Java EE 6

Nous avons le plaisir de vous annoncer que la première session du Ch’ti JUG est prévue le 13 mai. Elle aura lieu à 18h30 aux Salons du Pont Neuf à Lille (cliquer ici pour un plan d’accès)

proxiadCette session est rendue possible grâce à la société ProxiAD Nord.

Le thème de cette session sera : “Java EE 6, qu’est-ce qui nous attend ?

J2EE 1.4, Java EE 5 et bientôt Java EE 6. L’année 2009 coïncide avec la sortie de la nouvelle version de l’Enterprise Edition et de son 10e anniversaire. Mais le J2EE de l’époque ressemble-t-il encore au Java EE d’aujourd’hui? Dans cette session, Antonio Goncalves vous présentera les nouveautés Java EE 6 : un modèle de programmation centré sur les EJBs, un packaging simplifié, une couche de persistance enrichie, une nouvelle API pour les ressources REST, une simplification radicale de la couche web, et bien d’autres améliorations qui feront de Java EE 6 la plateforme idéale pour vos applications. Basé sur des standards, s’inspirant de framemeworks open source, utilisant les conteneurs léger, Java EE 6 allie standards, robustesse et solutions éprouvées.

Architecte senior, Antonio Goncalves intervient chez ses clients comme consultant et formateur. Ancien consultant Weblogic chez BEA Systems, il s’est spécialisé depuis 1998 dans l’architecture logicielle et les technologies Java. Antonio est l’auteur du livre Java EE 5 aux éditions Eyrolles ainsi que le livre Beginning Java EE 6 Platform with GlassFish 3 édité chez APress. Il est membre du JCP et intervient sur les JSR 316 (Java EE 6), JSR 317 (JPA 2.0) et JSR 318 (EJB 3.1). Il enseigne également la plate-forme Java EE au Conservatoire National des Arts et Métiers. Il est rédacteur technique pour les sites DevX et developpez.com. Antonio est co-fondateur et co-responsable du Paris Java User Group.

Pour assister à cette session, merci de vous inscrire rapidement car les places sont limitées !

bouton-inscription1







A très bientôt !

Cyril et Julien

mardi 14 avril 2009

GWT feedback from an Eclipse RCP developer // Retour d'expérience GWT d'un développeur Eclipse RCP

GWT a été utilisé sur le projet XYZ pendant plus de 6 mois et c'est une première pour le pôle édition de logiciel de mon client: un retour d'expérience s'impose.

GWT : La réponse à l'expression des besoins

Le besoin

  1. Faire une application Web ergonomique
  2. Être isofonctionnel avec l'application à refondre (= client riche Eclipse RCP + Serveur)
  3. Réutiliser les services existants
  4. Puis, ajouter des fonctionnalités majeures (notion magasin, refonte éditions, etc...)

Les atouts de GWT

GWT c'est la possibilité d'écrire des applications "AJAX Web 2.0 new age technologies" mais sans écrire de Javascript ! On réalise uniquement du code JAVA qui ensuite est compilé et optimisé en Javascript.

  • Développement
    • On écrit du code Java, puis on peut voir les changements immédiatement sans recompiler (hosted mode + refresh)
    • On peut mettre des points d'arrêt sur du code AJAX dans le debugger Java
    • On compile et déploie du "Compiled and deploy optimized, cross-browser JavaScript"
  • Fonctionnalités
    • Communication avec le server via un système RPC simple ou via JSON, XML ou requête HTTP simple (soumission de formulaire)
    • Optimisation du javascript téléchargé par les utilisateurs en fonction de leur profil (langue + navigateur)
    • Réutilisation des composants graphique sur différentes application en découpant par module les différentes briques
    • Possibilité d'utiliser d'autres librairies Javascript ou de coder du javascript directement
    • Support simple de l'historique du navigateur avec les boutons précédant, suivant
    • Gestion efficace de la localisation et de l'internationalisation
    • Un choix productif d'outils de developpements (Eclipse, Netbeans, Intelli )
    • Teste du code avec JUnit
    • Possibilité d'étendre et contribuer à Google Web Toolkit qui est open source

Le choix de la librairie graphique

GWT seul permet de mettre en œuvre des application de type client riche mais pas de manière productive.

En effet, la gallery de widgets parle d'elle même. Il manque cruellement de composants graphiques de haut niveau pour réaliser des applications d'entreprise. Ce manque est en passe d'être comblé (prévu pour fin 2009 avec GWT 2.0) mais en attendant il faut faire sans.

Il faut donc se tourner vers des librairies tierces qui sont assimilées à une "surcouche" graphique. Il en existe 3 majeures:

  • GWT-EXT (celle qui a été retenue)
  • EXT-GWT ou GXT (payante pour des projets non libres, gratuite pour les projets open-source)
  • smartGWT (pas assez mature au moment du choix, et maintenant ?)

Après 6 mois d'utilisation, même si il existe certains points de blocage avec la librairie GWT-EXT, on peut affirmer qu'elle a rempli pleinement son rôle:

  • Apporter des composants graphiques de hauts niveaux
    • Tableaux avec colonnes, tri, regroupement etc.
    • Arbres avec drag & drop
  • Validation de formulaire
  • Classes de facilitant graphiques
  • Apporter un style graphique (CSS) d'entreprise pour l'application
  • etc...

De plus, GWT-EXT met à disposition d'une bibliothèque d'exemple très pratique :

  • Pour choisir les composants graphiques lors de la conception
  • Pour trouver des exemples de codes lors du développement

Par contre, après 6 mois d'utilisation, le projet GWT-EXT a été figé par l'équipe des développements et seul des corrections seront prises en charge. Le responsable du projet a changé d'équipe ainsi que de projet pour créer smartGWT qui est à présent assez mature pour réaliser ce type d'application. Ce qui n'était pas le cas en octobre 2008, date de début du projet. La release 1.0 de smartGWT n'est pas encore d'actualité en mars 2009 puisque le produit est encore en beta. Il faudra peut être prévoir une tache de refonte de la couche graphique avec un nouveau framework (smartGWT ou GXT ?).

La montée en compétence rapide

Après seulement quelques jours de lecture et de suivi d'articles et tutoriels en tout genre sur GWT, on est à même de mettre en place une application à condition d'avoir déjà une expérience significative en développement Java EE.

Les principaux atouts qui facilitent la vie avec GWT :

  • Code 100% JAVA
  • Très peu de CSS
  • Presque pas de javascript
  • Une configuration simple
    • A comprendre
    • A maintenir
  • Une ouverture de la solution à l'existant en entreprise (intégration de ACEGI, des services existants, etc...)

Comme rien n'est parfait, voici quelques points bloquants lors du développement :

  • Impossibilité de debugger directement dans un navigateur (obligation d'utiliser le hosted mode)
    • Cette fonctionnalité sera implémentée dans GWT 2.0
  • Limitation du composant graphique des arborescences multi colonnes (GWT-EXT ColumnTree)
  • Aucun cadre de développement ou presque... Vous avez la parole ! Pas si simple...
  • To be continued...

La mise en place de pattern techniques

GWT n'impose rien d'autre qu'une classe servant de point de départ pour la construction de l'application. On peut choisir de composer son application dans le plus grand n'importe quoi ou d'agencer le code pour faciliter la maintenabilité et la pérennité... au choix !

Les actions et commandes

GWT apporte la possibilité de gérer l'événementiel de l'application mais rien n'est prévu pour déléguer et mutualiser le code au sein de classe spécifiques en charge de réaliser des taches. On retrouve ce type de pattern dans les applications Eclipse RCP: les actions et les commandes.

Pour combler ce vide, des classes et interfaces ont été implémentées. Elles sont simples et permettent de cadrer les développements afin de mettre en place une façon de faire qui est réutilisée dans toute l'application.

Les actions étendent une interface et implémentent une méthode execute().

Les commandes sont associées à un gestionnaire de commandes qui permet de déclencher une tache à partir de son identifiant et d'un tableau de paramètre si besoin. Elles nécessitent d'être enregistrée dans le gestionnaire de commande au démarrage de l'application.

Cette façon de faire à été récupérée de la façon de faire Eclipse. Après coup, la notion de commandes devrait être supprimée pour ne laisser que des actions et ainsi simplifier le travail du développeur.

Un exemple d'action:

public class TestAction implements IAction {
public Object execute() {
MessageBox.alert("This is a test message");
return null;
}
}

Les vues et éditeurs

Les notions de vues et d'éditeurs présentes dans Eclipse n'existent pas dans GWT. Même si cela donne beaucoup de liberté, encore une fois cela ne donne pas de cadre au développement ce qui peut être gênant quand on créé des applications d'entreprises que l'on souhaitent faire reposer sur un socle de développement stable.

Il faut donc s'improviser créateur de framework graphique pour cette partie, ce qui n'est pas bien difficile si on ne fait que ce dont on a besoin. Pas besoin de coder l'équivalent de JFace pour GWT.

Il faut un peu de bon sens et unifier la façon de faire afin de ne pas s'y perdre par la suite.

Le modèle MVC

Il n'existe pas de pattern pour implémenter une application selon les bonnes pratiques du MVC, il faut encore une fois cadrer soit même ce développement. Pour faciliter la maintenance et la compréhension de l'application, il est préconisé de dissocier le modèle, de la vue et du contrôleur. Le modèle représente l'entité correspondant à l'écran, la vue correspond à la couche uniquement graphique de l'écran et le contrôleur est le gestionnaire qui fait office d'interface de contrôle des données.

A chaque module graphique a été associé un contrôleur, le but est de dissocier totalement la couche purement graphique de position des composants (label, text, liste, combo...) de la couche de contrôle en charge des interactions, du chargement des données, de la partie événementielle, de la synchronisation etc...

Les contrôleurs doivent étendre une classe paramétrée qui les forcent à implémenter une méthode d'initialisation de la couche graphique ainsi qu'une méthode de récupération de la couche graphique associée:

public class TestControler extends MyControler {
private TestUI testUI;
private TestBean testBean;
public void init() {
testUI = new TestUI();
testUI.getTestComponent().setValue(testBean.getTestProperty());
...
}
public TestUI getUI() {
return testUI;
}
}

Le modèle n'a pas d'implémentation particulière, nous utilisons directement les entités métiers (les beans) au sein du contrôleur.

La gestion du dirty

De la même façon que pour le reste, il n'existe pas de gestion du dirty des différentes entités au cours de leur édition. Le dirty permet de connaitre l'état de synchronisation d'un objet par rapport à un référentiel. Soit on gère le dirty par rapport au modèle soit par rapport à la base de données, et nous avons choisi cette dernière possibilité.

Le but est simplement d'indiquer graphiquement les modifications réalisées par l'utilisateur qui ne sont pas synchrones avec la base de données; quand la sauvegarde n'a pas encore été effectuée.

Pour gérer le dirty, nous n'avons pas non plus créé de framework. Mais un développement spécifique à du être mis en œuvre pour gérer cette problématique. Il n'est donc pas réutilisable.

Le databinding

Le databinding n'existe pas nativement dans GWT. En comparaison avec Eclipse RCP, c'est un manque.

Nous avons du gérer manuellement/programatiquement la synchronisation entre la couche graphique et le modèle métier.

Les limitations rencontrées

  • Problèmes de fuites mémoires avec Internet Explorer
  • To be continued

Un bilan positif

GWT est simple a prendre en main mais il faut être PRAGMATIQUE ! Les développeurs sont totalement libres de faire ce qu'ils souhaitent. Comme rien n'est proposé et que tout est à faire, on peut se laisser tenter par l'implémentation de frameworks techniques sur les différents points de manque. Mais nous ne sommes pas des frameworkers. Notre métier c'est faire des applications répondant à un besoin métier pour un contexte donné.

Un autre bilan se dessine de lui même: Le résultat ! L'application fonctionne et les utilisateurs sont satisfaits !

mardi 7 avril 2009

Retour d'expérience sur Scrum

XYZ et SCRUM : Duo de choc

Le projet XYZ est un des projets pionnier dans l'application des méthodologies agiles au sein du pôle édition de logiciel de la DSI de mon client actuel et pour cette raison un retour d'expérience était nécessaire, d'où la création de cet article issu d'une page similaire présente sur le wiki.


Notre vision de SCRUM

Mais qu'est ce que SCRUM ?

Scrum propose une façon d'appréhender la gestion de projet qui change radicalement par rapport à certaines formes de gestion de projet dites classiques (ex: cycle de développement en cascade sans itérations).

  • Ce qu'il faut retenir:
    • On favorisera les personnes et la communication plutôt que les outils et les processus.
    • On mettra en avant un produit opérationnel plutôt qu'avoir une documentation "trop" complète.
    • On préférera la négociation avec le client que de graver dans le marbre une expression du besoin qui évolue avec le temps.
    • On choisira d'être flexible plutôt que rigide et se tenir uniquement au plan initial.

Ce que l'on garde, ce que l'on ne garde pas

Ce que l'on garde :

  • Les principaux généraux (vu ci-dessus : Itérations, Livraisons, Agilité)
  • Un Scrum Master
  • Une équipe auto-gérée
  • Des intervenants ponctuels (audit de code, audit fonctionnelle, consultation, etc.)
  • Le Product Backlog (liste des fonctionnalités du produit et Sprint Backlog (liste des fonctionnalités d'un sprint)
  • Le Sprint Review (rétrospective du sprint)
  • Le Sprint Planning (plannification du prochain sprint)

Ce que l'on ne garde pas :

  • Scrum meeting ou Daily Scrum : L'équipe projet se composant de 3 personnes et étant dans le même bureau, il n'y a pas de réunion spécifique organisée. Nous travaillons au quotidien ensemble et nous connaissons donc parfaitement les taches de chacun.
  • Sprint Review => présentation du produit : La présentation du produit à l'équipe et aux utilisateurs n'est pas réalisée à chaque sprint. Nous avons préféré la mise à disposition du logiciel sur une plateforme via l'envoi d'un mail pour les informer. L'équipe maitrisant l'ensemble des fonctionnalités de l'application.
  • Burndown Chart

Notre application de SCRUM

Le produit est découpé en fonctionnalités (Backlog Produit).

On regroupe ces fonctionnalités au sein de Release prédéfinie.

Afin de réaliser les release, on effectue des sprints de 15 jours (modulable si besoin).

Chaque sprint contient des fonctionnalités à réaliser puisés au sein du Backlog Produit de la Release courante.

Entre chaque sprint a lieu le Sprint Review ainsi que le Sprint Planning
Le Sprint Review :

  • le bon fonctionnement des fonctionnalités du sprint est vérifié.
  • l'équipe liste les évènements marquants du sprint précédent et décide de mener des actions si besoin (le but étant de s'améliorer à chaque sprint)

Le Sprint Planning :

  • l'équipe décide de la communication à effectuer pour ce sprint (envoi de mail aux équipes utilisatrices avec les fonctionnalités et faits marquants retenus)
  • l'équipe découpe les fonctionnalités sélectionnés dans le backlog en taches à réaliser de 0 à 1,5 jours pour le prochain sprint. Il existe une notion de priorisation sur les taches :
    • hautes : à faire en priorité
    • normales
    • faibles.

Remarques : Le Sprint Planning est à préparer : une analyse générale des fonctionnalités du prochain sprint doit être effectuée au préalable.

Les outils de gestion de projet utilisé

L'outil principal est un fichier Excel :

  • une feuille pour la Backlog Produit
  • une feuille pour le suivi des taches à réaliser
  • une feuille pour les faits marquants de chaque sprint.

SCRUM, le bilan

Le bilan est très positif : on a une vision des fonctionnalités très rapidement (a chaque fin de sprint).

L'effet tunnel est incompatible avec cette méthodologie.

Cela nous permet de toujours vérifier l'utilisabilité de chaque fonctionnalité.

SCRUM ne diminue pas la charge du projet mais améliore la qualité du produit développé.

Des charges de recette et de correction du bugs sont à prendre en compte lors de chaque sprint.

Le client final a plus de chance d'être satisfait du produit développé par rapport à une méthode classique ou on lui livre une version au bout de X mois.

Ce qui nous a manqué

  • Le calcul de la vélocité de chaque sprint

cela permet de voir l'amélioration de l'efficacité de l'équipe.

Il s'agit d'un graphique qui représente l'état d'avancement du projet ainsi que le reste à faire. Il donne une bonne idée sur le respect de la date prévue de livraison.

  • Un tableau afin de pouvoir échanger autour de celui ci.

Ce qui ne nous a pas manqué

  • L'utilisation de post it pour gérer l'état des taches à réaliser. Avec seulement 3 membres au sein de l'équipe, le manque de cet outil ne s'est pas fait ressentir, peut être à tort.

Les perspectives

Maintenant que SCRUM a été éprouvé sur un petit projet avec une petite équipe et que les résultats sont très positifs, il serait opportun de profiter de cet élan pour appliquer cette méthodologie sur d'autres projets avec d'autres équipes et ainsi répandre la culture agile au plus grand nombre.

Par exemple, un projet pilote de taille moyen avec une équipe de 4 ou 5 personnes serait un candidat idéal pour continuer dans ce sens.

En parallèle, gérer des projets SCRUM d'envergure (>10 personnes et >1 équipe) n'étant pas chose aisée, il serait bon de s'armer comme il se doit avant de se lancer dans une telle entreprise. Des formations ou des interventions réalisées par des experts de la méthodologies (Scrum Master) favoriseraient la réussite de projets plus conséquents.


Nos points de vues de SCRUM

Le point du vue du "chef de projet":

SCRUM associe l'ensemble de l'équipe autour du projet, chaque sprint est compris par l'équipe et l'ensemble du baklog produit est connu de tout le monde.

Ce qui n'est pas le cas dans des méthodes classiques ou le développeur ne connait pas toujours ce que ces petits copains réalisent.

SCRUM permet d'avoir une meilleure vision du reste à faire, on connait ce qui a été développé et on connait le backlog produit non réalisé.

SCRUM permet une souplesse dans le sens ou la modification de fonctionnalités (en dehors du sprint courant) est possible avec très peu d'impact.

Le point de vue du "développeur":

Cette méthodologie est déroutante car elle remet en cause nombre de pratiques généralement constatées avec des méthodologies classiques, elle place l'équipe plus au centre du projet ce qui valorise le travail de chacun.

Les membres de l'équipe ont leur mot à dire et on attend d'eux qu'ils soient critiques et constructifs. Les choix qu'ils font engage leur responsabilité et le bon déroulant du sprint en cours, ceci entraine un engagement de chacun et améliore donc l'investissement de l'équipe.

SCRUM ne permet pas de réduire les charges mais améliore la qualité du produit livré au plus tôt grâce à la souplesse de la mise en œuvre et aux retours rapides des utilisateurs.