Un développeur aguerri applique quotidiennement beaucoup de ces principes, souvent par automatisme et expérience, mais éprouve généralement une grande difficulté à les énoncer clairement, à les recenser de manière exhaustive et a fortiori à les partager avec ses pairs. Or c’est sur le partage, la transmission et l’application de ces bonnes pratiques que repose la progression d’une équipe et l’amélioration continue de la qualité du logiciel développé.
Forts de ce constat, les consultants Xebia se sont posés comme défi d’extraire, trier et consolider ces bonnes pratiques, à partir de leurs expériences de terrain, dans le but de pouvoir les restituer sous forme synthétique puis de les partager entre eux et avec la communauté.

Le fruit de 6 mois de ce travail de consolidation, que Xebia est fière de vous dévoiler aujourd’hui, se présente sous la forme d’un ensemble de « flash cards », baptisées Xebia Essentials.

Concrètement, chacune de ces flash cards isole une bonne pratique ou un principe, énoncé de manière synthétique et facilement mémorisable sur son recto, détaillée au verso, et identifiée par un code couleur qui détermine le domaine auquel elle s’applique (code, architecture & design, test, process, état d’esprit …). Cerise sur le gâteau, chaque carte affiche un code-barres 2D qui permet, à partir d’un simple scan avec son téléphone mobile de retrouver une page web détaillée qui apporte des compléments sur le contenu de la carte elle-même (voir la vidéo).

Nous croyons que cette présentation sous forme de cartes, par son caractère pratique et ludique, est un formidable moyen de partager des pratiques de développement essentielles et de les mettre en application sur les projets.

Ces flash cards, initialement destinées à nos consultants et aux équipes projet chez nos clients, seront finalement mise à disposition de la communauté prochainement, à travers notre site.

Le rendez-vous annuel incontournable de la communauté Java européenne est arrivé ! 3000 participants inscrits et une centaine de speakers pour 5 jours de conférences à Anvers en Belgique : Devoxx s’annonce cette année comme grandiose après une édition 2009 en léger retrait en raison du contexte économique. Xebia sera présent à cet évènement pour vous retransmettre l’information qui y sera véhiculée.

Au-delà des connaissances techniques qui y circulent, des échanges et des rencontres qui s’y font, Devoxx est aussi un formidable baromètre de l’éco-système Java actuel. Il est donc intéressant d’observer les sujets les plus en vogue cette année :

• NoSQL : il s’agit clairement du sujet majeur dont il sera question cette année. Très peu représenté l’année dernière (2 sessions seulement), on compte pour cette édition pas moins d’une douzaine de sessions dédiées à ce thème. Il sera ainsi question de Cassandra, HBase, Hadoop, Hive, Pig, MongoDB ou encore Voldemort.
• Java EE 6 et JPA 2 : déjà très représenté l’année dernière, ce sujet sera encore d’actualité cette année à Devoxx, ces APIs n’ayant pas encore été digérées par les entreprises.
• JDK 7 : le sujet devient récurrent, mais la récente actualité le concernant le rend incontournable dans une conférence Java de cette envergure. Cette semaine à Anvers sera l’occasion de faire le point sur les dernières avancées et orientations avec l’équipe responsable du JDK chez Oracle.

Outres ces sujets majeurs, on retrouve de nouveaux venus tels que DevOps, ce mouvement prônant le rapprochement des équipes de développement et d’exploitation, ainsi que des sujets maintenant plus classiques qui présenteront leurs dernières évolutions tels que Grails, Android, Scala, ou HTML5.

Comme l’année dernière, vous retrouverez jour après jour sur ce blog et celui de Duchess France nos retours des principales sessions qui se tiendront à Anvers cette semaine. Retrouvez également l’information en live sur nos comptes Twitter : dijouxellene, mfiguiere, morlhon et rmat0n.

Pour la rentrée, Xebia Training a le plaisir de vous proposer les formations Java EE suivantes :

• Formation Java performance tuning
  • Animée par Kirk Pepperdine.
  • Les 13, 14, 15 et 16 septembre 2010 à Paris.
  • Les 22, 23, 24 et 25 novembre 2010 à Sophia Antipolis.
• Formation Architectures d’aujourd’hui avec Java EE 6
  • Animée par Antonio Goncalves.
  • Les 20, 21 et 22 septembre 2010 à Paris.
• Formation Applications Java prêtes pour la production
  • Animée par Cyrille Le Clerc.
  • Les 23 et 24 septembre 2010 à Paris.
• Formation troubleshooting en Java
  • Animée par Guillaume Bodet.
  • Les 29 et 30 septembre 2010 à Paris.

Si vous souhaitez avoir de plus amples informations sur ces formations, n’hésitez pas à nous contacter :

• Par téléphone au 06.09.69.05.49.
• Par mail : info@xebia-training.fr.
• Via le site de Xebia Training.

Cette formation approfondie de 4 jours vous permettra d’obtenir les compétences nécessaires pour optimiser la performance de vos applications Java. Vous aborderez pendant cette formation tous les aspects de la performance : l’outillage nécessaire, les méthodologies à appliquer, les concepts d’architecture sous jacents à la performance, les meilleures pratiques, le benchmarking et la gestion de mémoire.

A l’issue de cette formation, vous serez en mesure :

• D’identifier rapidement et régler les problèmes de performance de vos applications.
• D’identifier et résoudre des problèmes de fuite mémoire en quelques heures.
• D’isoler des problèmes classiques et d’éviter de s’engager dans des plans d’actions couteux et inefficaces.
• D’identifier des problèmes de performance avant qu’ils ne deviennent critiques pour les applications.

Les stagiaires bénéficieront des Tips de Kirk Pepperdine, référence reconnue dans le monde de l’optimisation de performance objet.
Kirk Pepperdine dispose de 15 ans d’expérience dans les technologies OO et l’optimisation de la performance. Figure emblématique du monde Java et élu « Champion JAVA » en 2005, Kirk est reconnu comme le référent de l’optimisation de performance Java.
Vous pouvez consulter le programme complet de cette formation en consultant notre site : http://training.xebia.fr/formation-java-performance-tuning-kirk-pepperdine/.

Agilité

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

SOA

• RabbitMQ racheté par SpringSource

Le coin de la technique

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

Agilité

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

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

• Règles métiers
• Worfklows
• Technique

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

La gestion des risques dans un projet agile

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

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

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

SOA

RabbitMQ racheté par SpringSource

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

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

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

Le coin de la technique

Billy Newport et la programmation parallèle

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

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

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

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

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

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

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

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

Performance jQuery avec $.delegate()

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

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

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

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

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

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

Faille de sécurité dans Oracle Java

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

Actualité éditeurs / SSII

• Vague de départs chez Sun/Oracle
• Avec son OS4, Apple bride les développeurs
• AWS s’enrichie d’un nouveau service de notification

Agilité

• Maîtriser votre dette technique

Actualité éditeurs / SSII

Vague de départs chez Sun/Oracle

Le rachat de Sun par Oracle constitue un changement de politique et d’identité majeur pour l’entreprise qui avait créé Java. On pouvait donc s’attendre à un certain nombre de départs de quelques personnes clé de Sun. Ces dernières semaines ont vu notamment les démissions de :

• James Gosling : le créateur du langage Java. Après avoir passé 20 ans chez Sun, James Gosling quitte Sun/Oracle. Son départ a logiquement fait beaucoup de bruit au sein de la communauté Java.
• Simon Phipps : le directeur de la stratégie Open Source de Sun. Il avait rejoint Sun 10 ans auparavant et était devenu Chief Open Source Officer il y a 5 ans.
• Tim Bray : le co-rédacteur de la spécification XML et directeur des technologies Web chez Sun. Il rejoint Google dès à présent.

Ces départs retentissants, accompagnés de disparitions de produits et de changements de politiques, marquent bien la fin d’une époque…

Avec son OS4, Apple bride les développeurs

Apple a dévoilé la semaine dernière son nouvel OS, OS4, système d’exploitation destiné aux derniers iPhones, iPods et autres iPads. Nous ne reviendrons pas sur les nombreuses nouveautés techniques mais sur un simple paragraphe de la « iPhone Developer License Agreement » dont les termes ont depuis animé la blogosphère. L’ancienne version de ce document spécifiait que les développeurs devaient utiliser les API publiques de la manière prescrite par Apple et ne devaient pas utiliser d’appels à des API non publiées ou privées. Cette licence est maintenant beaucoup plus restrictive: elle spécifie explicitement que les applications devront être écrites en C, C++ ou Objective-C (voir Javascript à travers le Webkit d’origine). Tout programme destiné à être exécuté après une traduction ou se reposant sur une couche type machine virtuelle est interdit. La conséquence directe est que Flash, Java ou .Net se voient interdire l’accès à l’immense marché des applications iPhone.

La première question venant à l’esprit est « pourquoi ? ». Pourquoi se limiter alors que ces types de langages et technologies ont le vent en poupe ces temps ci et sont un fort moteur d’innovation. Une réponse apportée par Steve Jobs est que l’utilisation par les développeurs de couches intermédiaires produit des sous-applications non standard qui grèvent l’évolution de la plateforme.

En fait, selon John Gruber, Apple cherche à éviter à tout prix qu’une autre compagnie n’établisse ses propres outils comme un standard surtout si ceux ci permettent d’écrire un seul code et de l’exécuter indifféremment sur iPhone, Android ou Windows Mobile. Apple veut imposer sa plateforme de développement, que celle-ci devienne un standard, un passage obligé. Plus les développeurs seront familiers avec elle, plus ils développeront pour elle. De la même manière que Windows s’est imposé dans les années 90. Eviter le « write once, run anywhere », ca ne vous rappelle rien ?! Surtout que les applications iPhone représentent déjà la plus grosse part du gâteau des applications mobiles.

Les conséquences sont importantes. En premier lieu, l’avenir de Flash sur les machines de la Pomme semble compromis et de nombreux développeurs voient leurs efforts réduits à (presque) néant. Nous n’avons pas fini d’entendre parler de cette affaire et de débattre pour savoir si Apple préserve simplement la qualité de sa plateforme ou bien joue trop restrictif, ce qui, pour certains, n’est plus acceptable.

AWS s’enrichie d’un nouveau service de notification

Amazon enrichie son offre Cloud Computing AWS (Amazon Web Services) d’un nouveau service de notification. Baptisé Simple Notification Service (SNS), il permet à des systèmes externes de souscrire à un topic pour recevoir des notifications par SMTP, HTTP(S) ou Amazon SQS (Simple Queue Service). SNS vient donc en complément du service SQS existant puisque ce dernier était un broker de messages qui offrait une connectivité HTTP. SNS, quant à lui, se définit plutôt comme un publish-subscribe lié à une capacité d’intégration.

Ce type de traitement peut être effectué très simplement au sein des applications Java, par programmation. Tout l’intérêt de ce nouveau service est donc le même que pour la majorité des autres services de Cloud Computing offerts par Amazon : il s’agit d’un service clé en main pour lequel aucune tâche de déploiement, d’exploitation, et de planification de charge n’est requise. Le choix d’exploiter ce service peut alors être fait sur la base d’une projection de coût basé sur l’habituelle tarification linéaire d’AWS, tandis qu’en informatique traditionnelle ce choix aurait été basé sur les contraintes de mise en œuvre d’un middleware supplémentaire.

L’offre de Cloud Computing d’Amazon s’étoffe mois après mois avec l’arrivée de services supplémentaires, conférant ainsi à Amazon une position très confortable sur ce marché. Le Cloud Computing est un marché émergeant qui se cherche encore des standards. AWS, fort de son innovation régulière et de sa popularité pourrait s’octroyer une position de standard de facto telle celle gagnée par Spring. Le fait que le projet Eucalyptus – qui vise a offrir une solution de private cloud – soit basé sur les contrats des services d’AWS donne d’ailleurs un crédit supplémentaire à cette hypothèse.

Agilité

Maîtriser votre dette technique

La dette technique est généralement introduite à cause de raccourcis pris lors d’un développement pour tenter de gagner du temps, en lieu et place d’une conception propre, simple et évolutive. L’évolution et la maintenance de ce code se feront au prix d’efforts supplémentaires que l’on peut assimiler à des intérêts financiers.

Dans Monetizing the technical debt, Vikas Hazarati nous explique que la dette technique doit être maîtrisée faute de quoi, l’application risque de péricliter. En effet, au delà d’une certaine dette technique, la modification du code risque d’entraîner des comportements hasardeux (régressions) dans l’application. La diminution de la dette (capital) se fera en refactorant le code avant d’atteindre un niveau de dette trop élevé. L’article nous explique les bénéfices de monétiser notre dette technique et donne quelques éléments pour déterminer le niveau d’endettement (notamment via l’emploi d’un plugin Sonar).

La détermination d’un montant de dette technique pertinent semble difficile à mettre en œuvre et la détermination d’un seuil de maîtrise semble aussi particulièrement subjective. Le ressenti de l’équipe de développement sur le niveau (qualitatif) de la dette technique semble plus pertinent.

Comme l’explique Ward Cunningham, l’introduction d’une petite dette technique peut accélérer le développement à condition que celle-ci soit remboursée rapidement après sa souscription. Une bonne pratique pour vous aider à maîtriser votre dette technique est d’identifier le code à améliorer au moment où vous l’introduisez et de planifier les corrections nécessaires lors des itérations suivantes.

Cette formation approfondie de 4 jours vous permettra d’obtenir les compétences nécessaires pour optimiser la performance de vos applications Java. Vous aborderez pendant cette formation tous les aspects de la performance : l’outillage nécessaire, les méthodologies à appliquer, les concepts d’architecture sous jacents à la performance, les meilleures pratiques, le benchmarking et la gestion de mémoire.

A l’issue de cette formation, vous serez en mesure :

• D’identifier rapidement et régler les problèmes de performance de vos applications.
• D’identifier et résoudre des problèmes de fuite mémoire en quelques heures.
• D’isoler des problèmes classiques et d’éviter de s’engager dans des plans d’actions couteux et inefficaces.
• D’identifier des problèmes de performance avant qu’ils ne deviennent critiques pour les applications.

Les stagiaires bénéficieront des Tips de Kirk Pepperdine, référence reconnue dans le monde de l’optimisation de performance objet.
Kirk Pepperdine dispose de 15 ans d’expérience dans les technologies OO et l’optimisation de la performance. Figure emblématique du monde Java et élu « Champion JAVA » en 2005, Kirk est reconnu comme le référent de l’optimisation de performance Java.
Vous pouvez consulter le programme complet de cette formation en consultant notre site : http://training.xebia.fr/category/filiere-java-jee/.

Cette soirée gratuite vous permettra d’appréhender les bonnes pratiques que se doivent de respecter les Directions Etudes et Développement pour rendre leurs applications Java/J2EE prêtes pour la production.

Elle se déroulera dans les locaux de Xebia : 156, boulevard Haussmann, 75008 Paris.
Les inscriptions peuvent se faire :

• Par mail : info@xebia-training.fr
• Par téléphone : 01.53.89.99.93
• En ligne sur le site de Xebia Training

Les technologies Java ont été massivement adoptées par les DSI pour la réalisation de leurs applications critiques. Porteuses de valeur et d’innovation, elles posent régulièrement problème au niveau des départements Exploitation/Production. Instabilité chronique, manque de capacité à monter en charge, difficultés de diagnostiques en cas de dysfonctionnement, déploiement chaotique sont autant de maux fréquemment rencontrés par les entreprises utilisatrices.

Les bonnes pratiques que se doivent de respecter les Directions Etudes et Développement pour rendre leurs applications Java/J2EE prêtes pour la production s’articulent autour des axes suivants :

Les bonnes pratiques pour le déploiement

Le déploiement est le baptême du feu d’une application en production. Comment réussir cette épreuve ?

• Complexité des composants à déployer : simplicité rime avec fiabilité,
• Les paramètres de configuration : éviter l’anarchie,
• Traçabilité et build automatisés : maitriser sa plateforme.

Les bonnes pratiques de robustesse

Dans l’adversité, une application robuste assure un service minimum plutôt que de s’arrêter :

• Dépendances inter-application : fail fast est il synonyme de fragilité ?
• Prévention des saturations et des effets “domino” : l’art du code défensif,
• Modes dégradés : les négociation technico-fonctionnelles.

Les bonnes pratiques pour la supervision et le monitoring

Une application en production doit exposer son état aux équipes d’exploitation et faciliter la détection de problèmes :

• Indicateurs de bon fonctionnement d’une application : ne pas se noyer dans les chiffre,
• Comment exposer les indicateurs de performances ? Fichier de log versus page JSP versus Java Management eXtension (JMX) ?

Les bonnes pratiques de log

Grande source d’incompréhension entre les départements études et exploitation, les logs d’application Java ? Quels formats de messages ?

• Codes erreurs chers aux exploitants, exceptions chainées et stacktraces familières aux développeurs, quel compromis ?
• Des logs de troubleshooting extrêmement verbeuses aux logs d’audit sécurité à conserver plus d’un an en passant par celles de perfs et celles de diagnostique, comment organiser les logs ?

Les bonnes pratiques organisationnelles

Avoir une application prête pour la production ne se limite pas à des bonnes pratiques techniques, la collaboration des départements études et exploitation est essentielle :

• Prendre en considération les réalités de production dans les développements : une amélioration continue,
• Les incidents : comment s’y préparer pour qu’ils ne se transforment pas en longues indisponibilité.

BONUS

Les bonnes pratiques de robustesse

• Les mécanismes de ré-essai

Agilité

• Quand Toyota se met au Lean

Le coin de la technique

• Ehcache 2.0 : un renouveau ?
• Scalaj Collections
• Sonar 2.0
• MySQL + Memcached vs Cassandra

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

• Kawa Camp Paris mardi : HTML 5, Android, NoSQL

Agilité

Quand Toyota se met au Lean

Tout le monde le sait, le Lean est l’adaptation du système de production de Toyota au développement logiciel. Et pourtant, qui est en train de s’inspirer du Lean pour améliorer son développement logiciel ? … Toyota!
Dans cet article, Henrik Kniberg (l’auteur de « Scrum and xp from the trenches ») nous raconte comment il a découvert avec stupeur que Toyota utilisait encore le « bon » vieux cycle en V pour le développement logiciel. Conscient des problèmes rencontrés il semblerait cependant que les équipes de développement de Toyota s’orientent vers les méthodes agiles. La boucle est ainsi bouclée!

Le coin de la technique

Ehcache 2.0 : un renouveau ?

Ehcache est une solution de cache Open Source qui est longtemps restée très basique : aucun mécanisme de réplication n’était proposé. Le projet se limitait alors une table de hachage enrichie d’une logique d’éviction et d’offload sur disque. La réplication du cache sur plusieurs nœuds par RMI est apparue tardivement, et fut suivie d’autres technologies de réplication telles que JGroups ou JMS. Plus récemment, l’acquisition du projet par Terracotta fut assez logiquement suivie de l’introduction d’une réplication par Terracotta en version 1.7.

Ces dernières années ont donc vu un enrichissement (ou une complexification) croissant d’Ehcache. Une nouvelle version 2.0 vient d’être annoncée par Terracotta et les nouveautés incluses créent une nouvelle fois la rupture avec les versions précédentes :

• Support de JTA : Ehcache se comporte maintenant comme une ressource transactionnelle XA. Ce support de JTA place ainsi EhCache face à JBoss Cache, maintenant renommé Infinispan, qui se démarquait jusqu’alors parmi les caches Open Source par ses capacités transactionnelles.
• Write-behind : Ehcache est maintenant capable d’écrire de manière asynchrone et planifiée dans la ressource dont il est la façade.

Les autres nouveautés concernent diverses améliorations liées à la configuration dynamique d’Ehcache ou à l’utilisation de Terracotta.

Il s’agit donc bien d’une version majeure pour Ehcache qui propose désormais de nombreuses fonctionnalités dédiées aux architectures distribuées. Le poids de la distribution s’en ressent puisqu’il est passé de 300 Ko pour la version 1.0 a 14 Mo pour la version 2.0 : une vraie rupture…

Scalaj Collections

Voici une petite librairie fort sympathique qui permet de convertir une collection Java vers une collection Scala et inversement (vu sur le Coderspiel).

La librairie enrichit certaines classes existantes comme List, Map et Set côté Scala ou ArrayList côté Java. Une fois l’objet créé et si besoin initialisé avec certaines données, il suffit d’appeler la méthode asJava ou asScala pour modifier le type l’objet. Il est aussi possible d’appeler la méthode foreach sur une liste Java. Les méthodes map, filter et flatMap sont en cours de développement. Quelques exemples :

List(1, 2, 3).asJava   // returns java.util.List1
Map(1 -> "a", 2 -> "b", 3 -> "c").asJava   // returns java.util.Map1
val list = new java.util.ArrayList1
list.add(1)
list.add(2)
list.asScala   // returns scala.Seq[Int]
list.foreach(print)   // prints "123"

Le projet est hébergé sur GitHub. Vous pouvez récupérer le jar à cette adresse ou par maven :

<dependency>
  <groupId>org.scalaj</groupId>
  <artifactId>scalaj-collection_${scala.version}</artifactId>
  <version>1.0.Beta1</version>
</dependency>

Sonar 2.0

Dans cette première release de 2010, l’équipe Sonar élargit le champs d’analyse de leur outil en y ajoutant un septième axe d’analyse de qualité logiciel. Pour rappel, les six premiers axes déjà supportés par Sonar sont:

• La couverture de code par les tests unitaires
• La distribution de la complexité (par classe et par méthode)
• La recherche de bugs potentiels (avec FindBugs)
• La détection des codes dupliqués
• L’insuffisance des commentaires
• Le respect des normes du langage

Le septième et dernier axe, propose d’évaluer la conception objet à l’aide:

• D’une matrice de dépendance des classes, équivalente à la DSM de IntelliJ Idea
• Des métriques de Chidamber & Kemerer (DIT, NOC, RFC, CA, CE, LCOM4)

Ces nouveaux outils vont nous permettre, d’une part, de détecter et résoudre les cycles de dépendances, et, d’autre part, de surveiller l’étendue des responsabilités de nos classes. L’équipe Sonar reste donc très active, elle prévoit d’ailleurs une nouvelle version pour le courant du mois de mai avec notamment la détection de code mort dans la roadmap.

• L’annonce sur le blog Sonar
• La release note
• La roadmap

MySQL + Memcached vs Cassandra

Après Twitter il y a un mois, c’est maintenant Digg qui vient d’abandonner sa solution de persistance basée sur MySQL et Memcached au profit de Cassandra. Les raisons invoquées pour l’abandon de leur précédente solution de persistance restent les mêmes :

• Complexité induite par le partitionnement de MySQL
• Manque de scalabilité de l’ensemble
• Maintenance délicate du cluster MySQL

Le choix de Cassandra parmi l’ensemble des base de données NoSQL disponibles était quant à lui dirigé par les qualités que l’on reconnait souvent à ce projet :

• Sa nature column-oriented apporte une persistance plus structurante qu’une simple solution clé-valeur
• Son architecture peer to peer ne présente pas de single point of failure assurant donc la haute disponibilité
• Le projet bénéficie d’une large communauté, gage de pérennité de l’investissement

Les difficultés à gérer de très larges volumes de données dans les bases de données relationnelles sont ainsi régulièrement mises en avant. Ainsi Philip Tellis publiait il y a quelques mois son retour d’expérience sur un projet nécessitant la persistance de quelques 40 millions d’enregistrements par jour dans une base de données MySQL partitionnée : on se rend rapidement compte des nombreux efforts nécessaires à la mise en œuvre d’une telle architecture en comparaison à la solution clé en main proposée par Cassandra.

Face à cette opposition, il est intéressant de se souvenir que Facebook, le créateur de Cassandra, est également le plus gros utilisateur de Memcached au monde. Il y est utilisé conjointement à MySQL montrant ainsi que l’un des contributeurs majeurs du mouvement NoSQL a su tirer le meilleur de ces deux mondes.

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

Kawa Camp Paris mardi : HTML 5, Android, NoSQL

Le Kawa Camp Paris 1 se déroulera demain mardi 23 Mars à partir de 19h00 au Quigley’s Point. Les thèmes qui suscitent le plus d’intérêts sont cette fois HTML 5, Android et NoSQL. Déjà 32 participants confirmés et 11 autres qui tenteront de venir.

Les Barcamp Java sont un très bon moment pour discuter de technique comme de carrière et d’entretenir son réseau.

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…

A l’origine, JDuchess est un JUG féminin provenant des Pays Bas. Après avoir rencontré Clara Ko (JUG Leader de JDuchess), elles nous a proposé de représenter son JUG en France. Ce que nous souhaiterions pour JDuchess c’est de monter une communauté où les femmes faisant du Java peuvent se rencontrer et partager leurs expériences, leurs points de vue. Nous voudrions pouvoir monter un réseau social pour rendre les femmes plus visibles dans ce domaine, les inciter à participer à des événements comme le Paris JUG, et d’autres événements techniques ou conférences. Et pourquoi pas y faire une présentation.

Vous pouvez rester en contact avec les Duchess via Twitter , notre Google Group et LinkedIn.

Pour celles qui assisteront à la soirée Emmanuel Bernard du Paris JUG le 9 Mars vous pourrez retrouver les Duchess pour l’Avant JUG qui se passera au Vavin Café (18, Rue Vavin, 75006 Paris) à partir de 18h30.

Lorsque vous serez inscrites au JUG, contactez ellene(dot)dijoux(at)jduchess(dot)org qui vous accueillera Mardi prochain.

J’y serai et je serai heureuse de vous y rencontrer.

Actualité éditeurs / SSII

• Sonatype ouvre son dépôt maven pour java.net
• La fusion JRockIt / Hotspot pas pour demain

Agilité

• Utilisez-vous des métriques intelligentes sur vos projets ?

Le coin de la technique

• Jigsaw, les modules du pauvre ?
• Comment les closures seront implémentées dans OpenJDK 7 ?
• L’actualité des bases de données NoSQL toujours aussi riche
• Astuce de la semaine, récupérez la liste complète des options de votre JVM

Actualité éditeurs / SSII

Sonatype ouvre son dépôt maven pour java.net

L’idée est venue d’une quantité toujours grandissante de plaintes sur les dépôts Maven fournis par java.net. A l’heure de la fusion annoncée entre Kenai et java.net, Kenai n’a aucune solution pour gérer les dépôts et java.net fait mauvaise presse sur ce point. Il n’aura pas fallu longtemps à Sonatype pour saisir l’opportunité de mettre en avant sa solution Nexus. L’éditeur propose donc à tous les projets java.net de migrer vers leur instance Nexus OSS, allant même jusqu’à organiser le 5 mars une grande journée migration, avec la mise à disposition pour tous des services de conseil et d’ingénierie interne. Outre la performance et la stabilité du dépôt Maven maintenu par Sonatype, Nexus génère des fichiers d’index utilisés par nos IDE pour rechercher les dépendances de nos POM.

• La nouvelle sur DZone
• L’annonce sur le blog Sonatype

La fusion JRockIt / Hotspot pas pour demain

Nous en parlions il y a quelques semaines, Oracle envisage de ne proposer à l’avenir qu’une seule JVM, qui tirerait le meilleur des deux que la firme s’est offert (JRockit via BEA, et Hotpsot via Sun). Dans un récent webcast (via InfoQ), Mark Reinhold s’est exprimé sur le sujet. Cette fusion n’est pas pour tout de suite : trop de clients utilisent les fonctionnalités spécifiques à l’une ou l’autre des JVMs en production, et il serait risqué de les forcer à migrer vers une version fusionnée bancale. Ce dernier se dit jaloux de certaines fonctionnalités de JRockIt et donc particulièrement excité d’avoir l’occasion de l’étudier en profondeur. Cependant, ce qui transparait dans son discours (et peut être via nos diverses expérience), c’est que la JVM de Sun est en avance sur celle de BEA. La prochaine version fusionnée devrait donc tendre plus vers Hotspot que vers JRockit. En résumé rapide, cette future VM Oracle devrait avoir les fonctionnalités runtime de Hotspot, et le garbage collector et la robustesse de JRockit. Finalement, à part l’ébauche d’une timeline, nous ne sommes pas beaucoup plus avancés.
Coté nouveautés du JDK 7, Mark Reinhold se dit aussi particulièrement excité par l’intégration du projet Coin (au contraire de la grande majorité des consultants Xebia, qui trouvent que la plupart de ces évolutions syntaxiques confinent au gadget).
Il reparle aussi des closures, principalement sous l’angle des raisons de la polémique, mais personne ne semble réellement savoir comment elles seront implémentées dans le JDK 7 (voir ci-dessous pour l’avancement du projet Lambda).
Dernière annonce, pour ceux qui comme lui sont impatients de voir une JVM enfin modulaire (aka Jigsaw, prévu dans le JDK 7, voir ci-dessous), ils devraient en avoir un aperçu mi-mars, avec la release 88 de l’OpenJDK.

Certains noteront avec un certain amusement (ou une certaine nostalgie) quelques ratés : « We, at Sun… »

Agilité

Utilisez-vous des métriques intelligentes sur vos projets ?

Mike Griffiths, agiliste expérimenté et bloggeur actif, nous présente sa réflexion sur l’utilisation des métriques dans un projet.
Au préalable, Mike nous prévient que :

• Toutes les observations ne sont pas utiles et d’une grande aide pour analyser et comprendre un phénomène. Elles peuvent même amener à de mauvaises conclusions.
• Certaines mesures très utiles ne sont pas facilement observables.

Une autre caractéristique à ne pas négliger est l’effet Hawthorne : L’observateur influence la mesure. On retrouve d’ailleurs ce phénomène en physique quantique. Mike nous explique alors que le fait d’observer et donc d’influencer la mesure, à un effet positif.

Pour lui, une métrique « intelligente » doit avoir les caractéristiques suivantes :

• Simple et auto-générée.
• Influence de manière significative ce que l’on cherche à observer.
• Permet de prendre des décisions et décrire des tendances pour le futur.

Mike nous conseille de donner plus d’attention aux métriques permettant d’observer des tendances futures et d’anticiper.

On peut ainsi opposer aux vieilles métriques : nombres de lignes codées, points de fonctions réalisés ou nombres d’heures travaillées ; des métriques plus « intelligentes » : confiance des sponsors, satisfaction client, nombre de fonctionnalités réalisées, ou encore temps passé à la correction de bugs.

Dans la dernière partie de l’article sont présentés un certain nombre de métriques plus ou moins connues des agilistes, comme : le taskboard de Scrum ou Kanban. L’utilisation de métriques intelligentes est indispensable pour mener à bien un projet. Elles permettent d’observer des tendances, d’identifier et d’anticiper des problèmes; et ainsi, de prendre les bonnes décisions.

Le coin de la technique

Jigsaw, les modules du pauvre ?

Adam Bien est l’un des Java champions les plus visibles et les plus lus d’internet. Il a publié cette semaine un petit article au titre accrocheur : « Jigsaw / JDK 1.7 sera une solution qui permettra de répondre à 80% des besoins de modularité ». Vous avez probablement suivi les différents épisodes et rebondissements de la modularité dans le JDK 7. C’est peut-être l’occasion de faire le point sur ce que propose Jigsaw.

Le projet Jigsaw proposera une implémentation permettant la mise en place d’un système de modules bas niveau pour vos projets. Il sera également utilisé en interne pour découper le JDK Oracle/Sun lui-même.

• Jigsaw vous permettra de choisir tout ou partie du JDK tout en restant 100% rétro-compatible, d’améliorer les temps de démarrage de la JVM et son utilisation mémoire.
• Jigsaw  pourra être utilisé directement sur vos projets si vous disposez d’une JVM reposant sur ce système. Jigsaw sera chargé avant rt.jar et sera donc disponible à quiconque désirant l’utiliser. Ce projet étant open source, il sera également possible de réutiliser celui-ci dans d’autres contextes.
• Jigsaw vous permettra de rendre vos applications modulaires progressivement. Nul besoin de migrer vos applications dans leur ensemble pour tirer parti des bénéfices de la modularité. Un même package peut être éclaté dans plusieurs modules.
• Contrairement à OSGi, Jigsaw ne vous permet pas le rechargement de modules à chaud. Vos modules sont chargés statiquement au démarrage de vos applications.
• Tous vos modules sont chargés dans un même classloader, cela permet de simplifier grandement son utilisation. Du même coup, il vous sera probablement possible de ‘tricher’ en chargeant, au runtime, des classes d’un module sans que vous en ayez réellement le droit.

Si vous confondiez modularité du JDK avec OSGi, cette liste vous a certainement ouvert les yeux : Jigsaw vous propose une solution beaucoup moins fournie qu’OSGi.

Dans les faits, ce projet a été créé, avant tout, pour casser notre bon vieux JDK monolithique. Bon nombre de polémiques ont été faites sur ce choix. Pourquoi se contenter d’aborder 80% des problématiques de la modularisation avec une nouvelle solution alors qu’OSGi en aborderait 90% ? La simplicité et la souplesse d’utilisation ont été préférées à une solution décrite comme lourde (nécessitant beaucoup de glue), vieillissante (datant de 1998) et difficile à maîtriser. Ce choix a été sans conteste difficile à effectuer, il s’est ailleurs attiré les foudres des défenseurs d’OSGi, mais reste complètement défendable.

Comment les closures seront implémentées dans OpenJDK 7 ?

Fin 2009, le projet Lambda, dont le but est d’apporter les closures à la prochaine version de Java, apparaissait au sein d’OpenJDK. Le lancement du projet faisait suite aux rebondissements dans l’actualité du JDK 7 lors de la conférence Devoxx un mois auparavant. Une documentation montrant la syntaxe des closures avait accompagné la création du projet, plus tard, un draft d’une spécification plus formelle est apparue, mais quid de l’implémentation ?
Rémi Forax, contributeur au projet Lambda, a mis à disposition la présentation qu’il a faite au FOSDEM’10, dans laquelle il résume les discussions ayant eu lieu sur la mailing list du projet concernant les possibilités d’implémentation :

• Convertir les closures en classes anonymes. Cette solution présente l’inconvénient de produire beaucoup de classes et pose problème pour certaines constructions liées au closures.
• Convertir les closures en invocations dynamiques telles que le permettra la JSR-292 (Supporting Dynamically Typed Languages on the Java Platform). Cette solution ne produit pas de classes supplémentaires et bénéficie de bonnes performances puisque l’invocation dynamique présentera un temps d’exécution similaire aux invocations de méthode classiques.

Le reste de ses slides présente certaines des problématiques d’implémentations des closures liées à l’accès aux variables locales et aux champs de la classe hôte.

L’actualité des bases de données NoSQL toujours aussi riche

Depuis plusieurs mois maintenant le mouvement NoSQL s’est installé dans l’actualité. A Paris, le NoSQL User Group a attiré l’attention en réunissant une cinquantaine de personnes à chacune de ses 2 sessions jusqu’à présent.

D’un point de vue plus général, l’actualité des bases de données NoSQL est marquée par l’intérêt croissant qu’elles suscitent, et par leur évolution rapide grâce à l’effort soutenu de leurs développeurs. Ainsi on a pu noter récemment :

• Neo4j, une base de données orienté graphe, est maintenant disponible en version 1.0 finale. L’intérêt de la représentation en graphe est la possibilité de modéliser les données relatives aux réseaux sociaux, mais également tout type d’objets qui seraient liés entre eux de manière arbitraire. De plus, il est possible d’appliquer à ces données divers algorithmes de graphe classiques tels que la détermination du plus court chemin entre deux objets ou de l’objet central/majeur dans un nuage d’élément.
• Cassandra vient pour sa part d’être publié en version 0.5.1, et connait un succès tout particulier puisque Twitter vient d’annoncer qu’il l’utiliserait désormais comme solution de persistance en remplacement de MySQL. Par ailleurs le projet Lucandra a été créé récemment pour permettre d’utiliser Cassandra comme solution de persistance pour les indexes Lucene. Donné à la Fondation Apache par Facebook, Cassandra est pour rappel un hybride entre BigTable de Google et Dynamo d’Amazon.
• HBase profite d’une communauté très active et d’un intérêt important, renforcé par sa position de sous-projet du très populaire Hadoop. Sematext vient de publier un digest de l’actualité récente de ce projet. Celle-ci est principalement marquée par le développement d’une réplication multi datacenter, par l’arrivée d’un plugin DataNucleus pour HBase et par la disponibilité prochaine d’une solution de benchmark pour les cloud storages développée par Yahoo!.

Enfin, deux conférences entièrement dédiées au NoSQL sont à venir : NoSQL Live le 11 mars à Boston et, plus proche de nous, NoSQL Europe du 20 au 22 avril à Londres.

Astuce de la semaine, récupérez la liste complète des options de votre JVM

Cette astuce est complètement inutile, et donc également complètement indispensable. Cet article nous propose une petite commande permettant de récupérer la liste complète des options de votre JVM Hotspot à partir de sa library native Linux, la voici :

prompt$  strings $JAVA_HOME/jre/lib/amd64/server/libjvm.so | grep -B646 assert_null$ | grep -v '{' | grep -v '&' | grep -v '/' | grep -v '%' | grep -v assert_null

• Le catalogue numérique.
• Le catalogue PDF.

Xebia Training se positionne logiquement dans la continuité de Xebia, tant sur la qualité de son offre de formation technique que méthodologique (méthodes agiles), en proposant des formations haut de gamme animées uniquement par les référents de leur domaine.

Avec pour principe premier le refus de tout compromis sur la qualité du formateur et du contenu, Xebia Training fait systématiquement intervenir des acteurs de références dans leurs domaines respectifs.

Nos formations, savant équilibre entre théorie et travaux pratiques, sont destinées à un large public soucieux d’acquérir les meilleures pratiques de notre industrie.

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


Après une première passe qui nous a permis de calibrer les logs de manière un peu plus pertinente, il est temps, toujours sans l’aide du code source, de mettre les mains sous le capot de Tomcat (6.0.20).

Et pour cela, rien de mieux que de jeter de nouveau un œil à notre VisualVm.

Tant de threads pour un seul utilisateur.

Pour (re)commencer, penchons nous sur nos threads, juste après le démarrage du serveur (et donc avant la première connexion d’un utilisateur)

Lorsque l’on démarre un serveur Tomcat, un certain nombre de threads sont affectés à sa ‘tuyauterie’ interne (connecteurs RMI, JMX). Mais de là à avoir 165 threads, il y a certainement un souci quelque part !
Creusons un peu, et entrons dans le détail de ces threads en utilisant l’onglet Threads.

Hormis les threads ‘connecteurs’ de Tomcat, on voit apparaître 150 threads catalina-exec. Ces threads sont en charge des traitements des requêtes HTTP, via le HTTP-8080-acceptor. Nous avons donc, « à froid » 150 unités d’œuvre prêtes à traiter nos requêtes. Sachant que pour l’instant nos tests se limitent à un utilisateur, on sent que nous sommes très légèrement surarmés par rapport à nos besoins.
Tomcat ne devrait-il pas gérer automatiquement ces problématiques de montée ou descente en charge ?
Allons faire un petit tour dans la documentation, du côté du connecteur HTTP.

Si nous recherchons le paramètre minSpareThreads dans nos fichiers de configuration, nous le trouvons dans server.xml. Repassons le à une valeur plus réaliste de 10 threads, sachant que Tomcat montera automatiquement en charge si besoin.
Cela n’a pas d’impact visible sur les performances, mais au moins, les ThreadDumps deviennent lisibles (obfusquer les ThreadDumps était le but recherché de ce paramétrage).
Autre paramètre qui a interpellé les connaisseurs de Tomcat, la classe de l’Executor. org.apache.catalina.core.extended.PrestartingThreadExecutor n’est pas une classe courante. D’habitude, on utilise plutôt le StandardThreadExecutor. Une fois encore, on peut remercier nos buggers en chef : PrestartingThreadExecutor est une classe custom, qui démarre automatiquement tous les threads HTTP. De nouveau, l’impact sur les performances est négligeable pour un utilisateur, mais mieux vaut laisser Tomcat gérer toutes les problématiques de vie du serveur d’application. Sans vouloir leur faire offense, nos maîtres de cérémonie n’ont pas le niveau des équipes Apache rodées à l’exercice depuis de très nombreuses années
Dernier paramètre « malin » introduit au niveau de Tomcat, le paramètre -Xss. Celui-ci peut être découvert via l’overview de VisualVm. -Xmx, -Xms sont des paramètres classiques (nous reviendrons dessus) que grand nombre de développeurs connaissent. Mais -Xss ? Comme d’habitude, notre meilleure arme est la documentation de Sun.

-Xssn
    Set thread stack size.

Avons nous réellement besoin d’une taille de stack de 1024 Ko ? Difficile à dire, surtout a priori. Mais une fois encore, le plus simple est de faire confiance à Tomcat, quitte à devoir intervenir a posteriori. Nous ne sommes plus à un redémarrage près.

Maintenant que notre application est déployée et paramétrée de manière à peu près correcte, il est temps de rentrer « dans le dur » : mettre les mains dans le cambouis et explorer le code source.

Fuite mémoire, threads dump, ça explose de tous les côtés.

Dès que nous avons eu le code source entre les mains, plusieurs stratégies se sont dégagées :

• la première consiste à conserver un seul utilisateur dans les scripts JMeter et à le pousser à faire plus d’itérations,
• la seconde consiste à mettre plus d’utilisateurs JMeter en parallèle.

Toujours dans le but de rester très didactique, nous allons appliquer la première stratégie. Qui trouve rapidement sa limite :

Aux environs de la 70ème itération, la heap used tangente la heap max, le Garbage Collector est déclenché plusieurs dizaines de fois par seconde de manière totalement inefficace, et la JVM finit par faire un joli OutOfMemory. Les symptômes classiques de la fuite mémoire.

Comment faire pour la trouver ?
C’est à la fois simple et complexe : depuis la JVM 6, il est très facile, grâce à VisualVm de réaliser des « photographies » exhaustives de la mémoire de la JVM, les célèbres heap dumps. Malheureusement, ce n’est possible que sur les JVM locales.
Conformons nous donc à l’énoncé et n’installons pas notre Tomcat en local. La solution consiste à utiliser la commande jmap.
Commençons par générer un histogramme, que nous allons filtrer.
jmap -histo <pid_jvm> | grep org.spring
Notre premier candidat arrive en 16ème position dans l’histogramme :
16: 14000 560000 org.springframework.samples.petclinic.Vet
14 000 vétérinaires, voilà qui est surprenant… De là à dire que notre fuite tourne autour de cet objet métier, il n’y a qu’un pas. Malheureusement, à part en allant dans le code à la pioche, il va être difficile de colmater la fuite avec aussi peu d’information. De nouveau, jmap va nous rendre service, cette fois en générant un heap dump.
jmap -dump:format=b,file=/tmp/dump.hprof <pid_jvm>
Pour exploiter ce dump, nous avons choisi d’utiliser l’outil Eclipse Mat. Dès l’ouverture, Mat nous propose de rechercher les leak suspects
Et là, le diagnostic est assez évident.

Un type d’objet monopolise à lui seul 92 % de la mémoire. Il ne reste plus qu’à creuser dans le heap dump pour déceler l’allocation coupable.
Passons donc à la vue dominator tree. En dépliant progressivement la pile mémoire (en cliquant sur l’objet qui a la plus grande retained heap), on constate que la mémoire est occupée par de très nombreuses occurences de org.springframework.samples.petclinic.util.CacheFilter$CacheEntry

Maintenant que nous avons un coupable, il est temps, pour la première fois, d’ouvrir notre code source sous Eclipse. En faisant une simple recherche de classe sur notre coupable désigné, nous arrivons au code suivant :

HttpSession session = request.getSession();
Map<String, CacheEntry> cache = (Map<String, CacheEntry>) session.getAttribute("pages.cache");
if (cache == null){
    cache = new Hashtable<String, CacheEntry>();
    session.setAttribute("pages.cache", cache);
}
...
//Return cached content if available
String path = context.getRealPath("") + request.getRequestURI() + request.getQueryString();
CacheEntry cacheEntry = cache.get(path);
if (cacheEntry != null) {
    response.setContentType(cacheEntry.t);
} else {
    //Else, fetch it
    cacheEntry = new CacheEntry();
    CacheResponseWrapper wrapper = new CacheResponseWrapper(response);
    chain.doFilter(request, wrapper);
    byte[] buf = cacheEntry.buf;
    InputStream in = wrapper.getContentAsInputStream();
    OutputStream out = cacheEntry.c;
    int length;
    while((length = in.read(buf)) >= 0) {
        out.write(buf, 0, length);
    }
cacheEntry.t = wrapper.getContentType();
cache.put(path, cacheEntry);
}

Chaque page est donc mise en cache dans la session de l’utilisateur. Le timeout du cache étant fixé à l’infini, on voit de manière assez évidente que chaque fois que notre JMeter lance une campagne de test, il ouvre une nouvelle Session dans laquelle l’ensemble des pages vues est gardée en mémoire (avec un taux de réutilisation proche de zéro).
L’utilisation des ressources mémoire de notre JVM est ici particulièrement mauvaise.
Deux solutions sont envisageables :

• basculer le cache dans un scope application. Mais dans ce cas, attention, la taille de celui-ci peut vite exploser et l’utilisation d’un filtre qui cache systématiquement tout le contenu de la réponse peut rapidement échapper à tout contrôle.
• supprimer purement et simplement ce cache dont le taux de hit est ridiculement bas. C’est la solution que nous choisirons ici, car c’est la plus économique (une ligne à commenter dans le web.xml).

Cette correction ne devrait toutefois pas affecter notre nombre élevé de Vets trouvés via l’histogramme… Nous y reviendrons probablement.

Ne reste alors plus qu’à re-construire (via Maven) et relivrer l’application pour voir le résultat.

Cette fois, le gain de performance ne se mesure pas directement dans JMeter. Les temps de réponse de l’application sont sensiblement identiques à ce qu’ils étaient avant nos interventions.

En revanche, nous avons largement gagné en performance dans deux domaines :

• le plus immédiat, celui du ressenti utilisateur : plus la peine de rebooter notre serveur tous les 70 scenarii, et ça toutes les équipes d’exploitation vous le diront (sauf les mauvais élèves qui ont bêtement automatisé leurs redémarrages), c’est un énorme gain.
• celui plus égoïste, d’avoir des traces propres et peu nombreuses, donc beaucoup plus exploitables.

Pour finir, les points attribués :

• Fuite mémoire de CacheFilter en session
• Passage de la barre des 70 scenarii pour 1 utilisateur
• 2 points pour l’équipe qui a trouvé

Comme l’a très bien pressenti l’un de nos lecteurs (voir les commentaires sur l’article précédent), nous ne sommes pas encore au bout de nos surprises

Le premier XKE dans nos nouveaux locaux a donné lieu à de bien curieuses scènes : des bisounours ont hué des poubelles sous le regard moqueur de pokemons ! Et, non, les cartons de déménagement ne nous sont pas tombés sur la tête. Ce n’était là que quelques uns des noms choisis par des équipes de 3 à 4 consultants, qui se sont mesurés dans un concours de tuning de performance, sur une application Java EE standard, buggée (volontairement, pour une fois) par les maîtres de cérémonie, Guillaume Bodet et Cyrille Le Clerc. Tous les participants se sont vus remettre une VM, contenant un Tomcat, une application (PetClinic de Spring, revue et « corrigée ») et des scripts de performance JMeter. Le code source n’a, dans un premier temps, pas été fourni.

Pour tous, un seul but : faire diminuer les temps de réponses de l’application.

Les règles étaient les suivantes :

• Un bug n’est considéré comme trouvé que lorsqu’il a été identifié, qu’un correctif a été proposé et que la preuve est faite que ce correctif permet d’améliorer significativement les temps de réponse.
• Il existe trois niveaux de difficulté, allant du bug évident à l’anomalie la plus fourbe.
• Le choix des outils est libre.

A vos marques… Prêts ? Débuggez !

Préambule

L’un des buts de ce Xke était d’être très didactique, dans les méthodes de recherche et dans l’utilisation des outils. Les bombes placées dans le code permettaient de réaliser une progression linéaire (dans la difficulté comme dans les gains attendus). Cette progression est retranscrite dans cet article et ceux qui vont suivre.

Cependant, pour différentes raisons que nous aurons l’occasion d’expliquer, l’ordre des analyses, et donc de découvertes des bugs, n’est pas celui qu’aurait choisi un champion de la performance, j’ai nommé Kirk Pepperdine. Nous lui avons soumis notre application, et nous vous exposerons sa méthode d’analyse et les raisons qui la motivent dans le dernier article de la série.

Premier contact avec l’application…

Ouverture du navigateur, entrée de l’url, et, pas de surprise, l’application PetClinic s’ouvre.

Premier lancement de JMeter, et première constatation : avec un seul utilisateur, l’application met en moyenne plus de 2 secondes à répondre. Inacceptable pour la plupart des sites web (surtout avec un seul utilisateur actif).

… et premiers réglages

A première vue, la machine ne semble pas à genoux, on peut donc incriminer directement l’application.
Nous allons donc chercher à savoir ce qu’elle fait. Un réflexe classique, qu’un certain nombre d’entre nous a eu, est d’aller ouvrir les logs. Catalina.out est vide, on n’a pas de répertoire de logs applicatives évident, à priori le coupable classique, la configuration log4j, est à écarter. Et pourtant… Pour savoir ce que fait réellement notre application, il est possible de réaliser une série de thread dumps. Pour cela, deux possibilités :

• la vieille école, qui va dumper le contenu des threads à l’aide d’un kill -3 sur la jvm.
• l’école moderne, qui va utiliser JVisualVm (et ses plugins) pour réaliser la même opération à l’aide d’une belle interface.

Et là, demie surprise, notre thread actif est souvent surpris dans la méthode org.apache.log4j.spi.LoggingEvent.getLocationInformation. Nous aurions donc un logger actif. Nos soupçons initiaux se confirment, ne reste plus qu’à débusquer le coupable.
Nous n’avons pas (encore) le code source. Or, cette bombe plombe tellement l’application qu’il n’est pas envisageable que nous ne puissions pas la résoudre de suite. On doit donc avoir un fichier de paramétrage de la log externalisé. Là encore, VisualVm va nous aider. Dans la fenêtre overview, les paramètres de démarrage de la VM sont affichés. Et l’on voit apparaitre une directive de configuration log4j, -Dlog4j.configuration.

Un petit grep dans le répertoire de lancement de Tomcat ($TOMCAT_HOME/bin), et nous voyons apparaître dans le setEnv.sh la ligne -Dlog4j.configuration=file:$CATALINA_HOME/conf/log.xml. Et si nous ouvrons ce fichier, le root Logger est bien en DEBUG. Mais aucune directive spécifique pour logger ailleurs que dans la console. Tout devrait donc aller dans catalina.out. Ca sent la redirection ‘sauvage’. Continuons à parcourir les fichiers de lancement. Un petit tour dans catalina.sh, et surprise, une belle redirection Unix "$CATALINA_BASE"/logs/catalina.out 1> /var/log/catalina/tomcat.log &
Et en ouvrant ce fichier, on comprend mieux le temps perdu : des milliers de lignes de debug !

Celles ci ont d’ailleurs une particularité sympathique : à chaque ligne de debug, le numero de ligne de la classa Java est indiqué.
C’est pratique ! Pourquoi ne met on pas systématiquement en place cette configuration sur nos projets ?
Un petit tour dans la documentation Log4J nous apprend :

Log4J nous prévient, ces méthodes sont sous performantes. Si l’on creuse un peu dans le source, on trouve la classe affichant les pattern %M et %L, org.apache.log4j.spi.LocationInfo, qui contient le constructeur suivant :

public LocationInfo(Throwable t, String fqnOfCallingClass) {
if(t == null || fqnOfCallingClass == null)
return;
String s;
// Protect against multiple access to sw.
synchronized(sw) {
t.printStackTrace(pw);
s = sw.toString();
sw.getBuffer().setLength(0);
}
[...]

Autrement dit, pour chaque ligne de log, Log4J génère une stackTrace pour pouvoir récupérer le numéro de la ligne et le nom de la méthode. Pas vraiment performant.
Modifions donc le pattern et observons le résultat.

• Suppression de %M:%L dans le pattern du Logger
• Temps moyen de 2,3 s à 2,0 s pour 1 utilisateur
• 2 points pour l’équipe qui a trouvé

Toujours concernant ce fichier de log, nous voyons apparaître une ligne ne respectant pas le PatternLayout de Log4J, préfixée par Hibernate, qui trace une requête SQL. Gardons cette ligne en mémoire, nous y repenserons quand nous aurons le code source.

Deuxième amélioration immédiate envisageable, une application, qui plus est en production, ne devrait pas avoir besoin d’un niveau de log aussi fin. Passons le donc à ERROR.

• Logger de DEBUG à ERROR
• Temps moyen de 2,0 s à 1,75 s pour 1 utilisateur
• 1 point pour l’équipe qui a trouvé

Nous avons fait un sort au logger. Mais nous n’en avons pas encore fini avec la configuration out-of-the-box de cette application.

Source

Image libre de droits

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 !

Pour ceux qui ne le connaissent pas, Kirk Pepperdine dispose de plus de 15 ans d’expérience dans les technologies orientées objets et l’optimisation de la performance. Figure emblématique du monde Java, il a été élu Java Champion en 2005. Kirk est reconnu comme le référent de l’optimisation de performance Java. Il est le DSI de Kodewerk Ltd et le principal contributeur de javaperformancetuning.com.

Le déroulement de cette session privée est très simple : deux heures de questions-réponses et de discussion informelle autour d’un verre avec l’un des experts mondiaux de la performance java.

Vous pouvez désormais vous inscrire sans poser de question à Kirk. Le nombre de places restant limité, les règles sont désormais très simples : premiers arrivés, premiers servis.

Pour ceux qui ne le connaissent pas, Kirk Pepperdine dispose de plus de 15 ans d’expérience dans les technologies orientées objets et l’optimisation de la performance. Figure emblématique du monde Java, il a été élu Java Champion en 2005. Kirk est reconnu comme le référent de l’optimisation de performance Java. Il est le DSI de Kodewerk Ltd et le principal contributeur de javaperformancetuning.com.

Le déroulement de cette session privée est très simple : deux heures de questions-réponses et de discussion informelle autour d’un verre avec l’un des experts mondiaux de la performance java.

Le nombre de places étant très limité (30 places), nous vous proposons de nous soumettre, via le formulaire d’inscription ci dessous une question que vous souhaiteriez poser à Kirk Pepperdine. La sélection des participants à cette rencontre se fera en fonction de l’intérêt des questions proposées.

SOA

• Spring Integration et Apache Camel : 2 ESB lightweight en action

Le coin de la technique

• Impala, la modularité pour Spring sans OSGi
• La définition de DataSources dans JEE 6
• Les google-collections sont finales !
• Spring Roo en 1.0.0 pour terminer l’année

SOA

Spring Integration et Apache Camel : 2 ESB lightweight en action

La mouvance SOA a amené un certain nombre de produits classifiés comme ESB (Enterprise Service Bus) dont le but est de répondre aux problématiques d’intégration courantes en entreprise. Dans un premier temps, ces produits prenaient la forme de middlewares très lourds dont la mise en œuvre devait être justifiée par des besoins importants. Il y a deux ans, nous assistions à l’avènement d’ESB qualifiés de lightweight car ils prenaient la forme de frameworks moins gourmands en ressources et plus simples à utiliser. Spring Integration et Apache Camel sont les deux principales options à envisager en matière d’ESB léger.

C’est justement de l’utilisation de chacun de ces deux frameworks que discute l’article que vient de publier Biju Kunjummen. Il y propose une problématique d’intégration qui consiste en l’exposition d’un service qui, lorsqu’il est invoqué, entraîne l’invocation multiple d’un même service de bas niveau via l’utilisation d’un pattern splitter sur la requête et d’un pattern aggregator sur la réponse. Les deux frameworks offrent nativement ce type d’EIP (Enterprise Intergration Pattern).

Aucun favori ne se démarque clairement dans la comparaison entre ces deux implémentations : Spring Integration vient s’intégrer naturellement à l’Application Context de Spring en reprenant le même type de structure de définition XML, tandis qu’Apache Camel, bien qu’offrant également la possibilité d’une configuration XML, sera surtout apprécié pour son DSL Java permettant la définition des routes d’intégration.

Le lecteur intéressé par ces deux frameworks pourra se tourner, au-delà des documentations respectives, vers les deux livres en préparation chez l’éditeur Manning, Spring Integration in Action et Camel in Action, prévus pour l’été prochain.

Le coin de la technique

Impala, la modularité pour Spring sans OSGi

La modularité est un sujet porteur en ce moment, tant du côté du JDK avec Jigsaw, que du côté Java Entreprise avec OSGi dont le principal acteur actuellement est sans conteste SpringSource avec Spring Dynamic Modules et son serveur d’application associé Spring dm Server.

Phil Zoio a été interviewé il y a peu pour présenter le projet Open Source qu’il a fondé : Impala. Il s’agit d’une vision différente de la modularité pour applications d’entreprise. Ainsi, Impala repose sur Spring, tout comme Spring Dynamic Modules, mais contrairement à ce dernier, il n’utilise pas OSGi et adopte une stratégie radicalement différente : il constitue lui-même des modules encapsulant chacun un application context qui déclare un certain nombre de beans. La solution de modularité ainsi produite offre tout comme OSGi un fonctionnement dynamique permettant le chargement à chaud de nouveaux modules.

Dans un climat où beaucoup s’interrogent sur la potentielle lourdeur d’OSGi, ce type d’initiative proposant une solution alternative plus simple face au standard prend tout son sens et n’est pas sans rappeler l’offensive de Spring Framework lui-même, il y a quelques années, face au contesté standard EJB.

La définition de DataSources dans Java EE 6

Matt Corey poste cette semaine un article mettant en avant une facilité rarement (jamais ?) évoquée de Java EE 6 : la configuration des sources de données par annotation. En effet, si la nouvelle spécification de Sun est largement couverte depuis des mois, y compris sur notre blog, il est en général question des nouveautés qui retiennent le plus l’attention telles que les beans singletons d’EJB 3.1, l’API query builder de JPA 2.0 ou encore ses nouveaux modèles de composants.

En fait il s’agit d’une standardisation de la technique de configuration des sources de données dans les serveurs d’application Java EE. Cette définition était en effet jusqu’alors un détail d’implémentation des serveurs et n’était donc pas portable. Cette configuration peut donc maintenant se faire par l’annotation @DataSourceDefinition ce qui évite ainsi l’utilisation de XML et va donc dans le sens de la logique initiée depuis Java EE 5. L’exemple suivant permet de mieux se rendre compte de son utilisation :

@DataSourceDefinition (
className="org.apache.derby.jdbc.ClientDataSource",
name="java:global/jdbc/AppDB",
serverName="localhost",
portNumber=1527,
user="user",
password="password",
databaseName="dev-db"
)
public class Config {
...
}

Si tout le monde n’appréciera pas forcément d’avoir recours à une annotation pour ce type de configuration, les projets souhaitant distribuer des war ou ear portables qui se connectent à une base de données embarquée ou locale devraient en revanche y trouver leur compte.

Les google-collections sont finales !

Annoncée sur la users list du projet, l’API google-collections passe en version finale 1.0.
Pour ceux qui ne connaissent pas encore cette API de collections type-safe, rendez-vous sur cette page pour une introduction à la librairie.

La finalisation de Google Collections constitue un changement majeur dans l’environnement des développeurs Java. En effet Apache Commons Collections constituait jusqu’alors le principal complément à l’API de base du JDK. Or, la librairie de la fondation Apache est vieillissante et ne propose toujours pas les generics de Java 5. Google Collection se positionne donc ni plus ni moins que comme un remplaçant.

La FAQ répondra à bon nombre de questions que l’on peut se poser sur cette API notamment sur les raisons qui ont poussé Google à créer sa propre API plutôt que de contribuer à Commons Collections.

Enfin on notera que Google Collections sera intégré à Guava sous peu pour constituer la librairie d’extension du JDK de Google.

De par la nature de ces APIs, Google Collections et Guava peuvent également constituer un premier pas vers la programmation un peu plus orientée fonctionnelle. A ce sujet, il est aussi possible de regarder du côté de lambdaj, une API de parcours de collections sans boucle explicite. Et pour ceux qui souhaitent aller encore plus loin, rendez-vous sur functional.java ou  tournez vous vers la préparation des closures dans Java.

Spring Roo en 1.0.0 pour terminer l’année

Encore une release pour Spring pour clôturer en beauté l’année 2009. Bravo!
Spring Roo, 8 mois après sa première version alpha, vient de sortir en 1.0.0. Roo, en quelques mots, permet de développer des applications plus rapidement en générant et maintenant, tout au long des développements, une partie importante du code source (du POJO à la JSP).
Un effort a été mis sur la documentation qui a intégré un tutoriel et les commandes. La seule partie encore en travaux est le chapitre 3, celle qui concerne le fonctionnement interne de ROO. Cette partie permet entre autres d’avoir les bases pour développer des extensions.
En standard, Roo propose déjà des extensions, comme par exemple les fonctionnalités de sécurité, basées sur Spring Security et des flows avec Spring Webflow.

Spring Roo présente un formidable intérêt pédagogique, car il s’appuie systématiquement sur les toutes dernières versions des jars de Spring et d’Hibernate.
On peut par contre trouver peu commode son mécanisme interne qui se base sur la technologie AspectJ. Son principe est de générer les méthodes de classe en se basant sur des fichiers d’aspects. Jusqu’à présent, notre expérience avec Spring Roo a montré que cela ne fonctionnait pas de manière complètement transparente pour le développeur, même avec l’Eclipse de SpringSource (STS). Cette limitation pourra donc dissuader certaines équipes de partir sur un projet avec ROO tout au long des développements.

Voici sur Slideshare, les deux présentations mises en ligne par le leader du projet, Ben Alex:

• Introduction To Spring Roo 1.0.0
• Spring Roo 1.0.0 Technical Deep Dive

Actualité éditeurs / SSII

• Le meilleur de The Server Side

Le coin de la technique

• Spring Security seulement un alignement sur Spring 3.0 ?
• Tour d’horizon de JBoss Infinispan
• JGroups à l’heure du Cloud Computing

Actualité éditeurs / SSII

Le meilleur de The Server Side

Avec les fêtes vient le temps des rétrospectives. Et c’est TheServerSide qui ouvre le bal, avec son hit parade des neuf fils de discussion les plus vus en 2009. Sans surprise, on retrouve quelques stars de l’année, dont la popularité ne devrait pas faiblir en 2010 : JavaEE 6 et Glassfish 3, la persistance (JPA, les caches d’Hibernate, la démarcation transactionnelle avec Spring)… Mais aussi les buzz de l’année : Google App Engine, les langages next-gen… On trouve ensuite un grand article communautaire, sur ce que doit savoir un architecte applicatif.
Enfin, et nous devons bien avouer qu’à la vue des évènements passés, cela prête à sourire, un très beau fil de prospective : IBM parle de racheter Sun.

Cette première rétrospective reflète pour nous bien les tendances de l’année passée : pas mal de grandes manœuvres chez les éditeurs, des concurrents à Java de plus en plus présent, un nouvelle spécification très attendue, et des frameworks incontournables qui continuent à mener la danse.

Le coin de la technique

Spring Security seulement un alignement sur Spring 3.0 ?

Dans la foulée de la sortie de la version 3 de Spring Framework, c’est au tour de Spring Security de faire son annonce. Le point le plus marquant de cette version est l’utilisation du Spring Expression Language pour décrire les règles de contrôle d’accès qui simplifieront des vérifications simples comme @PreAuthorize("#contact.name == principal.name)") et surtout, couplé à des classes java transverses de sécurité, permettra d’effectuer élégamment des contrôles déclaratifs sophistiqués tels que :

@PreAuthorize("isPhysician(#patientFile.patient)")
public void create(PatientFile patientFile);

Bien sûr, il faudra programmer la méthode isPhysician(), Spring Security ne se substituera pas au code métier de votre application, il sera juste une aide précieuse .
Nous noterons au passage que l’Expression Language apporte à l’Aspect Oriented Programming le haut niveau d’abstraction qui permet de programmer des fonctionnalités métiers transverses sans être un spécialiste de la plomberie ProceedingJoinPoint et autres joyeusetés. L’AOP devient alors beaucoup plus accessible pour les développeurs d’informatique de gestion.

Les autres nouveautés que nous garderons en tête : des contrôles pré et post traitement (@PreAuthorize et @PostAuthorize), la restructuration des jars similaire à celle que Spring 2.5 a connu, et une clarification des règles de redirection post authentification.

Tour d’horizon de JBoss Infinispan

Le projet Infinispan a été initié en milieu d’année 2009 chez JBoss. Il s’agit d’une évolution de JBoss Cache d’un simple cache vers un DataGrid.

Dans le dernier épisode en date de JBoss Asylum, le podcast dédié à la communauté JBoss maintenu par Emmanuel Bernard et Max R Andersen, Mark Surtani, leader du projet Infinispan, était invité pour parler de son projet. Il a pu faire un tour d’horizon global en commençant par le lien entre JBoss Cache et Infinispan :

• Contrairement à JBoss Cache qui utilisait une organisation arborescente, Infinispan se base uniquement sur une structure clé-valeur à plat.
• Tout comme le faisait JBoss Cache, Inifinispan utilise JGroups pour assurer la découverte de ses instances.
• Une API d’adaptation permettra d’assurer la transition entre JBoss Cache et Infinispan, notamment en offrant une arborescence au dessus de la structure de base d’Infinispan. Des outils seront fournis afin de migrer les fichiers de configuration.

Manik Surtani a également abordé les fonctionnalités à venir, après la finalisation de la première version, dévoilant ainsi les ambitions de positionnement de ce produit :

• Utilisation de Lucene pour offrir une API de requêtes puissante permettant des recherches dans le DataGrid. Plusieurs possibilités d’architecture ont été évoquées telles que la réplication d’un index complet sur l’ensemble des noeuds ou la distribution de shards de l’index complet sur les noeuds via l’utilisation d’un InfinispanDirectory pour Lucene, actuellement en cours de développement.
• Intégration éventuelle avec Hibernate Search. Infinispan se substituerait à Hibernate Core et Hibernate Search lui apporterait alors la fonctionnalité de recherche.
• Possibilité d’effectuer des continuous requests pour que les résultats d’une requête s’enrichissent au fur et a mesure de l’arrivée de données sur la grille.
• API de MapReduce permettant de soumettre un Callable et un ensemble de clés d’objets sur lesquels doivent s’appliquer le traitement pour obtenir un Future représentant le résultat, à venir, après opération de réduction.

La plupart des fonctionnalités évoquées sont présentes dans les produits commerciaux que sont Oracle Coherence ou IBM eXtreme Scale. Toutefois, de telles possibilités seraient inédites dans un produit Open Source ce qui devrait faire d’Inifinispan un produit très intéressant à suivre en 2010…

JGroups à l’heure du Cloud Computing

JGroups est un framework permettant la communication au sein d’un groupe de serveurs. Actuellement développé au sein de JBoss, il est à la base de nombreux middlewares et frameworks d’entreprise permettant un fonctionnement distribué tels que JBoss Cache ou plus récemment Infinispan.

Après un an sans mise à jour majeure, Bela Ban, leader du projet, annonce la version 2.8. Outre de nombreuses évolutions améliorant la flexibilité de JGroups, un apport notable s’est glissé dans la liste : le support d’Amazon EC2. Il s’agit là d’une nouveauté emblématique de cette année 2009 qui va se conclure ; la majorité des frameworks cherche à afficher une compatibilité voire une synergie avec les environnements de Cloud Computing courant.
En pratique, cette intégration de JGroups à EC2 se fait par l’ajout d’un nouveau protocole de découverte de voisinage nommé S3_PING. Comme son nom l’indique, il utilise un stockage S3 commun dans lequel tous les membres d’un groupe écrivent leurs coordonnées. Ce mécanisme est particulièrement bien adapté à EC2 qui, de part la topologie réseau qu’il offre, ne permet pas le multicasting et n’est guère adapté aux autres protocoles de découvertes qui existaient jusqu’alors dans JGroups.

Notons tout de même que la principale nouveauté de cette version 2.8 est l’ajout du concept d’adresse logique que Bela Ban présentait il y a quelques mois. Une adresse logique permet de découpler l’identité d’un nœud JGroups de son adresse réseau ; l’association entre adresse logique et physique est résolue lors de la découverte des nœuds. Outre le découplage offert par ce concept, ces adresses permettent également de simplifier la gestion des pertes de messages lors de la ré-incarnation d’un nœud suite a son indisponibilité temporaire.

10 ans après sa création, JGroups continue donc de se maintenir à jour et, dans la mesure où il remplit toujours parfaitement son rôle, il devrait rester présent encore des années dans plusieurs middlewares et frameworks majeurs.

Actualité éditeurs / SSII

• JEE 6 commence à apparaître chez JBoss

Le coin de la technique

• Sortie de TeamCity 5
• Apache Camel continue d’évoluer

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

• Suite et fin, traduction de la deuxième partie de DDD Quickly

Actualité éditeurs / SSII

JEE 6 commence à apparaître chez JBoss

Quelques jours avant la finalisation de Glassfish V3, l’implémentation de référence de la nouvelle spécification JEE, JBoss met à disposition une première milestone de JBoss AS 6.0, le serveur d’application que l’éditeur destine à implémenter JEE 6.

Ce premier jet apporte seulement 3 des composants propres à JEE 6 :

• Weld, un conteneur CDI implémentant la JSR-299 (Contexts and Dependency Injection).
• Un moteur de validation implémentant la JSR-303 (Bean Validation). L’implémentation utilisée est Hibernate Validator 4.0.
• Une implémentation de JSF 2. Il s’agit de l’implémentation de référence de Sun.

Pourquoi ces composants en particulier ? Parce qu’il s’agit soit des composants pour lesquels JBoss est responsable de l’implémentation de référence, soit, dans le cas de JSF 2, d’une implémentation de référence empruntée à Sun. Or, ces composants sont forcément finalisés puisqu’ils seront intégrés à l’implémentation de référence de l’ensemble de la spécification JEE 6 qu’est Glassfish V3, qui sera disponible dans quelques jours (peu après la finalisation de la spécification le 10 décembre).

JBoss AS 6.0 M1 embarque Hibernate 3.5.0 beta 2, or Steve Ebersole, un des membres de l’équipe Hibernate, expliquait que le support de JPA 2 dans cette version était encore partiel. Aucune indication n’est par contre donnée quant au statut de l’autre composant majeur de JEE 6 qu’est EJB 3.1.

Aucune roadmap n’est annoncée, mais il semble raisonnable de penser à une finalisation pour fin 2010. Si l’on regarde la vitesse de déploiement des serveurs Java EE 5, rares seront donc les privilégiés qui pourront utiliser Java EE 6 avant 2011 voire 2012…

Le coin de la technique

Sortie de TeamCity 5

Fin de semaine dernière est sortie la nouvelle version du serveur d’intégration continue de JetBrains à savoir TeamCity (via JavaLobby). Cette version 5 apporte son lot de nouveautés et elles sont assez alléchantes, jugez par vous-même :

• support d’Amazon EC2 avec un agent de build sur le Cloud permettant de faire du build distribué,
• meilleur support de maven,
• templates de build (préférences partagées),
• intégration avec les gestionnaires de bugs YouTrack, Jira et Bugzilla,
• archivage de projets,
• command line tool (build sans plugin intégré à l’IDE),
• back-up and restore pour simplifier la maintenance de TeamCity,
• ainsi que plusieurs nouvelles fonctionnalités et corrections de bugs dont le support de Git et la compatibilité du plugin TeamCity avec IntelliJ IDEA CE.

Les licences ne changent pas, laissez-vous tenter !

Apache Camel continue d’évoluer

Claus Ibsen, un membre de l’équipe Apache Camel, annonce une nouvelle version 2.1 du moteur de médiation d’Apache.

Il liste les principales nouveautés parmi lesquelles on notera un effort particulier pour apporter une gestion plus robuste des routes :

• Amélioration des messages d’erreur fournit au démarrage en cas de mauvaise définition d’une route.
• Il est désormais possible de définir un ordre de démarrage pour les routes.
• Il est également possible d’indiquer si une route doit être auto-démarrée.

Poursuivant dans cette voie, Claus Ibsen explique son intention d’apporter un graceful shutdown à Camel pour la version 2.2, ce qui permettrait un arrêt de l’ESB sans perdre de messages. Cet arrêt sans perte est dors et déjà possible avec la version 2.1 mais nécessite plusieurs manipulations via JMX (arrêt des routes, puis arrêt du moteur lorsque plus aucun message n’est en cours de traitement).

James Strachan, créateur du projet, expliquait lors de Devoxx 2009 que la majorité de ses clients déployaient Camel sur Tomcat, Jetty ou ServiceMix pour bénéficier d’un environnement de monitoring plus riche et d’une structure plus familière pour l’administration. Ces pratiques montrent les besoins de robustesse des entreprises quant aux déploiements Camel. Ces améliorations, répondant à des problématiques réelles lors de l’utilisation de Camel pour la médiation, devraient donc être accueillies avec joie par les équipes utilisant ce framework.

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

Suite et fin, traduction de la deuxième partie de DDD Quickly

Dans la revue de presse du 10 octobre 2009, nous avons relayé l’information de la traduction de la première partie de DDD Quickly.

La traduction de la deuxième et dernière partie est terminée. Ce livre est disponible sur le portail DDD France.

Dans cette deuxième partie : On y retrouve des techniques pour mettre en oeuvre DDD sur de gros projets impliquant plusieurs équipes, mais aussi pour refactorer un domaine et gérer sa croissance, notamment à travers la distillation et l’identification d’un Coeur de Domaine. (source sur le blog de Guillaume)

Félicitations à Guillaume Lebur pour ce gros travail, et bonne lecture de DDD Vite fait au pied de votre arbre de Noël !

Comme énoncé dans notre résumé de la keynote du mercredi, la star de ce Devoxx 2009 est clairement JEE6. Et, au premier rang avec mon superbe t-shirt « I Love Spring », j’ai pu profiter d’une présentation générale de cette nouvelle version de JEE par Antonio Goncalves et la petite caricature de Rod Johnson .

Introduction

Tout d’abord quelques chiffres autour de JEE6 :

• une sortie prévue le 10 décembre 2009
• 11 ans de JEE (JPE / J2EE / JEE)
• le plus grand intervalle entre 2 versions (3 ans et demi avec JEE5)
• 28 spécifications

Un récapitulatif nous montre les différentes spécifications utilisées (ainsi que quelques technos Java SE 6) avec en jaune les nouvelles spécifications et en noir les montées de version majeures :

Il y en a pour tous les goûts : de l’injection, du back-end et du web et cela a de quoi séduire.

Certaines spécifications sont marquées comme pruned par JEE6 et pourraient éventuellement disparaître dans JEE7. Nous parlons ici des Entity CMP 2.x, de JAX-RPC, JAX-R et de JSR-88 (Java EE Application Deployment).

Antonio nous fait ensuite un rapide tour d’horizon des spécifications marquantes de ce JEE6.

Web Profile

Web Profile est un sous-ensemble de la plateforme JEE orienté Web. On compte parmi les spécifications retenues JSF, Servlet, JSP, JPA, JTA, JCDI, @Inject ou bien encore EJB Lite. La liste complète en image :

EJB Lite

De même que pour Web Profile, EJB Lite est un sous-ensemble d’EJB 3.1, le tout packagé dans un fichier War. Retenues dans EJB Lite :

• Local Session Bean
• Injection
• CMT / BMT
• Interceptors
• Security

Out donc les Messages Driven Beans, les Remote Interfaces ou bien encore les Timer Services.

Managed Beans

Les Managed Beans sont de simples POJOs gérés par le container (lightweight model). Ces beans supportent un ensemble de services basiques (par annotations) dont :

• Injection (@Resource …)
• Life-Cycle (@PostConstruct, @PreDestroy)
• Interceptor (@Interceptor, @AroundInvoke)

@javax.annotation.ManagedBean
public class MyPojo {
   @Resource
   private DataSource dataSource ;
   @PostConstruct
   private void init() {
      // ...
   }
   @Interceptor(LoggingInterceptor.class)
   public void perform() {
       // ...
   }
}

Bean Validation

Antonio nous parle ensuite de Bean Validation, spécification qui va nous permettre de définir des contraintes directement sur nos POJOs par annotations. L’accroche : constrain once, validate anywhere ! Nous pouvons donc ajouter des validations de type @NotNull, @Size ou autres sur nos propriétés de bean. Il est aussi possible de définir nos propres validateurs.

Cette spécification définit ainsi un standard de validation pour Java, Bean Validation étant déjà supportée par JPA 2.0 et JSF 2.0. On a ainsi une validation qui part de la base de données et va jusqu’à la couche cliente.

JAX-RS

Un peu de RESTful dans JEE avec JAX-RS qui passe au passage en version 1.1 pour supporter les EJBs. L’API reste bien sûr orientée POJO et annotations. Voici un exemple d’intégration de JAX-RS avec un EJB :

@Path("/users/{userId}")
@Stateless
public class UserResource {
   @GET @Produces("image/jpeg")
   public byte[] getPhoto() {
      // ...
   }
   @GET @Produces("text/xml")
   public String getUser(@PathParam("userId") String id) {
      // ...
   }
}

@Inject et CDI (Context and Dependency Injection)

Nous vous avons déjà beaucoup parlé de ces JSRs (ici, ici, ici mais aussi là et encore là).
@Inject, @Named, @Qualifier, @Scope ou bien encore @Singleton, voici les annotations de JSR-330 que nous allons pouvoir utiliser.
Quant à CDI (JSR-299), qui utilise @Inject, elle nous propose un set de services utilisables par nos composants EE (servlets, beans…). Elle nous permet aussi d’utiliser nos EJBs directement dans JSF en tant que backing beans.
Évidemment, le contenu de ces spécifications est beaucoup plus large et nous n’avons ici qu’un rapide résumé.

Mais aussi…

Parmi les autres nouveautés, on peut citer en vrac :

• Appels asynchrones avec @Asynchronous avec un retour void ou Future<T> ;
• Annotation @Singleton ;
• Annotation @Cacheable avec toute l’API de cache (contain, evict ou evictAll) qui permet le support d’un cache de second niveau ;
• Embeddable Container, API qui permet d’initialiser le container, de récupérer les contextes… faisant qu’il est possible de le faire tourner dans un environnement Java SE (par exemple une application Swing), ce ne sera qu’un JAR dans votre classpath ;
• Timer Service pour gérer la planification de tâche avec l’annotation @Schedule ;
• Fichier web.xml optionnel grâce entre autres aux annotations @WebServlet, @WebFilter,@WebListener ou bien encore @WebInitParam ;

Conclusion

L’opération séduction fonctionne plutôt bien pour JEE6 si l’on écoute les différents commentaires des conférenciers en sortie de session. La simplicité et facilité d’utilisation des EJBs, le profile web ou encore les injections ont vraiment convaincus et nombreux sont ceux qui attendent désormais avec impatience ce 10 décembre 2009. En effet, il n’y a plus qu’à tester et à voir si JEE6 tient vraiment toutes ses promesses…

• 2500 participants,
• 737 compagnies représentées comme Xebia par exemple ,
• 132 sessions,
• 120 speakers,
• 56 JUGs (dont 10 en France),
• 36 pays,
• et 19 partenaires ce qui est moins que d’habitude.

La nouvelle version de Parleys.com

Stephen Janseen débute en nous expliquant ce que fournira la nouvelle version de Parleys.com. Gratuites et disponibles, le nombre de vidéos augmente sur les serveurs, ce qui est très coûteux. Pour pallier ce problème, il a décidé de publier le plus tôt possible les conférences de Devoxx (ce week end même d’ailleurs ). Et avec un abonnement de 49€ pour 6 mois, un utilisateur pourra soit télécharger toutes les vidéos qu’il souhaite sur le site soit les regarder directement en streaming. Pour les plus patients, la video sera rendue publique en streaming pour tous au bout d’un an.
Dans cette nouvelle version, il sera possible :

• De définir des channels privés ou publiques selon les besoins du publieur,
• De choisir son look’n'feel,
• D’ajouter des commentaires sur la piste video.

Ces nouveautés sont actuellement disponibles sur http://beta.parleys.com.

La keynote de Java EE 6

Cette année à Devoxx, la star est clairement JEE6 avec pas moins de 7 sessions autour de ce sujet :

• Une keynote.
• Une université et un BOF JEE6.
• Une université et un BOF JSF 2.0.
• Une conférence JEE6.
• Une conférence JEE6 et Glassfish V3.

La keynote met en avant les spécifications les plus hypes de JEE6 avec entre autres :

• EJB 3.1,
• DI 1.0 (@Inject),
• CDI 1.0 (Context and Dependency Injection),
• JSF 2.0 (événement que nous avons couvert),
• Bean Validation 1.0,
• Servlet 3.0,
• et JAX-RS 1.1.

Un article plus complet décrivant JEE6 arrivera très prochainement, l’information principale de cette keynote étant la date de sortie de JEE6 qui est prévue pour le 10 décembre 2009 (Cf. notre précédente revue de presse).

La keynote d’Adobe avec en guest-star Flash Catalyst

Adobe fut à l’honneur cette année à l’instar de JavaFX. La keynote fut l’occasion pour l’éditeur de tenter une opération séduction de la communauté Java avec des annonces autour de Flex, Air, Flash Player Lite et Flash Catalyst.

Pour commencer, Flash Player 10.1 fut présenté. Cette version a surtout été travaillée pour fonctionner sur téléphone mobile :

• Réduction de la mémoire utilisée.
• Limitation de la consommation de batterie.
• Gestion du multi-touch et de l’accéléromètre.

Serge Jespers a présenté un Flash Player déployé sur mobile : oui, il est enfin possible d’accéder à Parleys depuis son mobile !

La liste des partenariats entre Adobe et les fabricants de smartphone et d’OS a considérablement augmenté depuis l’année dernière. Avec, entre autres, le petit dernier : RIM, l’OS de BlackBerry. Actuellement, Apple ne fait toujours pas partie de cette liste. Aucun accord n’a été trouvé pour le moment. Il n’est donc pas possible de lire une application Flex par exemple depuis le navigateur de son iPhone. En revanche, il est possible de déployer une application Flex sur l’AppStore et de l’utiliser. En effet, Adobe a mis en place un moyen permettant de convertir un swf en code natif pour l’iPhone. Des jeux Flash sont d’ailleurs déjà disponibles sur l’AppStore.

Autre annonce, la sortie depuis quelques jours de la béta de Adobe Air 2.0. Cette version fournit les nouveautés suivantes :

• Le support de l’usb.
• Le support du multi-touch.
• De nouvelles APIs permettant de récupérer la sortie du microphone.
• Une sécurité améliorée pour mieux répondre aux standards des entreprises et gouvernements.

Nos deux speakers ont ensuite impressionné la salle en réalisant rapidement à partir d’un dessin issu d’Illustrator une application Flex comportant des effets, gérant un évènement click sur un bouton, et le plus impressionnant de tous, la gestion d’une scrollbar provenant d’un dessin. Cette génération fut ensuite exportée dans Flash Builder 4 en tant que projet Flex. La salle semblait séduite par la démo. Attendons maintenant 2010, pour voir si cette plateforme tiendra ses promesses et si la communauté continuera à suivre.