Revue de Presse Xebia

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

Agilité

• Comment faire des tests d’IHM sans se tirer une balle dans le pied ?
• La gestion des risques dans un projet agile

SOA

• RabbitMQ racheté par SpringSource

Le coin de la technique

• Billy Newport et la programmation parallèle
• Performance jQuery avec $.delegate()
• Faille de sécurité dans Oracle Java

Agilité

Comment faire des tests d’IHM sans se tirer une balle dans le pied ?

L’automatisation des tests d’IHM est souvent une mauvaise idée. Le constat est très souvent le même : bien que simple à mettre en place en général, leur apport est souvent mineur par rapport à leur coût (je vous dirige vers l’excellent article de Robert Martin pour creuser le sujet). Comment faire si l’on veut cependant s’engager dans cette voie?
Dans cet article, Gojko Adzic (commiter fitnesse et auteur du livre passionnant « Bridging the communication gap« ), nous livre des pistes pour maximiser le retour sur investissement sur ceux-ci. Tout d’abord, ne surtout pas partir sur de l’enregistrement brut des cas de tests les uns après les autres (avec Selenium IDE par exemple). C’est dans ce cas-là que l’on se tire une balle dans le pied. Les coûts de maintenance explosent et l’intérêt des tests est remis en question au fil du temps.
La clé est de représenter les tests d’IHM sur plusieurs niveaux :

• Règles métiers
• Worfklows
• Technique

Les niveaux supérieurs sont plus stables dans le temps et sont plus compréhensibles que ceux du dessous. Les niveaux supérieurs s’appuient bien évidemment sur les niveaux du dessous pour fonctionner.
Le but de cette approche est de faire en sorte que les tests restent compréhensibles (bon courage pour aller comprendre la règle métier cachée derrière une centaine d’instructions Selenium) et surtout de promouvoir la réutilisabilité afin de garder la main sur la maintenance des tests.

La gestion des risques dans un projet agile

Mike Cohn, scrum master certifié et auteur de nombreux ouvrages de référence, nous suggère une manière de mettre en place la gestion des risques sur un projet agile.
Le management des risques est un sujet central dans de nombreux projets et est souvent considéré comme un enjeu déterminant pour leur réussite.
Il existe un ensemble de méthodes dédiées, ainsi que des normes et pratiques pour limiter les risques.
Au premier abord, on peut constater que Scrum n’implémente pas vraiment une gestion spécifique des risques. Cependant, les différentes pratiques et outils mis en place comme: les itérations courtes, l’intégration continue, les tests automatisés, etc. permettent de limiter drastiquement l’apparition des risques.
Ainsi, la mise en place d’une gestion des risques sur des projets agiles ayant des facteurs de risque faibles n’est pas nécessaire. Pour les autres projets, Mike nous propose une solution introduite par John Brothers dans The Agile Times avec le risk burndown chart.

Pour obtenir ce graphique, il convient au préalable de faire un recensement des risques (durant un sprint planning par exemple). On évalue la probabilité d’apparition, l’impact en jours sur la livraison si celui-ci se réalise, et enfin le nombre de jours exposés à ce risque potentiel. Pour calculer ce dernier, Mike multiplie la probabilité du risque par l’impact en nombre de jours. Ces informations sont renseignées dans un tableau de recensement.
Pour générer le risk burndown chart, il suffit ensuite de positionner la colonne du nombre de jours exposés en ordonnée et le nombre de jours (ou de sprints) en abscisse. On constate alors que plus on avance dans les sprints, moins le projet est exposé à des risques.

Sans tomber dans le sur-outillage, la mise en place d’un risk burndown chart permet d’introduire de manière légère la gestion des risques. Le tableau de recensement des risques peut suffire.

SOA

RabbitMQ racheté par SpringSource

Deux nouvelles importantes ces derniers jours autour d’AMQP, une bonne et une mauvaise.

La bonne nouvelle pour AMQP, c’est le rachat (ici, ici et là) par VMWare de RabbitMQ, rejoignant ainsi la gamme de produit SpringSource. Ceci donne l’occasion à Rod Johnson de donner son point de vue. Les efforts de RabbitMQ pour s’intégrer à des solutions cloud semblent avoir été déterminants pour VMWare. L’aspect standardisation par contre apparait moins dans les différentes annonces et il est sûrement encore trop tôt pour savoir quel sera l’investissement de SpringSource dans le groupe de travail d’AMQP. Néanmoins AMQP profitera sûrement de l’aura de Spring dans la communauté Java et ça ne peut être qu’une bonne nouvelle pour ce standard. Par contre OpenCredo, qui tente de faciliter les solutions AMQP en Java et propose entre autres un template Spring pour RabbitMQ, risque d’être une victime collatérale de cette nouvelle association.

Ensuite la mauvaise nouvelle. IMatix, qui a créé OpenAMQ, la première implémentation de ce standard, a l’intention d’arrêter son support en 2011. 0MQ, acheté il y a quelques mois, remplacera ce produit. Par la même occasion, ils cesseront de participer au groupe de travail AMQP. Outre le fait que 0MQ parait avoir des performances très supérieures à OpenAMQ, il semble que l’inertie autour de la nouvelle version de la norme AMQP/1.0 ait fini par éteindre l’enthousiasme des dirigeants d’iMatix. D’ailleurs, on peut trouver sur leur site un article intéressant sur les arcanes du groupe de travail. Il apparait qu’à vouloir spécifier trop de choses le standard deviendrait beaucoup trop complexe et que le retard pris sur la livraison de la nouvelle version serait dû à des considérations plus humaines que techniques, laissant entendre que l’ambiance n’y est peut-être pas toujours très détendue.

Le coin de la technique

Billy Newport et la programmation parallèle

Billy Newport, un des acteurs majeurs de la programmation distribuée, a donné une interview à InfoQ dans le cadre de Qcon.
Il y parle de programmation parallèle en Java, selon lui l’avenir de notre langage.
La tendance actuelle dans le hardware est à la multiplication des cœurs, mais au ralentissement de leur fréquence. Et contrairement à ce que semblent penser certaines équipes d’exploitation (nous avons des noms), la multiplication des cœurs ne permettra pas aux applications Web de traiter plus d’utilisateurs, plus vite (bien au contraire, puisque unitairement, les cœurs sont moins puissants).

Le problème que Billy Newport voit dans l’écosystème actuel est l’absence complète d’un framework de haut niveau pour faciliter la programmation parallèle (qui reste une arcane secrète réservée aux grand maîtres). Il existe bien un certain nombre d’outils pour gérer le comment implémenter des traitements parallèles :

• les grilles de calculs en mémoire, comme eXtrem Scale.
• les traitements massifs de fichiers, comme Hadoop.

Malheureusement, aucune de ces solutions ne propose d’API de haut niveau qui permettrait de décrire les traitements à appliquer aux données quelle que soit l’implémentation « physique » mise en place. De plus, il semblerait que bien peu de personnes travaillent dans la recherche sur ce sujet. Billy Newport y voit là une superbe opportunité pour créer la prochaine entreprise à la mode dans l’open source.
Proposer une API de haut niveau qui proposerait de décrire les traitements et la façon de les appliquer aux données, en permettant de s’abstraire de la tuyauterie classique de la programmation parallèle :

• Gérer les structures de données et la concurrence autour de ces données.
• Gérer la distribution optimisée des traitements (afin que le gain de temps réalisé en utilisant un cœur distant ne soit pas perdu en temps d’IO par exemple).

Selon lui, les mécanismes existant en Java posant les prémices du calcul massivement parallèle (les Actors en Scala par exemple) sont de trop bas niveau.
Afin de pouvoir faire de la programmation parallèle sans avoir à connaitre toutes les implémentations sur le bout des doigts, il faudrait que Java adopte une réflexion comme celle que les auteurs de Haskell et Erlang ont mené (et non pas des recherche sur des mécanismes de primitives comme Scala)

D’autres problématiques vont apparaitre, notamment à cause des mécanismes d’auto découverte des nœuds d’une architecture distribuée (il existe plusieurs parades, comme changer les ports standard ou bien utiliser un mécanisme déclaratif).

Bref une entrevue passionnante, dont vous trouverez l’intégralité en video, mais également en transcript, peut être plus accessible pour les anglophobes.

Performance jQuery avec $.delegate()

Voilà une petite astuce jQuery plutôt intéressante pour gagner en performance sur votre site web si vous êtes déjà, tout comme moi :), un accro de la fonction live (via ce site).

Pour la gestion des évènements, nous avons la méthode bind qui permet d’associer à un élément de notre page un évènement de type click, change, focus… Mais bind ne s’appliquera que sur les éléments explicitement retournés par le sélecteur. Ainsi, même si nous spécifions un sélecteur du type $('a') (tous les éléments a de la page), les éventuels éléments a qui seraient créés plus tard dans la page ne seront pas pris en compte.

Pour cela, jQuery 1.4 introduit la méthode live qui est un bind présent et futur. En effet, il s’applique sur tous les éléments retournés par le sélecteur mais aussi sur tous les éléments futurs de la page qui matcheront avec ce sélecteur ! Une fonctionnalité très intéressante donc mais aussi très consommatrice si l’on a un DOM important. En effet, le sélecteur parcourt à chaque fois le document pour matcher les nouveaux éléments et leurs associer l’évènement.

Mais c’est sans compter sur delegate qui est un live voisin. Ainsi, plutôt que de matcher tous les éléments a de ma page, delegate va s’appliquer sur un élément parent (et donc restreint) et, de cet élément parent, rechercher un certain élément sur lequel binder l’évènement. Imaginons que notre a soit inclus dans un élément ayant l’id container, on pourra alors écrire :

$('#container').delegate('a', 'click', function() {...})

Une écriture quelque peu différente donc mais un véritable gain sur un DOM conséquent. A essayer d’urgence !

Faille de sécurité dans Oracle Java

Oracle Java a sorti une nouvelle mise à jour du JDK et du JRE 6 suite à une alerte de sécurité sur le Java Deployment Toolkit utilisé pour Java Web Start. Tavis Ormandy et Ruben Santamarta ont découvert simultanément la possibilité d’exécuter du code arbitraire à travers cette faille et ont alerté la communauté le 9 avril dernier. Ce problème existe depuis la version 1.6.0_10 et est dû à un certain laxisme sur la vérification du paramètre « codebase » dans le JNLP qui devient maintenant obligatoire. Bien que ce problème impacte potentiellement les environnements Linux, Windows semble plus vulnérable, donnant par exemple la possibilité de charger une DLL. Par contre il ne concerne pas les Mac. Oracle a commencé par minimiser la gravité du problème avant finalement de sortir cette mise à jour une semaine après sa découverte. Il est donc fortement conseillé de se mettre à jour.