RIA

• Inquiétude de la communauté Flex suite aux annonces d’Adobe

Le coin de la technique

• Sortie de JQuery 1.7

Evénements de notre communauté en France et à l’étranger

• CITCON London 2011

RIA

Inquiétude de la communauté Flex suite aux annonces d’Adobe

La semaine dernière, il y a eu beaucoup de confusions, et de rumeurs suite aux diverses annonces d’Adobe concernant Flash, Flex et HTML5. Tout a commencé lorsqu’Adobe a annoncé la semaine dernière l’abandon de Flash Player pour mobile. Une vague de rumeurs et de confusions s’est alors abattue un peu partout, certaines personnes confondant le Flash Player avec la solution AIR pour mobile qu’Adobe ne compte pas abandonner. Tout aurait pu s’arrêter là mais c’était sans compter sur les autres communiqués plutôt maladroits d’Adobe pour annoncer leur intention de miser sur HTML5 dans le futur et de leur intention de fournir Flex à la communauté. Ce qui a provoqué de vives réactions au sein de la communauté Flex, le plus parlant est bien entendu le billet de Fabien Nicollet auteur du blog Flex Tutorial qui montre bien l’inquiétude et l’incompréhension face à ces annonces. Finalement, suite à la panique engendrée, Michael Chaize, évangéliste de la plateforme Flash chez Adobe France a pris l’initiative de réaliser un communiqué non officiel à la communauté francophone pour la rassurer. Dans ce qui peut être dit :

• Adobe n’abandonnera pas Flex, une équipe Adobe – diminuée certes – travaillera en collaboration avec la communauté et d’autres sociétés utilisatrices de Flex,
• La totalité du projet Flex sera donnée à la communauté mais on ne sait pas encore à quelle fondation open source elle appartiendra,
• Adobe devrait donner plus d’informations sur Flex au moment de la sortie de la release de la version 4.6 qui est prévue pour le 29 Novembre 2011.

Au delà de la communauté francophone, on peut voir aussi beaucoup de réactions au travers des commentaires et réactions sur Twitter. Ce qui commence à faire réagir Adobe qui s’active pour réaliser une communication plus claire. Cette maladresse semble avoir ébranlé la communauté Flex. Espérons que les annonces à venir permettront de rassurer tout le monde et que l’ouverture de Flex à la communauté soit le début de belles initiatives.

Le coin de la technique

Sortie de JQuery 1.7

La nouvelle version de la très populaire librairie Javascript est sortie en début de mois avec son lot de nouveautés.

Au rang des changements, on notera l’apparition d’une nouvelle API de gestion des évènements. Celle-ci remplace et unifie les méthodes existantes de binding d’évènements (bind(), click(), delegate() et live()) par la méthode on(), et d’unbinding (unbind(), undelegate() et die()) par la méthode off().
Cette nouvelle méthode on est définie par la signature suivante : on(events [,selector] [,data], handler) (les éléments entre crochets sont optionnels). Elle permet donc d’associer une fonction de callback (handler) à un ou plusieurs évènement(s) déclenché(s) dans l’objet sur lequel la méthode on est appelé. Il est aussi possible de filtrer les éléments sur lesquels cette méthode s’applique à l’aide d’un css selector et de passer des données à la fonction de callback.
La fonction off de son côté possède la signature off([events], [,selector] [,handler]) permettant de supprimer des bindings. Les méthodes de binding habituelles sont encore présentes pour des raisons de rétro-compatibilité mais sont désormais dépréciées.

Cette nouvelle API vient avec une nouveau moteur de gestion des évènements qui amène une amélioration sensible des performances dans la majorité des cas.

Pour ce qui est des autres nouveautés :

• amélioration du support de HTML5,
• un fonctionnement plus intuitif des méthodes slideToggle() et fadeToggle(),
• le support de l’API Asynchronous Module Definition permettant la définition de modules qui pourront être chargées de manière asynchrone,
• de nombreuses autres améliorations et corrections de bug à voir dans le billet d’annonce.

Evénements de notre communauté en France et à l’étranger

CITCON London 2011

La CITCON (Continuous Integration and Testing Conference) s’est déroulé du 11 au 12 novembre à Londres dans les locaux de Skills Matter. Comme son nom l’indique, cette conférence est dédiée à tout ce qui touche à l’intégration continue et aux tests mais c’est avant tout un événement de type « Open Space ».

Le principe de la CITCON

Le premier jour de la conférence débute à 18h. Tous les participants (environ une centaine) sont invités à proposer un sujet (débats, présentation technique, démonstration d’un outil, …). Un court résumé est rédigé sur un post-it qui sera ensuite collé sur un immense tableau représentant le planning de la conférence :

Le planning s’est très vite rempli, il y avait 5 salles à notre disposition pour les 5 slots horaires prévus (1 heure par slot). Vous l’aurez compris, le contenu de la conférence est entièrement créé par la communauté. Elle est libre de proposer les sujets mais également l’heure à laquelle ils seront abordés (on parle de planning refactoring, tout le monde avait la possibilité de changer les post-it de place). Comme 5 sujets sont animés en parallèle, les participants avaient la possibilité de quitter une salle pour se rendre dans une autre si finalement la discussion ne les satisfaisait pas, c’est ce qu’on appelle la règle des deux pieds.

Les sujets abordés
Voici une liste non exhaustive des discussions animées par les participants.

• Root Cause Analysis by Squirrel
• Aramis: Why do projects fail by Eric Lefevre-Ardent.
• Dev and Ops and System Ops oh my by Squirrel
• Configuration Changes
• What can we learn from CI by Benjamin Mitchel
• Do you use your tests in prod
• Radiators by Tom Denley
• How to move an agile team from Continuous Integration to Continuous Deployment
• To feature branch or not to feature branch
• Are you satisfied of your build tools
• TDD : Hands On
• …

N’ayant pu assister à toutes les présentations, je vous livre quelques informations (il est difficile de retranscrire l’intégralité des discussions).

TDD : Hands On
La session TDD animée par Steve Freeman (l’auteur du livre Growing Object-Oriented Software, Guided by Tests) était très intéressante. Un des participants voulait comprendre comment mettre en place le Test Driven Development dans son projet. Pour ce faire, il a projeté sur le video-projecteur une méthode écrite en Java non testée. Steve Freeman a guidé l’assistance de bout en bout. De la création de la classe de tests jusqu’à l’injection de dépendances en passant par l’écriture de tests unitaires mettant en exergue les règles de gestion de la classe à refactorer.

Are you satisfied of your build tools ?
Un premier tour de table était destiné à lister tous les outils de builds utilisés au quotidien par les participants. Les noms de Ant, Gradle, Maven sont évidemment sortis assez vite, mais il existe toujours des projets qui utilisent Make. Nous avons abordés les outils connexes que sont Jenkins, Teamcity et des plugins comme m2eclipse.

La conférence s’achève
En fin d’après midi, nous voilà tous réunis pour exprimer en quelques mots les moments forts et les souvenirs que nous garderons de CITCON 2011. Un tirage au sort a permis à quelques chanceux de gagner des livres tels que Agile Testing et Domain Specific Language.

C’était un réel plaisir d’assister à la CITCON, énormément de passionnés venant parfois de très loin. Il y a forcément une certaine déception de ne pouvoir assister à toutes les présentations, par exemple à celle où un participant a construit un robot pour tester Angry Birds automatiquement !

RIA

• JavaFx est mort, vive JavaFx 2 Bêta

Le coin de la technique

• Mark Reinhold liste les besoins du futur système de modules

Evènements de notre communauté en France et à l’étranger

• What’s Next

RIA

JavaFx est mort, vive JavaFx 2 Bêta

Vous souvenez-vous de JavaFx ? Cette tentative de Sun de développer un nouvel RIA pour réaliser des interfaces riches sous téléphone mobile et desktop, basé sur un nouveau langage Fx Script, et ainsi concurrencer les ténors comme Flex, Android ou IOS. Annoncée à la dernière conférence JavaOne en septembre 2010, Oracle semble avoir suffisamment d’intérêt pour JavaFx pour développer une version 2 basée sur une toute nouvelle API en pur Java.

Ainsi, la version 2 vient de sortir en Bêta et force est de constater que le site qui lui est dédié est déjà bien documenté et les nouveautés sont nombreuses. Parmi les plus importantes, on peut noter:

• Une API en Java. Celle-ci a été conçue pour tourner éventuellement sur d’autres langages JVM comme JRuby ou Scala.
• Un nouveau moteur graphique 3D tirant parti du GPU des cartes graphiques.
• Un nouveau moteur dédié au multimédia basé sur GStreamer.
• Un composant web utilisant WebKit pour intégrer du contenu HTML dans JavaFx.
• Une large palette de composants graphiques de haut niveau, comme les graphiques, les tableaux, les menus, etc. Une API est même fournie afin de permettre à tous de créer leurs propres composants.
• Une interopérabilité avec Swing.

Pour le moment, les applications JavaFx ne tournent que sur Windows, mais, comme l’indique Richard Bair dans un post destiné à rassurer ceux qui s’inquiétaient de cet aspect, « JavaFX will be cross platform ». Il existe un plugin pour NetBeans alors que pour les autres IDE, il faut récupérer le SDK et builder le projet avec Ant.
Même si beaucoup sont sceptiques quant à l’avenir de JavaFx, Oracle suit sa roadmap: la version finale devrait arriver d’ici la fin de l’année. En attendant, vous pouvez toujours lire la doc d’architecture récemment mise à jour.

Le coin de la technique

Mark Reinhold liste les besoins du futur système de modules

A l’origine, le projet Jigsaw devait permettre d’alléger le JDK en permettant de le modulariser et ainsi de n’utiliser que les composants dont a réellement besoin une application. Le projet change avec le temps et vise maintenant, à terme, un système de modules permettant:

• en interne au JDK, la convergence entre Java ME et SE;
• en externe, de mettre à disposition des applications le système de modules qui était destiné à l’origine aux seules entrailles du JDK.

Mark Reinhold, l’architecte en chef Java chez Oracle, annonce sur son blog qu’il a ébauché un document de travail destiné à lister les besoins d’un système standard de modules pour Java. Ce document sera l’un des points de départ d’une éventuelle JSR « Java Platform Module System » mentionnée dans la JSR Umbrella de Java 8. Vu de l’extérieur, on ne peut qu’être étonné de voir qu’un projet débuté il y a de cela plusieurs années en soit encore à tâtonner de la sorte. D’autant que le positionnement par rapport à OSGI, qui est lui déjà fonctionnel depuis bien longtemps, semble encore se chercher.
Comme c’était le but, plusieurs réponses ont été faites à la publication de cette ébauche. Les 2 plus abouties sont les suivantes:

• Celle de David Bosschaert. Celui-ci revient sur les bénéfices que nous pourrons tirer d’un système de modularisation directement dans Java. Pour lui, cela permettra de sensibiliser les développeurs à ces problématiques pour évoluer plus facilement ensuite vers OSGI. Il envisage même qu’il puisse être possible de se servir des implémentations existantes d’OSGI comme base de l’implémentation du Project Jigsaw. Nous n’avons pas fini de nous demander quelles sont les différences entre les 2 ! De plus, il soulève le point du format de définition des modules: il milite pour un format lisible par les humains, une sorte de MANIFEST.MF++ basé sur un DSL, alors qu’il est possible que ce format soit finalement du java compilé.
• David Lloyd, lui, compte exposer son analyse en détail à travers une série de posts sur le blog de JBoss. La première partie de cette analyse correspond au 1er chapitre de l’ébauche de Reinhold. Lloyd y revient sur les notions de versioning, les relations entre les packages et les classloaders, le code natif et enfin la sécurité. Cette dernière est pour lui la grande absente même si les choses vont globalement dans le bon sens. Ses analyses de la suite du document de Reinhold devraient suivre.

Le projet Jigsaw semble donc repartir sur des bases qui, sans être nouvelles, se trouvent renforcées et élargies. Mais n’espérons pas le voir avant Java 8, et encore !

Evènements de notre communauté en France et à l’étranger

What’s Next

Nous vous l’avions annoncé ici-même: les 26 et 27 mai derniers se tenait la conférence What’s Next au Grand Rex à Paris. Organisée par Zenika, cette conférence gravitait autour des technologies et des outils de demain pour la plateforme Java et son écosystème. La revue de presse est l’occasion de vous faire un rapide retour sur l’évènement qui sera complété très prochainement par un article plus détaillé.

Nous avons d’abord eu droit à des conférences théoriques:

• La Keynote d’Adrian Colyer sur l’actualité de SpringSource, très orienté CloudFoundry.
• Une introduction au langage Clojure par Howard Lewis Ship: attention syntaxe difficile, idéale pour les utilisateurs de Lisp.
• La gestion de la mémoire par Jevgeni Kabanov: du CPU aux différents GC, en finissant par la plateforme Azul Zing dépourvue de pause GC.
• L’explication de ce que sont les WebSockets et de leur avantage par Brad Drysdale.
• Java, son histoire et son avenir par Neal Gafter, suivi d’une courte présentation sur Windows Azure, la plateforme PaaS Java-ready de Microsoft.
• Un cours magistral d’architecture par Theo Schlossnagle: couplage lâche, isolation des services, programmation défensive et monitoring en sont les maîtres-mots.
• Akka et le modèle acteur, une autre façon d’aborder le développement orienté évènement avec un système scalable et disponible par Jonas Bonér.
• Comment améliorer l’intégration continue par Kohsuke Kawaguchi, beaucoup d’idées et de propositions pour simplifier la vie du développeur.

Mais nous avons aussi eu le droit à notre lot de démonstrations, parfois captivantes :

• Un tour d’horizon d’Eclipse Orion, l’IDE en ligne par Boris Bokowski. La performance de l’éditeur est impressionnante pour son moteur JavaScript, mais ses fonctionnalités en font plutôt un éditeur de texte basique.
• Jags Ramnarayan nous présente SQLFabric en quelques slides et se lance dans une démonstration de création d’une base de données en SQL et pourtant dans le cloud, un no NoSQL.
• Rob Harrop fait une démonstration de RabbitMQ en utilisant plusieurs langages de programmation, il se connecte même en Telnet à la file de messages, pour finir par une application en WebSocket avec NodeJS.
• Michaël Chaize développe un client Twitter en Flex Mobile, pour lister les tweets sur la What’s Next. Il le déploie ensuite sur plusieurs supports Tablette et Mobile Android.
• Shay Banon a quant à lui tout fait dans un terminal pour nous démontrer les possibilités d’Elastic Search, un serveur REST au dessus de Lucene et fonctionnant en cluster avec partitionnement et réplication.

Vous l’aurez compris, cette conférence fut riche en enseignements. Quelques tendances ressortent de ces deux jours:

• La scalabilité est sur toutes les lèvres.
• Nous avons beaucoup parlé et vu des applications HTML5.
• NodeJS émerge vraiment comme solution de premier ordre.
• De même, le langage Scala suscite un intérêt grandissant.
• Et enfin, et ce malgré la méfiance de Theo Schlossnagle, le cloud et le NoSQL se démocratisent.

Merci à Zenika pour l’organisation de cette belle conférence et à l’année prochaine pour la What’s Next 2012.

En attendant l’article plus détaillé, vous pouvez lire les comptes-rendus sur les blogs de Nicolas Martignole ou de Benoît Courtine.

Sommaire

• Principe de fonctionnement
• Écrire le manifest du cache
• Intégrer le manifest à l’application
• Gérer la mise à jour du cache
• Gérer le cache en JavaScript
• Aller plus loin avec le manifest
• Notes de sécurité
• Conclusion

Principe de fonctionnement

Une page HTML intègre une référence vers un fichier manifest. Celui-ci liste les URL des ressources à mettre dans le cache. Quand le navigateur charge la page pour la première fois, il va télécharger toutes les URL du manifest et les stocke dans le cache. Tous les chargements suivants se feront directement à partir du cache sans passer par le serveur.

En parallèle, le navigateur va vérifier la version de son fichier manifest auprès du serveur. En cas de mise à jour, le navigateur va télécharger l’intégralité des ressources dans un nouveau cache, qui sera utilisé pour tous les chargements suivants.

Que le navigateur soit en ligne ou hors-ligne, il n’y a plus aucun impact sur l’affichage de la page qui vient directement du cache.
Maintenant que vous connaissez le principe de fonctionnement passons à la première étape.

Écrire le manifest du cache

Il s’agit d’un fichier texte encodé en UTF-8 qui contient une liste d’URLs réparties en trois sections :

• CACHE : C’est la section par défaut, elle contient les URLs que le navigateur doit impérativement mettre en cache.
• NETWORK : Liste les URLs qui doivent toujours être consultées sur le serveur. Ce sera par exemple le cas des ressources AJAX et des ressources externes (publicité, …).
• FALLBACK : Cette section permet d’associer des préfixes d’URL à des ressources alternatives utilisées en cas d’indisponibilité.

Passons maintenant à la pratique : la première chose à faire est de créer notre cache manifest.

CACHE MANIFEST
# Version 1 25/09/2010
images/img01.gif
images/img02.gif
images/img03.gif
styles/default.css
lib/demo.js
demo.html
offline.html
NETWORK:
/online.html
FALLBACK:
/online  offline.html

Le navigateur doit donc conserver en cache les ressources statiques du site (images, css, javascript), ainsi que la page demo.html.
La page online.html sera toujours consultée sur le serveur. En cas d’indisponibilité, le navigateur affichera la page offline.html à la place du service en ligne.

Par défaut, seules les ressources listées dans le cache explicite sont disponibles. Par exemple : si vous oubliez de lister une image, celle-ci ne sera pas affichée dans la page. Il faut donc lister toutes les ressources, ou bien ajouter le joker ‘*’ dans la section NETWORK afin de permettre le téléchargement des ressources manquantes. Les ressources listées dans la section CACHE sont toujours prioritaires sur les autres. De ce fait, le joker n’a aucune incidence sur la mise en cache, il permet seulement d’accéder à d’autres ressources, y compris sur des domaines différents.

Intégrer le manifest à l’application

Pour activer le cache, il reste maintenant à ajouter le fichier dans l’application web et à référencer son URL dans l’attribut manifest='cache-manifest.mf' en s’assurant qu’il est encodé en UTF-8 et que le serveur lui donnera bien le type mime ‘text/cache-manifest’.

web.xml:

<mime-mapping>
    <extension>mf</extension>
    <mime-type>text/cache-manifest</mime-type>
</mime-mapping>

Pages HTML:

<html manifest="cache-manifest.mf">
...

Au premier chargement d’une page, le navigateur va construire son cache en téléchargeant toutes les ressources listées dans le manifest et afficher la page. Après quoi, le navigateur affichera toujours cette page à partir du cache.
Notez bien que toute page référençant le manifest est ajoutée dans le cache explicite associé à ce dernier. Dans le cas de la page online.html, il ne faut donc surtout pas y référencer le fichier manifest.

Nous avons maintenant une première démonstration fonctionnelle que l’on peut qualifier de preuve de concept. Nous souhaitons modifier la page demo.html pour y ajouter un peu de contenu. Malheureusement, vous l’aurez compris, la modification du fichier html sur le serveur n’a aucun effet immédiat.

Gérer la mise à jour du cache

Souvenez vous, le navigateur vérifie toujours la version du fichier manifest au chargement des pages du cache. Si le manifest n’est plus à jour, le navigateur va le récupérer et va télécharger l’ensemble des ressources dans une nouvelle version du cache en tache de fond. Au prochain chargement de la page, le navigateur utilisera le cache le plus à jour et vous pourrez constater la prise en compte de vos modifications.

Attention, les ressources du manifest sont téléchargées en outrepassant les directives de cache HTTP. A contrario, le fichier manifest est géré dans un cache standard du navigateur, ce qui signifie qu’il respecte les standards de mise en cache. Si le serveur est configuré pour forcer la mise en cache pendant trois semaines du fichier manifest, il vous faudra attendre autant de temps avant de pouvoir voir la moindre modification de votre interface.

En développement, l’interface change régulièrement, il donc est impératif d’interdire la mise en cache du fichier à l’aide du header HTTP Cache-Control. Pour la production, les directives de cache peuvent-être plus agressives (24h par exemple) car l’interface évolue moins vite. Les en-têtes HTTP peuvent-être positionnées à l’aide d’un filtre sur l’URL du manifest ou d’une Servlet générant le manifest.

A chaque modification du fichier manifest détectée par le navigateur, celui-ci re-télécharge l’intégralité du cache. Pour garantir la mise à jour du cache à chaque nouvelle version de l’application, il faut donc modifier le fichier manifest. C’est le rôle du commentaire # version 1 25/09/2010 qui changera à chaque livraison ou déploiement de l’application.

Le site est donc consultable hors-ligne et nous sommes capables de forcer la mise à jour du cache. L’utilisateur pourra continuer à consulter le site et verra une page d’erreur appropriée s’il tente d’accéder à des services indisponibles. Pour un site statique c’est très bien mais quand on parle d’application, on pense à quelque chose de dynamique.

Gérer le cache en JavaScript

Pour un blog dont le contenu évolue lentement, il est envisageable de s’assurer que la version du manifest soit changée à chaque nouvel article. Le manifest devient alors un service généré par l’application qui change le commentaire de version à chaque nouvel article.
Malheureusement, l’utilisateur ne pourra voir le nouvel article qu’à son deuxième passage sur le site, une fois que le cache aura été mis à jour. Un début de solution est d’utiliser l’API JavaScript pour recharger automatiquement la page lorsque le nouveau cache est prêt.

L’objet window.applicationCache va nous permettre de :

• Suivre l’activité et l’état du cache associé au document courant.
• Lancer le téléchargement de la nouvelle version du cache si le manifest a changé.
• Activer la nouvelle version du cache pour que les prochains chargements l’utilisent.

<script>
// Activer le nouveau cache quand il est disponible et recharger la page
window.applicationCache.addEventListener('updateready', function (){
  	window.applicationCache.swapCache();
  	alert('mise a jour du cache');
  	window.location.reload();
}, false);
// Notifier les erreurs
window.applicationCache.addEventListener('error', function (evt){
	alert('Erreur du cache : ' + evt);
}, false);
// Vérification de la version du manifest
window.applicationCache.addEventListener('checking', function (evt){
	alert('Vérification du cache : ' + evt);
}, false);
// Télécharger le nouveau cache quand le manifest a changé
window.applicationCache.addEventListener('obsolete', function (evt){
	alert('Le cache est obsolète : ' + evt);
	window.applicationCache.update();
}, false);
// Le manifest n'a pas changé
window.applicationCache.addEventListener('noupdate', function (evt){
	alert('Pas de mise à jour du cache : ' + evt);
}, false);
</script>

Ce code rechargera automatiquement la page du navigateur lorsque le cache aura été mis à jour. Le lecteur du blog peut maintenant voir rapidement le nouvel article ou tout du moins son introduction. Pour pouvoir lire l’article hors-ligne, il faudra qu’il pense à afficher la page au moins une fois pour la mettre en cache.

Aller plus loin avec le manifest

La solution peut être de créer un service générant le manifest en changeant, d’une part, de version à chaque nouvel article publié et, d’autre part, en listant les URLs des derniers articles dans le cache explicite. Le chargement prendra plus de temps mais le lecteur pourra consulter l’article hors-ligne sans plus d’effort.

Attention, les pages implicites qui déclarent le manifest sans être listées dans ce dernier y sont ajoutées et seront téléchargées elles aussi lors de la mise à jour du cache.
Soyez prudent quand vous activez le manifest et ne multipliez pas les pages. Dans le cas du blog par exemple les pages affichant les articles ne doivent pas utiliser le manifest. Le lecteur ne souhaite certainement pas télécharger l’ensemble des articles qu’il a déjà lu à chaque nouvel article.

Cette solution minimaliste peut convenir à certains, mais elle n’est pas applicable pour un site dont le contenu change beaucoup ou pour un site à fort trafic tant l’utilisation du cache est mauvaise.

Pour optimiser l’utilisation du cache, il faut le considérer comme la vue statique de l’application qui évoluera au gré des changements d’interface et non au gré du contenu. Le contenu dynamique devra être servi par des requêtes asynchrones. Pour la mise en cache et le fonctionnement il faudra utiliser les nouvelles API JavaSript : LocalStorage et document.onLine. De cette manière, le manifest redeviendra un fichier statique évoluant au gré des versions de l’application.

Pour garantir l’indexation du contenu par les moteurs de recherche et assurer la compatibilité avec d’anciens navigateurs, prévoyez toujours un mode dégradé sans manifest ni contenu asynchrone.

Notes de sécurité

Notez que le cache est maintenu par nom de domaine. Il n’existe qu’une seule instance du même manifest pour un serveur. Pour les serveurs hébergeant plusieurs applications, l’utilisation d’hôte virtuel est plus que conseillée.

Le cache ne doit jamais contenir de données confidentielles. Les pages de login et tous services de sécurité doivent être exclus du cache. Ne les listez jamais dans le manifest sauf pour les exclure et surtout n’intégrez pas le manifest dans ces pages.

Informez l’utilisateur sur les dangers de ce service et surtout laissez le choisir d’activer ou non le fonctionnement hors ligne. En effet si le navigateur lui-même n’est pas protégé, toute personne y ayant accès pourra consulter le cache. Pour limiter le problème vous pouvez activer le service en stockant un cookie sur le navigateur si l’utilisateur active le mode hors ligne. Ainsi le lecteur devra répéter l’opération pour tous les navigateurs sur lesquels il souhaite consulter le site.

En dehors de ces règles de sécurité basiques, toutes les règles de sécurité inhérentes aux sites web s’appliquent.

Conclusion

Dans ce premier article, nous avons posé la première pierre d’une application hors-ligne, en intégrant un fichier manifest pour mettre en cache son interface et ses ressources statiques. Dans le prochain article, nous verrons comment utiliser les nouvelles API JavaScript pour permettre de lire et d’éditer du contenu hors-ligne.

Les points importants du manifest :

• Versionnez le manifest avec un commentaire
• Désactivez ou maitrisez les directives de cache HTTP
• Minimisez le nombre de pages référençant le manifest
• Stockez uniquement les ressources statiques du site

Mise en place de l’image Photoshop/Illustrator

N’ayant que très peu de connaissance de l’univers Photoshop, cette tâche s’est avérée au début périlleuse… Néanmoins, les différents tutoriaux d’Adobe permettent d’acquérir suffisamment de connaissances pour mettre en place une image, dont voici le résultat:

Assez basique, le premier écran listera les voyages, et lorsque l’utilisateur cliquera sur l’un d’eux, une image s’affichera dans le panel de droite. C’est dans cet écran que sera branché notre backend Java. Le menu sera simplement utilisé afin de montrer la mise en place des états/transitions avec Catalyst. Ainsi, les autres rubriques du menu afficheront respectivement une carte, et un descriptif.

Voici notre arborescence de l’image Photoshop créée:

Le principe est simple: l’image est découpée en calque, et ces derniers sont regroupés par fonctionnalités/pages. Ainsi nous retrouvons notre menu (navigation) avec les types d’effets que nous voudrons voir lorsque la souris de l’utilisateur passera sur le texte (ici une image violette), et les différentes pages avec leurs contenus.
Cette organisation est très importante, car par la suite nous l’utiliserons afin de mettre en place les transitions entre pages et créer nos composants.

Flash Catalyst

Une fois l’image importée dans Catalyst, nous constatons que la structure de Photoshop est bien présente et qu’un état a été créé.

Nous allons commencer par créer les transitions entre les différents écrans:

• Sélectionnez le premier état en haut à gauche et renommez le en voyages.
• Sélectionnez pour cet état la page que vous voudrez afficher dans la fenêtre Layers en haut à droite (en l’occurrence voyages page)
• Créez deux autres états (Duplicate State en haut à gauche)
• Répétez l’étape 2 pour les pages opérateurs et XKE.

Animons cette page en créant les boutons:

• Revenez sur l’état «voyages».
• Sélectionnez le texte «Voyages» ainsi que le fond violet.
• La fenêtre Convert to Artwork apparaît, sélectionnez Button.
• Re cliquez sur le texte Voyages et cochez Label dans la fenêtre qui est apparue.

• Dans la fenêtre Layers (en haut à droite), renommez Voyages en Label et voyages over en over (ce sera un composant générique pour les autres boutons du menu).
• Revenez sur la racine de votre projet (nom du projet) et renommez le composant Button en voyages_button par exemple (fenêtre en haut à droite).
• Ajoutez le label Voyages dans les propriétés du composant, et décochez Enabled.

• Sélectionnez le label de «Voyages» et modifier la couleur en noir (dans la fenêtre Properties en bas à droite)

• Copier coller deux fois le composant voyage_button dans la fenêtre Layers (en haut à droite). Ce seront les boutons Opérateurs et XKE.
• Supprimez les composants du layer navigation importés de l’image Photoshop

• Tout comme «Voyages», modifiez les labels pour Opérateurs et XKE (par contre laissez la propriété Enabled cochée).
• Vous devez réaligner les boutons les uns en dessous des autres, car en créant ces composants, Catalyst les a superposés.
• Sur chaque bouton, faire clique droit => Share to State => All States.
• Allez dans les états Opérateurs et xke: alignez les boutons et vérifier la couleur des labels.
• Attention, pour ces états vérifiez également que pour le bouton Voyages, la propriété Enabled est bien cochée.
• Cliquez sur le bouton Voyages, la fenêtre suivante s’ouvre

• Dans Up et Down, désélectionnez voyages over dans la fenêtre layers.

• Cliquez sur le bouton «Voyages» et dans le panneau Interactions (sur la droite), sélectionnez Add Interaction.
• Dans la liste déroulante Choose state, sélectionnez voyages.

• Répétez ces opérations pour les boutons Opérateurs et XKE.
• Allez dans File => Run Project pour tester la navigation.

Passons à la création de la scrollBar verticale ainsi que de son association avec une liste déroulante :

• Sélectionnez les éléments graphiques qui vont composer la scrollBar.
• Une fenêtre est apparue (Convert to Artwork), sélectionnez Vertical scrollBar dans la liste. Ne tenez pas compte du message Component Issues.
• Cliquez sur Edit Parts, et associez les éléments graphiques aux éléments de la scrollBar.

• Un fois le composant terminé, cliquez sur la racine du projet (nom de votre projet) en haut à gauche.
• Sélectionnez le fond gris clair avec le texte San Francisco et dans la fenêtre Convert Artwork, sélectionnez Data List.
• Cliquez sur Edit Parts, et associez le fond gris ainsi que le texte San Francisco à Repeated Item.

• Ajustez la taille de la Data List à celle de la scrollBar.
• Dans la fenêtre du bas, cliquez sur l’onglet Design-Time Data.
• Ajouter des données en cliquant sur Add Row.

• Couper la scrollBar, double cliquez sur la Data List et coller la scrollBar dedans (l’association avec la liste est effectuée à ce moment).
• Allez dans File => Run Project pour tester l’application.

Analyses

A travers la mise en place de cette première partie, nous pouvons effectuer les constats suivants:

• La maîtrise des outils Photoshop et Illustrator est indispensable : créer ses composants graphiques, appliquer des effets nécessitent un travail non négligeable.
• Pour un développeur n’ayant pas de connaissances graphiques, la courbe d’apprentissage peut être assez longue.
• Lors de la mise en place de l’image, il faut anticiper les transitions et effets car l’arborescence des composants est importante pour Catalyst.
• L’outil Catalyst possède de bonnes interactions avec Photoshop et Illustrator:
• l’import d’images Photoshop est bien reconnu
• possibilité de modifier et d’améliorer ses composants à partir de Catalyst dans Illustrator.
• Catalyst permet de créer des états, transitions assez rapidement et facilement
• La création de certains composants n’est pas forcément très intuitive : création d’un composant Button et suppression des «boutons» créés dans Photoshop…

Vous pouvez télécharger l’image et le projet Catalyst sur le SVN de Xebia France

Agilité

• Convaincre votre MOA de passer aux méthodes Agiles

RIA

• Sortie de SproutCore 1.0

Le coin de la technique

• Commenter son code: jusqu’où aller ?
• Où l’on reparle de la JSR-310

Agilité

Convaincre votre MOA de passer aux méthodes Agiles

Dans un récent article, Alexandre Boutin explique comment convaincre une MOA de s’intéresser à l’agilité.
La démarche d’Alexandre a été de demander à la MOA de répondre à un questionnaire reprenant les divers problèmes habituellement rencontrés :

• difficultés à définir le besoin fonctionnel et à maîtriser son évolution au cours du temps,
• délais importants entre chaque version et effet tunnel pendant les périodes de développements,
• les versions se terminent généralement avec du retard,
• communication avec la MOE,
• la productivité n’est pas au rendez-vous.

Ce questionnaire ayant permis à la MOA de mettre le doigt sur des problèmes récurrents, Alexandre présente les avantages que vont apporter l’utilisation des méthodes agiles dans leur travail :

• meilleure communication et visibilité sur le travail de la MOE,
• livraisons fréquentes à dates fixes d’un produit démontrable et fonctionnel,
• amélioration de la productivité.

Alexandre termine par préconiser un accompagnement pour se former et passer aux méthodes agiles le plus rapidement et le plus efficacement possible.

L’adoption d’une méthode de travail (agile ou non) par l’ensemble des acteurs d’un projet est fondamentale. Il est en effet compliqué pour une MOA de travailler avec des méthodes différentes de celles employées par la MOE. Cela génèrera immanquablement des problèmes de communication entre les deux parties.
Convaincre une MOA de changer ses habitudes de travail n’est pas chose aisée, et le questionnaire proposé par Alexandre Boutin (potentiellement agrémenté en fonction des spécificités du contexte du projet) peut-être un bon moyen de déclencher le besoin de changement.
L’adoption d’une méthode agile n’est pas sans contrainte, mais un bon coach agile saura mettre en avant les bénéfices de l’agilité pour combler les lacunes de l’ancienne méthode.

RIA

Sortie de SproutCore 1.0

Les frameworks HTML5 continuent de se mettre à jour. Et après 52framework, c’est au tour de SproutCore de sortir en release majeure (version 1.0, information relayée ici).

InfoQ a récemment réalisé une interview de Charles Jolley (CEO de Sproutit) concernant SproutCore.
On y apprend ainsi que le framework gère certaines fonctionnalités d’HTML5 (comme l’offline storage ou le nouveau tag video) et qu’il est possible d’intégrer du code existant jQuery, ExtJS, YUI ou bien encore Prototype.
Il explique aussi les raisons principales de la migration, côté vue, de Ruby à JavaScript. La première est l’arrivée prochaine d’un Drag & Drop UI Designer (facilitée par les APIs JavaScript) et la seconde pour des raisons de performances (jusqu’à 10 fois plus rapide que la version précédente !).

Rendez-vous sur cette page pour une petite démonstration de SproutCore et sur celle-ci pour le téléchargement.

Le coin de la technique

Commenter son code: jusqu’où aller ?

Rebondissant sur une discussion qu’ont eu des programmeurs .Net de Seattle, InfoQ publie un article sur l’intérêt de commenter (ou non) son code. Le sujet, tel un éternel serpent de mer, donne toujours matière à discussion. A tel point que les interventions des lecteurs, à la suite de l’article, sont des plus intéressantes !

Le consensus semble être que les commentaires sont à éviter au maximum car le code se doit de s’auto-documenter: sans commentaires, et seulement avec le nom des méthodes et des variables, nous devons être capable de le comprendre. Ainsi, pour Thiébaut Champenier, il y a 2 types de commentaires:

• Les commentaires documentant l’API (notés /** */ )
• Les commentaires dans le code (notés /* */ ou // ) qui doivent un maximum décrire pourquoi le code existe plutôt que comment le code agit.

Alex Suvorov ajoute qu’une suite de plusieurs opérations successives nécessitant un commentaire devrait plutôt être extraite en une fonction nommée de manière explicite. Tim Linquist, lui va même plus loin en souhaitant disposer d’une fonctionnalité lui permettant de sortir les commentaires du code une fois la documentation (javadoc) générée. Pour contrebalancer ces avis, la palme du meilleur commentaire revient à Pete Haidinyak. Celui-ci se permet une suggestion amusante destinée à toutes les personnes « qui ne commentent pas leur code ou qui pensent qu’un commentaire toutes les 10000 lignes est suffisant ». Il leur demande de rajouter un en-tête dans leur code spécifiant: « A toute personne chargée de maintenir ce code: si vous ne comprenez pas mon code ou êtes troublé par mon style, n’hésitez pas à m’appeler à toute heure, nuit et jour, au numéro suivant: { numéro_de_téléphone_du_développeur }. Je vous expliquerai ce que j’avais en tête lorsque j’ai écrit ce code ». L’idée est bonne, avec un tel en-tête, les développeurs risqueraient de se soucier un peu plus de la façon dont les autres peuvent comprendre leur code !

Où l’on reparle de la JSR-310

La JSR-310 (Date and Time API) était initialement prévue pour le JDK 7 mais il y a un an, la roadmap de Sun l’en excluait. Cette spécification était pourtant attendue par tous ceux qui étaient lassés par les défauts de java.util.Date et qui voyaient en Jodatime (dont la JSR-310 est largement inspirée) une échappatoire tentante. L’API proposée par cette JSR est en effet beaucoup plus riche et permet de représenter tous les concepts d’instants et de durées.

Lors de l’annonce du report du JDK 7 en novembre dernier, Mark Reinhold avait laissé la porte ouverte aux fonctionnalités qui avaient été abandonnées faute de temps ; la JSR-310 en faisait partie. Courant février, questionné sur cette spécification par un spectateur d’un webcast, il disait regretter qu’elle n’ait pu être finalisée dans les temps. Dans le même temps, Stephen Colebourne, spec lead de la JSR-310, expliquait sur son blog qu’il disposait désormais de temps libre pour travailler sereinement sur cette spécification. Quelques semaines plus tard une early draft review voyait le jour. Enfin, il y a quelques jours, Stephen Colebourne répondait à un commentaire en disant que l’inclusion de la JSR-310 dans le JDK 7 dépendrait de sa finalisation et de la volonté de Sun/Oracle.

La saga de la JSR-310 semble donc renaître de ses cendres et la possibilité de son intégration au prochain JDK est bien réelle. L’affaire est donc à suivre…

Actualité éditeurs / SSII

• Subversion devient un projet top-level Apache

Agilité

• Sortie du livre « SCRUM : Le guide pratique de la méthode agile la plus populaire »

RIA

• HTML5 + CSS3 = 52framework

Le coin de la technique

• Les nulls, c’est nul !
• G1 pas à la hauteur des espérances ?

Actualité éditeurs / SSII

Subversion devient un projet top-level Apache

Après seulement 3 mois d’incubation (mais sur le point de fêter ses 10 ans, Collabnet ayant sorti la première version en 2000), Subversion est maintenant projet top-level Apache. Pour ce faire, le projet a du se plier aux règles strictes édictées par la fondation Apache, qui touchent à la fois au code source du logiciel, à la provenance des différents codes, à leur licence, au site internet du projet, au processus de release des nouvelles versions… C’est un gros travail mais il permet ensuite aux projets de bénéficier de toute l’infrastructure ainsi que de l’aura de la fondation Apache.
Subversion s’assure donc pour la suite une stabilité et une plus grande visibilité, élargit sa communauté et s’octroit plus de crédibilité vis à vis des entreprises. En effet, être projet top-level Apache est gage de pérennité.
Le projet en aura besoin, étant fortement concurrencé par les outils de gestion de version distribués comme Git ou Mercurial. Martin Fowler notait ainsi récemment plusieurs points négatifs de SVN :

• l’absence de copie locale du repository d’où des problèmes de performance et l’impossibilité de travailler offline sur ce repository.
• le fait que les branches aient une visibilité globale est un frein à l’innovation: les développeurs sont moins enclins à créer une branche pour expérimenter diverses innovations.

Néanmoins, SVN reste pour lui le meilleur des outils non distribué, et est largement recommandable. D’autant que c’est un outil plus simple à appréhender et son ancienneté fait que les bonnes pratiques sont largement répandues. D’autre part, ajoutons que les développeurs semblent ne pas se reposer sur leurs récents lauriers, et annoncent la disponibilité dans la version 1.7 de la fonctionnalité de offline commit. Comme d’habitude, nous bénéficions encore de la concurrence pour avoir à notre disposition les meilleurs outils. Chouette !

Agilité

Sortie du livre « SCRUM : Le guide pratique de la méthode agile la plus populaire »

Claude Aubry, auteur du bien connu blog Scrum, Agilité et Rock’n roll nous délivre dans ce livre un condensé de son expérience sur la mise en place de Scrum. Très pragmatique, ce livre traite point par point les différentes composantes de Scrum en les expliquant et en détaillant pour chacune les pratiques qui fonctionnent et celles à ne pas tenter. Après avoir dévoré les 5 premiers chapitres nous ne pouvons que vous engager à lire cet ouvrage qui fera office de référence pour vous accompagner sur vos projets Scrum.
C’est comme d’avoir un peu de Claude Aubry avec soi sur son projet, mais sans l’accent

RIA

HTML5 + CSS3 = 52framework

Même si c’est en très bonne voie, les navigateurs Web du marché ne sont pas entièrement compatibles HTML5 et CSS3. Néanmoins, plusieurs librairies JavaScript permettent de rendre votre navigateur 100% compatible avec ces 2 technologies et 52framework en fait partie.

Au menu, la librairie nous propose d’utiliser les différentes nouvelles balises HTML5 telles que aside, nav, section ou bien encore article. Les nouveaux input type='email' et input type='url' sont aussi de la partie. La balise script contenant du JavaScript n’a plus besoin de l’attribut type='text/javascript'. Côté CSS3, il est possible d’utiliser les coins arrondis, les text-shadow et les box-shadow.
La démo se trouve ici, le plus intéressant étant son code source où l’on retrouve les nouveaux éléments cités ci-dessus.

Pour le téléchargement, rendez-vous est pris sur le Google Code du projet section Downloads.

Le coin de la technique

Les nulls, c’est nul !

C’est en tout cas ce que beaucoup d’entre nous ressentent en tombant sur certaines NullPointerExceptions. Et suivent les premières questions : Où sont les tests unitaires ? Quel paramètre n’a pas été testé ? Mais, ressenti de plus en plus grandissant avec les derniers langages alternatifs pour la JVM, pourquoi laisser passer des valeurs nulls en paramètre ?

Pour ne prendre qu’un seul exemple, Scala permet d’éviter ce genre de désagrément grâce à la classe Option (Avoid using nulls in Scala). Dans le cas d’une valeur définie, il suffit d’utiliser Some(something) qui est l’option avec valeur. Et pour le null, il faudra se tourner vers None qui est l’option sans valeur. Le code est ainsi réduit et ne contient plus de test if(obj !=null) (englobé dans l’option None) :

// possible parameters
var anObject = Some(5)
var nullObject = None
// our code that do not care about nulls
val doubleFunc = (option:Option[Int]) => print(option.map(_*2))
doubleFunc(anObject)
doubleFunc(nullObject)
// prints
Some(10) // values has been doubled
None // does nothing

Mais pour Java ? Une petite piqure de rappel ne faisant pas de mal, cet article nous présente une solution possible avec en citation Martin Fowler et le pattern Special Case.

L’idée est la même que pour l’option Scala. On commence par définir une classe abstraite ou une interface avec une méthode spécifique qui sera appelée par notre code. Et de là seront créés 2 objets : un objet réel et un objet null. Ce dernier implémentera la méthode demandée mais ne fera rien alors que l’objet réel exécutera son code métier. Ainsi, plus de test de nullité, notre code lancera directement la méthode sur l’objet et ne se souciera plus de savoir si l’objet est null ou non.

Ce pattern anti NPE est une solution possible mais elle n’est pas la seule. Si vous avez suivi l’actualité, vous êtes malheureusement au courant que les operateurs null-safe et elvis ne seront pas implémentés par l’ambitieux Project Coin. Le sucre syntaxique ne viendra donc pas directement dans nos appels de fonctions mais par les annotations de JSR-305 dont @NonNull. Bien sûr, cette spécification a pour cible FindBugs, Intellij IDEA, Checkstyle ou bien encore PMD. On aurait préféré une intégration au Project Coin mais c’est déjà mieux que rien…

G1 pas à la hauteur des espérances ?

G1 (Garbage First) est un nouvel algorithme pour votre Garbage Collector. Il est destiné à remplacer l’implémentation par défaut lors de l’arrivée de la prochaine JVM. Celui-ci apporte un certain nombre d’avancées significatives dont des performances annoncées (quasi) compatibles avec le temps réel. Pour cela, G1 relève le défi de la maitrise des temps de pause des collections stop the world grâce à une gestion innovante de la mémoire (reposant sur beaucoup plus de ‘petites’ zones).

Nous n’allons pas détailler son fonctionnement ici. Si le sujet vous intéresse, nous vous encourageons à consulter l’un de nos articles sur le sujet. Il date un peu, mais son contenu reste tout à fait d’actualité : GC générationnels traditionnels (jdk6) VS GC Garbage First (jdk7).

Si les fonctionnalités de ce nouvel algorithme sont alléchantes, on retrouve ici et là quelques retours frileux suite à son usage. L’auteur de ce billet annonce des performances moins bonnes qu’avec le garbage collector par défaut lors de l’utilisation de LinkedHashMap. Faut-il s’en inquiéter pour autant ? Non ! Vu la criticité de ce genre de fonctionnalité, il est tout à fait normal que quelques ajustements soient faits lors des premiers retours d’utilisation terrain. C’est d’ailleurs le but recherché suite à l’intégration à Java 6 update 14 (via les options -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC), même s’il est vrai qu’il n’est plus flagué ‘expérimental’ depuis peu sur les derniers build du jdk 7.

En revanche, en plus de la mise en doute des performances de G1 relayée sur le internet, nous pensons qu’un élément bloque effectivement son adoption en production : le monitoring. Celui-ci est aujourd’hui insuffisant, ni jstat ni VisualGC ne remontent d’informations comme le montrent les captures d’écran ci-dessous.

jstat et VisualGC ne sont pas encore prêts pour G1

$ jstat -gccause 30572 5s
Warning: Unresolved Symbol: sun.gc.generation.0.space.1.capacity substituted NaN
Warning: Unresolved Symbol: sun.gc.generation.0.space.1.used substituted NaN
...
Warning: Unresolved Symbol: sun.gc.collector.0.invocations substituted NaN
Warning: Unresolved Symbol: sun.gc.collector.0.time substituted NaN
...
S0 S1 E O P YGC YGCT FGC FGCT GCT LGCC GCC
? ? ? ? 79.96 ? ? ? ? ? unknown GCCause No GC
? ? ? ? 79.96 ? ? ? ? ? unknown GCCause No GC


Actualité éditeurs / SSII

• Tomcat 6.0.24, version mineure mais non négligeable

Agilité

• Le pair-programming comment ça marche ?

RIA

• Firebug passe en version 1.5

Actualité éditeurs / SSII

Tomcat 6.0.24, version mineure mais non négligeable

Nous allons commencer par un clin d’oeil humoristique, même les plus grands ont des difficultés à builder, le projet Tomcat a brulé trois tags subversion pour faire une release sans défaut, il y a eu de nombreux problème d’adaptation des sauts de ligne aux plateformes Windows/Unix-Linux .

Ensuite, la sécurité avec la correction de la faille CVE-2009-3555 appelée « SSL-Man-In-The-Middle attack » qui intéressera ceux qui gèrent SSL avec Tomcat.

Enfin, nous avons retenu deux nouvelles fonctionnalités qui nous paraissent particulièrement utiles :

L’intégration de la RemoteIpValve pour connaitre l'adresse IP de l'internaute et le protocole (http/https) utilisé lorsque Tomcat est précédé de load balancers et/ou d'un serveur web. Nous en avons longuement parlé dans Tomcat : Adresse IP de l'internaute, load balancer, reverse proxy et header Http X-Forwarded-For et dans Tomcat, SSL, communications sécurisées et X-Forwarded-Proto.
Exemple :
Fragment de server.xml pour déclarer le RemoteIpValve avec utilisation de X-Forwarded-Proto :

<Valve className="org.apache.catalina.valves.RemoteIpValve" protocolHeader="X-Forwarded-Proto" />
<!-- AccessLogValve must be declared after RemoteIpValve -->
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
       prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/>

L'intégration du JmxRemoteLifecycleListener qui permet de figer le deuxième port d'écoute RMI et ainsi se connecter avec VisualVM et un tunnel SSH pour passer les firewalls. A nous le profiling sur les serveurs de production ! Mais attention aux chausses-trappes :

• il faut télécharger le catalina-jmx-remote.jar et le copier sous $TOMCAT_HOME/lib,
• un vilain problème de UnmarshalException/ClassNotFoundException dans les clients comme Hyperic HQ si vous activez useLocalPorts (contournement ici),
• les propriétés à définir dans setenv.sh (ou catalina.properties) en plus de la déclaration dans server.xml.

L'occasion d'une contribution ?
Exemple :
Fragment de setenv.sh pour déclarer des variables d'environnement de JmxRemoteLifecycleListener :

-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

Fragment de server.xml pour déclarer le JmxRemoteLifecycleListener :

<Listener className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
          rmiRegistryPortPlatform="6969"
          rmiServerPortPlatform="7969"
          useLocalPorts="true" />

Agilité

Le pair-programming comment ça marche ?

Stuart Wray de la Royal School of Signals, s'est fendu d'un article sur le fonctionnement du pair-programming dans l'édition de Janvier du magazine de l'IEEE. Dans l'article, il liste quatre bonne pratiques permettant de garantir selon ses termes, l'efficacité du développement par pair. Il ne s'agit pas de simplement développer à deux l'un au clavier et l'autre le doigt sur l'écran.

• Dialogue entre les développeurs :
  Il est important de verbaliser les problèmes rencontrés de façon intelligible. Présenter une difficulté à un tiers permet de garder le focus dessus et l'effort de présentation force à clarifier la situation. Il faut sortir la tête du mur pour résoudre les problèmes et parfois le seul fait de présenter le blocage permet de trouver la solution. L'auteur identifie la conversation comme un point clé permettant aux paires d'être et de rester productifs.
• Voir plus de détails :
  Un phénomène bien connu de tous, deux personnes ne voient pas les même choses au même moment. C'est à cela que sert la relecture sur le blog Xebia. Il y a toujours des fautes d'inattention, liés à des centre d'intérêts différents par exemple. En paire, un développeurs trouve plus rapidement certaines erreurs que son collègue qui en voit d'autres. Celui qui ne tape pas au clavier repère toujours beaucoup plus rapidement les coquilles.
  Stuart lève notre attention sur la fatigue des paires, en travaillant ensemble, les développeurs commencent à repérer les mêmes erreurs et à fixer leur attention sur les mêmes points. La productivité est alors en chute libre et l'apport du pair-programming se perd. Il faut prévoir des rotations régulière entre les paires pour se prémunir contre cet effet de bord.
• Combattre les mauvaises pratiques :
  Les deux développeurs doivent prendre l'engagement de coder en respectant une convention, en utilisant des bonnes pratiques. Chacun est juge du travail de son voisin, pourtant a terme c'est le travail des deux ensemble qui sera jugé. Cet engagement nécessaire des deux parties augmente la responsabilité de chacun sur la qualité du code produit. Posez vous la question : faites vous plus propre en développant seul dans votre cave ou en développant sous le regard attentif de votre paire ?
• Partager et juger l'expertise :
  Aucun individu n'a la même productivité et la différence varie au moins d'un facteur de un à dix entre deux individus. Cela implique des erreurs d'estimation temporelle par exemple si votre héros Java qui code les yeux fermés annonce une journée pour une tache et qu'elle est réalisée par un autre le temps passé ne sera sûrement pas d'une journée (Tous le monde ne peut pas coder les yeux fermés). C'est seulement en collaborant étroitement avec un développeur qu'il devient possible de juger de ses capacités. Mais avec le pair programming et la rotation des paires chaque développeur connait les domaines d'expertise des autres et sait se positionner par rapport aux autres. Les estimations seront donc plus réaliste dans une équipe en pair programming.

• La news sur InfoQ
• L'article complet

RIA

Firebug passe en version 1.5

Firebug, le plugin Firefox ultime pour le débogage de nos applications web, passe en version 1.5 (via Ajaxian).
Pour rappel, cet outil permet d'inspecter notre code HTML, CSS et Javascript, de l'éditer avec répercutions direct sur la page, d'analyser les flux XMLHttpRequest avec le nombre d'appels effectués ainsi que leur durée... En bref, un outil incontournable !

Les corrections de bugs sont nombreuses et les nouvelles fonctionnalités sont aussi au rendez-vous. On appréciera ainsi un mode d'inspection encore plus robuste, une boîte d'information rapide lors de l'inspection, l'ajout du bouton de persistance, le blocage du Javascript et des évènements sur un breakpoint, les nombreux nouveaux breakpoints ou bien encore l'explorateur XML pour une réponse de type XML. Ces deux derniers points seront à coup sûr des fonctionnalités clés pour le débogage de nos applications.

Si vous ne le possédez pas encore, c'est par ici que cela se passe.

Actualité éditeurs / SSII

• dm Server 2.0 transféré de SpringSource à Eclipse
• HornetQ 2.0, un véritable renouveau ?
• Nexus sous license GPL: Sonatype explique son choix

Agilité

• Le rôle des leaders dans une équipe agile

RIA

• Le nouveau jQuery est arrivé !
• Survol de la galaxie Flex.

Actualité éditeurs / SSII

dm Server 2.0 transféré de SpringSource à Eclipse

SpringSource annonce cette semaine la finalisation de dm Server 2.0. Il s’agit là d’une mise à jour importante qui agit principalement sur la réduction des nuisances causées au développeur de par la nature même d’OSGi. En effet, si beaucoup peuvent s’accorder sur le fait que la modularité dynamique peut constituer un intérêt sur de nombreux projets, c’est le coût en nuisances et en lourdeurs qui fait que cette solution n’est toujours pas très populaire au sein des applications d’entreprise. L’enjeu est donc crucial puisqu’il s’agit maintenant pour SpringSource de rendre attractif son serveur modulaire pour les entreprises. Un an et demi après le lancement du projet l’évolution de cette version 2.0 sera donc à suivre…

Parallèlement, SpringSource annonce le transfert de dm Server au sein de la fondation Eclipse. Il tiendra alors le rôle d’implémentation de référence de la spécification BluePrint OSGi 4.2 récemment finalisée. Tout comme le travail de simplification apporté à la nouvelle version, la standardisation permettra de rassurer les entreprises sur la pérennité de la technologie proposée par dm Server, qui restait jusqu’alors propriétaire.

HornetQ 2.0, un véritable renouveau ?

Pour mémoire, HornetQ est le nouveau nom de JBoss messaging. En bref, c’est pour le moment un projet Open Source sans support ayant vocation à s’intégrer dans le futur aux produits d’entreprise RedHat. Nous en parlions déjà en aout l’année dernière. La roadmap visait alors clairement la mise à disposition d’une API de messaging RESTful. Malheureusement, il n’y en a même pas l’ombre pour le moment et cela reste dans la roadmap. Gageons que quelques problèmes d’architecture accompagnés de bugs bloquants ont empêché le développement de cette nouvelle fonctionnalité.

L’annonce reprend principalement la précédente et ne liste rien de neuf par rapport à Aout 2009. Mais s’il y a bien dans le Jira du projet un grand nombre de bugs corrigés, c’est surtout la maturité du source qui a grandi.
Malgré tout, la bonne nouvelle est que JBoss espère bien pouvoir l’intégrer dans sa ligne produit et que RedHat continue l’investissement sur le projet.

Nexus sous license GPL: Sonatype explique son choix

Nexus est le gestionnaire de dépôts Maven développé par Sonatype. La version 1.0 est sortie à l’été 2008 sous la licence GPL. Il faut croire que Sonatype a fait face à de nombreuses critiques car la société vient de publier sur son blog un post intitulé « Why we chose the GPL for Nexus » lui permettant d’argumenter son choix. Alors quelles furent ces raisons ?
Le « problème » de la GPL est qu’elle force à redonner à la communauté les changements effectués dans le source au cas où le logiciel obtenu est redistribué. Dans le cas spécifique de Nexus, Sonatype explique que le produit était vu dès l’origine comme un produit commercial, sans question d’open source. Puis, trouvant le processus de développement plus fun, intéressant et plus productif, couplé au fait que l’équipe voulait « protéger son investissement », il fut décidé de passer en Open Source. Sonatype est franc sur ce dernier point et affirme l’avoir toujours été.
Ensuite, la société explique les idées qui guident généralement ses choix de licence:

• L’Affero GPL ne permet pas aux utilisateurs de développer des extensions, même à usage interne, sans avoir à redistribuer les sources. Dans le cas de Nexus, cela aurait sans doute impacté négativement son adoption.
• Sonatype considère que, pour un projet open source, passer d’une licence donnée à une licence plus restrictive n’est pas correct. On se souvient que certains on déjà réalisé cette transition en s’attirant alors des critiques d’utilisateurs. Sonatype déclare que ce ne sera pas leur cas.
• La documentation, elle, est soumise à un principe différent. En effet, la compagnie pense que celle-ci constitue une bonne partie de la plus-value apportée. Ainsi, ils ne veulent pas voir de concurrents se servir de leur travail. C’est pourquoi ils ont choisi la licence Creative Common 3.0 BY-ND-NC interdisant à quiconque de modifier cette documentation.

Au final, cet article est passionnant dans la mesure où il nous permet de bien appréhender le raisonnement derrière le choix d’une License pour des produits très répandus dans l’écosystème Java. Nous les utilisons tous les jours sans forcément nous poser de questions. Pourtant, pour certains clients, il peut être important de garder fermées leurs sources. Après, savoir si c’est une réelle nécessité ou un simple état d’esprit difficile à changer est une autre histoire !

Agilité

Le rôle des leaders dans une équipe agile

Mike Cohn, auteur de nombreux livres sur l’agilité et membre fondateur de l’Alliance Agile, revient sur le rôle des managers au sein d’une organisation de type agile. Un des principes forts des méthodes agiles est la mise en place d’une équipe auto-organisée, où il n’y a théoriquement plus de chef de projet. Cependant, Mike nous averti qu’une auto-organisation ne veut pas dire les développeurs font tout ce qu’ils veulent. Au contraire, Mike explique que des managers ont tout à fait leur rôle à jouer dans ce type d’organisation. Ainsi, il développe l’idée d’une influence subtile et indirecte des managers sur l’équipe.
C’est alors au fur et à mesure des challenges, des échecs et réussites que l’équipe évolue d’elle-même vers l’organisation la plus appropriée. Les managers sont néanmoins là pour poser certaines limites et contraintes.
A la fin de son article, Mike nous présente un exemple concret d’un scrum master au prise avec un développeur, qui est un peu trop solitaire, et nous expose comment il pourrait résoudre ce problème de manière subtile. Le scrum master peut être alors vu comme un agitateur au sein de l’équipe pour l’aider à devenir plus agile. Et, c’est là l’un des plus gros challenges d’un scrum master, qui consiste à naviguer entre un subtil mélange de contrôle et d’influence.

RIA

Le nouveau jQuery est arrivé !

Un an jour pour jour (ou presque) après la sortie de jQuery 1.3, voici venir la nouvelle mouture du framework qui nous arrive dans une version 1.4. Le détail complet des nouveautés se trouve sur cette page. Le mot d’ordre : performance !

L’API a subit une réécriture complète. Un des points marquants est la fonction live(), déjà présente dans la version précédente, qui supporte désormais tous les évènements Javascript (click, change…). Pour ce qui est des nouveautés au niveau de l’API, on retiendra plus particulièrement :

• contains() : vérifie l’existence d’un nœud DOM dans un autre nœud DOM,
• isEmptyObject() et isPlainObject() : vérifie si un objet est vide ou existant (new Object ou {}),
• detach() : supprime du DOM un set d’éléments,
• focusin() et focusout() : ajoute un événement de type focus,
• clearQueue() : supprime de la pile les éléments qui n’ont pas encore été lancés,
• delay() : définit un timer pour l’exécution de certains éléments dans la pile,
• toArray() : récupère tous les éléments du conteneur jQuery dans un tableau.

Côté performance, on peut noter une réelle amélioration pour les méthodes remove, html et empty. Un gros travail a donc été effectué au niveau des méthodes de manipulation du DOM. Il en va de même pour la gestion des attributs et des propriétés css.

Pour le téléchargement de la librairie production (minifié et GZippé) ou développement (code non compressé) ou pour consulter la documentation, je vous renvoie directement sur la home page du site. Et pour les fans de CheatSheet (comme moi ), la version 1.4 est déjà disponible au format HTML, PDF ou PNG.

Et si vous appréciez jQuery et le travail de toute l’équipe qui se trouve derrière, vous pouvez faire une donation de 20$ et ainsi recevoir un eBook jQuery gratuitement !

Survol de la galaxie Flex.

Vous voulez passer à Flex, mais vous ne savez pas par où commencer ? Suivant l’adage « Pour bien travailler il faut avoir de bons outils », InfoQ propose un survol de la galaxie Flex. Sans rentrer dans les détails de l’article, on notera :

• les IDE : le célèbre FlexBuilder, mais aussi IntelliJ, ou encore des environnements plus exotiques comme Amethyst, EnsembleTofino et FlashDevelop. Nous n’avons pas (encore) eu l’occasion d’essayer ces derniers, mais si l’un de nos lecteurs possède une expérience avec ces outils, qu’il n’hésite pas à la partager !
• les frameworks : là encore, outre les classiques (PureMvc, Cairgorm…), quelques petits nouveaux tentent d’émerger, dont deux qui nous ont interpellé : Ruboss (pour intégrer Ruby on Rails) et Prana (IoC). Nous espérons bientôt les tester.
• les outils de support du developpement : là encore, Flex commence à se doter d’un arsenal conséquent : tests unitaires (FlexMonkey), couverture de code (FlexCover), tests de GUI (RIATest). Il ne reste plus qu’à monter une usine logicielle digne de ce nom en agrégeant ces utilitaires.
• les outils d’intégration dans l’entreprise : là encore, un certains nombre de ces outils sont archi-connus (comme BlazeDs), et d’autres plus confidentiels, peuvent présenter un réel intérêt : intégration à Struts (FxStruts), AmFast (Python)… Nous aurons probablement l’occasion d’en reparler.

Au final, InfoQ propose un survol relativement complet et permet de découvrir de nouveaux outils. Ne reste plus qu’à les tester, ou à recueilli vos retours d’expérience !

Actualité éditeurs / SSII

• Java EE 6, Glassfish v3 et NetBeans 6.8 dans les bacs
• Terracota et Quartz : un premier produit disponible.

RIA

• GWT 2.0 est (enfin) là !
• Sortie de la release de FlexPMD 1.0

Le coin de la technique

• Le projet Lambda apparaît au sein d’OpenJDK
• Nouvelle version du meilleur IDE Java du monde…
• 10 ans d’attente et ECMAScript 5
• Nouvelle Milestone d’Eclipse Helios
• Spring Surf – le studio de composition de pages pour Spring MVC

Actualité éditeurs / SSII

Java EE 6, Glassfish v3 et NetBeans 6.8 dans les bacs

C’est la fin de longs mois d’attente, Sun nous livre finalement sa version 6 de la plateforme Java EE dont nous parlons depuis déjà longtemps sur le blog. Comme promis, c’est GlassFish v3 qui sert d’implémentation de référence à JavaEE 6. Le tout est fourni prêt à l’emploi : le SDK, l’implémentation serveur et l’IDE compatible. Vous pouvez donc d’ores et déjà essayer les EJB lite, les Servlet 3.0, la validation de Bean, l’injection de dépendance et bien sûr, la toute nouvelle JSF 2 « tant attendue ».
Voilà un beau cadeau de Noël que Sun nous offre, d’autant que la sortie de GlassFish v3 s’accompagne des plugins adéquats pour Eclipse et IntelliJ. Nous souhaitons longue vie et grand succès à cette nouvelle plateforme JavaEE.
Pour plus d’information sur le sujet:

• JavaEE6 à Devoxx
• La news sur le site de Sun
• Inteview de Roberto Chinnici sur InfoQ
• L’annonce sur The Server Side

Terracota et Quartz : un premier produit disponible.

Un peu moins d’un mois après le rachat de Quartz par Terracota, l’éditeur met en application son acquisition, en proposant Terracotta Quartz EX, un Job Store pour Quartz. Cette nouveauté permet de développer une plate forme de gestion de charge et de distribution des traitements basée sur une gestion des jobs en mémoire.
Pour ceux qui utilisaient Quartz de manière non clusterisée, une nouvelle version de Quartz permet d’utiliser une instance de serveur Terracota comme JobStore. Cela procure, automatiquement, à la fois une solution de persistance et de haute disponibilité pour la programmation des jobs. Cette implémentation repose sur le lock manager et la plate forme haute-dispo de Terracotta (et ne nécessite donc pas de base de données).
Pour ceux qui utilisaient déjà Quartz de manière clusterisée, à l’aide d’une base de données centrale, le nouveau Terracotta Job Store permet de continuer à utiliser le mode clusterisé, sans l’overhead dû à la base de données.

A n’en pas douter, comme pour EHCache, aquis il y a quelques temps déjà, Terracotta va rapidement proposer de nouvelles applications permettant de profiter au mieux des interactions possibles entre un scheduler et une plate-forme clusterisée.

Au passage, Quartz a subi un lifting afin que le framework respecte au mieux les normes Maven et s’intègre plus facile à Hudson.

Via infoQ

RIA

GWT 2.0 est (enfin) là !

L’une des sensations de la semaine dernière n’est autre que la sortie en release finale de GWT en version 2.0, quelques mois seulement après la mise à jour 1.7 qui ne faisait que corriger GWT pour les navigateurs récents.

Nous avons déjà bien couvert le sujet dans nos précédentes revues de presse, que ce soit pour la Milestone 1 ou la Release Candidate 1. Rien de nouveau donc si vous nous suivez régulièrement. On retrouve ainsi le development mode, le code splitting, l’intégration HTMLUnit, l’UIBinder, le RunAsync et bien d’autres. Le détail complet des différentes nouveautés se trouve sur cette page.

A noter aussi l’arrivée avec GWT 2.0 de Speed Tracer, un outil vous permettant d’analyser votre application et ainsi de repérer d’éventuels problèmes de performances.
Le plugin Eclipse a lui aussi été mis à jour et possède désormais de nouvelles fonctionnalités spécifiques à GWT 2.0, comme le support d’UiBinder et de ClientBundle.

Concernant la migration, les retours (comme celui-ci) sont plutôt encourageants et laissent présager une migration sans trop de difficultés. Les gains en performance se situent, comme on pouvait s’y attendre, au niveau du development mode et de son plugin pour débuguer directement dans le navigateur (ce bon vieux Hosted Mode ne va décidément pas me manquer). Même au niveau des librairies tierces, il n’y a pas de grosses incompatibilités remontées par l’auteur.

La section téléchargement se trouve ici.

Sortie de la release de FlexPMD 1.0

Une bonne nouvelle cette semaine pour les développeurs Flex : la sortie de FlexPMD, FlexCPD et FlexMetrics en release pour contrôler votre code. Voyons un peu plus en détail ces différents outils :

• FlexPMD

Nous vous en parlions en septembre, FlexPMD fournit maintenant des fonctionnalités supplémentaires :

• invocation depuis Eclipse grâce à son plugin,
• depuis FlashDevelop ou TextMate sur Mac OS X.

Le rapport peut être généré en HTML ou XML. Son rapport au format XML est un standard pouvant être exploité par tout intépréteur PMD comme le plugin d’Hudson.

• FlexCPD (Copy & and Paste Detector)
• FlexCPD permet comme son nom l’indique de détecter les duplications de code. Basé sur le moteur de JavaCPD, il peut être appelé en ligne de commande par une tâche Ant ou avec Maven. Les résultats sont exploitables dans Hudson également grâce au plugin DRY.
• FlexMetrics
• FlexMetrics permet d’avoir des métriques sur votre code Flex. Comme FlexCPD, il peut être appelé en ligne de commande, avec Ant ou Maven. Pour interpréter les résultats de l’outil, il est possible d’utiliser le plugin JavaNCSS.

Des outils intéressants donc, pour ajouter vos projets Flex dans vos outils d’intégration continue.

Le coin de la technique

Le projet Lambda apparaît au sein d’OpenJDK

Mark Reinhold annonce la création d’un nouveau sous-projet au sein d’OpenJDK : le Projet Lambda. Son but est d’apporter une implémentation des closures pour le JDK 7. Dans la mesure où il est prévu que cette fonctionnalité soit implémentée dans un premier temps pour être spécifiée par la suite, il sera particulièrement intéressant de suivre l’évolution de ce projet dans les prochains mois afin de découvrir à quoi pourraient ressembler les closures dans la prochaine version de Java.

Un premier document de travail a été mis à disposition. Il présente de manière non formelle la proposition pour l’implémentation des closures qui est retenue pour le moment. Cette proposition se base sur les trois principales bases de travail qui s’étaient dégagées lors des débats précédents, à savoir la BGGA, la CICE et la FCM. Elle met en avant principalement :

• La syntaxe retenue pour la définition de fonctions anonymes qui se base sur le caractère #, ainsi #()(42) définit une fonction retournant toujours 42.
• La définition d’un type Java pour ces fonctions. Ainsi la fonction #()(42) prise en exemple précédemment a pour type #int().
• Les fonctions anonymes peuvent être converties automatiquement lorsqu’elle sont passées en argument d’une méthode attendant une instance d’une classe anonyme. En clair, il sera possible de créer une nouvelle thread avec new Thread(#() { ...some code... } ) plutôt que de fournir au constructeur une classe anonyme implémentant Runnable pour définir la méthode run(). Cette possibilité permettra donc aux closures d’être utilisées directement dans les APIs existantes !
• Dans certaines conditions, les closures sont à même d’utiliser les variables accessibles dans le contexte dans lequel elles sont définies.
• Le mot clé this peut être utilisé si la closure est déclarée depuis une méthode d’instance, il référence alors l’instance à laquelle est attachée la méthode concernée.

Enfin, pour faciliter les évolutions des APIs existantes que pourraient justifier ces nouvelles possibilités du langage, la notion de méthodes d’extensions est introduite. Il s’agit de permettre la définition de méthodes au sein des interfaces dont l’implémentation par défaut serait une méthode statique indiquée en argument.

Pour plus de détails sur cette proposition, n’hésitez pas à lire le document de travail, volontairement très didactique, du projet Lambda.

Nouvelle version du meilleur IDE Java du monde…

… en tout cas, c’est une des accroches d’IntelliJ IDEA
JetBrains continue donc sur sa lancée d’évolution majeure de ses produits.
Ainsi, après TeamCity 5.0, c’est au tour d’IntelliJ IDEA d’évoluer et de passer en version 9.

Les nouveautés sont très nombreuses. Les points importants retenus par JetBrains sont :

• la rapidité de l’IDE,
• l’amélioration de la lecture du code (meilleure coloration syntaxique…),
• meilleure UI, une structure de projet plus flexible,
• premier support Java 7 avec JSR308, support de JEE 6,
• meilleur support de Groovy,
• plugin de développement Android,
• support d’autres frameworks (Tapestry, GAE, GWT 1.7 et 2.0, Spring 3.0 et Spring Security 2.0 et 3.0),
• meilleur support de Maven,
• plusieurs nouvelles fonctionnalités pour le développement d’applications Flex. (Air, FlexUnit…).

Deux éditions nous sont proposées en téléchargement (avec différentes licences) :

• l’édition ultimate : complète, gratuite pour les licences Classroom et Open Source Project ;
• l’édition community : produit sous licence Apache 2.0 proposant en standard l’IDE pour Java et Groovy (et quelques plugins gratuits).

Et même quelques Friends of Eclipse vous encouragent à le télécharger Comme on dit : l’essayer, c’est l’adopter !

10 ans d’attente et ECMAScript 5

ECMAScript, langage de programmation de type script implémenté entre autres par Javascript et ActionScript, passe en version 5 (via InfoQ).
La version 4 ayant été abandonnée, il faut remonter à 1999 pour voir la dernière version d’ECMAScript et sa version 3… Ce fût long, mais au moins il est là !

Comme nous le rappelle Alex Blewitt, celle-ci essayera de s’imposer là où la version 4 (qui a d’ailleurs été abandonnée) a échoué, à savoir être pleinement supportée par les navigateurs actuels. En effet, nos sites web et nos outils évoluent mais pas la spécification ECMA. Côté application, c’est une nouvelle fois Google Wave (en GWT donc Javascript) qui est cité en exemple pour son côté collaboratif live. Et pour les outils, l’auteur cite Speed Tracer (inclus dans la release GWT 2.0) qui va nous permettre de détecter et de fixer certains problèmes de performances sur nos applications.

On notera la rétrocompatibilité avec les anciennes applications ECMAScript grâce au code suivant :

"use strict;"

Ce code indique au runtime ECMAScript qu’il faut être compatible avec la version 5 d’ECMAScript et ses différentes nouveautés. Il sera possible d’être compatible sur tout le document ou seulement sur une partie de code. Concernant les anciens runtimes, le strict sera compris mais ne changera pas leur comportement.

Concernant les nouveautés de la spécification, on retiendra :

• déclaration de variable obligatoire : terminé les i=3, il faudra obligatoirement passer par var i=3 ;
• eval devient un mot clé réservé ;
• l’opérateur with disparaît ;
• les fonctions et objets ne peuvent plus avoir des arguments/propriétés doubles avec le même nom ;
• nouvel objet JSON et mécanisme de parsing désormais standard ;
• méthode trim pour l’objet String ;
• méthodes indexOf, map, filter and reduce pour l’objet Array;
• nombreuses nouvelles méthodes sur Object dont seal (empêche l’ajout/la suppression de propriétés), freeze (propriétés read-only), keys (liste les propriétés de l’objet) ou getPrototypeof (prototype de l’objet).

Beaucoup de bonnes nouvelles pour les développeurs donc. La rétrocompatibilité permettra une mise en place progressive sur notre code, soit par bloc soit directement sur toute la page. Côté API, on avait déjà l’habitude d’utiliser ces fonctions par l’intermédiaire de librairies comme jQuery mais cette standardisation est la bienvenue.

Nouvelle Milestone d’Eclipse Helios

Eclipse 3.6, nom de code Helios, vient de sortir en version Milestone 4. De nouvelles fonctionnalités sont apparues avec ce build, comme :

• la possibilité d’éditer plusieurs quick fix en même temps
• les « virtual folders » qui permettent de créer des regroupements de fichiers au niveau du projet pour une navigation plus facile
• amélioration du plugin JUnit

Pour plus de détails, voici la liste des améliorations et l’annonce officielle d’EclipseSource.

Spring Surf – le studio de composition de pages pour Spring MVC

Spring s’intéresse à présent à la gestion documentaire, grâce à une collaboration avec Alfresco, le système de GED Open Source Java, qui a démarré le projet Surf. A l’origine, l’objectif était de proposer aux utilisateurs d’Alfresco une plateforme pour développer leurs propres applications connectées à la GED.

Pour profiter des facilités de développement d’applications que propose Spring avec Spring Roo et Spring Tool Suite, Alfresco commence à migrer son projet Surf dans l’incubator Spring Extension.

Pour le moment, les principales informations se trouvent sur le wiki d’Alfresco, la page d’accueil de Spring Surf étant encore très succincte.

Pour démarrer, seuls l’addon Spring Roo et un QuickStart sont disponibles chez Spring (pas encore de tutorial). Et pour mieux connaitre ce que deviendra cette extension, l’application Alfresco Share, basée sur la plateforme Surf donne un bon nombre de pistes comme :

• Création d’applications uniquement par scripting (Freemarker, Groovy, PHP, JavaScript)
• Ajout de pages à une application basée sur le framework Spring MVC
• Développement avec un modèle extensible de templates, composants, styles, etc.

Les styles

Avec Flex, les styles sont très simples à mettre en place, et se font de la même manière qu’en HTML :

• Soit via la définition des styles directement dans le fichier MXML :

<mx:Style>
	myStyle {
		fontFamily: "arial";
		background-color:#FFFFFF;
	}
</mx:Style>

• Soit via la définition d’une feuille de styles CSS, déclarée dans le fichier MXML :

<mx:Style source="css/xebia.css"/>

Concernant le composant DataGrid, modifier les couleurs des lignes devient trivial avec la propriété alternatingItemColors. Néanmoins la situation se corse lorsque nous devons appliquer ces couleurs aux lignes d’une seule colonne…

Exemple

Prenons un exemple :

XebiaCustomDataGrid1.mxml

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" minWidth="1024" minHeight="768">
	<fx:Script>
	<![CDATA[
			import mx.collections.ArrayCollection;
			[Bindable]
			public var xebia:ArrayCollection = new ArrayCollection([
				{Company:"Xebia France", City:"Défense", Benefits:200000},
				{Company:"Xebia Hollande", City:"Hilversum", Benefits:400000},
				{Company:"Xebia Inde", City:"New Dehli", Benefits:150000},
				{Company:"Xebia US", City:"New York", Benefits:500000},
				{Company:"Xebia Allemagne", City:"Berlin", Benefits:160000},
				{Company:"Xebia Espagne", City:"Barcelone", Benefits:80000},
				{Company:"Xebia Portugal", City:"Lisbonne", Benefits:75000},
				{Company:"Xebia Italie", City:"Milan", Benefits:110000}
			]);
		]]>
	</fx:Script>
	<mx: DataGrid dataProvider="{xebia}" sortableColumns="false" selectable="false" height="228" width="515">
		<mx:columns>
			<mx: DataGridColumn headerText="Company" dataField="Company"/>
			<mx: DataGridColumn headerText="City" dataField="City"/>
			<mx: DataGridColumn headerText="Benefits" dataField="Benefits"/>
		</mx:columns>
	</mx: DataGrid>
</s:Application>

Dans cet exemple, nous avons un simple DataGrid remplit avec une ArrayCollection, et dont les lignes ont des couleurs alternées.

Dans ce second exemple, nous ajoutons une CSS :

xebia.css

.grid {
	alternatingItemColors: #ffccff, #ff99cc;
}
.header {
	fontWeight: bold;
}

XebiaCustomDataGrid2.mxml

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" minWidth="1024" minHeight="768">
	<fx:Style source="css/xebia.css"/>
	<fx:Script>
	<![CDATA[
			import mx.collections.ArrayCollection;
			[Bindable]
			public var xebia:ArrayCollection = new ArrayCollection([
				{Company:"Xebia France", City:"Défense", Benefits:200000},
				{Company:"Xebia Hollande", City:"Hilversum", Benefits:400000},
				{Company:"Xebia Inde", City:"New Dehli", Benefits:150000},
				{Company:"Xebia US", City:"New York", Benefits:500000},
				{Company:"Xebia Allemagne", City:"Berlin", Benefits:160000},
				{Company:"Xebia Espagne", City:"Barcelone", Benefits:80000},
				{Company:"Xebia Portugal", City:"Lisbonne", Benefits:75000},
				{Company:"Xebia Italie", City:"Milan", Benefits:110000}
			]);
		]]>
	</fx:Script>
	<mx: DataGrid dataProvider="{xebia}" sortableColumns="false" selectable="false" styleName="grid" headerStyleName="header" height="228" width="515">
		<mx:columns>
			<mx: DataGridColumn headerText="Company" dataField="Company"/>
			<mx: DataGridColumn headerText="City" dataField="City"/>
			<mx: DataGridColumn headerText="Benefits" dataField="Benefits"/>
		</mx:columns>
	</mx: DataGrid>
</s:Application>

On notera l’ajout des attributs styleName et headerStyleName dans les propriétés du DataGrid, ainsi que de la déclaration de la CSS :

<fx:Style source="css/xebia.css"/>

Nous obtenons ainsi le rendu suivant :

Mais que faire si nous voulons appliquer un style sur une seule colonne ? La solution consiste à surcharger les cellules de la colonne concernée par un renderer. Pour ce faire, une classe ActionScript doit être mise en place.

Voici la classe CustomCell.as :

public class CustomCell extends Label
     {
      override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
        {
            super.updateDisplayList(unscaledWidth, unscaledHeight);
            var g:Graphics = graphics;
            g.clear();
	    	if (DataGridListData(listData).rowIndex % 2 == 0) {
	        	g.beginFill(0xffdfbf);
	     	} else {
	     		g.beginFill(0xffc080);
	     	}
	        g.drawRect(0, -2, unscaledWidth+1, unscaledHeight+4);
	        g.endFill();
        }
     }

Ainsi pour chaque ligne, nous dessinons un rectangle dans la cellule avec la même alternance de couleurs.
Il ne nous reste plus qu’à appliquer ce renderer au DataGrid.

XebiaCustomDataGrid3.mxml

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" minWidth="1024" minHeight="768">
	<fx:Style source="css/xebia.css"/>
	<fx:Script>
	<![CDATA[
			import mx.collections.ArrayCollection;
			[Bindable]
			public var xebia:ArrayCollection = new ArrayCollection([
				{Company:"Xebia France", City:"Défense", Benefits:200000},
				{Company:"Xebia Hollande", City:"Hilversum", Benefits:400000},
				{Company:"Xebia Inde", City:"New Dehli", Benefits:150000},
				{Company:"Xebia US", City:"New York", Benefits:500000},
				{Company:"Xebia Allemagne", City:"Berlin", Benefits:160000},
				{Company:"Xebia Espagne", City:"Barcelone", Benefits:80000},
				{Company:"Xebia Portugal", City:"Lisbonne", Benefits:75000},
				{Company:"Xebia Italie", City:"Milan", Benefits:110000}
			]);
		]]>
	</fx:Script>
	<mx: DataGrid dataProvider="{xebia}" sortableColumns="false" selectable="false" styleName="grid" headerStyleName="header" height="228" width="515">
		<mx:columns>
			<mx: DataGridColumn headerText="Company" dataField="Company"/>
			<mx: DataGridColumn headerText="City" dataField="City"/>
			<mx: DataGridColumn headerText="Benefits" dataField="Benefits" itemRenderer="renderer.CustomCell"/>
		</mx:columns>
	</mx: DataGrid>
</s:Application>

Nous remarquons que la propriété itemRenderer a été ajoutée sur la troisième colonne du DataGrid.

Ainsi nous obtenons le rendu suivant :

Enfin à travers cet exemple nous revoyons une des limites de Flex: malgré la richesse des composants et de leurs comportements, lorsque les développements deviennent un peu plus subtils, du code ActionScript est nécessaire, là où dans cet exemple une simple instruction CSS aurait suffit…

En espérant que cette solution puisse aider d’autres personnes !

Vous pouvez télécharger les sources sur le SVN de Xebia France.

Qu’est ce qu’un effet ?

Flex 3

En Flex, il est possible de définir des effets pour des transitions ou lors du déclenchement d’un évènement (hide, show par exemple).
Nous allons reprendre l’exemple du Dissolve disponible sur le Flex 3 Component Explorer.
On commence par définir les effets :

<mx: Dissolve id="dissolveOut" duration="1000" alphaFrom="1.0" alphaTo="0.0"/>

Puis on indique au composant cible, l’effet qu’il doit utiliser lorsque l’on cache le label :

<mx:Label text="Nokia 9930"
          fontSize="14"
          visible="{cb1.selected}"
          hideEffect="{dissolveOut}"/>
...
<mx:CheckBox id="cb1" label="visible" selected="true"/>

Dans Flex 3, il n’est pas possible de gérer des effets sur la valeur d’une propriété comme le texte ou la couleur par exemple. Les effets ne sont en effet applicables que sur les composants.

Flex 4

La nouveauté dans Flex 4 tient tout d’abord dans la définition d’une nouvelle super classe Animate qui vient remplacer TweenEffect. Cette nouvelle super classe fournit de nouvelles propriétés telles que easer, interpolator et motionPaths que nous verrons par la suite.

Dans cette nouvelle version, les effets sont plus flexibles et il est possible de :

• modifier la valeur des propriétés telles que le gradient d’une couleur ou la taille,
• régler la vitesse de l’effet, lui donner une accélération au début ou à la fin par exemple,
• déplacer plus facilement les composants lors d’un effet.

Les nouveaux effets

Les effets 3D

Parmi les nouveaux effets, voici probablement les plus impressionnants d’entre eux : les effets en trois dimensions. Grâce à Flash Player 10 qui est maintenant capable de représenter un objet 3D, on peut par exemple exécuter un effet de déplacement en profondeur ou une rotation.

La configuration des effets

Avec cette nouvelle super classe Animate viennent de nouvelles propriétés :

• easer : l’atténuation de l’effet (en quelque sorte une accélération ou décélération avec laquelle l’effet sera appliqué),
• interpolator : fonction utilisée par l’effet pour calculer les valeurs à prendre pour une propriété entre le début et la fin de cet effet,
• motionPaths : un vecteur contenant des objets MotionPath, chacun portant le nom et la valeur que la propriété peut prendre,
• repeatBehavior : permet de répéter l’effet.

Avec ces nouvelles fonctions, il est encore plus simple de réaliser des effets customisés comme par exemple un bouton qui s’enfonce lorsque l’on clique dessus, ou un changement de couleur lorsque le curseur pointe un composant. Maintenant à vous de laisser parler votre imagination.

Actualité éditeurs / SSII

• Amazon lance Relational Database Service
• Oracle tente de rassurer la communauté Sun
• Keynote de Rod Johnson à SpringOne/2GX 2009

Le coin de la technique

• Optimisez vos requêtes SQL
• Apache POI 3.5
• Interminables débats sur la mort de Java
• Une version de tcServer pour les développeurs

Evènements de notre communauté en France et à l’étranger

• Flex 4 chez les Tontons Flexeurs

Actualité éditeurs / SSII

Amazon lance Relational Database Service

Quelques mois après la disponibilité d’Amazon Elastic MapReduce, le libraire américain continue d’enrichir sa gamme de services de Cloud Computing en lançant Amazon Relational Database Service (RDS).

RDS offre une base de données MySQL sur une plate-forme dynamiquement provisionnable. Suivant la logique initiée avec ses autres services, la facturation est fonction de la consommation réelle, la gestion des instances se fait à l’aide d’un Web Service spécifique à RDS et leur monitoring est possible par CloudWatch.

Outre ces caractéristiques communes aux services d’Amazon, on retiendra principalement de RDS :

• Utilisation de MySQL 5.1 avec InnoDB,
• Offre de réplication prévue pour assurer la haute disponibilité, mais non disponible à ce jour,
• Système de gestion des backups.

Par ce service, Amazon déleste ses clients des principales tâches liées à l’administration d’une base de données relationnelle. Répondant ainsi à un besoin réel, on peut s’attendre à ce que ce service, s’inscrivant dans l’offre homogène d’Amazon, rencontre un succès commercial.

Plusieurs réactions et commentaires ont suivi cette annonce, on retiendra particulièrement l’observation de Krishnan Subramanian, sur le coup dur que constitue ce nouveau service pour FathomDB, une entreprise qui proposait un service d’hébergement MySQL sur EC2. Il remarque alors qu’il est délicat pour des startups de parier sur de tels services propriétaires.

Oracle tente de rassurer la communauté Sun

Depuis l’acquisition de Sun par Oracle en avril dernier, le futur de la stack Sun a fait l’objet de peu de communiqués. Quelques rumeurs ici ou là sur le futur de MySQL ont fait surface, après la disparition du lien permettant de télécharger les premières briques de MySQL 6. C’est peut-être pour couper court à ce genre de bruits de couloir qu’Oracle présente ses intentions sur la stack Sun via la mise à jour de sa FAQ . En résumé « on garde tout, et on en fait toujours plus » :

• Oracle dit vouloir passer plus de temps sur Solaris et Sparc que Sun ne l’a fait par le passé. La collaboration d’ingénieurs base de données Oracle et Sun ouvre d’ailleurs de nouvelles perspectives.
• Côté virtualisation, tous les produits Sun ‘devraient’ continuer à être développés : VDI, Secure Global Desktop, Sun Ray, and VirtualBox.
• Un alignement entre Oracle Weblogic Server et Glassfish Enterprise Server va être effectué. Glassfish reste l’implémentation de référence open source pour Java EE 6.
• Netbeans restera une solution alternative open source à Oracle JDeveloper et Oracle Enterprise Pack pour Eclipse.
• MySQL devrait être ajouté à la liste des bases de données de la suite Oracle au même titre que Berkeley DB, une base de données open source.

Comme vous pouvez le constater, rien de très précis, tout est au conditionnel. Le but est avant tout de ne surtout pas se mettre à dos les différentes communautés.

Keynote de Rod Johnson à SpringOne/2GX 2009

SpringSource est actuellement un des plus grands agitateurs de notre écosystème. Et donc quand Rod Johnson, le papa de Spring, vient donner un keynote en ouverture du plus gros évènements annuel de l’éditeur, on écoute avec attention. Grâce à InfoQ, il est possible de retrouver cette intervention en différé.
En résumé, pas grand chose de nouveau, mais Rod Johnson enfonce le clou sur les sujets que Spring met en avant depuis quelques mois déjà :

• Spring 3.0 : les nouvelles fonctionnalités, et les scénarios d’upgrade.
• Les languages dynamiques : Groovy et Grails, une fois encore à l’honneur
• Les outils destinés aux developpeurs: tcServer (voir par ailleurs), Spring Insight, SpringSource Tool Suite
• Les grandes manœuvre de l’éditeur : aquisition par VMWare (pas grand chose à se mettre sous la dent de ce coté là)
• Le futur de SpringSource : CloudFoundry et les Cloud d’entreprise en Java

En bref, un très bon résumé (pour ceux qui reviendraient de longues vacances) des changements qui nous attendent dans les mois à venir, impulsés par l’un des éditeurs les plus dynamiques du monde JEE.

Le coin de la technique

Optimisez vos requêtes SQL

Nous sommes tombés sur ce post qui nous propose 15 moyens pour optimiser vos requêtes SQL. Si quelques-unes d’entre elles vous paraitront être issues du bon sens commun, d’autres méritent le détour :

• Prenez le plus grand soin de vos index : Le contenu des index primaires se doit d’être le plus petit possible, les index uniques sont en règle générale plus performants.
• Recherchez par wildcard avec certaines précautions : Privilégiez l’utilisation de wildcard à l’utilisation de SUBSTR. Les wildcards postfixés sont plus performants que les wildcards préfixés. Dans la mesure du possible n’hésitez pas à n’indexer qu’une sous partie d’une chaîne de caractères plutôt que la chaîne dans son ensemble. En général utilisez les types de données les plus petits possibles.
• Simplifiez vos requêtes : Privilégiez l’utilisation de l’opérateur EXIST à une utilisation de COUNT. Limitez le nombre de lignes à retourner pour éviter la récupération complète d’une table. Utilisez des valeurs par défaut dans vos colonnes pour simplifier vos requêtes.
• Évitez les scans inutiles : Remplacer l’opérateur NOT d’une expression complexe par son inverse permet de ne pas évaluer l’intégralité de celle-ci. Transformez une sous-requête dans un IN par une sous-requête dans un FROM (et simulez ainsi une table virtuelle). Les UNION sont en principe plus efficaces que les OR car ils permettent d’optimiser l’utilisation des index.

Le tuning de requêtes SQL n’est pas simple, les commentaires sur le billet original en témoignent. Il dépend grandement de la base de données et de sa configuration. La base de données repose sur des statistiques pour savoir quand utiliser ses index. De ce fait, l’amélioration de la performance de vos requêtes commence le plus souvent par une analyse du plan d’exécution de celles-ci. Celui-ci vous permettra de trouver comment poser vos index. Enfin, certaines bases de données comme Oracle vous permettent d’agir directement sur son plan d’exécution à partir de votre requête, par l’intermédiaire de SQL HINT. A n’utiliser qu’en dernier recours

Apache POI 3.5

Du nouveau sur le support des documents Office 2007 en Java (sujet déjà abordé il y a un an) avec Apache POI qui est sorti il y a un mois en version finale 3.5 (via InfoQ). Parmi les nombreuses nouveautés, on retiendra surtout le support des fichiers .docx et .xlsx et plus globalement des documents Office 2007 (mais il aura fallu attendre un an entre la beta 3 et la version finale !).

Plusieurs librairies nous offrent déjà la possibilité de gérer nos fichiers Office 97-2003 (format Microsoft OLE2). Peu d’entre elles proposent la gestion des fichiers Office 2007 (format Microsoft Office Open XML ou OOXML) : par exemple Aspose.Word gère uniquement les fichiers Word 2007. Avec Apache POI 3.5, c’est toute la gamme de produits Office 2007 qui se trouve ainsi supportée.

Quelques modifications seront toutefois nécessaires dans votre code pour supporter ce nouveau format. En effet, le modèle org.apache.poi.hssf.usermodel.HSSF actuel reste compatible OLE2 mais ne supportera pas OOXML. Il faudra ainsi passer par le nouveau modèle org.apache.poi.ss.usermodel.HSSF pour bénéficier de ce support. Ce nouveau modèle s’appuyant fortement sur l’ancien, l’équipe précise que le switch ne devrait pas être trop ardu.

Le téléchargement se passe comme d’habitude sur les miroirs d’Apache.

Interminables débats sur la mort de Java

A chaque année ses raisons d’annoncer la mort de Java ; le débat n’est pas nouveau et les arguments se renouvellent depuis le début des années 2000 :

• Lourdeur de J2EE
• Complexité et densité de l’écosystème Java
• Manque d’intégration des solutions et les faiblesses du langage face au rival Microsoft .Net
• Inadaptation à la création d’interfaces pour le Web et pour les clients lourds
• Manque de productivité face aux nouveaux langages : Python, Ruby, …

En 2009 l’argumentaire se tourne maintenant vers les langages alternatifs pour la JVM – principalement Groovy et Scala – et vers l’incertitude liée à la gouvernance de Java. Ainsi il y a quelque semaines, Stephen Colebourne postait un inquiétant graphique montrant l’évolution décroissante du nombre de JSR créées auprès du JCP au cours des années. Il se demandait alors si cela pouvait être pris comme une perte de vitesse ou comme un signe de maturité mais remarquait que l’innovation était maintenant principalement portée par les communautés Open Source.

Stephan Schmidt apportait, en septembre dernier, une analyse intéressante du débat sur la mort de Java. Il commençait par dissocier les 3 composantes de Java que sont le langage, la JVM et le JDK, chacun ayant une pérennité distincte. Il exposait alors différents points :

• La quantité d’offres d’emploi en Java reste constante comme le montre le graphe Indeed (devenant un classique en argumentaire).
• Avant la mort de Java, un successeur doit se distinguer. Or Ruby et Python ont peiné à faire leur place dans le monde de l’entreprise. Il reconnaît en revanche le positionnement appréciable de Groovy suite à sa prise de contrôle par SpringSource puis par VMWare et l’innovation intéressante portée par Scala.
• Java est toujours à même d’apporter les caractéristiques qui ont amené son succès : pas de pointeurs, gestion de la mémoire, orientation vers l’entreprise et Internet, gestion simple du parallélisme.
• C’est le monde de l’entreprise qui permet le succès d’un langage, or Java répond toujours à ses besoins même si le langage présente des défauts nuisant à la productivité.
• Java a perdu il y a bien longtemps le hype qui l’entourait, mais cela ne signifie pas pour autant sa mort.

A travers l’évolution du débat, un aspect majeur ressort : les critiques portent maintenant principalement sur le langage Java, la JVM étant reconnu pour ses qualités et la capitalisation qui s’est faite autour d’elle. Dès lors, la JVM se présente comme une plate-forme standard pour les développements, non sans rappeler le statut acquis par l’environnement x86 d’Intel des années auparavant.

La mort annoncée du langage Java au profit de langages alternatifs pour la JVM doit, quant à elle, probablement être modérée. En effet Java, fort de ce que Sun décrit comme la plus grosse communauté de développeurs au monde, n’est actuellement clairement pas menacé.

Une version de tcServer pour les développeurs

SpringSource vient d’annoncer la sortie prochaine (pour l’instant, une preview est téléchargeable) de tcServer Developer Edition. Que trouve t’on dans ce joli package ?

Côté serveur d’application, rien de nouveau, c’est toujours du 100% Tomcat.
C’est une fois de plus dans les à-côtés que tcServer se distingue, avec l’arrivée de Spring Insight. Spring Insight, c’est une console qui va vous permettre de surveiller ce qui se passe au cœur de votre application, à la fois en prenant un point de vue global, mais aussi en zoomant très précisément sur une requête HTTP donnée.

Et quoi de nouveau me direz vous ? Et bien, à vrai dire, pas de rupture technologique (plusieurs outils permettaient de réaliser des mesures comparables) mais une facilité d’intégration à votre application, sujet si cher à Spring. Tout se passe en AOP (rien à faire donc dans votre code), toutes les informations sont stockées en mémoire (pas de base de données, mais en contrepartie, une augmentation de la mémoire consommée par votre application) et les principaux frameworks du marché peuvent être scrutés en utilisant un mécanisme de plugin.
En revanche, Spring est très clair : il s’agit d’un outil de développement : son utilisation en production exposerait vos applications d’un point de vue sécurité.
Une fois de plus, SpringSource joue la carte du tout intégré et de la simplicité, et risque de séduire à la fois des développeurs et des Q&A un tant soit peu sensibles à la qualité intrinsèque d’une application.

Nous avons aimé :

• L’expressivité des métriques qui identifient les URL d’invocation, les principaux composants (actions Spring MVC, composants métier, etc), les transactions et les accès SGBD avec les requêtes SQL.
• La granularité macro qui est souvent plus facile à comprendre que les mesures ultra-détaillées que nous proposent les profilers java.

Notre souhait : l’intégration à l’environnement de développement et au code source de l’application en cliquant sur les graphes de Spring Insight.

Le screencast et la preview de tcServer Dev. se trouvent sur le blog de SpringSource.

Evènements de notre communauté en France et à l’étranger

Flex 4 chez les Tontons Flexeurs

Les tontons flexeurs, le rendez-vous incontournable des flexeurs et des autres, nous propose une nouvelle présentation qui portera sur les nouveautés de Flex 4.
Christophe Coenraets, évangéliste senior chez Adobe, nous présentera ainsi les nouveautés de LiveCycle Data Services 3, le Model-Driven Developpement avec FlashBuilder 4 et l’intégration de Flex avec Spring.
La présentation se déroulera le mardi 10 novembre de 14h à 16h. Les inscriptions se font comme d’habitude sur l’evenbrite.

Actualité éditeurs / SSII

• La fondation Eclipse se prépare à Servlet 3.0 avec Jetty 7.0
• Sonar 1.11

RIA

• Air ‘Athena’
• DHTMLX 2.5
• Tips and Tricks Maven 2

Le coin de la technique

• Sécurité : 5 choses de plus que les agresseurs d’applications web ne vous diront pas
• Les optimisations du JDK 6u14 activées par défaut sur le JDK 7

Actualité éditeurs / SSII

La fondation Eclipse se prépare à Servlet 3.0 avec Jetty 7.0

La fondation Eclipse nous livre une nouvelle version de Jetty estampillée 7.0. Côté nouveauté, pas grand chose à vrai dire. Il y a évidemment l’habituelle série de corrections de bugs et d’améliorations de performance. Cette nouvelle version marque surtout le début de la route vers l’implémentation des servlets 3.0 prévue pour Jetty 8.0. C’est aussi l’occasion pour Eclipse d’assimiler un peu plus le projet en changeant principalement le package ancêtre de org.mortbay vers org.eclipse, gare au refactoring donc. A noter tout de même, Jetty est maintenant livré sous une forme modulaire pleinement compatible OSGI. Webtide en profite pour livrer la même version de Jetty, en y intégrant des modules additionnels:

• JSP de glassfish
• JTA d’atomikos
• plugin maven
• integration d’ant
• configuration Spring

Jetty 6 sera encore maintenu pendant quelques temps (aucune précision de la part d’Eclipse), tous les nouveaux développements seront faits sur Jetty 7, et la branche 8 sera en pré-release dans les prochains mois et supportera l’API Servlet 3.0.

• L’annonce sur la ML
• La news d’InfoQ
• La page Jetty chez Eclipse
• La page Jetty chez Codehaus

Sonar 1.11

SonarSource nous gratifie d’une version 1.11 du désormais célèbre outil de suivi de qualité Sonar. Comme souvent, de nombreux de bugs ont été corrigés. Parmi les améliorations, on peut noter les passages à Hibernate 3.3 et GWT 1.7. Au chapitre des nouvelles fonctionnalités, la possibilité de réutiliser les fichiers de configuration PMD et CheckStyle définis dans le pom permettra de plus aisément éviter les doublons.

SonarSource tente de faciliter la vie des développeurs de plugins avec l’apparition d’un archétype Maven pour créer des plugins Sonar. D’autres nouveautés d’API, comme le filtrage de widgets suivant différents critères (comme le rôle utilisateur ou la langue choisie), ajoutent de la flexibilité.

• L’annonce sur le blog Sonar avec plein de jolies images.
• La release note.

RIA

Air ‘Athena’

Non, ce n’est pas une nouvelle marque de baskets, mais, comme les flexeurs le savent depuis le Flash Camp de mai, le nom de code de la future version de Adobe Air, la version 2.0. Comme on s’y attendait, celle-ci fonctionnera avec Flash 10 et Flex 4. Même si aucune date officielle n’a été avancée, Adobe dévoile peu à peu les principales évolutions de sa plate-forme, nouveautés répertoriées par Elad Elrom sur InsideRIA.
Commençons par celle qui nous semble vitale dans l’adoption de AIR / Flex à grande échelle, à savoir une amélioration drastique des performances. Les équipes d’Adobe ont mis l’accent sur la réduction des ressources (CPU et mémoire) consommées par le runtime AIR. Les tests effectués sur une mini application montrent en effet une diminution des ressources utilisées (en regard de la version 1.5). Reste à tester ces optimisations sur une application gourmande… Toujours au chapitre performance, Adobe promet une optimisation de Webkit (le browser open source embarqué par AIR) et une installation Linux native.
Au menu des nouveautés, nous avons :

• Une meilleure connaissance de la plate-forme matérielle, avec la gestion des devices multi-touch et la gestion des périphériques de stockage USB ou réseau ‘à chaud’.
• Un enrichissement des fonctionnalités des APIs existantes : points de sauvegarde dans les transactions, support IPv6, augmentation de la taille maximale de la fenêtre AIR, manipulation des données de l’API Microphone, time-out d’inactivité…
• De nouvelles fonctionnalités via de nouvelles API, dont la plus étonnante est l’API File promises. Celle-ci permet de télécharger en local, depuis une application AIR, un ensemble de fichiers par simple Drag & Drop. D’autres API font également leur apparition, en particulier au niveau du support réseau et de l’adhérence de AIR à l’OS (les fichiers peuvent maintenant être ouverts par des processus natifs de l’OS, par exemple Notepad pour un .txt sous Windows).

Une évolution assez naturelle donc (correction des gros points de blocage des versions précédentes), mais quelques promesses de fonctionnalités intéressantes, en particulier via l’adhérence à l’OS.

DHTMLX 2.5

Des nouvelles de DTHMLX (la 11ème librairie de notre revue de presse de fin janvier dernier) qui est sorti il y a quelques semaines en version 2.5.

Cette release apporte plusieurs corrections et améliorations sur tous les composants de la suite. On retiendra plus particulièrement :

• Une API orientée objet (l’API fonctionnelle est toujours disponible) ,
• Nouvelle skin par défaut avec d’ici peu (mais non présent dans cette release) un Skin Customizer qui permettra de modifier facilement les couleurs principales du thème standard,
• Nouveau moteur de rendu qui améliore la performance d’affichage des composants Layout, Windows, Accordion et Tabbar,
• Une API de conteneurs unifiée (toujours pour les Layout, Windows, Accordion et Tabbar),
• Améliorations générales pour les composants Grid, Tree et TreeGrid,
• Révision complète du DocsExplorer.

Puisque nous sommes sur DHTMLX, notons aussi le composant Scheduler v.2.0, sorti en juillet dernier, qui n’est pas inclus dans la suite mais qui vaut tout de même le détour si vous avez besoin d’un composant calendrier haut niveau.

Les téléchargements se passent par ici et comme d’habitude vous aurez le choix entre le téléchargement composant par composant ou le téléchargement de la suite complète.
Chaque composant existe en édition standard ou professionnelle. Pour résumer la version standard contient moins de fonctionnalités et est sous licence GPL alors que la professionnelle contient toutes les fonctionnalités, un support prioritaire en cas de bugs/questions sur le forum et plusieurs centaines d’exemples de fonctionnalités avancées.
Pour le détail des licences et des différents prix proposés pour les composants et pour la suite complète, cela se passe sur cette page.

Tips and Tricks Maven 2

Sonatype nous présente ici quelques nouveautés intéressantes de maven disponibles depuis la version 2.1 concernant les projets multi-modules. Cela se traduit par de nouvelles commandes disponibles telles que:

• -rf, -resume-from: permet de spécifier au maven reactor le projet à partir duquel on veut reprendre le build
• -pl, -projects: permet de sélectionner une liste de modules d’un projet multi-modules
• -am, -also-make: combinée avec l’option -pl, elle permet de construire tous les modules dépendants du module passé à l’option pl
• -amd, -also-make-dependents: combinée avec l’option -pl, elle permet de construire tous les modules qui ont une dépendance vers le module passé à l’option pl

Très bonne nouvelle donc pour les développeurs dont le build prenait beaucoup de temps à cause de la reconstruction de modules non modifiés (et non impactés) par leurs nouveaux développements.

Le coin de la technique

Sécurité : 5 choses de plus que les agresseurs d’applications web ne vous diront pas

Le Denim Group continue sa série 13 Things a Web Applications Attacker Won’t Tell You que nous avions traitée la semaine dernière avec 5 nouvelles failles de sécurité de nos applications web :

• Ce n’est pas parce que vous utilisez un framework de sécurité que votre application est sécurisée.
• Je n’utilise pas un browser pour attaquer votre application web.
• J’adore quand votre site me permet d’uploader des fichiers dans l’arborescence des répertoires servis par l’application web.
• Je peux intercepter et voler toutes les informations qui passent sur HTTP si elles ne sont pas protégées par SSL ou un mécanisme équivalent.
• Une sécurité obscurantiste n’en est pas une (ne pas savoir faire ou se dire que ca n’arrivera pas ne protège pas).

Si le dernier point est un débat éternel chez les experts de la sécurité les premiers sont en revanche communément admis.

Les optimisations du JDK 6u14 activées par défaut sur le JDK 7

Rémi Forax, un contributeur sur OpenJDK et sur la JSR-292, a fait part de son étonnement en constatant un gain significatif de performance entre deux builds successifs de l’OpenJDK 7 actuellement en cours de développement. C’est ainsi qu’il a pu se rendre compte que deux optimisations majeures du compilateur JIT de la JVM étaient activées par défaut depuis le build 72 du projet : l’escape analysis et la compression de pointeurs. Celles-ci étaient apparues dans le JDK 6u14 mais n’y étaient pas activées par défaut.

Pour rappel l’escape analysis consiste en l’analyse du bytecode d’une méthode pour découvrir les références vers les objets qui ne « s’échappent » pas du contexte de la méthode. Grâce à cette analyse, la JVM peut alors décider d’allouer ces objets directement sur la stack plutôt qu’en heap comme c’est normalement le cas. Il en résulte un gain de performance évident puisque le coût d’allocation et de libération de mémoire est alors supprimé pour ces objets.

La compression de pointeurs, quant à elle, concerne uniquement les JVM 64 bits. En effet le passage d’un adressage de 32 à 64 bits entraîne une consommation plus élevée de la mémoire du fait de l’augmentation de la taille des pointeurs, induisant elle-même des temps de chargement plus longs et une surconsommation du cache du processeur. Pour palier ce problème, la compression de pointeurs se base sur le fait que la JVM aligne l’adresse des objets sur 64 bits (ceci afin de simplifier et donc d’accélérer leur accès en mémoire), pour procéder à un scaling des pointeurs. Ainsi, en limitant l’espace mémoire adressable à 32 Go, il est possible de contenir un pointeur dans 32 bits et donc de revenir à une consommation mémoire proche de celle d’une JVM 32 bits.

L’activation par défaut de ces deux optimisations sur le JDK 7 montre que l’équipe du projet estime désormais qu’elles ne sont plus expérimentales et qu’elles conviennent dans la majorité des cas. Ismael Juma précise par ailleurs qu’il est possible que ces activations par défaut soient reportées également au JDK 6 courant 2010.

Actualité éditeurs / SSII

• Google essuie les plâtres et met à jour l’Android NDK
• MIDP 3 et MSA 2 pour sauver J2ME ?

Agilité

• Départs de la Scrum Alliance : bruits de couloirs

RIA

• Sécurité : 13 choses que les agresseurs d’applications web ne vous diront pas

Le coin de la technique

• Les roadmaps des implémentations de JPA 2.0
• Web Beans est mort ! Longue vie a Weld !

Actualité éditeurs / SSII

Google essuie les plâtres et met à jour l’Android NDK

Pour rappel, le NDK est un environnement de développement complémentaire au SDK qui permet d’utiliser des langages autres que Java pour développer sur Android. Ce NDK est principalement dédié au développement C et C++. Parmi les nouveautés de la version 1.6, vous trouverez :

• Les librairies OpenGL ES 1.1 qui rapprochent encore un peu Android de l’IphoneOS.
• Ciblage de version Android pour garantir le fonctionnement de votre application.
• Possibilité de mélanger les sources Java et le code natif dans un même projet.

Mais la semaine passée fût aussi l’occasion d’une joute entre Google et certains développeurs Android. Sujet de la discorde, le CyanogenMod une version libre, modifiée, d’Android. Google n’a pas apprécié le fait que son développeur ait la riche idée de distribuer avec son mod, les applications propriétaires qui lui sont chères. Citons par exemple : GMail, YouTube, Maps et Market. Nul besoin de dire que le système perd de son intérêt quand il est privé de ces outils estampillés Google…

Le spécialiste de la recherche a donc demandé l’interruption de toute distribution de ce mod, en attendant que le développeur trouve un moyen de livrer de l’Android sans aucune des G-Apps. C’est un baptême du feu pour ce système que Google a voulu ouvert. D’aucun disent que Google avait la possibilité de créer une alternative libre au jardin d’Eden d’Apple entouré de hauts remparts, à la place ce sera un autre jardin avec des murs un peu plus bas.

MIDP 3 et MSA 2 pour sauver J2ME ?

Mobile Information Device Profile (MIDP), associé à Connected Limited Device Configuration (CLDC) constitue l’API de base de J2ME, c’est cette architecture qui constitue le parc de 2 milliards de devices revendiqués par SUN.

La JSR-248 (Mobile Service Architecture), quant à elle, définit un ensemble d’APIs additionnelles pour les environnements MIDP J2ME apportant chacune un service particulier permettant souvent d’accéder à des fonctionnalités matérielles sous-jacentes (Bluetooth, GPS, Camera, …).

Ces deux piliers de J2ME sont en train d’évoluer avec la finalisation de MIDP 3 et MSA 2. Tandis que le premier apportera un rafraichissement de l’API de base de J2ME, le second poussera plus loin les possibilités d’intégration des applications mobiles J2ME.

Alors que les valeurs montantes du moment dans le monde du développement mobile sont clairement les plates-formes Android et iPhone, le rafraîchissement des APIs J2ME vieillissantes est le bienvenue et viendra épauler JavaFX Mobile dans son hypothétique ascension. On peut toutefois douter que cela suffira à inverser la tendance même si J2ME, fort de son parc colossal, n’est clairement pas menacé à court terme.

Agilité

Départs de la Scrum Alliance : bruits de couloirs

Vous le savez surement, la fin de l’été a marqué un tournant au sein de la Scrum Alliance.
Le 15 Septembre, dans un communiqué laconique (et très américain – nous remercions … blablabla pour son excellent travail … blabla), il nous était annoncé le départ de deux éminents membres de la Scrum Alliance, Ken Schwaber (son CEO) et Jim Cundiff (son Managing Director).
Après une enquête acharnée et au détour de quelques indiscrétions de sources (que nous ne citerons pas), il s’avère que Ken a eu un grave accident de vélo et que Jim a été démissionné compte tenu de ses manquements dans la refonte du processus de certification dont il était en charge.

RIA

Sécurité : 13 choses que les agresseurs d’applications web ne vous diront pas

Le Denim Group regroupe dans 13 Things a Web Applications Attacker Won’t Tell You les principales failles de sécurité de nos applications web :

1. Transformer une requête GET en POST ne cachera pas les paramètres même s’ils n’apparaissent plus dans la barre d’adresse du navigateur (vérifiez avec Charles Proxy ou Fiddler si vous en doutez).
2. Utiliser un champ de formulaire hidden ne permet ni de cacher une information ni d’empêcher sa modification.
3. Idem pour les cookies (voir #1).
4. Contrôler les données coté client avec du javascript ne m’empêchera pas de modifier leur valeur.
5. J’aime vous entendre dire « Cela n’arrivera jamais en production ».
6. Et j’adore quand vous dites « Un pirate ne ferait jamais ça ».
7. Je déteste les validations strictes cote serveur.
8. Cette page d’erreur avec le message détaillé me facilite tellement la vie.
9. La plupart des bannières « Sécurité Garantie ! » ne me servent qu’a voir que vous n’avez pas compris les bases de la sécurité.
10. Ce scanneur d’application web que vous avez lancé, il n’a rien trouvé. Il n’a même pas effleuré les failles de votre application.
11. Ce scanneur réseau que vous avez lancé, il n’a même pas commencé a tester la sécurité de votre application.
12. Je connais AJAX (et toutes les nouvelles technologies a la mode) mieux que vous et mieux que vous ne pouvez imaginer.
13. Le plus astucieux vous vous croyiez, le mieux je me sens.

Moralité, soyons humble et rigoureux, nous ne pourrons pas dire que nous ne savions pas, ces conseils sont répétés par la plupart des tutoriaux de frameworks web .

Le coin de la technique

Les roadmaps des implémentations de JPA 2.0

Alors que la JSR-317 (Java Persistence API 2.0) vient de diffuser une Proposed Final Draft 2 et que sa finalisation approche, nous souhaitions faire un tour d’horizon des principales implémentations en préparation. Comme c’est souvent le cas avec les JSRs, les développeurs n’attendent pas la finalisation des spécifications pour commencer à les implémenter. Ainsi, on se souvient que JPA 1.0, intégré à la JSR-220 (Enterprise JavaBeans 3.0) avait fait l’objet d’implémentations alpha chez JBoss dès la diffusion des early drafts, ce qui avait permis la stabilisation du conteneur peu après la finalisation de la JSR.

• Hibernate : l’équipe de développement Hibernate a annoncé fin aout la disponibilité d’une version 3.5 beta 1 qui implémentait la majorité des nouveautés de JPA 2.0. Aucune indication n’était alors donnée sur la date de finalisation, mais le bon avancement permet de supposer qu’elle arrivera rapidement. A noter toutefois que certaines optimisations importantes telles que la compilation des requêtes criteria n’arriveront que dans une version ultérieure.
• EclipseLink : la fondation Eclipse avait annoncé fièrement en début d’année 2008 qu’EclipseLink serait l’implémentation JPA 2.0 de référence. Une roadmap mise à jour en avril dernier fait état d’une version 2.0 d’EclipseLink implémentant JPA 2.0 pour l’automne 2009.
• Apache OpenJPA : le projet OpenJPA maintient une roadmap très rigoureuse tablant sur un démarrage de phase release candidate pour la fin de l’année. Il s’agira de la version 2.0 d’OpenJPA, elle est actuellement développée sur le trunk du projet.

La première version de la spécification JPA a été un succès puisque de nombreux développeurs ont reconnu sa légitimité et l’ont adopté dans leurs projets plutôt que de se reposer sur l’API propre à leur framework de persistance. Toutefois, pour certaines fonctionnalités telles que les requêtes criteria ou des options de mapping évoluées, il était jusqu’alors nécessaire de contourner JPA. Dès lors, on imagine aisément que JPA 2.0, comblant les manques de son ainée, bénéficiera d’une large adoption. La disponibilité des moteurs JPA 2.0 qui seront utilisés par JBoss AS, Glassfish et WebSphere autour de la fin de l’année devrait par ailleurs accélérer l’omniprésence de cette nouvelle API.

Web Beans est mort ! Longue vie a Weld !

Apres les bruits de couloir de la Scrum Alliance, nous continuons la rubrique people avec une fois encore Web Beans. Après le changement de nom de la JSR 299 en Java Contexts and Dependency Injection, voici que la Reference Implementation se rebaptise Weld.
Pendant ce temps, la JSR 330: Dependency Injection for Java continue son chemin avec son implémentation partielle dans Spring Framework 3.0 RC1 et son intégration dans Google Guice.

Actualité éditeurs / SSII

• Condamnation pour non respect de licence

RIA

• Chrome dans IE avec Google Chrome Frame

Le coin de la technique

• Guide utilisateur de Tellurium
• Lucene évolue et prépare l’avenir
• JBoss Microcontainer et son Virtual File System
• Injection de dépendances en Javascript …

Evènements de notre communauté en France et à l’étranger

• Devoxx 2009 : le planning des sessions est maintenant connu
• Asylum, un nouveau podcast dédié à JBoss

Actualité éditeurs / SSII

Condamnation pour non respect de licence

Qu’arrive-t-il lorsque l’on réutilise du code open source sans se soucier de sa licence ? On se fait taper sur les doigts. C’est en effet la mésaventure qui est arrivé à la société Edu4, comme le présente l’article de la Free Software Foundation France sur l’affaire.
Ayant fourni en 2000 à l’AFPA (un organisme de formation professionnelle) un logiciel basé sur VNC, Edu4 a reçu une requête de cet organisme demandant le code source du logiciel, conformément à ce qu’autorise la licence GPL.
Edu4, dans un premier temps, a refusé de fournir les sources de VNC modifiées par ses soins. Puis, à la suite d’une décision de justice de 2002, a fourni des sources ne correspondant pas à la version livrée et dans lesquelles le texte de la licence GPL de VNC avait été retiré.
Cette semaine, la cour d’Appel de Paris a reconnu Edu4 coupable.
Nous savons tous comment se passent les projets sur lesquels il y a une certaine pression et certains enjeux qui poussent à sortir des produits le plus vite possible sans mesurer toutes les conséquences. Nous ne jetterons donc pas la pierre à Edu4. Mais cette histoire permet de préciser que (1) la licence GNU GPL a bien valeur légale en France et que (2) n’importe quel utilisateur de logiciel basé sur la licence GNU GPL est en droit de réclamer les sources, et pas seulement les auteurs du code original (dans le cas présent, les auteurs de VNC n’ont pas participé au procès).

Il faut donc être bien conscient des conséquences que peut avoir la réutilisation de code open-source. Selon la licence (article de Wikipedia sur les licences du logiciel libre), il y a des obligations et des contraintes. Mais c’est bien là la moindre des choses pour pouvoir profiter de code déjà testé, éprouvé et amélioré par nombre de contributeurs. Cette prise de conscience est d’autant plus nécessaire que les composants open-source sont de plus en plus présents dans les SI des entreprises françaises. Pour un autre éclairage sur ces questions, on peut citer l’interview de Matt Light par ITRManager.

RIA

Chrome dans IE avec Google Chrome Frame

Une des sensations de la semaine dernière est l’annonce de Google Chrome Frame ou comment transformer Internet Explorer en Google Chrome.
On ne compte plus les sites ayant relayé l’information : cela passe par InfoQ, Ajaxian, Inside RIA ou encore TechCrunch.
Google Chrome Frame se présente sous la forme d’un plug-in pour Internet Explorer (6, 7 et 8). Le plug-in se lancera sur la balise suivante (ce qui implique donc que tous nos header HTML doivent être changés) :

<meta http-equiv="X-UA-Compatible" content="chrome=1">

À partir de là, 2 possibilités :

• Le plug-in est installé : il détecte le tag et lance le moteur de rendu de Chrome (WebKit) dans IE
• Le plug-in n’est pas installé : la page s’affiche normalement dans IE mais il est possible de rediriger l’utilisateur vers une page d’installation

Les avantages sont multiples : on retiendra de nombreuses optimisations de performances Javascript, un chargement de page plus rapide mais aussi l’utilisation de HTML 5 avec le offline et les canvas.
Il sera alors possible, comme le rappelle InfoQ, pour Google Wave d’offrir une expérience utilisateur complète à tous les utilisateurs d’Internet Explorer (en effet, celui-ci utilisera de nombreuses fonctionnalités de HTML 5).
Le support d’IE continuera comme le rappelle Lars Rasmussen (Team manager de Google Wave) qui insiste aussi sur le fait que les différentes versions d’IEs ralentissent l’élaboration d’applications web dîtes riches (avec des quick fixes à n’en plus finir pour obtenir des résultats présents out of the box chez les autres navigateurs).

Plusieurs réactions ont suivi cette annonce. On pourra retenir celle de Robert Nyman (par Ajaxian) qui rappelle fort justement que les utilisateurs restant sur de vielles versions d’IEs sont (pour résumer grossièrement) :

• soit des utilisateurs qui ne savent pas ce qu’est un navigateur (et donc n’installeront jamais ce plug-in)
• soit (malheureusement pour ceux qui y sont confrontés) des sociétés qui bloquent les mises à jours logicielles (il sera donc peu probable que le plug-in soit autorisé à être installé)

Dion Almaer se pose la question de l’inversion des rôles quant à l’expérience utilisateur : est-ce au développeur de choisir (forcer ?) le renderer/navigateur à utiliser ?
En tous cas, on ne peut que saluer le travail effectué et espérer que cela aidera, ne serait-ce qu’un peu, à réduire les IE 6 de ce monde

Le coin de la technique

Guide utilisateur de Tellurium

Tellurium nous annonce la sortie de son guide utilisateur version 0.6.0.
En 5 chapitres, celui-ci parcourt :

• Les concepts et fonctionnalités principaux de l’outil
• Un Getting Started
• Les sous-projets de Tellurium (archetype Maven, TrUMP…)
• L’architecture de Tellurium
• Ses APIs (DSLs, data access…)

Le PDF se récupère à cette url.
Et pour un petit aperçu du projet, je vous renvoie vers notre article sur comment améliorer l’écriture de vos tests selenium.

Lucene évolue et prépare l’avenir

Le projet Apache Lucene annonce la disponibilité de la version 2.9 du célèbre framework de recherche d’information. La liste des changements est conséquente.

Shalin Shekhar Mangar, committer sur Apache Solr, faisait part il y a quelques mois d’une activité très dense sur le projet Lucene pour préparer cette nouvelle version. Il expliquait alors que la majorité du travail était imputable au near real-time search, amélioration permettant de refléter très rapidement les modifications des données dans les résultats des requêtes alors que celles-ci sont habituellement rendues visibles seulement après le commit des changements dans l’index.

Outre cette nouvelle possibilité de recherche en temps réel, les principaux apports de Lucene 2.9 :

• Optimisations portant sur la mise en cache de segments inchangés de l’index, apportant un gain significatif de performance
• Gestion plus efficace des champs numériques avec l’ajout des classes NumericField et NumericRangeQuery. Il en résulte un gain de performance sur les requêtes par intervalles
• Support des requêtes géo-spaciales (module contrib/spatial)
• Nouveaux analyzers (PersianAnalyzer, ArabicAnalyzer, et SmartChineseAnalyser)
• Diverses améliorations d’API notamment sur le Collector / Scorer et le QueryParser

Par ailleurs, Lucid Imagination, une société américaine d’expertise Lucene, propose un webinar sur les nouveautés de cette version. On y retrouve également les plans pour la version 3.0 : les changements seront majeurs puisqu’il est prévu de passer l’API à Java 5 et de supprimer les éléments précédemment dépréciés.

La documentation du projet évolue également mais reste moins fournie qu’on ne le souhaiterait et les développements avec Lucene doivent souvent être accompagnés de l’ouvrage Lucene In Action paru chez Manning. Ce livre paraîtra dans une seconde édition, mise à jour pour la version 3.0 du framework, en mars 2010.

Cette activité dense de l’équipe Lucene est en rapport avec l’importance que prend ce projet dans la mise en œuvre des nombreux cas d’utilisations issus du Web moderne, tels que les recherches intelligentes et rapides, les systèmes de suggestions, et les analyses de contenu.

JBoss Microcontainer et son Virtual File System

Le projet Microcontainer de JBoss est le noyau de la version 5.0 du serveur d’application de l’éditeur sortie en fin d’année dernière. Il remplace le Microkernel JMX qui était utilisé jusqu’alors dans les version 4.x de JBoss AS. Le choix d’un tel noyau développé en interne avait fait l’objet de quelques remarques lors de son développement puisqu’il offre des fonctionnalités très classiques telles que la gestion du cycle de vie de ses composants, l’injection de dépendances et de propriétés, et des fonctionnalités d’AOP.

Ce Microcontainer s’illustre malgré tout par son système de déploiement reposant sur une abstraction très flexible encapsulant le chargement de ressources qu’elles soient sous forme de Jar, de fichiers, ou de répertoires : le Virtual File System. Cette fonctionnalité très puissante est malheureusement très peu documentée dans le manuel utilisateur du projet. Sa bonne maîtrise est pourtant souhaitable pour bien comprendre le comportement et les possibilités du déploiement d’applications dans JBoss AS 5.0 ou encore (scénario certes beaucoup moins courant) pour utiliser directement le Microcontainer dans un projet.

Ce manque de documentation est maintenant partiellement comblé grâce à Ales Justin, travaillant chez JBoss sur leur serveur d’application, qui a mis en ligne un article sur VFS. Cet article fait suite à deux articles précédents sur le modèle de composants et l’injection de dépendances dans JBoss Microcontainer.

Il y présente l’architecture de VFS et les abstractions et APIs mises en œuvre. On découvre alors des interfaces très claires et on se rend compte qu’il est envisageable de développer son propre protocole pour VFS afin de permettre le chargement de ressources depuis n’importe quelle source de stockage (réseau, base de données, repository, …).

Au-delà de la compréhension de cette architecture et de son comportement standard, on retiendra donc cette possibilité d’adapter le déploiement des applications sur JBoss AS 5.x à l’infrastructure mise en place dans l’entreprise, et ce, pour un coût raisonnable.

A noter que l’auteur annonce que le prochain article portera sur le système de classloading du Microcontainer. A suivre donc …

Injection de dépendances en Javascript …

Dans la série pourquoi faire simple quand on peut faire compliqué, à l’heure où Spring vient d’annoncer la sortie de la version 3-RC1 de son framework, à l’heure où Google sort son nouveau framework web sitebricks basé sur Google Guice, son framework d’injection de dépendances, pourquoi ne pas abandonner tout cela et gérer vous-même l’injection des dépendances de votre application Java en … Javascript ! C’est ce que nous propose l’auteur de cet article.

S’il est clair que vous n’allez pas jeter votre framework préféré dés la lecture de ce billet, cette solution
a tout de même le mérite, en plus d’être originale, d’utiliser uniquement les fonctions du JDK : Scripting API + proxy dynamique.

Evènements de notre communauté en France et à l’étranger

Devoxx 2009 : le planning des sessions est maintenant connu

Devoxx (anciennement JavaPolis) est la première conférence Java au niveau européen et la seconde au niveau mondial, après JavaOne. L’édition 2009 se déroulera du 16 au 20 novembre et devrait, cette année encore, réunir plus de 3000 personnes.

Le planning des sessions est maintenant connu, ce qui permet d’observer les tendances du moment. On dégage ainsi une présence marquée du Cloud Computing, de JDK 7 et des langages alternatifs pour la JVM, notamment Scala.

On peut également noter quelques sessions particulièrement alléchantes telles que :

• Le keynote de Steven Harris (Oracle, Product Development & Server Technologies)
• Le keynote d’Ivar Jacobson
• Distributed Programming the Google Way par Gregor Hohpe (l’auteur de Enterprise Integration Patterns), qui présentera les technologies mises au point par Google (MapReduce, GFS, Sawzall, Chubby, Protocol Buffers, …) pour rendre leurs applications distribuées optimales et surtout réalisables
• The Modular Java Platform & Project Jigsaw par Mark Reinold, qui permettra de faire le point sur cette technologie clé du JDK 7 qui est encore peu documentée.
• Maven 3 par Jason van Zyl (créateur de Maven)

En outre, pour ceux qui n’auraient pu assister à la présentation de JEE 6 par Antonio Goncalves au ParisJUG en début d’année, ou qui souhaiteraient être au fait des dernières évolutions, il présentera de nouveau une session sur ce sujet à Devoxx.

L’édition 2009 s’annonce donc aussi riche que les précédentes, ce qui laisse présager que, comme les années passées, les places seront toutes vendues 1 ou 2 semaines avant le début de la conférence, alors ne tardez pas à vous inscrire si vous êtes intéressés !

Asylum, un nouveau podcast dédié à JBoss

JBoss Community Asylum est un nouveau podcast créé par Max R. Andersen (JBoss Tools), Emmanuel Bernard (Hibernate), et Michael Neale (Drools) dont le contenu sera entièrement centré sur l’actualité et les informations relatives à la communauté JBoss.

Le premier épisode est en ligne et revient sur la conférence JBoss World et les nouveautés qui y ont été présentées, notamment :

• Infinispan, une évolution majeure de JBoss Cache
• REST-*, un ensemble de spécifications de services pour REST
• GateIn, le nouveau portail issu du partenariat entre JBoss et eXo
• TorqueBox, un conteneur d’applications Ruby On Rails pour JBoss AS
• HornetQ, la nouvelle version de JBoss Messaging
• Shrinkwrap, une API d’assemblage d’archives applicatives Java

Pour rappel, Emmanuel Bernard participe également à un podcast en français, les Cast Codeurs, dont le dernier épisode en date est disponible depuis hier.

Architecture

• Gartner adopte le pragmatisme avec l’Architecture Émergente

Actualité éditeurs / SSII

• JBoss HornetQ

RIA

• BlazeMonster

Le coin de la technique

• Liste finale des évolutions du langage Java apportées par le JDK 7
• Fin d’Eclipse RCP, place à…
• TestSwarm

Architecture

Gartner adopte le pragmatisme avec l’Architecture Émergente

Gartner nous livre un plaidoyer pour la pragmatisme avec Emergent Architecture. La formulation est parfois compliquée mais on se réjouira de trouver la responsabilisation des équipes sur le terrain et des Architectes d’Entreprise évangélistes de lignes directrices. Pour reprendre une expression chère au Lean Manufacturing, « Empower the People » :

1. Non déterminisme – Dans le passé, les architectes d’entreprise prenaient des décisions centralisées qui s’appliquaient à tous. Dans une architecture émergente, ces architectes d’entreprise doivent au contraire décentraliser la prise de décisions pour permettre l’innovation.
2. Acteurs autonomes – Les architectes d’entreprise ne peuvent plus contrôler tous les aspects de l’architecture comme ils le faisaient auparavant ; ils doivent désormais reconnaître l’étendue et la variété du SI ; ils doivent déléguer le contrôle aux équipes sur le terrain.
3. Limiter les contraintes aux lignes directrices – Jusqu’à présent, les architectes d’entreprise ont fourni des spécifications détaillées de tous les aspects de l’architecture ; ils doivent désormais limiter leurs prescriptions aux lignes directrices et de permettre le choix.
4. Acteurs orientés objectif – Auparavant, les seuls objectifs qui comptaient étaient les objectifs de l’entreprise mais cela s’est maintenant déplacé et chaque acteur agit dans ses propres intérêt. Il ne faut pas pour autant oublier les lignes directrices.
5. Influences locales: Les acteurs sont influencés par des interactions locales et des informations limitées. Les feedbacks au sein de leur sphère de communication modifie leur comportement. Aucun acteur individuel ne possède la vision globale d’un système émergent. Les architectes d’entreprise doivent intensifier leur travail coordonner et de transmission de l’information.
6. Systèmes dynamiques et adaptatifs: le système (les différents acteurs et leur environnement) changent avec le temps. Les architectes d’entreprise doivent définir les pourtours des systèmes émergents et ajuster en fonction des changements.
7. Environnement aux ressources limitées: L’abondance, les budgets illimités, ne permet pas de créer une architecture émergente ; c’est au contraire la rareté des moyens qui permet une architecture émergente.

Actualité éditeurs / SSII

JBoss HornetQ

Après 2 ans de développement, le projet JBoss Messaging 2.0 sort enfin dans les bacs sous le nom HornetQ. Ce Message Oriented Middleware n’est pas une évolution de son prédécesseur qui continue d’exister dans sa version 1.0, mais belle et bien une réécriture (presque) intégrale. Redhat nous le vend comme un MoM opensource, multi-protocol, embarquable, haute performance, réparti, et asynchrone.
HornetQ peut-être utilisé en standalone ou bien embarqué dans un serveur d’application JBoss AS par exemple. Chose appréciable, HornetQ est léger, il dépend uniquement du JDK (5 minimum) pour être complètement fonctionnel.
Dans sa présentation, Redhat nous annonce que le projet est facile d’utilisation avec une documentation déjà très complète et la bagatelle de 65 exemples de codes sources. Il est même possible de démarrer en moins de 5 minutes.
HornetQ bénéficie d’une conception orientée Pojo qui lui permet d’être utilisé directement dans Spring ou Guice. La performance a fait l’objet d’une attention importante, avec un journal haute performance et JBoss Netty pour la scalabilité.
JBoss nous livre une liste sans fin des fonctionnalités embarquées parmi lesquels on retiendra:

• JMS 1.1
• JTA
• Adaptateur JCA

Enfin, l’editeur annonce orienter ses développements vers le support d’API RestFull qu’il voit comme le futur du cloud computing. Redhat souhaite donc pousser la porte des clouds privé en tentant de s’imposer comme le provider de message incontournable dans le nuage.

• Site du projet
• Wiki

RIA

BlazeMonster

BlazeMonster vient de sortir dans sa deuxième version. Pour rappel cet outil, basée sur la technologie AIR, permet le support et l’aide à la génération de code pour consommer/exposer des services Java en tant que service Remote pour BlazeDS ou LCDS (LiveCycle Data Services).
Parmi les supports, nous avons entre autre :

• Génération des fichiers de configurations : déclarations des services, channels..
• Génération du code appelant le service Remote
• Génération des beans ActionScript (Value Object)
• Visualisation des réponses des services Remote

Dans cette deuxième version, BlazeMonster intègre le support de Spring BlazeDS, permettant la génération de services Remote en utilisant cette librairie. Je vous invite à jeter un coup d’œil sur les autres corrections et évolutions apportées à ce projet ici.
Facile d’utilisation, ce projet permet de copier/coller des morceaux de code dans votre application, facilitant le développement.
Enfin, à travers ce projet nous voyons, une fois de plus, l’engouement que les technologies Flex et BlazeDS remportent. Peut être pouvons nous espérer l’intégration de ce type d’outil dans le Flash Builder 4. Alors messieurs d’Adobe, qu’attendez vous ?

Le coin de la technique

Liste finale des évolutions du langage Java apportées par le JDK 7

En début d’année, Sun a initié le Project Coin, un sous-projet d’OpenJDK visant à recueillir les propositions d’évolutions du langage Java pour le JDK 7 prévu pour début 2010. Les soumissions ont été nombreuses et Joseph D. Darcy, leader du projet, informait régulièrement la communauté sur l’avancement du processus de sélection. C’est maintenant la liste finale des évolutions qu’il annonce. Sauf problème de planning, il s’agit donc là de ce que le langage Java sera dans JDK 7 :

• Clause switch utilisable sur les String.
• Gestion automatique des resources. Cette évolution vise à simplifier la gestion de la fermeture des flux ou autre ressources par l’utilisation d’une clause try spécifique pour les objets implémentant l’interface Disposable introduite dans le JDK pour l’occasion.
• Inférence de type améliorée pour la création d’objets génériques grâce à une syntaxe du type List<String> list = new ArrayList<>().
• Evolution de la gestion des warnings pour l’utilisation des generics dans des varargs.
• Autorisation de la notation binaire pour les entiers comme en C/C++ et possibilité de placer des underscores dans les nombres pour en simplifier la relecture tel que long creditCardNumber = 1234_5678_9012_3456L
• Accès en lecture et écriture aux valeurs des collections Java par la notation utilisé jusqu’alors uniquement pour les tableaux.

On est loin de la liste d’évolutions très audacieuses initialement prévue pour JDK 7, mais les évolutions finalement retenues ont l’avantage d’être réalistes en terme de temps d’implémentation, tout en apportant un confort supplémentaire au quotidien pour les développeurs Java.

Rémi Forax, très au fait des développements sur l’OpenJDK, propose d’ailleurs son analyse des tâches restant à accomplir et de leur complexité pour chacune des évolutions.

Fin d’Eclipse RCP, place à…

Après Java Rebel, c’est Eclipse RCP qui se trouve sur la voie du changement de nom.
Cette fois-ci, ce n’est pas pour une raison de marque déposée mais tout simplement, dixit l’auteur, parce que ce nom est horrible .
Un vote est organisé avec tous les noms remontés par la communauté Eclipse depuis 3 mois.
Alors, Aurora, Montage ou Tangram, c’est à vous de voter ! Et ça se passe sur cette page.

TestSwarm

John Resig, créateur de jQuery, nous annonce que Test Swarm est maintenant ouvert au public (par ajaxian).

Test Swarm permet de tester le code Javascript sur différents navigateurs de différentes plateformes de manières continues. A l’origine utilisé pour jQuery, il est désormais possible de tester son propre code Javascript, moyennant 8 steps d’installation paragraphe Setting Up Your Own Swarm. Les tests (jobs) peuvent être lancés à chaque commits (SVN ou Git) ou bien en appelant une URL spécifique. Les résultats des tests sont résumés dans un tableau avec une colonne pour chaque navigateur/plateforme. Il est possible de rester au niveau projet mais on peut affiner l’affichage au niveau commit voir au niveau de chaque fichier js de tests. Côté couleur, les tests vert se sont bien passés, les rouges contiennent au moins une erreur, les noirs ont au moins une erreur critiques et les gris sous en cours/en attente. Des logs sont disponibles pour chaque run de tests et permettent de voir ceux qui ne seraient pas passés.

Les frameworks de tests unitaires Javascript gérés (bien d’autres suivront) sont pour l’instant :

• QUnit (jQuery)
• UnitTestJS (Prototype)
• JSSpec (MooTools)
• JSUnit
• Selenium
• Dojo Objective Harness

Une vidéo de type quick tour nous donne un bon aperçu du site. Plusieurs directions sont possible concernant la roadmap du produit dont l’intégration à l’IDE, tests sur encore plus de browser… Un produit à suivre.

• Les effets
• Dessine moi un bouton … avec spark.
• Les autres nouveautés de Flex 4
• Conclusion
• Pour aller plus loin

Pour visualiser les exemples Flex 4 ci dessous, il vous faudra installer Flash Player 10.

Les effets

Une différence notable avec la précédente version de Flex est la gestion des états qui est maintenant nettement plus simple.
En Flex, il est possible de décrire plusieurs états associés à un composant. Ces états définissent, pour un composant, des éléments à ajouter, des styles ou des propriétés à appliquer. En effet, il est question de manipuler des AddChild, des SetProperty ou encore des SetStyle qui peuvent devenir très vite lourds à gérer. Pour mieux comprendre, prenons un exemple :
Nous allons réaliser une application sur 2 états, l’état blueState qui va colorer le label helloLabel en bleu et l’état redState qui va le colorer en rouge. Pour ce faire, avec Flex 3, nous utilisons les balises SetStyle qui permettent de modifier le style color du label et de le mettre à la couleur voulue.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" minWidth="300" minHeight="300">
    <mx:states>
        <mx:State name="blueState">
            <mx:SetStyle target="{helloLabel}" name="color" value="blue"/>
        </mx:State>
        <mx:State name="redState">
            <mx:SetStyle target="{helloLabel}" name="color" value="red"/>
        </mx:State>
    </mx:states>
    <mx:HBox>
        <mx:Label text="Bonjour !" id="helloLabel"/>
        <mx:Button label="Bleu" id="blue" click="currentState='blueState'"/>
        <mx:Button label="Rouge" id="red" click="currentState='redState'"/>
    </mx:HBox>
</mx:Application>

Avec Flex 4, il n’est plus question de définir des SetStyle ou SetProperty dans les composants. Tout se fait dans les attributs qui peuvent se décliner en fonction des états comme ceci : styleOuPropriete.monEtat. Ainsi color.blueState prendra la couleur bleu lorsque l’on sera dans cet état.D’autre attributs apparaissent également dans les composants graphiques comme includeIn ou encore excludeFrom pour permettre d’exclure ou d’inclure un composant en fonction de l’état courant. De plus, Flex prend maintenant par défaut le premier état lorsqu’on en définit plusieurs pour un composant. C’est la raison pour laquelle nous avons ajouté defaultState comme état par défaut. Avec Flex 4, notre précédent exemple donne donc ceci :

<?xml version="1.0" encoding="utf-8"?>
<s:Application
   xmlns:fx="http://ns.adobe.com/mxml/2009"
   xmlns:s="library://ns.adobe.com/flex/spark"
   xmlns:mx="library://ns.adobe.com/flex/halo" width="300" height="300">
	<s:states>
		<mx:State name="defaultState" />
		<mx:State name="blueState" />
		<mx:State name="redState" />
	</s:states>
	<mx:Label text="Bonjour !" color="black" color.blueState="blue" color.redState="red"/>
	<s:Button label="Rouge" click="currentState='redState'"/>
	<s:Button label="Bleu" click="currentState='blueState'"/>
	<s:layout>
		<s:HorizontalLayout />
	</s:layout>
</s:Application>

Certes, il s’agit d’un petit exemple. Mais cela pourrait simplifier la gestion des états sur des applications plus élaborées.

Dessine moi un bouton … avec spark.

De nouvelles librairies ont vu le jour dans Flex 4. Commençons par la librairie spark, présente depuis Mai 2009. Elle offre toute une nouvelle génération de composants dont l’architecture est clairement différente de son prédécesseur halo. Cette dernière proposait des composants graphiques sur lesquels il n’était possible que de changer les couleurs et le style du texte : le Flex Style Explorer en est un bon exemple.
La librairie spark, de son côté, propose un nouveau type de composant « skinnable », c’est-à-dire que nous avons d’un côté le dessin représentant un bouton et de l’autre l’objet bouton. De plus, spark intègre la librairie FXG qui fournit tous les composants permettant de faire des dessins vectoriels.
Pour mieux comprendre le fonctionnement, rien de mieux qu’un exemple :
Nous créons d’abord un Skin sous le nom de component.CustomSkin.

<?xml version="1.0" encoding="utf-8"?>
<s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009"
   xmlns:s="library://ns.adobe.com/flex/spark"
   xmlns:mx="library://ns.adobe.com/flex/halo" height="300" width="300">
    <fx:Metadata>
        [HostComponent("spark.components.Button")]
    </fx:Metadata>
    <s:states>
        <mx:State name="up" />
        <mx:State name="over" />
        <mx:State name="down" />
    </s:states>
    <s:Ellipse height="86" width="96" verticalCenter="0" horizontalCenter="0">
        <s:fill>
          <mx:SolidColor color="#FF0000" color.over="red" color.up="blue"/>
         </s:fill>
    </s:Ellipse>
    <s:layout>
        <s:BasicLayout/>
    </s:layout>
</s:Skin>

Nous définissons le comportement de ce composant grâce au metatag HostComponent, ici il s’agit donc d’un bouton. Nous ajoutons ensuite les états en regardant dans la documentation, nous pouvons voir que Button dispose des états : up, over, down et disabled. Contentons-nous des trois premiers états pour cet exemple. Enfin, on finit par dessiner un bouton qui sera disposé dans un layout qui doit être défini dans tout composant spark. Ce skin est ensuite associé à un bouton dans l’application principale.

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:s="library://ns.adobe.com/flex/spark"
    xmlns:mx="library://ns.adobe.com/flex/halo"
    minWidth="1024" minHeight="768"
    xmlns:component="component.*">
    <fx:Script>
        <![CDATA[
            import mx.controls.Alert;
            import component.MyButton;
        ]]>
    </fx:Script>
    <fx:Style source="TestFlex4.css"/>
    <s:Button skinClass="component.CustomSkin"  click="Alert.show('Je suis un bouton !')"/>
</s:Application>

Et voici le rendu :

Les autres nouveautés de Flex 4

Support dans l’ASDoc des fichiers MXML
La SDK de Flex 3 ne générait que la documentation associée au code ActionScript 3. Il est maintenant possible dans le SDK 4 de générer de l’ASDoc pour les composants MXML.

Le data binding dans les deux sens
Actuellement, la liaison des données dans un composant avec Flex se fait de la façon suivante :

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:TextInput id="myText1" />
    <mx:TextInput id="myText2" text="{myText1.text}" />
</mx:Application>

Dans cet exemple, l’édition dans myText1 modifie le champs myText2 mais l’inverse ne se fait pas. Pour les lier tous les deux il faudrait modifier myText1 comme ceci :

<mx:TextInput id="myText1" text="{myText2.text}"/>

Avec la nouvelle notation que propose Flex 4, il suffit de faire comme ceci :

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
   xmlns:s="library://ns.adobe.com/flex/spark"
   xmlns:mx="library://ns.adobe.com/flex/halo" minWidth="1024" minHeight="768">
    <s:TextInput id="myText1" />
    <s:TextInput id="myText2" text="@{myText1.text}" />
    <s:layout>
        <s:VerticalLayout/>
    </s:layout>
</s:Application>

Et automatiquement les deux composants sont liés.

Conclusion

Toutes ces nouveautés proposées par Adobe ont pour but :

• d’améliorer la productivité du développeur en simplifiant le langage,
• d’avoir plus de liberté sur le design.

La librairie spark propose des composants radicalement différents de ce que l’on peut actuellement utiliser dans Flex 3, mais il est cependant possible d’utiliser les composants de l’ancienne librairie nommée halo. Les habitués ne s’y perdront donc pas.
Mais alors pourquoi autant de changement ? La raison est très simple et se nomme Flash Catalyst. Le nouvel outil d’Adobe sorti en Juin 2009 en version bêta est capable de générer du code Flex à partir de dessins réalisés par la gamme Creative Suite 4.
Flex 4 est toujours en bêta actuellement, une release est prévue pour le dernier trimestre 2009.

Pour aller plus loin

• LiveDocs Flex 4
• Télécharger le SDK

Actualité éditeurs / SSII

• Avancement des spécifications et implémentations JEE 6

RIA

• Des nouvelles d’Ext-GWT

Le coin de la technique

• Nouveau concept dans JUnit 4.7 : Rule
• Attention à votre mémoire avec String.substring()
• Sortie de Wicket 1.4
• Chouchoutez vos tests unitaires.

Evènements de notre communauté en France et à l’étranger

• Sun perd JRuby

Actualité éditeurs / SSII

Avancement des spécifications et implémentations JEE 6

Le dernier podcast des Cast Codeurs a été l’occasion de faire un tour de table des informations que chacun des speakers possédait sur JEE 6. Même s’il ne s’agit pas d’informations officielles, elles offrent un aperçu intéressant sur ce que pourrait être JEE 6 lors de sa finalisation ainsi que sur son calendrier :

• Antonio Goncalves, membre de l’Expert Group JEE 6, explique que la bataille entre les JSR-330 (Dependency Injection for Java) et JSR-299 (Java Contexts and Dependency Injection) sur le terrain de l’injection de dépendances semble partie pour se terminer de manière constructive. En effet la JSR-330 ne présentant pas d’incompatibilité particulière avec le modèle très évolué proposé par la JSR-299, les deux spécifications devraient se compléter harmonieusement. La JSR-330 définirait un ensemble d’interfaces de base que la JSR-299 viendrait étendre pour ajouter ses concepts plus élaborés. Afin de permettre cet ajustement de dernière minute, la finalisation de la spécification JEE 6 serait légèrement repoussée, la portant ainsi autour d’octobre / novembre 2009.
• Emmanuel Bernard, travaillant sur les problématiques de persistance chez JBoss, nous apprend quant à lui que l’implémentation des drafts des spécifications JEE 6 est en cours chez JBoss et devrait aboutir en version 5.2 du serveur d’application de l’éditeur avec une première implémentation non conforme au TCK, la conformité viendrait dans un deuxième temps, lors d’une version ultérieure. Il évoque la possibilité d’une présentation de ce travail lors du JBoss World de début septembre. D’autre part, la JSR-303 (Bean Validation) dont il est responsable est proche de la finalisation mais un conflit avec le JCP sur une problématique de licence complexifie l’avancement.

On ne peut que se réjouir de cette éventuelle harmonie entre les deux JSR d’injections de dépendances puisque les développeurs seraient ainsi libres de choisir la spécification sur laquelle ils se basent, en fonction de leur besoins plus ou moins complexes.

RIA

Des nouvelles d’Ext-GWT

Ext-GWT, la librairie Javascript ExtJS portée en GWT (cf. article sur la galaxie GWT), sort en version 2.0.1.
Profitons de cette sortie pour parler plus globalement du projet et de la release majeure 2.0 sortie il y a maintenant un mois.

Celle-ci apporte en effet son lot de nouveaux composants et nouvelles fonctionnalités. Ces ajouts réduisent ainsi l’écart entre les 2 projets. On trouve ainsi :

• le Tree Panel et le Tree Grid (démo), ce dernier (qui étend directement le composant Grid donc plus de binder) bénéficiant de toutes les fonctionnalités du tableau
• le row editor (démo) qui permet de modifier une ligne complète du tableau, toutes les cellules de la ligne passant en mode édition (alors qu’avant il fallait éditer toutes les cellules une par une)
• le HTML editor / Rich Text Editor (démo)
• le Live Charting (démo) qui rejoint ainsi GChart (évoquée lors d’une précédente revue de presse) et OFCGWT
• le ButtonGroup (démo) et le Status (démo)

Un travail important a été apporté sur les boutons, la barre d’outil, la gestion de l’overflow dans cette barre…

Les nouveautés étant très nombreuses, un détour par le fameux showcase permettra de les parcourir/tester.

S’agissant d’une mise à jour majeure, un guide de migration présent dans le produit décrira les changements dans l’API.

Téléchargement par ici et si (comme moi ) vous attendez déjà la suite avec la 2.1, vous trouverez la nouvelle roadmap par là.

Le coin de la technique

Nouveau concept dans JUnit 4.7 : Rule

La version 4.7 du célèbre framework de test unitaire, JUnit, est en cours de préparation. Un nouveau concept a été dévoilé : Rule.

Ce concept va réjouir les accrocs du test automatisé par JUnit. En effet, cette fonctionnalité permettra de modifier l’exécution de vos tests, afin de les préparer à un contexte d’exécution.

Un des exemples les plus significatifs est le suivant :

 public static class HasTempFolder {
   @Rule
   public TemporaryFolder folder= new TemporaryFolder();
   @Test
   public void testUsingTempFolder() throws IOException {
     File createdFile= folder.newFile("myfile.txt");
     File createdFolder= folder.newFolder("subfolder");
     // ...
   }
 }

Grâce à cette déclaration @Rule public TemporaryFolder folder= new TemporaryFolder();, avant le test il n’y a pas besoin de créer de répertoire temporaire, après le test il n’ y a pas besoin de supprimer les répertoires et fichiers créés pendant le test. Cela permet donc plus facilement de faire des tests automatisables, répétables, et portables d’environnement à environnement.

Il existe d’autres Rules comme par exemple :

• ExternalResource: utilisable d’un fichier externe (accessible par système de fichier)
• Timeout: le test doit répondre avant un timeout
• ExpectedException: le test doit jeter des exceptions bien déterminés
• Et bien d’autres

Il y aura donc un ensemble de Rules qui permettront d’éviter de refaire des petits bouts de code personnel pour faire la même chose en une annotation.

Attention à votre mémoire avec String.substring()

Voici un article intéressant qui permet de comprendre ce qui se trouve sous le capot de la classe du JDK String : String and memory leaks ; il pourrait même vous donner une petite goutte de sueur sur le front. Même si le titre de l’article n’est pas forcement bien choisi (‘fuite mémoire’ alors qu’il s’agit plus de rétention mémoire), il nous montre simplement comment une méthode de la classe, substring, peut cacher un loup.

En effet, à des fins d’optimisation, on fait tourner le code suivant :

public static void sendEmail(String emailUrl) {
    String email = emailUrl.substring(7); // 'mailto:' prefix has 7 letters
    String userName = email.substring(0, email.indexOf("@"));
    String domainName = email.substring(email.indexOf("@"));
}
public static void main(String[] args) {
    sendEmail("mailto:user_name@domain_name.com");
}

A première vue, on a trois instances de la classes String :

• String email = "mailto:"
• String userName = "user_name@"
• String domainName = "domain_name.com"

Cependant, concrètement, en mémoire il n’y a qu’un tableau de char qui est stocké : "mailto:user_name@domain_name.com", les instances des classes String enregistrent seulement les intervalles utilisés du tableau de char.

Le piège est de manipuler une grosse chaine de caractères (qui vient d’un fichier batch par exemple) et d’utiliser substring afin de limiter la taille de la chaine et donc l’utilisation mémoire. Faux ! La chaine initiale sera toujours stockée en mémoire.

Assez déroutant !

Sortie de Wicket 1.4

Le projet Wicket continue d’évoluer et, alors que nous vous parlions d’une version 1.3.6 en mai dernier (qui a d’ailleurs fait l’objet d’une Refcard DZone), c’est la version 1.4 après un an de travail qui nous arrive dans la mains (par Yes Wicket ! et Apache Wicket).

Au menu des nouveautés : un nouveau packaging des jars Wicket (qui les rend compatibles OSGi), un seul jar pour les modules Spring et plusieurs modifications d’IModel, de ses implémentations et plus globalement des APIs pour tirer avantage de Java 5 (Generics…). L’utilisation des Generics dans le code de Wicket a commencé il y a environs un an par un sondage passionné sur la mailing-list, pour arriver seulement dans la milestone 3 de Wicket 1.4 avec autant de partisans que de détracteurs – défenseurs du support du JDK1.4- et ceci jusqu’à la release final. Le thread sur The Server Side est également impressionnant ! Pour le détail complet, rendez-vous sur le Jira du projet.

Tout comme pour Ext-GWT 2.0 (ci-dessus), une guide de migration de 1.3 vers 1.4 est disponible. Un petit téléchargement ?

Chouchoutez vos tests unitaires.

InfoQ publie un intéressant florilège : « Réalisez de meilleurs tests unitaire ».
Certains trouveront que, de nouveau, on enfonce des portes ouvertes. D’autres (comme nous), apprécierons les nombreuses réactions qui découlent de ce genre d’article, et penserons qu’il n’est jamais inutile de rappeler ces grands principes de base afin d’arrêter de voir des tests unitaires martyrisés (et inutiles) sur certains projets.
Bref, en un mot comme en mille, vos tests unitaires sont des classes de code java, qui sont vitales pour vos projet, il est donc urgent d’en prendre grand soin (nommage, documentation, refactoring…)

Evènements de notre communauté en France et à l’étranger

Sun perd JRuby

Trois développeurs clés de JRuby, à savoir Charles Nutter, Thomas Enebo et Nick Sieger, ont choisi de quitter Sun MicroSystems. Suite au rachat récent par Oracle et à l’incertitude concernant le support de JRuby par le nouveau propriétaire, ils ont décidé de rejoindre la société Engine Yard, spécialisée dans l’hébergement d’applications Ruby On Rails. Engine Yard a l’air enthousiaste à l’idée de pouvoir être le support du développement de l’offre JRuby et de la communauté qui va avec. (Source)

Afin de déclarer votre service Remote, les lignes suivantes doivent être ajoutées dans votre applicationContext.xml :

<bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
	<property name="mappings">
	    <value>
	        /*=mySpringManagedMessageBroker
	    </value>
	</property>
</bean>
<!-- Envoie les requêtes au "message broker" -->
<bean class="org.springframework.flex.servlet.MessageBrokerHandlerAdapter"/>
<!-- Le MessageBroker de BlazeDs -->
<bean id="mySpringManagedMessageBroker" class="org.springframework.flex.core.MessageBrokerFactoryBean" />
<!-- Service myService -->
<bean id="myService" class="com.xebia.impl.MyServiceImpl" />
<flex:remoting-destination message-broker="mySpringManagedMessageBroker" destination-id="myServiceDest" ref="myService" />

Ainsi que la référence au fichier xsd : http://www.springframework.org/schema/flex/spring-flex-1.0.xsd

Malheureusement, au démarrage de votre application, vous aurez cette erreur :

org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 67 in XML document from ServletContext resource [/WEB-INF/classes/applicationContext-service.xml] is invalid;
        nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'flex:remoting-destination'.
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)

Pourtant cela fonctionnait parfaitement avec les versions précédentes de Spring BlazeDS Integration …

Je regarde donc le fichier xsd sur lequel se base mon applicationContext (http://www.springframework.org/schema/flex/spring-flex-1.0.xsd), et le remoting-destination est bien présent… étrange. Je regarde également la documentation du projet et d’après cette dernière, ma configuration est bonne … le mystère s’épaissit.

Après quelques recherches, j’ai l’idée de regarder le xsd du jar de Spring BlazDS Integration (org.springframework.flex-1.0.0.M2.jar). Et eureka, je trouve l’explication : le xsd du jar n’est pas le même que celui vers lequel pointe mon applicationContext… Au chargement de l’application, c’est le xsd du jar qui est recherché… De plus, je me rends compte que cette version a subi un peu de refactoring et certains chemins ont été modifiés.
Par conséquent, vous devez déclarer votre service Remote de cette manière :

<bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
  <property name="mappings">
	   <value>
	       /*=mySpringManagedMessageBroker
	   </value>
  </property>
</bean>
<!-- Envoie les requêtes au "message broker" -->
<bean class="org.springframework.flex.messaging.servlet.MessageBrokerHandlerAdapter"/>
<!-- Le MessageBroker de BlazeDs -->
<bean id="mySpringManagedMessageBroker" class="org.springframework.flex.messaging.MessageBrokerFactoryBean" />
<!-- Service myService -->
<bean id="myService" class="com.xebia.impl.MyServiceImpl" />
<flex:remote-service message-broker="mySpringManagedMessageBroker" service-id="myServiceDest" ref="myService" />

Vous remarquerez que remoting-destination et destination-id sont devenus remote-service et service-id et que les chemins des classes MessageBrokerHandlerAdapter et MessageBrokerFactoryBean ont changé.

Néanmoins, une solution plus rapide consiste à effectuer une montée de version vers la 1.0.0.RELEASE de Spring BlazeDS Integration. En effet, le fichier xsd ainsi que les chemins ont été remis comme la version RC2, posant ainsi moins de problèmes.

En espérant que cette solution puisse aider d’autres personnes !

RIA

• Mockito-Flex

Le coin de la technique

• JPA implementation patterns
• HadoopDB : un hybride entre MapReduce et DBMS
• Gaelyk ou Groovy sur AppEngine
• PostGIS, le SIG Open Source qui monte

Evènements de notre communauté en France et à l’étranger

• Enquête JavaEE 6

RIA

Mockito-Flex

Un mois après la sortie de la version 1.0, Mockito-Flex se met à jour en 1.0.1. Une release mineure donc mais qui apporte toutefois son petit lot de nouveautés (matchers anyOf(type:Class), notNull() …).

Les utilisateurs de Mockito ne seront pas perdus, le code Flex étant très similaire au code Java que ce soit pour les assertions ou pour le verify:

var list:ArrayCollection = ArrayCollection(mock(ArrayCollection, "collection", [[]]));
given(list.getItemAt(1)).willReturn("A");
assertEquals("A", list.getItemAt(1));
assertNull(list.getItemAt(2));
...
var array:Array = mock(Array) as Array;
array.push("1");
array.pop();
verify().that(array.push("1"));
verify().that(array.pop());

Le projet est très récent et néanmoins en bonne voie : article sur InfoQ, mailing-list, tutoriel… Comme toujours, rendez-vous est pris dans la section téléchargements.

Le coin de la technique

JPA implementation patterns

Vincent Partington, collègue de Xebia Hollande, a réalisé une série d’articles autour de la spécification JPA. Ses articles sont un complément à la documentation existante afin de faire le tour sur les fondamentaux et les faux-amis de JPA :

• Dao générique
• Persister, retrouver, effacer une entité
• Pattern d’architecture : Pour ou contre les DAO, DTO ou facade service, …
• Et bien d’autres patterns …

JPA et ses implémentations (telle qu’Hibernate) restent une technologie difficile à maitriser, et ces articles vous aideront à prendre des décisions techniques importantes pour vos projets.

HadoopDB : un hybride entre MapReduce et DBMS

Daniel Abadi a présenté HadoopDB, un projet issu des universités de Yale et de Brown, qu’il qualifie d’hybride entre MapReduce et DBMS classique. Il s’agit d’une extension pour Hadoop et Hive qui permet d’utiliser une base de données en remplacement de HDFS, le file system distribué utilisé par Hadoop.

Concrètement chaque nœud Hadoop embarque son propre serveur de base de données. HadoopDB reçoit des requêtes SQL qu’il analyse, traduit en tâches MapReduce qui seront envoyées sur chacun des nœuds du cluster Hadoop, puis retraduites en SQL pour être finalement exécutées par la base de données sous-jacente (SQL to MapReduce to SQL Planner).

L’ensemble du projet est décrit dans la publication qui lui est consacrée. Celle-ci présente en détail les réflexions qui ont accompagné la conception d’HadoopDB et les performances obtenues faces à des DBMS parallèles dédiés à l’analyse de données tels que Vertica. Si les performances mesurées d’HadoopDB sont en léger retrait face à Vertica, l’auteur met en avant que sa solution repose uniquement sur des technologies Open Source et qu’une base de données relationnelle (PostgreSQL) a été utilisée : il espère de meilleurs résultats en utilisant une base de données orientée colonnes.

Gaelyk ou Groovy sur AppEngine

Parmi les sujets traités régulièrement sur notre blog, on retrouve Groovy et Google AppEngine (GAE). Qu’obtient-on en mélangeant ? Et bien le dernier projet de Marcel Overdijk et de Guillaume Laforge à savoir Gaelyk (annonce).

Le toolkit s’appuie sur Groovlets et Groovy Template, et permet de déployer rapidement de petites applications sur GAE. Les auteurs rappellent en effet que pour de plus grosses applications, il vaut mieux se tourner vers Grails.

Le tutoriel très complet permet de faire un rapide tour d’horizon de Gaelyk.
Celui-ci décrit l’arborescence d’un projet Gaelyk, la configuration du web.xml et du appengine-web.xml.
La partie vues et contrôleurs s’intéresse :

• aux variables implicites mises en place par la servlet principale (eager avec request, response, context, session… et lazy avec out, html...),
• aux Groovy Templates, avec plusieurs exemples de gtpl, gestion des incude et redirect,
• aux Groovlets, avec là aussi plusieurs exemples de scripts.

Enfin, une dernière partie détaille les ajouts de syntaxes/méthodes spécifiques à Google AppEngine (envoi de mails, Entity, withTransaction()…) et explique comment déployer son application.
Un exemple d’application qui utilise Gaelyk est la Groovy Web Console, ou l’écriture de code Groovy live. Alors, un petit HelloWorld ?

PostGIS, le SIG Open Source qui monte

Les SIG (Systèmes d’Information Géographique) prennent de nos jours une nouvelle dimension avec la généralisation progressive de terminaux mobiles connectés à Internet et capables de se géolocaliser ou encore avec les sites Web riches proposant des cartes, des calculs d’itinéraires ou des recherches du plus proche point de vente. A travers cette évolution, un plus grand nombre d’entreprises peut potentiellement être intéressé par les SIG.

Alors que pendant un temps les principaux acteurs sur ce marché étaient des produits commerciaux, on trouve désormais une offre Open Source : MySQL Spacial, H2Spacial, SpacialLite et PostGIS.
Au sein de cette offre, PostGIS, une extension de PostgreSQL qui a fait son apparition il y a 4 ans, se distingue par sa maturité et sa popularité. Ainsi, l’éditeur Manning a récemment annoncé un ouvrage qui lui sera consacré pour début 2010.

Le site du projet vient d’annoncer la disponibilité de la version 1.4 de PostGIS apportant son lot d’améliorations et de corrections. Le driver JDBC dédié, composé principalement d’extensions à l’API JDBC standard, est lui aussi mis à jour, on le trouve dans la même archive que PostGIS.

Evènements de notre communauté en France et à l’étranger

Enquête JavaEE 6

Sun, via TheServerSide, relance la communauté Java pour ses cinq enquêtes à thème auprès des développeurs JavaEE6. Ces enquêtes doivent servir à optimiser les cours et les certifications JavaEE 6. Si vous êtes prêts à donner cinq minutes de votre temps à l’amélioration de la formation Java, n’attendez plus, vous avez jusqu’au 31 juillet.

Actualité éditeurs / SSII

• Les standards du Cloud Computing en préparation
• Fin de JavaRebel, place à …

RIA

• GWT 1.7 pour les nouveaux navigateurs !
• Flex Monkey 1.0

SOA

• La base de données dans une Event Driven Architecture
• REST et les abus de langage

Le coin de la technique

• OpenDS passe en version 2.0
• 10 bonnes raisons de chercher le successeur de Java

Evènements de notre communauté en France et à l’étranger

• Soirée Tontons Flexeurs

Actualité éditeurs / SSII

Les standards du Cloud Computing en préparation

Comme pour tout marché émergeant, le Cloud Computing s’est développé autour de technologies propriétaires mises au point par différents éditeurs et fournisseurs. Une session dédiée aux problématiques d’intégration lors du CloudCamp Paris avait conclu qu’aucun standard adapté n’était disponible pour permettre le transfert d’informations entre les différents fournisseurs et technologies du Cloud Computing.

Le monde du Cloud Computing montant en puissance mois après mois, la problématique de standardisation se fait de plus en plus pressante. C’est donc sans surprise qu’on a assisté à la constitution d’organismes de standardisation et de groupes de travail afin d’établir les standards à venir. Afin de donner une visibilité à l’ensemble de ces efforts, l’Open Grid Forum (OGF) annonce la création d’un site commun ou chaque organisme est invité à présenter ses travaux en cours : http://cloud-standards.org. On notera particulièrement deux spécifications prometteuses :

• Open Virtualization Format (OVF) : Format de packaging d’application permettant la distribution et le déploiement simplifié sur environnement virtualisé.
• Open Cloud Computing Interface (OCCI) : API standardisée permettant la définition, le provisioning et le monitoring d’infrastructures exposées en tant que services sur un Cloud (IaaS).

Par ailleurs, l’Open Cloud Consortium (OCC) explique travailler sur des frameworks d’interopérabilité entre Clouds et l’OASIS expose quant à elle sa vision selon laquelle le Cloud Computing est une extension naturelle des concepts SOA, et que, par conséquent, de nombreux standards qu’elle développe actuellement intègrent cette problématique.

Fin de JavaRebel, place à …

Zeroturnaround, l’éditeur de JavaRebel, doit faire face à un joli défi : pour avoir fait une entorse à la marque déposée Java, il doit modifier le nom de son produit, sans pour autant perdre la notoriété d’ores et déjà acquise. Pour faire d’une pierre deux coups (modifier effectivement ce nom mais aussi s’offrir un joli coup de pub), l’éditeur soumet ce renommage à un concours. En jeu, une licence JavaRebel à vie…

RIA

GWT 1.7 pour les nouveaux navigateurs !

Les dernières releases de GWT étaient plutôt espacées dans le temps (1 an entre 1.4/1.5 et 8 mois entre 1.5/1.6) mais il n’aura fallu attendre que 3 mois pour voir débarquer la version 1.6.5 1.7 de GWT.

Cette dernière version (définie comme mise à jour mineure / bugfix release) apporte un meilleur support des derniers navigateurs à savoir Internet Explorer 8, FireFox 3.5 et Safari 4 (meilleur support d’IE8 = disparition d’IE6 ? ).

L’ajout du user.agent ie8, qui peut potentiellement impacter certains projets, a fait pencher la balance vers un numéro de version de type majeure (1.7) pour forcer les développeurs à être attentif sur ce point important (une version de type 1.6.5 n’aurait pas eu le même impact).

Une simple recompilation suffit pour être compatible avec ces navigateurs, aucune modification de code n’est requise. Disponible comme toujours dans la section téléchargement du Google Code.

Flex Monkey 1.0

Plus de 7 mois après la sortie de la version 0.5 (précédente revue de presse), FlexMonkey, le framework de tests automatisés pour applications Flex et Air, se met à jour et passe ainsi en version 1.0 (par InfoQ).

Au menu : réorganisation de l’interface utilisateur, support direct d’applications Air (la console FlexMonkey devenant d’ailleurs une application Air) et tests générés pour Fluint (qui pourront aussi être lancés par FlexUnit 4).

Plusieurs tutoriels/exemples sont déjà disponibles sur la toile, on retiendra plus particulièrement le Getting Started d’Eric Owens (Gorilla Logic) et l’article très complet de Stuart Stern (CEO de Gorilla Logic et créateur de FlexMonkey) sur InfoQ.

SOA

La base de données dans une Event Driven Architecture

Sur son blog dédié aux traitements des évènements dans les systèmes d’informations, Tibco a publié un billet portant sur le positionnement d’une base de données dans une Event Driven Architecture (EDA).

Se trouvant à la base de nombreuses applications et services, elle constitue en effet une potentielle source d’évènements très intéressante. L’auteur met alors en avant la technologie Continuous Query Notification (CQN) intégrée à Oracle 11g, et qui permet aux clients d’une base de données de s’enregistrer pour recevoir des notifications lorsque les données d’une table ou le résultat d’une requête prédéfinie changent. On peut assimiler cette technologie à un mécanisme de trigger qui rappellerait des systèmes externes.

Cette possibilité permet ainsi d’enrichir les sources d’évènements disponibles au sein du système d’information : de par son positionnement, la base de données est capable d’offrir simplement des évènements qui seraient parfois complexes à générer au niveau applicatif. Dans une telle configuration, le Complex Event Processing (CEP) permettra alors de manipuler le volume important d’évènements ainsi créés afin d’en extraire des informations métiers utiles.

REST et les abus de langage

Ryan McDonough, contributeur au projet RESTEasy, a publié un billet dans lequel il fait un parallèle entre les abus de langages liés à REST et les mauvaises pratiques qui en découlent.

Parmi les erreurs de compréhension qu’il met en avant, on retrouve l’assimilation de REST à un protocole, la définition de REST en tant que synonyme de HTTP, ou encore l’utilisation abusive du qualificatif RESTful.

Il est souvent question lorsque l’on parle de REST de définition d’URLs, de représentations multiples d’une ressource, ou, plus couramment encore, d’opposition à SOAP. Loin de ces problématiques, Ryan McDonough met ici en avant le fait que REST est dans la réalité trop souvent utilisé pour justifier à tort tout type d’utilisation douteuse de JSON ou XML sur HTTP…

A ce titre, le livre RESTful WebServices de Leonard Richardson et Sam Ruby permet de comprendre en détail toutes les nuances de ce modèle d’architecture qui sont parfois délicates à appréhender.

Le coin de la technique

OpenDS passe en version 2.0

La version 2.0 du projet OpenDS est disponible. Il s’agit d’un serveur LDAP implémenté entièrement en Java et soutenu par Sun ; ces caractéristiques le positionne donc directement face à Apache Directory Server, son équivalent développé par la fondation Apache.

Ludovic Poitou présente les principales nouveautés de cette version :

• Ajout d’un control panel graphique, en remplacement du status-panel de la version précédente, permettant d’administrer le serveur et ses données
• Amélioration de la réplication multi-master
• Support de connections sécurisées SASL
• Affinement du système de contrôle d’accès
• Amélioration des performances. On notera sur ce point la collaboration avec l’équipe du garbage collector G1 qui avait été exposée il y a 2 mois

Au delà de l’ajout de fonctionnalités, la question du positionnement reste entière pour OpenDS tout comme pour son rival ApacheDS. En effet, l’annuaire est en général une ressource critique du système d’information pour laquelle on préfèrera généralement une implémentation native plus mature. Dès lors, OpenDS se destinera principalement au poste de développement, aux tests, et aux applications embarquant directement leur propre annuaire comme mécanisme de persistance.

10 bonnes raisons de chercher le successeur de Java

Dans la droite ligne d’un certain nombre de keynotes récentes, Mario Fusco expose, sur TheServerSide, 10 bonnes raisons de chercher un héritier à Java. Ces ‘manques’ de Java sont souvent évoqués, parfois partiellement comblés par les futures spécifications. Il nous a semblé malgré tout intéressant de les reprendre ici, ne serait ce pour que ces limitation soient bien comprises de tous.

• Absence de Closures, et son corollaire, l’absence de pointeur sur les fonctions (first-class function).
• L’existence de types primitifs (le langage n’est pas 100 % objet), et un autoboxing pas toujours performant (sur la gestion des null par exemple).
• La faiblesse des Génériques : impossible de découvrir leur type au Runtime.
• L’impossibilité de supprimer certains warnings concernant les génériques.
• Impossible de passer un paramètre void à une méthode.
• Le pattern proxy n’est pas implémenté de manière native sur les classes concrètes.
• Le switch…case est très faible
• La présence des exceptions Checked qui obligent à de douloureux try...catch ou à d’illisibles throws

Mario Fusco a l’honnêteté de reconnaitre que nombre de ces défauts font partie des péchés originels de Java et qu’il est quasiment impossible de les remettre en cause sans gravement compromettre la compatibilité ascendante du language, qui en est une des pierres angulaires. C’est pour cette raison qu’il se met en quête du next gen language

Vous ne manquerez pas de remarquer que, comme tout article qui parle de succéder à Java, ce billet est richement (parfois de manière assez virulente) commenté.

Evènements de notre communauté en France et à l’étranger

Soirée Tontons Flexeurs

Demain (mardi 21 Juillet) de 18h à 20h se déroulera une nouvelle soirée des Tontons Flexeurs dont le sujet est un retour d’expériences sur la mise en place d’applications Flex en entreprise dans le monde Java (tests unitaires/fonctionnels, intégration continue…).
L’événement étant déjà complet, il ne vous reste plus qu’à bookmarker leur calendrier pour être informé des prochaines réunions

RIA

• GChart 2.5 pour GWT

SOA

• jBPM 4.0 est disponible
• Avez-vous besoin d’un ESB ?

Le coin de la technique

• Making Good Software, bonnes pratiques du développement logiciel

Evènements de notre communauté en France et à l’étranger

• Sun fait évoluer sa certification programmer

RIA

GChart 2.5 pour GWT

Afficher des résultats sous forme d’histogramme ou de camembert se résume pour bon nombre de projets Java à l’import de JFreeChart, la librairie de référence pour faire des diagrammes en Java (démo).

Pour les projets GWT, une autre API fait beaucoup parler d’elle en ce moment (entre autres sur Ajaxian et onGWT) et cette API est GChart 2.5. Son objectif est simple : réaliser rapidement de beaux graphiques.

Une démo nous montre les capacités de l’outil en termes de rapidité d’affichage. Le code source de chaque exemple est aussi disponible (source du graphique Estimated Future Oil Prices).

Pour la release note technique (plus de compatibilité GWT 1.4, navigateurs testés, objets et méthodes dépréciés, bugfix…), tout se trouve sur cette page. Il ne reste plus qu’à tester ! Les retours d’expériences sont bienvenus dans les commentaires.

SOA

jBPM 4.0 est disponible

Tom Baeyens annonce sur son blog la disponibilité de la version finale de jBPM 4.0 respectant ainsi le calendrier prévu.

jBPM n’avait pas connu d’évolution majeure depuis 2005, cette nouvelle version constitue donc un évènement majeur pour les utilisateurs de jBPM. Les nouveautés apportées sont importantes :

• Nouvelle version du plugin Eclipse (GPD) permettant la définition graphique de processus suivant la notation BPMN
• Introduction de JBoss PVM (Process Virtual Machine), un moteur de workflow générique utilisé par jBPM pour l’implémentation des différents langages de définition de processus qu’il propose (jPDL, BPEL et Pageflow)
• Refonte des schémas de base de données utilisés pour les rendre plus évolutifs
• Intégration native à Spring
• Amélioration des performances
• Simplification de l’installation

Cette nouvelle version est d’ores et déjà disponible sur le repository Maven de JBoss. Par ailleurs, l’ensemble des apports de jBPM 4 seront passés en revue lors du JBoss World 2009 en septembre prochain, ainsi qu’à Devoxx 09 en novembre.

Avez-vous besoin d’un ESB ?

Ross Mason, fondateur de MuleSource a publié sur son blog une liste de points à vérifier avant de mettre en place un ESB. L’article, au titre plutôt racoleur (To ESB or not to ESB), à fait du bruit sur Twitter. D’ailleurs, en aparté, pour avoir nous-mêmes fait circuler ce lien, nous avons été surpris d’avoir été répondu par un certain @shakesp.

Pour en revenir au cœur du sujet, les points qui nous semblent intéressants sont simples à retenir :

• Commencez à penser à un ESB pour intégrer 3 applications, à plusieurs ESB si vous en avez plus que 10
• Avez-vous absolument besoin de plusieurs protocoles de communications ?
• Avez-vous de réels besoins d’intégration ? Découpage, routing, agrégation de messages …

Le coin de la technique

Making Good Software, bonnes pratiques du développement logiciel

Une fois n’est pas coutume, nous vous proposons cette semaine la découverte d’un blog tout récemment ajouté dans nos RSS : Making Good Software. Ce blog établit des listes de bonnes (et mauvaises) pratiques du développement logiciel. Non pas que son contenu soit extraordinaire, puisque vous en connaissez probablement déjà les plus gros points, mais il a le mérite de les rappeler : toute ressemblance avec personnes existantes ou ayant existé ne suivant pas ces règles ne saurait être que fortuite

Dans un premier article, une liste des 5 erreurs non techniques les plus répandues chez les développeurs, dont nos 2 préférés qui vous feront probablement penser à quelqu’un de votre open-space:

• Ego surdimensionné :  » je suis le meilleur développeur au monde, et ça me permet d’avoir toujours raison  » (ou la fameuse conversation à sens unique)
• Manque de discipline :  » j’essaye de tout faire en même temps, mais je ne termine jamais rien  » (définition de done plus que douteuse)

Un autre article vous donne une liste de 10 points à suivre pour écrire du bon code :

• Factorisez votre code, pour simplifier la correction d’anomalies et le refactoring
• Ecrivez des méthodes les plus courtes possibles
• Travaillez le nom des vos objets, variables et méthodes, il s’agit de la meilleure des documentations
• Une seule responsabilité par classe,
• Travaillez l’organisation de votre code, par groupes physiques de fichiers et groupes logiques de fonctions
• Faites des tests unitaires, quand vous aurez fini, faites-en encore plus
• Refactorez le plus tôt et le plus souvent possible
• Auto-documentez votre code
• Privilégiez le code par interface
• Faites des revues de code régulières

Dans un autre article l’auteur décrit une matrice permettant de noter votre code en fonction de sa simplicité et de son extensibilité.

Et pour finir, histoire de ne pas commenter l’ensemble des billets du blog, les 7 étapes pour corriger un bug : de la recherche de l’erreur, à l’analyse des dommages collatéraux.

Evènements de notre communauté en France et à l’étranger

Sun fait évoluer sa certification programmer

Sun teste une nouvelle version de sa certification SCJP (Sun Certified Java Programmer). La grosse nouveauté de cette révision : l’examen contiendra dorénavant une partie programmation. Cette certification, que certains appellent ‘pensez comme un compilateur Java’ évolue donc pour adopter une approche plus pragmatique.

• Les demandes d’ New Sun Java Programmer Plus Certification, SCJP vs SJPPC

Actualité éditeurs / SSII

• Oracle annonce Oracle Middleware 11g

RIA

• ZK et ZKGrails

Le coin de la technique

• La transition de Jetty vers Servlet 3.0
• XWT pour Eclipse E4
• Se donner de la visibilité lors d’un échec Selenium

Evènements de notre communauté en France et à l’étranger

• Soirèe riviera JUG

Actualité éditeurs / SSII

Oracle annonce Oracle Middleware 11g

Le 1er Juillet, Oracle a présenté sa nouvelle offre autour du middleware: Oracle Middleware 11g et en particulier son offre SOA, Oracle SOA Suite.
Oracle propose un ensemble de produits qui utilisés conjointement permettent de concevoir, développer et superviser une application SOA.
Cette offre s’articule principalement autour de:

• JDeveloper pour le développement avec toujours un support soutenu de SCA et SDO
• Oracle Data Integration Suite, une offre de connecteurs (Messaging, Database,…)
• Oracle Service Bus 11g pour le routage, la transformation. Les principales nouveautés sont la possibilité d’appeler du code Java (seuls les appels vers des WebServices et des EJB étaient proposés), d’initier des transactions (XA) depuis le bus et de mettre en cache des résultats via Oracle Coherence 3.5 .
• Oracle BPEL Process Manager orchestre l’ensemble des processus métiers
• Oracle Business Rules offre l’externalisation des règles métiers
• Oracle Complex Event Processing (CEP) permet le traitement temps réel d’évènements métiers complexes.
• Oracle Business Activity Monitoring et Oracle Enterprise Manager Fusion Middleware Control se chargent de la supervision technique et métier de l’application
• Oracle Weblogic Server 11g (10.3.1). Cette version mineure de Weblogic Server remplace Kodo par TopLink, côté JMX, offre la possibilité d’inscrire des ‘CustomMBeans’ dans le Domain Runtime MBean Server et d’y accéder par WLST et, côté sécurité, deux nouveaux providers pour Oracle Internet Directory et Oracle Virtual Directory. Le support de Spring Framework semble également un peu plus poussé. Le plugin Eclipse est également mis à jour Oracle Enterprise Pack for Eclipse 11g
• Oracle Application Grid Coherence 3.5, composé de Weblogic Server, JRockit, Coherence 3.5, offre la technologie pour créer des applications ‘Data grid’.

Cette nouvelle version des produits étiquetés ‘Middleware’ présente (enfin) l’aboutissement de l’intégration des produits Oracle et BEA en une suite unifiée. Chaque domaine de l’application (développement, BPM, routage, intégration, supervision, …) est maintenant clairement associé à un produit (qui est parfois un regroupement de produits). Pas de nouveaux produits, seulement des versions mineures : serait-ce la version de la maturité ?

RIA

ZK et ZKGrails

Des nouvelles du projet ZK (Direct RIA) avec la sortie de la version 3.6.2 (par The Server Side)

Pour rappel, ZK est un framework open source Ajax permettant de développer des interfaces riches. Il embarque de nombreux composants graphiques qui vont de la date avec calendrier, de fenêtres et popups mais aussi des menus, des grilles… La définition de l’UI se fait à l’aide de ZUML (ZK User Interface Markup Language).

Cette version apporte d’importantes nouvelles fonctionnalités :

• Support de Google App Engine
• Amélioration des performances
• Nouveaux modes (include, instant, auto…)
• Mise à jour de composants (XUL et HTML)

Au total, c’est 48 bugs corrigés et 16 nouvelles fonctionnalités pour cette nouvelle mouture de ZK (qui se télécharge sur cette page).

A noter que dans la foulée, le projet ZKGrails (intégration du framework ZK dans Grails) a été mis à jour et embarque désormais ZK en version 3.6.2 (et toujours Grails en 1.1.1).

Cette version 0.7.4 de ZKGrails se récupère dans l’onglet téléchargements.

Le coin de la technique

La transition de Jetty vers Servlet 3.0

Jetty propose, depuis sa version 6, une API de continuation qui permet de suspendre et restituer l’exécution d’une requête. Cette fonctionnalité est particulièrement utile dans le cadre d’une application Comet.

Or, cette fonctionnalité est directement adressée par Servlet 3.0 dont la finalisation est imminente et qui sera implémentée partiellement par Jetty 7 et entièrement par Jetty 8. Un temps destiné à être dépréciée après l’arrivée des Servlet 3.0, l’API de continuation de Jetty perdurera parallèlement.

Greg Wilkins en explique les raisons : il souhaite offrir un compromis intermédiaire à la complexité de l’API asynchrone de Servlet 3.0. La compatibilité serait quant à elle assurée dans tous les conteneurs Jetty 6, 7 et 8.
L’API Servlet 3.0 apporte un certain nombre de changements majeurs. On peut donc s’attendre à ce que ce type d’initiatives visant à assurer une transition en douceur des applications se multiplient d’ici la finalisation de la spécification et de ses implémentations.

XWT pour Eclipse E4

Eclipse E4 est la prochaine version majeure d’eclipse.

Un des objectifs principaux d’e4 est de simplifier les APIs existantes d’eclipse.
Ce refactoring touche entre autres l’UI d’eclipse et son modèle de composants.

Cette vidéo, de type XWT in action, nous montre à la fois le code (descripteur XML du modèle…) mais aussi l’outillage avec une vue éditeur splittée source / design et une palette de composants SWT (qui sont tous gérés par XWT) et JFace.
A noter aussi ce tutoriel de type HelloWorld qui nous montre vers la fin la possibilité de styler ses composants avec une feuille CSS.

Pour celles et ceux qui sont déjà conquis ou qui souhaitent tester ces nouvelles fonctionnalités, l’installation d’E4 sur un eclipse existant est résumée sur cette page.

Se donner de la visibilité lors d’un échec Selenium

Dans la série trucs et astuces, Daniel Wellman partage sur le blog de stickyminds.com deux moyens de se donner de la visibilité lorsqu’un test Selenium échoue.

• Faire une capture d’écran lors de l’échec : l’idée peut sembler triviale, mais faire une capture d’écran devrait permettre d’éliminer rapidement un certain nombre de cas (une erreur de navigation par exemple). L’interface com.thoughtworks.selenium .Selenium (et son implémentation par défaut) de SeleniumRC offre une méthode (captureScreenshot(String)) pour réaliser cette capture.
• Enregistrer le DOM HTML : là encore, l’interface Selenium offre une solution toute faite pour enregistrer l’intégralité du source dans un fichier texte : getHtmlSource()

Ne reste plus qu’à factoriser l’appel de ces méthodes à chaque fois qu’un test échoue, et vous aurez à votre disposition pour débugger une erreur d’assertion, une StackTrace, une copie d’écran et un arbre DOM. Cela devrait faire gagner quelques précieuses minutes, surtout quand les scénarii Selenium sont longs à rejouer.

Evènements de notre communauté en France et à l’étranger

Soirèe riviera JUG

Le riviera JUG organise sa 4ème rencontre le 15 juillet prochain. Au menu cette soirée estivale, vous pourrez déguster une présentation sur la méthode SCRUM en plat de résistance et une présentation sur Groovy en dessert.

Soyez nombreux ! Et n’oubliez pas de vous inscrire ici.

RIA

• Vaadin 6
• Adaptateur Gilead pour GAE
• Une série d’annonces chez Adobe

Le coin de la technique

• Scalabilité avec Hibernate et Shards
• Jigsaw vs OSGi
• Pourquoi utiliser un portail ?
• Embarquer le Web dans Java avec JWebPane

Evènements de notre communauté en France et à l’étranger

• Xebia @ Jazoon 09

RIA

Vaadin 6

Au revoir IT Mill Toolkit et bienvenue à Vaadin (vu sur leur blog) !

Pour ceux qui ne le connaissent pas encore, Vaadin (anciennement IT Mill Toolkit) est un framework de développement d’applications RIA qui s’appuie sur GWT. Sa particularité est d’être runtime donc aucune compilation spécifique n’est demandée avant de packager la webapp (à l’inverse de GWT).

Simple changement de nom ? En tout cas très peu de changement côté API selon les auteurs du framework. Il faut plutôt se tourner vers l’outillage pour voir quelques nouveautés : un plugin eclipse (création de projets, de composants UI, de thèmes…) et, inclus dans le plugin, un éditeur WYSIWYG.

Côté liens utiles, l’habituel showcase, le livre et la comparaison maison avec les autres frameworks du marché (et la concurrence est rude dans le monde du RIA).

A noter que Vaadin sera présent à Jazoon pour une conférence sur RIA Security le mardi 23 juin à 15h (slides, projet et autres sur cette page).

Adaptateur Gilead pour GAE

Vous connaissez GWT, Gilead, et Google App Engine ? Et bien il ne reste plus qu’à mélanger tout ça et on obtient le Gilead GWT adapter for Google AppEngine (vu sur le GWT Blog).

Tout démarre d’un thread google groups avec comme point de départ la serialization exception lancée par les entités persistantes transférées vers GWT. Évidemment, la solution qui ressort très rapidement, outre l’utilisation de DTOs, est de passer par Gilead pour transformer nos entités persistantes en POJOs. Il suffit d’ajouter le jar adapter4appengine et de remplacer la classe PersistentRemoteService par EngineRemoteService dans vos remotes services. Dès lors, il sera possible d’envoyer ses entités persistantes vers le client GWT sans exceptions de sérialisation sur GAE.

1.0 M2 téléchargeable à cette url, documentation par ici. Attention toutefois, cette version n’est pas production ready.

Une série d’annonces chez Adobe

Après l’annonce de la sortie de la plateforme Flash il y a quelques semaines, voici une nouvelle série d’annonce de la part d’Adobe.

Pour commencer, deux news relayées par Andrew Twice dans InsideRIA.
La première concerne la sortie d’Adobe Table en version bêta. Cet outil permet de créer des feuilles de calcul, des plannings ou encore des listes de tâches en ligne:

• Les utilisateurs peuvent ajouter des données en même temps: les données sont mises à jour en temps réel pour tout le monde.
• Possibilité de savoir qui travaille sur Adobe Table.
• Création d’écrans communs et privés : les utilisateurs peuvent travailler de manière coopérative, et/ou créer des espaces privés pour ne garder que les informations importantes.
• Filtrage : les utilisateurs peuvent filtrer leurs données en temps réel.
• Tri.

Similaire à Google Document, cet outil a été développé sur la plateforme Flash et va continuer à évoluer. La démo se passe ici, la seule contrainte : avoir un compte Adobe.

La deuxième annonce concerne l’ouverture de la spécification de Real-Time Messaging Protocol (RTMP). Comme nous en avions parlé ici, la spécification a été publiée lundi dernier.

Enfin, Michael Chaize parle de la sortie de LiveCycle Data Services 3 en bêta. Disponible sur le labs d’Abobe, cette nouvelle version propose une meilleure qualité de service pour des applications dont la fiabilité est primordiale telles que les applications bancaires par exemple. Venant compléter la plateforme Flash (avec Flex 4 et Flash Builder 4), Adobe incite la communauté à faire ses retours sur le forum.

Le coin de la technique

Scalabilité avec Hibernate et Shards

Une session de QCon 2008, traitant de la scalabilité d’Hibernate, vient d’être mise en ligne. Présentée par Emmanuel Bernard, project lead d’Hibernate Search, et Max Ross, project lead d’Hibernate Shards, cette présentation offre une approche peu courante sur un problème pourtant récurrent.

Outre les classiques solutions permettant d’éviter certaines pertes de performance avec l’augmentation du volume traité, telles que la bonne gestion du cache, et les optimisations SQL, il a été question d’utiliser Hibernate Search et Hibernate Shards.

Hibernate Search est connu pour sa capacité à simplifier les recherches dans un ensemble d’entités grâce à l’utilisation de Lucene conjointement à la base de données. Emmanuel Bernard proposait ici de déléguer à Search certaines recherches qui s’avèrent très coûteuses à effectuer en base. Lucene étant placé sur une machine séparée, et pouvant même fonctionner en maître / esclave, il est ainsi possible d’obtenir une intéressante répartition de la charge.

Hibernate Shards, bien que plus ancien, est moins répandu du fait qu’aucune version finale n’a encore été produite. Il s’agit d’un module additionnel pour Hibernate permettant à une application de manipuler des données partitionnées sur plusieurs BDD. Le but étant d’encapsuler la conscience du partitionnement des données au sein de la couche Hibernate afin que l’application n’ait pas à gérer cette problématique. Les possibilités du framework sont intéressantes :

• La gestion correcte des Criterias sur des données partitionnées grâce à ShardedCriteria.
• Virtual Shards permettant de faire la distinction entre shard logique et shard physique et ainsi d’augmenter le nombre d’instances de base de données au fur et à mesure de l’augmentation des besoins.
• Generation d’IDs compatibles avec l’utilisation sous-jacente de plusieurs BDDs grâce à l’utilisation d’UUIDs.
• Gestion correcte de BDDs hétérogènes.

Ce sont finalement les fonctionnalités manquantes qui permettent de comprendre pourquoi Shards est toujours en version bêta. Max Ross s’est expliqué il y a plusieurs mois sur les problématiques rencontrées, de manière succincte sur un forum et plus longuement dans une interview. De nombreux défis restent ainsi à relever concernant la gestion correcte des agrégations dans les ShardedQuery et la fourniture d’outils d’aide au partitionnement et repartitionnement des données.
Max Ross est employé par Google et non par JBoss, tout comme les deux autres committers du projet (le code ayant été donné à JBoss par Google), et affirme ne disposer que de 20 % de son temps pour Shards. Ceci n’explique que partiellement le peu de commits sur le projet et ne nous rassure guère quant à sa finalisation prochaine.

Jigsaw vs OSGi

Sept mois après le démarrage du projet Jigsaw, sa légitimité n’est toujours pas reconnue face à OSGi qu’il est venu défier sur son propre terrain.

La semaine dernière JavaPosse diffusait une interview de Mark Reinhold et Alex Buckley, où ils ont pu présenter plus en détail leur vision de Jigsaw :

• Il a été conçu pour modulariser le JDK et est intégré au langage.
• Il ne repose pas sur une spécification car cela n’était pas possible compte tenu du calendrier de JDK 7. Il est donc à considérer comme un « détail d’implémentation » tout comme la gestion du classpath l’était dans les JVMs précédentes.
• Il n’est pas supposé entrer en concurrence avec OSGi, des outils permettant l’intégration entre modules Jigsaw et bundles OSGi étant prévus, mais non prioritaires.

Dans le même temps, Eric Newcomer (Co-Chair, Enterprise Expert Group de l’OSGi Alliance), postait une série de billets très virulents à l’égard du projet Jigsaw, reprochant principalement que Sun n’ait pas voulu se tourner vers OSGi, ne cherchant pas à combler les manques qu’il y trouvait, se tournant immédiatement vers une nouvelle technologie et ignorant donc les 10 années d’expérience acquises par OSGi.

En fait, il semble n’y avoir aucune justification technique permettant d’expliquer l’orientation de Sun vers Jigsaw plutôt que vers OSGi ou vers une évolution d’OSGi intégrée au langage. La véritable raison serait alors à chercher sur le plan politique : la modularisation est un concept important qui manque à Java actuellement et Sun ne pouvait probablement pas se permettre, pour l’ajout d’un tel concept, de s’appuyer sur une spécification émise en dehors du JCP sur lequel il a la gouvernance.

Pourquoi utiliser un portail ?

Le dernier podcast des Cast Codeurs était l’occasion d’une interview de Thomas Heute et Julien Viet sur les portails d’entreprise et sur le partenariat entre eXo et JBoss dont nous vous parlions la semaine dernière.

Les détails liés au partenariat ont déjà été largement couverts par la blogosphère, et c’est surtout le tour d’horizon du concept même de portail que l’on retiendra. Celui-ci reste en effet souvent un élément ambigu au sein de l’écosystème JEE.

Le rôle du portail est d’agréger plusieurs applications au sein d’une unique application Web. Ce besoin technique peut être atteint à plusieurs niveaux de l’architecture de l’application :

• Au niveau back-end, par agrégation de Web Service, se conformant ainsi à l’un des préceptes des SOAs.
• Au niveau applicatif, par l’utilisation d’un portail, ou d’une solution spécifique.
• Au niveau du navigateur Web, par l’utilisation de gadgets, en suivant le principe des Mashups.

En outre, il a également été question des problématiques d’intégration des frameworks Web aux portlets, de complexité éventuelle, et d’adaptation des technologies Web aux portlets. Déterminer si un portail doit être utilisé dans une architecture dépend alors du niveau de tolérance à ces problématiques.

Embarquer le Web dans Java avec JWebPane

Depuis plusieurs années, lorsque l’on veut afficher une page Web au sein d’une application Swing, il faut se tourner vers le composant Browser de la librairie Jdic. Ce composant utilise Embeddable Mozilla, et se présente sous la forme de code natif décliné pour chaque OS et d’un wrapper Java. Outre la nécessité de fournir une version spécifique à chaque OS, ce composant présente également l’inconvénient de mal s’intégrer aux applications Swing du fait de sa nature heavyweight. Pour rappel, un composant est dit heavyweight lorsqu’il est dessiné par l’environnement graphique du système d’exploitation ; à l’opposé il devient lightweight s’il est dessiné par l’application, ce qui est le cas de l’ensemble des composants Swing. Or, faire cohabiter les deux types de composants est délicat car n’étant pas dessinés au même moment, leur superposition est confuse et des chevauchements non contrôlables apparaissent.

Lors de JavaOne, Alexey Ushakov a fait la démonstration du composant JWebPane sur lequel il travaille actuellement et vient de poster des captures d’écrans. Contrairement à Jdic Browser, JWebPane se base sur le moteur WebKit pour effectuer le rendu HTML. Or celui-ci se caractérise par sa nature lightweight s’intégrant agréablement à Swing. La présentation d’Alex Ushakov permet également de constater que son composant est particulièrement riche en possibilité d’interactions et apporte un support pour d’éventuels plugins tels que Flash.

On ne peut qu’apprécier le choix de Sun de créer un composant pour Swing, réutilisable dans JavaFX, plutôt que de privilégier uniquement JavaFX comme cela est souvent le cas depuis son arrivée. L’intégration de JWebPane au JDK 7 est maintenant indispensable pour rendre ce composant réellement exploitable : se basant sur WebKit, il repose donc sur des librairies natives qu’il sera nécessaire de livrer avec les applications Java et seul l’intégration au JDK permettrait de l’éviter. Or, malgré les appels de la communauté, JWebPane reste pour le moment absent de la liste des features du JDK 7 et il est uniquement question d’une mise à disposition sur Java.net.

Actualité éditeurs / SSII

• Yahoo! distribue Hadoop
• JBoss et eXo fusionnent leurs solutions de Portlets
• Refonte de JBoss Messaging

RIA

• AjaxSwing 2.4

Le coin de la technique

• SoapUI 3.0 se prépare
• Comparaison Gigaspace – Coherence
• L’invocation dynamique pour Java se concrétise

Evènements de notre communauté en France et à l’étranger

• Retour sur le CloudCamp

Actualité éditeurs / SSII

Yahoo! distribue Hadoop

Yahoo! a annoncé la disponibilité de leur propre distribution du projet Hadoop. Répondant à une demande de la communauté qui souhaitait avoir accès aux modifications effectuées par Yahoo! en interne, cette distribution est basée sur la dernière version du projet Hadoop disponible auprès de la fondation Apache.

Avec 13 committers sur les 22 que compte au total Hadoop, Yahoo! porte largement ce projet dont la popularité croît rapidement. Dans un contexte où Google, son concurrent direct, affirme fortement sa présence dans le domaine du calcul distribué et sur le très convoité bien qu’émergeant marché du Cloud Computing, le projet Hadoop constitue une belle vitrine technologique pour Yahoo!.

Souhaitant couper court aux inévitables accusations de tentative de fork ou de prise de contrôle du projet qui n’ont pas tardées à arriver, Yahoo! précise sur la page d’accueil de sa distribution que l’ensemble des patchs apportés par cette dernière ont déjà été contribués à Apache mais ne sont pas encore apparus dans une version stable.

JBoss et eXo fusionnent leurs solutions de Portlets

JBoss a annoncé la constitution d’un partenariat avec eXo qui va donner lieu à la fusion de leur solutions de Portlets respectives : JBoss Portal et eXo Portal. C’est assez logiquement la solution de JBoss qui survivra à cette fusion.

En pratique, le portail résultant proposera les spécificités suivantes aux utilisateurs :

• L’expertise de JBoss sur son moteur de Portlet qui était plus abouti que la solution d’eXo en terme de performance et de modularité.
• L’interface utilisateur d’eXo Portal ainsi que les possibilités d’administration confortables qu’il apportait.
• Le support des Portlets 2.0 telles que définies par la JSR-286. Les deux portails supportaient déjà cette spécification finalisée il y a un an.
• Les deux entreprises seront a priori à même de proposer du support sur JBoss Portal

Cette information a été relayée par le Touilleur, et Janus Boye propose une analyse des impacts de cette fusion pour les clients actuels de l’une des deux solutions existantes.

Refonte de JBoss Messaging

JBoss Messaging est une brique importante de la plate-forme entreprise de JBoss. Après avoir entrepris une ambitieuse refonte de son serveur d’application, l’éditeur réitère l’opération avec son middleware de messages. JBoss Messaging 2.0 vient en effet d’être mis à disposition en version beta. Tim Fox, project lead de Messaging, précise que cette nouvelle version ne réutilise que 5 % du code de son prédécesseur. Parmi les nouveautés, on notera en particulier :

• Embarquable dans n’importe quel type d’application et intégrable facilement à JBoss MicroContainer ou à d’autre framework d’injection de dépendances (Spring ?)
• Stockage performant des informations de journalisation
• Stockage JDBC s’appuyant sur Hibernate
• Support des messages de grosse taille
• Moteur NIO supportant TCP, SSL, HTTP et APR

Il est intéressant de noter que JBoss Messaging 2.0 s’appuiera sur un moteur NIO basé sur Apache Mina. Ce choix est inattendu, dans le mesure où JBoss publie Netty, un framework concurrent de Mina créé il y a un an par Trustin Lee, alors committer sur le projet Mina. Le framework NIO d’Apache bénéficiant d’une plus grande maturité et d’un support APR aura probablement eu raison du corporatisme.

Par ailleurs, le support d’AMQP, STOMP et REST devrait arriver d’ici la version finale 2.0 selon Tim Fox. Ces technologies de transports constituent un attrait stratégique important : AMQP dispose d’un fort potentiel en tant que protocole standard de transport de messages M2M, STOMP assure la compatibilité avec d’autres middlewares de messages, et REST permet de s’aligner sur ActiveMQ et d’offrir un accès Web Service au MOM non sans rappeler Amazon Simple Queue Service.

RIA

AjaxSwing 2.4

Un projet qui fait beaucoup de bruit en ce moment, avec entre autres une présentation / démo à Java One, c’est Eclipse RAP. Pour résumer, un projet de type RAP sera très similaire à un projet RCP, à la grosse différence que la cible ne sera pas le desktop mais le browser. Cela veut dire que l’on continue à développer en SWT like (RWT) avec toutes les compétences acquises pour le développement d’un client lourd mais qu’on obtiendra au final un client léger.

Mais qu’en est-il pour Swing ? C’est du côté de chez TSS que l’on apprend la release 2.4 d’un projet faisant le pont entre Swing et HTML : AjaxSwing.

L’outil convertira votre application Swing en application HTML / Javascript au runtime (à l’inverse de GWT qui le fait à la compilation). Aucune modification spécifique ni connaissance particulière n’est demandée par AjaxSwing : le code est en pur Java / Swing. Que du bonheur Reste maintenant à voir sur un projet d’envergure si tout se fait réellement sans coup de tournevis particulier…

Pour les nouveautés de cette 2.4, on note :

• Amélioration mémoire (vidage du buffer entre les requêtes)
• Meilleur support des mouse listeners
• Amélioration de composants (FileOpenDialog, JTable cells…)
• Meilleures performances (regexp, communication serveur…)
• Plusieurs corrections de bugs

Plusieurs démos sont disponibles avec des applications en Java Web Start et les mêmes en Ajax. Et bien sûr un lien vers les pages incontournables : licences et téléchargement.

Le coin de la technique

SoapUI 3.0 se prépare

Eviware relaie via The ServerSide, l’annonce de la sortie en version 3.0beta de SoapUi, l’outil graphique pour manipuler des WebServices.
Après l’ajout de la gestion de services REST, ce nouvel opus continue sur la même voie pour faciliter encore leurs manipulations :

• A partir des différentes requêtes et réponses, l’outil génère un schéma XML de validation/WADL des flux et ce même si le contenu échangé n’est pas du XML (par exemple JSON ou HTML)
• Ajout du support des opérations OPTIONS et TRACE
• Montée de version de la spécification WADL.
• Comme pour le taux de couverture de test des opérations d’un WSDL, il est maintenant possible d’avoir le même calcul sur les ressources, méthodes et paramètres REST (accessible seulement pour la version pro).

De plus, cette nouvelle version comporte entre autres les fonctionnalités suivantes :

• Support de JavaScript : dorénavant, en plus de groovy, il possible d’utiliser du JavaScript comme langage de script
• L’outil WS-I utilisé pour calculer son niveau de conformité WS-I Basic Profile est maintenant packagé avec SoapUI
• Le navigateur de composant est amélioré pour permettre la vision de réponse HTML et REST au contenu complexe (ex : FLASH, SVG, Images…)

A ceci s’ajoute la correction de bugs (voir la realease note complète). SoapUi se positionne encore plus comme l’outil incontournable pour manipuler WebServices et Services REST.
Bientôt sur notre blog une série d’article présentant les principales fonctionnalités de l’outil.

Comparaison Gigaspace – Coherence

Gojko Adzic (via TheServerSide) propose sur son blog une intéressante comparaison entre deux des produits phares du DataGrid, Oracle Coherence et Gigaspace XAP (dommage d’avoir laissé de coté IBM eXtrem Scale).
Cette comparaison porte sur cinq points :

• Cache de données : match nul, les fonctionnalités des deux produits sont quasi identiques.
• Processing : Gigaspace possède un modèle de processing orienté évènements et offre un bonne intégration de Spring Transaction. Coherence est plus limité.
• Déploiement : Gigaspace se positionne en remplacement des serveurs d’applications, et possède donc des mécanismes de déploiement comparables, ce que Coherence ne propose pas. D’un autre coté, le produit d’Oracle offre un mécanisme de sérialisation qui autorise plusieurs version d’une même classe à être déployées sur une grille.
• Scaling : Coherence offre un scaling dynamique (à la hausse comme à la baisse) là où Gigaspace ne fonctionne qu’avec un nombre de nœuds données.
• Persistance : là encore, les fonctionnalités offertes sont très comparables

Et comme d’habitude dans ce genre de comparaison, pas de vainqueur, pas de vaincu, seulement deux produits qui répondent à des besoins différents :

• Gigaspace XAP, plus apte à remplacer des serveurs d’applications et réaliser du calcul distribué. Le modèle de processing est plus flexible et plus riche que celui de Coherence
• Coherence, très performant dans les grilles passives (lecture seulement), car il scale dynamiquement, offre une topologie de données flexible et possède de riches librairies clientes.

Pour résumer, cet article propose une très bonne grille d’aide à la décision.

L’invocation dynamique pour Java se concrétise

Rémi Forax, l’un des 4 committers d’ASM, un framework de manipulation de bytecode largement utilisé dans le monde Java, vient d’annoncer que leur dernière version supportait l’instruction invokedynamic.

Cette instruction est définie par la JSR-292 et vise à simplifier l’invocation de méthodes non connues lors de la compilation, ce qui constitue une des principales capacités des langages dynamiques tels que Groovy. Un gain significatif de performance est donc attendu pour ces langages, puisqu’ils n’auront alors plus à s’appuyer sur un coûteux mécanisme d’introspection ou de génération dynamique de bytecode d’invocation.

Au delà des langages dynamiques qui sont les premiers destinataires de cette JSR, de nombreux frameworks pourront également profiter de cette possibilité. En effet, la manipulation de JavaBeans et d’annotations, deux concepts majeurs dans le monde JEE actuel, induisent de nombreuses invocations de méthodes découvertes au runtime. Dans de larges projets, cela conduit actuellement à la génération massive de bytecode pour éviter de très lentes introspections, induisant une forte consommation de la PermGen des JVMs.

Le support de l’instruction invokedynamic par ASM, combiné au fait que le draft actuel de la JSR-292 est d’ores et déjà implémenté et disponible dans la preview de l’OpenJDK 7 depuis la b59, permet d’être optimiste quant à la finalisation prochaine de cette JSR.

Evènements de notre communauté en France et à l’étranger

Retour sur le CloudCamp

Un CloudCamp s’est tenu à Paris le 11 juin, réunissant un certain nombre d’acteurs du Cloud Computing. Les CloudCamps ont été initiés par Reuven Cohen et Dave Nielsen et visent a partager la connaissance et les expériences sur ce secteur émergeant.

Ce CloudCamp s’est révélé bien plus commercial dans son contenu que les JavaCamps : de nombreux partenaires ont ainsi présenté leurs solutions pendant environ une heure avant que les réelles sessions (au nombre de quatre, se déroulant en parallèle) ne commencent. De chacune d’entre elles, on retiendra :

• Architecture du Cloud : une solution de Cloud Computing doit apporter abstraction, elasticité et automatisation. Si les deux premiers points sont d’ores et déjà couverts par les solutions actuelles, l’automatisation n’est en revanche pas encore une réalité. Ce point constituera un élément déterminant pour l’adoption du Cloud Computing.
• Cloud et Sécurité : les problèmes de sécurité que l’on connaît aujourd’hui dans les SI demeurent avec le Cloud Computing, mais de nouveaux défis s’annoncent dans le cas de clouds accessibles publiquement et répartis à travers Internet sans forcément passer par un VPN dédié.
• Cloud et Intégration : le constat est sombre. Les projets lancés par les différents éditeurs et fournisseurs surfant sur la vague du Cloud Computing ne suivent aucune standardisation. Changer de fournisseur ou de solution sur un projet constitue actuellement une modification majeure.
• Aspects business du Cloud : l’émergence du Cloud Computing draine la création de nouveaux besoins à pourvoir. Les 3 niveaux d’abstraction du Cloud Computing que sont SaaS (Software As A Service), Paas (Platform As A Service) et IaaS (Infrastructure As A Service) apportent chacun leurs spécificités en termes de monétisation et d’opportunités.