Revue de Presse Xebia

Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Agilité

RIA

Le coin de la technique

Agilité

Brûlez des Stories, pas des Tâches

Beaucoup d’équipes Scrum sont habituées à décomposer les User Stories en tâches pour faciliter la répartition du travail dans l’équipe. Mais les problèmes arrivent dès lors qu’elles essaient d’estimer ces tâches (souvent en heures) et de les suivre.
Ron Jeffries suggère de ne pas utiliser de tâches. Il recommande d’utiliser les stories comme unité. Cela suppose que les stories soient suffisamment petites.

Chris Sims rappelle sur InfoQ quelques critères pour définir une bonne user story, que l’on retrouve dans le modèle INVEST (Independant Negotiable Valuable Estimable Small Testable).
Une story peut donc être réalisée par un seul développeur à condition qu’il ait les compétences pour la réaliser de bout en bout. Si votre équipe est spécialisée, vous pouvez y remédier à coup de pair programming.

Kelly Waters souligne que le sprint planning est allégé puisqu’il n’y a plus l’étape de décomposition en tâches.

Ron recommande également de suivre uniquement les stories sur le Burndown chart. Brûler les tâches donne l’impression d’avancer mais potentiellement aucune fonctionnalité ne sera livrable à la fin du sprint. Restez concentrés sur des fonctionnalités livrables, en vous aidant d’une bonne définition de terminé.

RIA

GraniteDS en version 1.2.0 GA

Une nouvelle version de Granite Data Services ou GraniteDS (solution serveur JEE pour le développement et le déploiement des applications Adobe Flex) est sortie avec de nouveaux supports pour :

  • TopLink (Intégré dans GlassFish V2, Sun AS et Oracle AS).
  • EclipseLink (Implémentation de référence pour JPA 2.0, intégré dans GlassFish V3).
  • GlassFish (Un service de sécurité spécifique basé le service de sécurité de Tomcat).

La prochaine version de GraniteDS fournira un support d’OpenJPA et de JPOX/DataNucleus. Elle fournira également un service de sécurité spécifique pour les serveurs d’applications WebLogic. Toutefois avec la prochaine version vous aurez la possibilité de déployer la totalité de vos applications Flex/GraniteDS sur les serveurs d’applications WebLogic.

Pour voir la liste complète des nouveautés, rendez-vous sur le post suivant.

Pour se procurer gratuitement GraniteDs 1.2.0 GA, cela se passe ici.

Sortie du framework JavaScript JQuery 1.3

L’équipe de jQuery, un des frameworks JavaScript le plus en vogue aujourd’hui, annonce la sortie d’une nouvelle version : jQuery 1.3 and the jQuery Foundation.

JQuery est un framework JavaScript extensible. Il permet de manipuler plus simplement et de manière plus portable (d’un navigateur à un autre) le JavaScript. Il apporte une syntaxe élégante et légère pour la manipulation d’un document HTML d’un navigateur (arbre DOM et évènements).

Il apporte de base :

  • un modèle d’événement (pression d’une touche du clavier, clic de souris, etc)
  • un sélectionneur de noeud dans l’arbre DOM
  • des routines pour le développement Ajax
  • des routines d’animation graphique

La communauté jQuery est très active et elle développe de nombreux plugins JQuery, de la fonction JavaScript utilitaire au composant graphique riche, comme par exemple :

La version 1.3 met à disposition différentes mises à jours:

Voici quelques exemples qui illustrent les capacités de JQuery :

// A la fin de chargement de l'arbre DOM par le navigateur
$(document).ready(function() {
// Attachement d'une fonction lors d'un clique à toutes les ancres
// (balise ) qui ont une classe CSS nommée "external"
$("a.external").click(function() {
alert("clic sur une ancre de style external");
});
});

Ainsi avec cet exemple tous les liens avec le style « external » dès qu’ils seront cliqués afficheront un message d’alerte.

Voici un exemple d’appel Ajax :

$.ajax({
type: "GET",
url: 'http://host.com/page.html',
success: function(content) {
// content est un parametre qui contient le code HTML de la page à l'url http://host.com/page.html
$("#content").html(content);
},
error: function() {
logInPage('Erreur de chargement Ajax de la page : http://host.com/page.html');
}
});

Le code $("#content") signifie que l’on sélectionne la balise avec l’identifiant content. La fonction html(« <a href...« ) signifie que l’on met dans la balise le code html en paramètre.

Ainsi si vous avez initialement dans votre page <div id="content">en cours de chargement ...</div>, après l’appel Ajax, le contenu de la page sera <div id="content"><h1>Titre1<h1>...</div> (où <h1>Titre1<h1>... est le contenu de la page à l’url http://host.com/page.html).

JQuery est un excellent framework, notamment grâce à une syntaxe bien pensée, mais qui exige quand même un certain coût d’entrée. Cependant, les exemples à disposition sont nombreux. De quoi réconcilier un certain nombre de développeurs Java avec le développement Web/Javascript.

Solution ORM en Javascript : Active Record JS

La société Aptana annonce la première version de Active Record qui permet d’utiliser une solution de mapping objet/relationnel (ORM) en Javascript en utilisant différents connecteurs :

Ce framework met en œuvre le pattern du même nom. Le pattern Active Record est un pattern souvent utilisé dans les frameworks Rails comme RubyOnRails, Django (Python) ou Grails (Groovy). C’est une approche pour lire les données d’une DB. Les attributs d’une table ou d’une vue sont encapsulés dans une classe.

Voici quelques opérations élémentaires qui peuvent être réalisées avec ActiveRecord JS :

// Connection en memoire (sans base de donnees)
ActiveRecord.connect(ActiveRecord.Adapters.InMemory);

// Creation du schema
ActiveRecord.execute('CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, ...

// Creation d'une entite
var jessica = User.create({
username: 'Jessica',
password: 'rabbit'
});

// Sauvegarde
jessica.save(); // ou jessica.synchronize()

// Recherche
User.findByUsername('Jessica');

Cependant ce n’est qu’une version béta, quelques problèmes d’implémentation subsistant, en particulier pour Internet Explorer.

Avec un tel framework, le client (navigateur) pourra fonctionner de manière plus détachée du serveur. D’une part, le client gèrera ses données propres indépendamment du serveur. D’autre part le client pourra sauvegarder et restaurer des informations dans le but de se re-synchroniser avec le serveur. Le client pourra gérer plus de traitement sans être lié au serveur, en quelque sorte en mode hors ligne (« offline »).

Pour plus d’informations vous pouvez consulter la page d’Active Record JS

Servlet 3.0 : une API innovante et convergente ?

L’API Servlet 3.0 vient de franchir le Public Review Ballot et nous pouvons aujourd’hui voir l’ampleur des innovations qu’apporte cette version. Les promesses de cette JSR concernaient principalement les applications RIA (introduction d’un mode asynchrone/comet) et l’intégration des frameworks web (accès programmatique à l’enregistrement des servlets et des filtres ou encore à la gestion des login et logout).
Si le manque de maturité des modes asynchrone et Comet pouvait rendre délicat leur standardisation, l’intégration des frameworks web semblait plus aisée étant donnée la longue expérience du monde Java sur ce sujet.

Hélas, on peut douter que Servlet 3.0 améliore réellement l’intégration de frameworks populaires comme SpringMVC, Struts2 ou encore Wicket. Cette pluggability passe d’abord par la possibilité de brancher un conteneur externe (comme Spring Framework ou Google Guice) pour instancier les composants de l’application (y compris les Servlet, les Filter et les ServletContextListener). Servlet 3.0 aurait pu mettre fin au monopole des conteneurs de servlets pour gérer le cycle de vie de ces composants, en introduisant une API de Service Provider Interface, qui permettrait d’utiliser un conteneur externe. Ces SPI sont fréquentes dans les API Java (cf JSF FactoryFinder, JAX-WS Provider, etc) et ont fait leurs preuves dans les frameworks web (Struts2 ObjectFactory, Wicket IWebApplicationFactory, etc).

A la place, Servlet 3.0 introduit un nouveau conteneur d’objets qui, s’il reprend les annotations standard @EJB, @Resource, @PersistenceContext, etc , n’en reste pas moins différent des déjà standards conteneur EJB, conteneur EJB Lite 3.1, conteneur de Managed Bean JSF ou encore du très probable conteneur de Web Beans.

L’enregistrement programmatique des Servlet et Filter (ServletContext#addServlet(...) et ServletContext#addFilter(...)) n’assouplit pas le monopole du conteneur de servlet sur le cycle de vie des Servlet et Filter : on enregistre les composants par leur nom de classe et le conteneur de servlet se charge de les instancier.

Par ailleurs, les annotations Servlet 3.0 (@WebServlet, @ServletFilter, @GET, etc), en plus de ne mutualiser ni le code, ni les concepts équivalents du très récent JAX-RS ( @Path , GET, etc), ont été beaucoup moins ambitieuses puisqu’on ne retrouve pas les QueryParam, PathParam, etc. de JAX-RS, qui existent pourtant depuis bien longtemps dans nos framework Web MVC (cf. Spring MVC @WebParam).

Ces limitations de la pluggability des frameworks web de Servlet 3.0 restreignent les perspectives de standardisation des frameworks web autres que JSF, pourtant si controversé :-( .

En revanche, petit rayon de soleil, le support des modes asynchrone/Comet dans Servlet 3.0 semble satisfaire les projets innovants en la matière même s’ils vont sensiblement plus loin que la nouvelle API startAsync() (cf Grizzly and the New Atmosphere Comet Framework: Q&A with Project Lead Jean-Francois Arcand]).

Le coin de la technique

Sortie de FEST-Swing 1.0

Alex Ruiz nous informe sur son blog de la sortie de FEST-Swing en version 1.0.

Pour rappel FEST-Swing, tout comme UISpec4J, est un outil de test d’interface utilisateur pour une application Swing.

Ses principales caractéristiques sont :

  • Support de tous les composants Swing standard (JDK),
  • API de création et de maintenance des tests,
  • Simulation de toutes les interactions utilisateur (souris, clavier…),
  • Supporte les Applets,
  • Ajout des captures d’écran des erreurs dans le rapport HTML,
  • Utilisable avec JUnit et TestNG.

Une interface utilisateur devient alors aussi simple à tester que :

dialog.comboBox("domain").select("Xebia");
dialog.textBox("username").enterText("rmaton");
dialog.button("login").click();
dialog.optionPane().requireErrorMessage().requireMessage("Please enter your password");

Chaque classe de tests a la possibilité de définir les fonctions setUp et tearDown :

  • setUp et tearDown en JUnit 3.8.x
  • Toutes méthodes avec @After et @Before pour JUnit 4.x
  • Toutes méthodes avec @AfterMethod et @BeforeMethod pour TestNG

On se retrouve avec des tests du type :

import org.testng.annotations.*;

import org.fest.swing.fixture.FrameFixture;

public class FirstGUITest {

private FrameFixure window;

@BeforeMethod
public void setUp() {
window = new FrameFixture(new MyFrame());
window.show(); // shows the frame to test
}

@AfterMethod
public void tearDown() {
window.cleanUp();
}

@Test
public void shouldCopyTextInLabelWhenClickingButton() {
// Your unit tests
}
}

La librairie se télécharge ici ou, pour notre pom adoré, dans ce repository.

Intégration Continue avec Maven

Brian Fox de Sonatype nous livre ses Maven Continuous Integration Best Practices pour faciliter l’Intégration Continue (IC) avec Maven :

  • Laisser le server d’IC déployer automatiquement les snapshots pour s’assurer que le repository est synchro avec le système de gestion des sources. Nexus aide en purgeant automatiquement les snaphosts.
  • Isoler les repository locaux des différents projets avec -Dmaven.repo.local=xxx pour éviter qu’un artifact buildé par un projet ne soit visible par les autres builds
  • Purger régulièrement (tous les soirs) les repository locaux permet de garder l’espace disque sous contrôle
  • Activer le mode Batch pour raccourcir les logs (skip les traces de téléchargement des dépendances) avec -B ou dans settings.xml :
false
  • Activer les traces complètes -e pour débugger plus facilement
  • Rediriger les erreurs des tests sur la sortie standard avec -Dsurefire.useFile=false ou dans settings.xml :
 true 
  • Toujours chercher les snapshots avec -U ou dans settings.xml :
always

Nouvelle version de RichFaces: la 3.3.0 est sortie

4 mois après la dernière version (3.2.2), JBoss sort la version 3.3.0 de RichFaces.
Celle-ci a corrigé pas mal de bugs, la liste est disponible sur Jira. Ella a amélioré certains composants ou en a simplifié d’autres. Enfin, le support du navigateur Chrome a été revu et amélioré.

Deux nouveaux composants viennent s’ajouter aux nombreux déjà existants :

  • l’éditeur WYSIWYG adapté de TinyMCE accessible par la balise <rich:editor>,
  • l’amélioration du traffic Ajax grâce à une file d’attente, en utilisant la balise <a4j:queue>.

L’éditeur ne nécessite pas de code javascript supplémentaire, tout est paramétrable par les propriétés du composant. Et surtout, il est extensible, on peut ajouter ses propres plug-ins.

La file d’attente Ajax est la petite révolution de cette version. Ce qu’on reproche souvent à JSF, c’est de rendre difficile l’utilisation d’Ajax dans le cycle de vie JSF. Ce composant va mettre de l’ordre dans tout ça et ne laisser passer qu’une requête à la fois, les autres sont mises en attente. Il va aussi réduire la charge du serveur en combinant plusieurs requêtes si celles-ci sont similaires. Enfin, plusieurs files d’attente peuvent être définies pour une gestion plus fine des requêtes (Global default queue, View scoped default queue, View scoped named queue, Form-based default queue).

D’autre part, quelques nouvelles fonctionnalités sont venues enrichir plusieurs composants:

  • le slider de nombre qui permet de changer une valeur en faisant glisser un curseur sur une ligne (<rich:inputNumberSlider>) peut être positionné verticalement,
  • l’évènement « clic droit » (onRowContextMenu) a été ajouté sur les lignes d’un tableau et permet de faire apparaître des informations (<rich:dataTable>),
  • l’élément d’un menu (<rich:menuItem>) peut être utilisé seul et ajouté directement dans la toolbar.

Comme toujours avec RichFaces, il est possible de voir à l’oeuvre les composants sur la page de démonstration.

Enfin, le souhait des utilisateurs va se réaliser, la prochaine version de RichFaces a pour objectif d’enrichir les possibilités de positionnement des composants dans une page.

LiquiBase 1.9 : Des améliorations bien utiles

Le mois dernier, un billet sur la refactorisation de base de données avait présenté LiquiBase dans sa version 1.8.1. Nous tenions donc à vous informer de la sortie d’une nouvelle version qui confirme la forte activité autour de cet outil.

Sans surprise, cette version 1.9.0 corrige son lot de bugs et améliore la validation dans le schéma XSD.

La fonctionnalité majeure de cette nouvelle release se trouve dans la balise <modifySQL>. Elle offre un mécanisme de modification du code SQL après génération par les balises standards. Cela permet d’ajouter des informations spécifiques à la base de données utilisée, comme « engine innodb » pour une base MySQL.
Là où, avant, on devait passer par du code SQL custom (<sql>), on va pouvoir rester sur les balises existantes et les modifier à notre guise.

D’autre part, une nouvelle balise (<stop>) permet, en développement, d’arrêter le traitement du fichier et d’aller regarder dans la base de données pour voir si tout se passe comme il faut.

Enfin, dans les versions précédentes, pour inclure d’autres fichiers, il fallait les énumérer un par un, à présent, il suffit d’indiquer un répertoire avec la balise <includeAll>. Il faut toutefois être prudent car l’ordre des fichiers est important et cette balise parcours la liste dans l’ordre alphabétique, une politique précise de nommage s’impose.

Pour rassurer certains qui penseraient qu’il vaut mieux attendre la version 2.0 qui sort généralement après la version 1.9, le responsable du projet LiquiBase précise que la version majeure n’est pas prévue dans l’immédiat et que les prochaines versions seraient 1.10, 1.11, etc.

Donc n’ayez crainte et allez-y.

Comparatif de performance entre JSF/Seam à Wicket

Peter Thomas nous propose dans son article Seam / JSF vs Wicket: performance comparison, un comparatif de performance entre une solution Seam/JSF et Wicket.

Il y a deux éléments intéressants dans cet article :

  • Le resultat de l’étude : Wicket semble plus performant que Seam/JSF

En effet, Wicket a une empreinte moins grande que Seam/JSF :

  • Wicket consomme moins de mémoire JVM
  • Wicket charge moins de classes
  • Wicket démarre plus rapidement. Le temps de démarrage n’est pas un critère primordial mais il est représentatif des performances globales et impacte le développement
  • Wicket a de meilleurs temps de réponse sur les différents scénarii
  • La méthode de test de performance.

Ce n’est pas une méthode formelle qui garantit le résultat de manière scientifique mais cela donne une tendance.
Les outils utilisés sont :

  • Ant pour le scripting du benchmark
  • JMeter pour réaliser les mesures de temps de réponses en injectant une charge
  • Eclipse Memory Analyzer pour réaliser les mesures d’empreinte mémoire de la JVM

Le travail effectué peut être facilement étendu à d’autres frameworks. Il est en outre possible de réutiliser une partie des scripts du projet Google Code PerfBench.

Billets sur le même thème :

Laisser un commentaire