Published by Publicis Sapient Engineering

Il y a 14 ans -

Temps de lecture 10 minutes

Revue de Presse Xebia

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

Actualité éditeurs / SSII

Agilité

Le Scrum meeting, story par story ?

RIA

Microsoft et Nokia adoptent jQuery

Le coin de la technique

Actualité éditeurs / SSII

Spring Source : les VC prennent le contrôle

Les semaines se suivent et ne se ressemblent pas chez Spring Source. Après le tumultueux revirement de stratégie Open Source il y a dix jours (cf. Nouvelle politique de maintenance de Spring : La très périlleuse route de monétisation de l’open source), Benchmark Capital, le principal fond d’investissement de Spring Source, prend le contrôle opérationnel de la société en nommant Rob Bearden President and Chief Operations Officer (COO). Rod Johnson conserve le titre de CEO.

C’est un véritable tournant dans la vie de Spring Source qui était jusqu’à présent gouvernée par son fondateur Rod Johnson et est aujourd’hui confrontée aux défis de la rentabilité et de la croissance.

Nous noterons au passage un clin d’oeil de l’histoire : Rob Bearden, avant de rejoindre Benchmark Capital, a été COO de JBoss. Le monde de l’Open source est petit, espérons que les relations conflictuelles entre les camps JBoss et Spring Source s’adoucissent :-)

Les interrogations sont nombreuses : quelle place trouvera Rod Johnson dans cette nouvelle organisation ? Quelle stratégie Open source va adopter Rob Bearden ? Entérinera-t-il la nouvelle politique de commercialisation des releases post trois mois qui suscite encore une polémique très vive ?

Quelques liens :

JBoss certifié Java EE 5 : un anachronisme corrigé …

L’anachronisme que personne ne comprenait est enfin corrigé. JBoss Application Server, précurseur de Java EE 5 avec le support de JPA dans Hibernate et la Web Application qui jouait le rôle d’un conteneur d’EJB 3 est enfin certifié Java EE 5. Sacha Labourey, JBoss, annonce dans JBoss AS is now EE5 certified! que la version release sera disponible dans les semaines à venir. Il n’en reste pas moins que JBoss AS 5 est une refonte sur le fond du serveur d’application (nouveau messaging, clustering, etc) qui a duré plus de trois ans (cf InfoQ : Releasing JBoss AS 5: Q&A with Project Lead Dimitris Andreadis) et qu’on peut s’attendre à une phase de stabilisation de la nouvelle stack JBoss.

… tandis que Websphere 7 sera le dernier grand sur la ligne d’arrivée

IBM nous rappelle avec Websphere que les parts de marché sont parfois décorrélées de l’implémentation des dernières spécifications. Websphere 7 sera le dernier grand serveur Java EE a être certifié Java EE 5.

La version d’évaluation est déjà disponible sur DeveloperWorks ; des blogs (Websphere Community et Websphere and Messagin) relaient la communication institutionnelle.

Agilité

Le Scrum meeting, story par story ?

Les daily standup meetings se déroulent habituellement personne par personne, c’est-à-dire que chaque membre de l’équipe répond aux 3 questions l’un après l’autre. Le défaut de cette méthode selon Mike Cohn est qu’elle ne permet pas toujours de voir les problèmes sur les stories dont personne ne s’occupe puisque personne n’en parle.
Il suggère la possibilité d’attaquer le standup story par story, mais on perd alors en visibilité sur ce que fait chaque personne. Face à ce dilemme, plusieurs solutions sont possibles :

L’équipe s’engage t-elle sur trop d’items par sprint ? Mike préconise une moyenne de 1 à 1,5 story / personne / sprint. Attention, cela ne veut absolument pas dire qu’une story doit être gérée par une seule personne !
Faire le standup devant le tableau des tâches, afin que chaque personne puisse pointer les items sur lesquels elle travaille.
Désigner des « story owners » : pour chaque story, une personne de l’équipe est responsable de son avancement. Cette personne n’est pas forcément le développeur principal de la story.
Regarder la taille de l’équipe : selon ses observations la taille idéale d’une équipe se situe entre 5-7 personnes.

La plupart des équipes font leur standup par personne, mais certaines équipes peuvent se heurter à un manque de visibilité sur certaines stories. Cette vision « story par story » peut répondre à leurs attentes.

RIA

Microsoft et Nokia adoptent jQuery

À part GWT avec Google, un des reproches que l’on peut faire aux librairies JavaScript/AJAX est leur absence de support par un grand éditeur. Cet état de fait pourrait bien changer pour la librairie jQuery, une de nos librairies favorites, que l’on conseille et rencontre de plus en plus fréquemment chez nos clients. jQuery annonce sur son blog l’adoption par Microsoft et Nokia du framework, et son intégration dans leur plateforme de développement officielle respective.
jQuery sera donc distribué avec Visual Studio, et sera présent dans tous les nouveaux téléphones de Nokia qui utiliseront le moteur de rendu maison Web Runtime.
Les bénéfices pour jQuery et ses utilisateurs sont multiples : la reconnaissance de la librairie comme parmi les plus populaires, et son amélioration via la soumission de patchs et de tests. Excellente nouvelle donc !

Le coin de la technique

Les spécifications REST se terminent

Vous en entendrez certainement parler prochainement à l’occasion de Spring 3.0, les spécifications de la JSR-311 : Java API for RESTful Web Service (JAX-RS) ont été approuvées quasi unanimement (15 pour, 0 contre, 1 non votant) par l’executive comitee.

JAX-RS est une API permettant l’implémentation de Web Services REST, son fonctionnement est simple :

on rajoute des annotations sur des classes et des méthodes pour décrire les services à exposer et la manière de les exposer
le choix du service s’effectue en fonction des URL / Content type / Headers et type de requête HTTP

REST étant à la mode, plusieurs framework existent déjà dont :

Jersey, l’implémentation de référence pour JAX-RS développée par Sun
Restlet, le framework du moment le plus utilisé pour les applications REST
CXF RESTful Services, l’implémentation JAX-RS du projet Apache CXF
RESTeasy, la version JBoss

Une interview des specs leads Marc Hadley et Paul Sandoz est disponible sur InfoQ. Une des questions intéressantes porte sur l’influence de la JSR311 sur les spécifications de Servlet. Cela nous rappelle que, même si les API REST et les Servlets ont des approches complètement différentes, ces deux technologies doivent pouvoir cohabiter et travailler ensemble.

JVM Wish List vue par Terracotta

Cet article présente une liste d’améliorations JVM espérées vues par un spécialiste Terracotta. S’il est vrai que cet outil aborde des problématiques peu communes (clustering de JVM), certaines de ces idées pourraient être utiles pour tout autre framework utilisant l’instrumentalisation de code.

Voici les idées proposées par Steeve Haris dans son article regroupées par domaines, elles permettent de :

Simplifier grandement le code de ce genre de framework en évitant d’avoir à développer des surcouches logicielles simulant certaines de ces fonctionnalités

Permettre de créer des proxy d’objets niveau JVM : cela faciliterait le maintien de la heap virtuelle de Terracotta
Pouvoir associer des métadatas à un objet : cela permettrait d’affiner les choix du memory manager de Terracotta
Faciliter le développement de tricks en améliorant le _Hot swapping_

Optimiser le nombre d’objets à instrumentaliser

Permette d’instrumenter des tableaux sans avoir besoin de passer par les classes les utilisant
Permettre le remplacement de méthodes natives : actuellement si l’on veut modifier le comportement d’une méthode native, nous somme obligé d’instrumenter tous les objets appelant celle-ci.

Adapter la JVM aux architectures d’aujourd’hui

La taille des listes et des collections est définie par un int. Les architectures 64 bits nous permettant d’ajouter de plus en plus de mémoire, il se peut que cette taille devienne insuffisante dans certaines utilisations.

Principes pour le design d’une API

Joshua Bloch (Google), auteur de Effective Java, énumère un ensemble de principes clés afin de réussir la conception et la réalisation d’une API : Bumper-Sticker API Design.

Une API n’est pas seulement mise en place dans les frameworks mais aussi dans des applications à différents niveaux :

la couche d’accès aux données
la couche service

La volonté d’une API est de réaliser un module cadré au fonctionnement clair. Le fonctionnement interne du module est caché derrière un contrat d’utilisation (qui ne repose pas nécessairement uniquement sur des interfaces Java). Le terme d’utilisabilité de l’API peut être employé.

L’utilisabilité d’une API peut être décrite avec les spécificités suivantes :

contrat d’utilisation simple et explicité, cela passe par le nommage des éléments (classe, méthode, argument, …).
l’intégration aux cas d’utilisation doit être naturelle. Pour que ce soit le plus naturel possible, on peut même envisager de d’abord coder les cas d’utilisation avec l’appel à l’API et ensuite coder l’implémentation de l’API.
l’implémentation de l’API doit être indépendante du contexte d’appel

Le développement d’API pose le problème de la gestion des versions. A partir du moment où elle est exposée, une API doit répondre de la même façon à tous les appels, quel que soit le client sollicitant le service. Il est vital de respecter les principes de l’IoC Inversion of Control, et ne pas enrichir chaque version d’un ou plusieurs comportements spécifiques :

if (isClient1) {
  // Traitement spécifique client 1
} else if (isClient2) {
  // Traitement spécifique client 2
} else {
...
}

Des principes qui font généralement débats sont aussi présentés :

Faire peu de documentation, les noms des classes/méthodes doivent être explicites
Ne pas remonter de CheckException que des RuntimeException

Il est vrai que la principale difficulté d’une API est de bien faire dès la première version. La moindre modification du contrat d’utilisation de l’API entraînera des régressions chez les clients de l’API.

C’est pour cette raison qu’il faut tenter de faire un premier jet aussi bref et concis que possible, et de ne traiter la multiplicité des cas qu’au fur et à mesure de leur apparition, dans des versions ultérieures.

Pour conclure, on reprendra la phrase de Joshua Bloch : le design d’API est un art, pas une science exacte.

N’hésitez pas à visionner le vidcast associé à cet article.

David Syer communique sur Spring Batch

Nous vous l’annoncions avant l’été, David Syer, le leader technique de Spring Batch, a entamé sa « tournée promotionnelle ».

À travers ce vidcast, capté au QCon de Londres et relayé par InfoQ (ou bien via le support de présentation), il revient sur :

les patterns de batch et leur utilisation
un survol des concepts de SpringBatch
une étude de cas
l’avenir de ce produit

D’autre part, dans une autre vidéo publiée sur TV4it, Olivier Rachon, Senior Manager chez Accenture, nous en dit plus quant à l’utilisation de ce récent framework : 5 projets en production, des 10aines en cours de développement.

Pour information, la version 1.1.2 est disponible et les premiers tests que nous avons effectués, dans le cadre d’un XKE, nous ont paru très convaincants. Nous devrions publier prochainement notre retour d’expérience sur ce framework.