Published by Publicis Sapient Engineering

Il y a 14 ans -

Temps de lecture 16 minutes

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é

Programmation en binôme vs Revue de Code

Chris Sims rebondit sur l’article de Theodore Nguyen-Cao, Pair Programming > Code Reviews, pour relancer le débat Pair Programming vs Code Review :

Étant donné que la revue de code se fait sur un code plus avancé qu’en programmation par binôme, la détection / correction de bugs est plus complexe au stade revue. Cependant, la mobilisation deux personnes sur la même tâche représente un coût qu’il ne faut pas non plus négliger.

La programmation en binôme (ou Pair Programming) a une grosse valeur ajoutée dans l’intégration de code. Voici le fonctionnement :

Le pilote du binôme veut intégrer une API
Le copilote du binôme a développé l’API
Le copilote décrit comment fonctionne l’API
Le pilote essaye d’intégrer l’API dans son environnement
Le pilote émet des souhaits pour l’API
Le copilote essaye d’intégrer ces souhaits (en tenant compte des autres utilisateurs de l’API)
Le copilote indique au pilote la prochaine version de l’API

Les deux parties sont gagnantes :

Le pilote intègre en douceur et en toute tranquillité
L’API est améliorée, on a une API plus « utilisable »
Les deux parties comprennent les besoins et contraintes de chacun

La revue de code permet à un tiers de jeter un regard neuf sur un code développé. Kent Beck, dans son livre Implementation Pattern, affirme que le code réalisé par un développeur doit expliciter ses intentions. La revue de code peut être une activité judicieuse pour vérifier cette règle.

Ainsi la revue de code permet d’améliorer la maintenabilité du code :

Amélioration de l’organisation des classes (nom des classes et packages)
Partage des expériences de conception ou de patterns
Partage des connaissances
Support d’un développeur novice par un développeur plus expérimenté

La revue de code peut être courte (30 minutes) et assez récurrente (une à deux fois par semaine).

Sensibilisation Scrum pour les Gamers

Une fois n’est pas coutume, voici un lien qui nous est proposé par un collègue de mission. Il s’agit d’une mini formation Scrum qui s’est glissée … dans une vidéo montrant les coulisses du jeu DC Universe Online. Cela se passe aux alentours de la 2e minute de la vidéo. Au programme, rapide description du fonctionnement des sprints et du Scrum board, développement en cycles courts et démonstrations possibles à chaque itération.
Clinton Keith avait déjà partagé son expérience de Scrum dans les jeux vidéos il y a un peu plus d’un an.
Un Gamer averti en vaut deux! Merci donc à Olivier pour ce lien peu commun.

Transmettez la vision produit à votre équipe.

Vous êtes vous déjà demandé si votre équipe de réalisation est guidée par une vision produit, insufflée par le Product Owner ? Selon Roman Pichler (voir l’article), il est important que chaque membre de l’équipe soit inspiré, motivé et concerné par le travail en cours de réalisation. Il nous fournit cinq questions fondamentales auxquelles tout membre de l’équipe devrait être capable de répondre :

Qui va acheter le produit et quels seront les clients ?
Quels besoins le produit va-t-il adresser ?
Quels attributs du produit sont critiques pour la satisfaction du client et le succès de produit ?
Quelle comparaison faites-vous avec des produits similaires?
Quels sont les délais et le budget impartis pour réaliser et lancer le produit ?

Même si l’idée ici n’est pas de transformer chaque membre de votre équipe en Directeur du Marketing, il est important que vous mesuriez la connaissance de l’équipe dans ces domaines. C’est l’un des principes agiles: avoir confiance en son équipe (et donc ne pas l’infantiliser en croyant qu’elle ne peut pas ou ne doit pas comprendre ces aspects).

RIA

11 belles librairies Web UI

Quand on parle d’APIs JavaScript Web 2.0 (frameworks/graphiques), on pense tout de suite à jQuery, Prototype, ExtJS, Script.aculo.us, Dojo ou bien encore Rialto.

Mais il ne faut pas limiter la liste à celles-ci ! Il y a une multitude d’autres librairies, qui sont pour certaines bien plus belles/rapides/robustes qui celles citées ci-dessus. Et on pourra en découvrir (ou redécouvrir) de nouvelles du côté de chez Antonio Lupetti qui nous référence 10 Beautiful Web UI librairies. Parmi celles citées, on retiendra particulièrement :

IT Mill Toolkit (démo) intégrant des composants entièrement Java avec GWT,
LivePipe UI (démo), un framework graphique s’appuyant sur prototype,
Jitsu (démo) avec définition des écrans par XML (qui sera ensuite compilé) et de nombreux outils intégrés dont la gestion du bouton retour et le data binding,
MochaUI (démo) qui s’appuie sur le framework MooTools,
Echo (démo) qui a été testé lors de notre RIA Contest,
Yahoo! UI (démo => Yahoo! Mail ;-)) qui a servi de base à ExtJS (qui n’était à l’origine qu’un add-on pour YUI).

On notera aussi dans la liste certaines librairies moins connues comme :

Mais l’article en donne 10 et c’est écrit 11 dans le titre ?!? En effet, à cette liste je rajouterai comme 11ème librairie DHTMLX, une API peu connue mais qui mérite de l’être. En plus d’être visuellement très abouti, chaque composant (téléchargeable à l’unité ou dans une suite) possède un grand nombre de fonctionnalités par rapport aux autres librairies du marché. Force est de constater qu’afficher un tableau qui peut contenir plus de 10000 enregistrements, avec des colonnes cachées/bloquées au runtime, le tout se voyant appliqué 3 filtres par défaut est très simple à mettre en place et surtout ne fait même pas sourciller l’API (affichage très rapide pour les navigateurs les plus récents et raisonnable pour d’anciennes versions) !

Plusieurs démos sont accessibles, on notera la bonne performance du RSS reader, de l’administration BDD ou bien encore de l’éditeur XML. Je vous la recommande fortement !

De nouveaux frameworks pour renforcer JavaFx

La communauté Java commence à se mobiliser autour de JavaFx.
Outre la sortie prochaine du premier livre consacré au sujet (Pro JavaFX™ Platform: Script, Desktop and Mobile RIA with Java™ Technology), cette semaine a vue la sortie de deux projets OpenSource autour du RIA de Sun : JFXtras (0.2) et WidgetFx (1.0.1)

Ces deux projets sont menés par Stephen Chin, qu’InfoQ a interviewé.

On notera tout d’abord qu’on a affaire à 2 projets communautaires, indépendants de Sun, et qui viennent compléter quelques vides du coté de JavaFx. Cependant, Stephen Chin insiste sur le fait que, bien que très occupées (probablement par la prochaine sortie de JavaFx Mobile), les équipes Sun avec lesquelles il est en contacte supporte et aide régulièrement cette initiative.

Entrons dans le détail de ces frameworks.
JFXtras apporte un ensemble d’ajouts à l’API Fx

JFXtras Grid – un layout de type grille 100 % Java
JFXStage / JFXDialog – Des classes pour remplacer celles de Fx, offrant un plus grand spectre fonctionnel.
JFXtras Test – Un framework de tests unitaires
JFXWorker – Une solution de traitement asynchrone

WidgetFx offre des outils de création aussi qu’un contenur de widgets performant et portable sur plusieurs plateformes (Windows XP/Vista, Linux et Mac OS X)

Support de personnalisation graphique des widgets et du Dock.
Support des composants Flash/Flex.
Amélioration des performances du moteur des widgets.
Un nouveau thème pour le Dock.

Stephen Chin revient aussi sur un grand nombre de sujets :

les éléments moteurs différenciants de Fx, à savoir l’intégration Java et Fx Mobile
le futur de Fx, fortement lié aux développements des plugins pour les différents IDE
les facteurs clés pour réussir un projet Fx, à savoir la communication accrue avec les équipes de design, l’obtention de retours rapides de la part des utilisateurs (tiens tiens…) et la réutilisation maximale des composants open source.
ses souhaits pour les futures version de Fx : support de l’asynchronicité, inclusion de Fx dans Java, intégration au Web 2.0

Pour voir widgetFx en action, suivez le lien

Adobe continue l’ouverture de ses technologies RIA

Dionysios G.Synodinos nous apprend dans Adobe to publish the Real-Time Messaging Protocol (RTMP) que Adobe a choisit de mettre à disposition son protocole de communication temps réel destiné à la transmission de données, de flux audio et vidéo sur de multiples supports (télévisions, ordinateurs, téléphones…).
Adobe riposte ainsi aux récentes ouvertures de technologies faites par Sun JavaFx et Microsoft Silverlight. Par ailleurs, Adobe annonce de futures ouvertures comme notamment:

la suppression des restrictions sur les formats SWF, FLV/F4V (FLV est le format vidéo de Flash). Depuis la version 9 de flash player, celui-ci prend en compte le mp4 et a mis au point le format F4V afin de supporter ce dernier.
la mise à disposition des protocoles Adobe Flash Cast et AMF. Le protocole Flash Cast, basé sur Adobe Mobile Platform permet d’utiliser des services multimédia en mode offline sur des appareils mobiles (téléphone portable, PDA…). En ce qui concerne AMF (Action Message Format), c’est le protocole binaire de transfert des données entre le serveur et le client.

Avec ces annonces, Adobe réaffirme sa volonté de rester leader dans le domaine des RIA. Reste à savoir si cela suffira pour contrer Silverlight et Java FX.

Session de formation gratuite pour JavaFx

Le site JavaPassion propose un ensemble de formations en ligne concernant JavaFx. Tout au long des quinze (!) sessions programmées d’ici Mai, Jim Weaver et Sang Shin balayeront toutes les facettes du RIA de Sun.
Toutes les explications, et tous les agendas, sur la page de JavaPassion.
A noter : cette page contient un grand nombre de liens vers des documents de référence. C’est donc une mine d’or pour qui s’intéresse un tant soit peu à cette technologie.

RIA en chiffres

Ted Patrick présente sur son blog un site permettant de visualiser la proportion de plugins Flash Player et de Silverlight installés sur le navigateur des visiteurs pour les 90 derniers jours. On savait déjà que Flash Player était installé sur la quasi totalité du parc informatique mondial, mais l’étude nous donne le pourcentage d’installation de Silverlight (entre 15 et 20%). Les résultats peuvent être visualisés par navigateur, par système d’exploitation, et par langue : http://www.riastats.com.

Le coin de la technique

Interview de Rod Johnson, Spring 3.0 et le reste

Dans une interview publiée cette semaine sur InfoQ sous forme d’une vidéo de 30 minutes, Rod Johnson répond à quelques questions indiscrètes sur l’état d’avancement et les orientations des différents projets de la Springosphère.

Nous retiendrons :

Le support des fonctionnalités REST est certainement l’une des nouveautés les plus attendues pour le prochain Spring 3.0 dont le premier milestone est disponible depuis fin 2008. Si cette fonctionnalité présente quelques similitudes avec Spring WS, elles n’adressent pas les mêmes problématiques et restent complémentaires. À l’origine le support de REST devait d’ailleurs être implémenté sur la base de Spring WS. Si au final Spring MVC a été jugé plus adapté, certaines fonctionnalités ont tout de même été extraites de Spring WS pour être utilisées (OXM).
Si comme nous, vous vous demandiez quelles étaient les intentions de SpringSource après le rachat de G2One en novembre dernier, voici un embryon de réponse. Rod nous dévoile les premiers fruits de ce rachat avec Spring Java Config. Disponible en test depuis 6 mois environ en pré-version dans le jpetclinic (projet exemple Spring), nous nous interrogions sur la valeur ajoutée apportée par cette fonctionnalité. Pour mémoire, elle permet de configurer vos applications Spring par l’intermédiaire de code Java comme vous le feriez en XML (voici un exemple de code). Cette possibilité prend tout son sens si on la croise avec les commodités offertes par Groovy. Vous pourrez probablement remplacer demain vos fichiers de configuration statique XML par des DSL dynamiques Spring-Groovy.
Spring 3.0 sera l’occasion de mettre en pratique la nouvelle politique de maintenance adoptée par Spring l’année dernière. Celle-ci incite fortement ses utilisateurs à coller aux dernières versions du framework. Les corrections de bugs n’étant plus repackagées sur les anciennes versions majeures du framework. Ainsi, à la sortie de Spring 3.0, si vous trouvez un bug dans l’un des modules de votre Spring 2.5.6, il vous faudra : soit monter de version, soit repackager vous-même votre propre version corrigée. Cela ne devrait pas poser trop de problèmes au vue de la maturité de la version 2.5. De plus, la rétrocompatibilité exemplaire entre Spring 3.0 et Spring 2.5 devrait vous permettre une montée de version en douceur. Rappelons tout de même que Spring pratique le pruning : la plupart des éléments dépréciés dans Spring 2.5 disparaîtront donc de la version 3.0.
Certains notent que Java EE se rapproche de Spring en offrant des fonctionnalités similaires, l’inverse est également vrai : Spring dmServer implémentera le profil Web de la spécification Java EE. Toutes les spécifications ne seront pas couvertes dans leur intégralité, c’est la nuance qui sépare un rapprochement d’une convergence.
C’est sans surprise que Rod nous parle de la distance que Spring prend avec SCA. SpringSource a fait le choix de partir sur une technologie concurrente plus porteuse : OSGi. De plus, SCA ne dispose pas d’un nombre d’utilisateurs assez important pour intéresser SpringSource pour le moment.
Cette interview nous a également permis de découvrir une fonctionnalité peu connue pourtant présente depuis Spring 2.0 : l’annotation @Configurable.

Pour conclure, si cette interview n’apporte véritablement aucune annonce fondamentale sur la stratégie de SpringSource, elle a le mérite de synthétiser les discussions en cours et de donner une idée plus précise de la roadmap de Spring pour les mois à venir.

Java EE 6 public review : Un Fat Web Profile et Web Beans en suspend

Roberto Chinnici, Java EE 6 specification leader annonce la sortie de la public review de cette spécification. Nous noterons :

Le Web Profile est assez lourd avec notamment les transactions distribuées (JTA), des EJB Lite et du controversé JSF. Certains trouveront que ce poids sera une barrière à l’entrée des éditeurs intéressés par ce profil léger ; d’autres estimeront que des technologies comme les transactions distribuées sont aujourd’hui incontournables. Le débat est sans fin :-)
JSR 299 « Web Beans », récemment remis à plat et renommé « Java Contexts and Dependency Injection » a pour le moment été retiré de Java EE 6 (voir ci dessous).
Servlet 3.0 nous a un peu déçu (cf Servlet 3.0 : une API innovante et convergente ?)
Les fonctionnalités dépréciées qui pourront disparaître dans Java EE 7 (aka pruning) : EJB entity beans (remplacés par Java Persistence), JAX-RPC (remplacé par JAX-WS), JAX-R (usage limité qui ne nécessite pas un statut ‘required’).

JSR-299 (ex Web Beans) : Une JSR « Dependency Injection » sans SpringSource

Nous avions évoqué dans Web Beans, un énième modèle de composant pour Java EE ? le problème de positionnement de cette JSR. Antonio Goncalves nous avait confirmé au Paris JUG que l’intégration de cette JSR à Java EE 6 était compliquée.

Gavin King nous rapporte cette semaine dans Revised Public Draft of JSR-299: Java Contexts and Dependency Injection que, du fait des retours de plusieurs membres du Java EE 6 Expert Group, la JSR dont il est le leader a été profondément remaniée pour mieux s’intégrer à la plateforme Java EE.

Nous retiendrons les points suivants :

La JSR est renommée « Java Contexts and Dependency Injection », un titre beaucoup plus clair que le vague « Web Beans ».
La « Dependency Injection » sera assurée par les conteneurs ‘légaux’ de Java EE : le conteneur EJB et le conteneur embarquable EJB Lite (déploiment dans un .war, etc).
Les mécanismes d’intercepteurs seront intégrés à ceux déjà existant dans la spécification EJB 3.1 .
JSR 299 n’est pour le moment pas inclue dans Java EE 6.

Si le renommage de cette JSR a le mérite d’appeler les choses par leur nom, on peut s’inquiéter de ce revirement très tardif et s’étonner de l’absence de SpringSource d’une JSR sur laquelle Rod Jonhson aurait la légitimité d’être leader, eut égard aux parts de marché et à la vitalité du conteneur Spring. Les risques de ratage de l’API semblent importants. Ne vaudrait-il pas mieux recommencer ce chantier sur des bases claires ?

Une JSR « Dependency Injection » sans SpringSource, c’est comme une JSR Java Persistance API sans JBoss/Hibernate ;-)

Sortie d’Apache Ivy 2.0

Apache a annoncé la sortie de Ivy 2.0, première version d’Ivy sous licence Apache.

Pour rappel, Ivy est un outil de gestion de dépendance agile initialement créé par Xavier Hanin. Il peut être comparé à Maven2, même si Ivy a un spectre de fonctionnalités moins larges. Il est spécialisé dans la gestion de dépendances, qu’il apporte à Ant quand les deux outils sont associés.

Les améliorations majeures sont :

Passage sous licence Apache, Ivy est maintenant un projet Apache (anciennement projet Jayasoft)
Amélioration de la compatibilité avec Maven et ses dépôts d’artefacts
Amélioration du fonctionnement interne (cache, resolvers, etc)

Sortie de VisualVM 1.1

VisualVM, l’outil de surveillance d’applications java vient de sortir en version 1.1. Nous vous avions annoncé, dans un précédent post que cet outil est maintenant intégré au JDK6 update 7. Cette nouvelle version intègre de nombreuses fonctionnalités et améliorations. L’API a été étendue pour le développement de plugins.

Des plugins permettent d’intégrer VisualVM à Eclipse et Intellij Idea.
Parmi les nouvelles fonctionnalités, on peut noter :

Le monitoring de l’utilisation CPU et mémoire (Garbage Collector) pour chaque application.
Une vue en mode Tableau sur l’onglet des Threads
Monitoring des JVM IBM via une connexion JMX.
VisualVM est basée sur la plateforme NetBeans 6.5

La suite des nouveautés ici : http://blogs.sun.com/nbprofiler/entry/visualvm_1_1_released

Par ailleurs, Danny Coward annonce l’intégration de VisualVM dans la plateforme de clustering TerraCotta.