Revue de Presse Xebia

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

Actualité éditeurs / SSII

• IE6 : End of life !
• cdnjs.com un content delivery network pour javascript

Agilité

• Traiter l’urgence dans une équipe agile

NoSQL

• Infinispan au Paris NoSQL User Group

Actualité éditeurs / SSII

IE6 : End of life !

IE6 Countdown est un site lancé par Microsoft pour mesurer la baisse de part de marché d’IE6 dans le monde (et accessoirement promouvoir IE7 et 8). Ce dernier affiche 3,9% pour la France, alors que la Chine plafonne à 34,5%. Le «_grand gagnant_» est la Norvège, qui affiche seulement 0,7% de part de marché. La firme de Richmond encourage vivement à migrer vers IE7/8, avec pour argument un tableau comparatif, où l’on peut observer que presque aucune feature des navigateurs modernes n’est supportée : gestion des fenêtres par onglets, barre de favoris, compatibilité avec les standards du Web. Les développeurs Web quant à eux, peuvent même rajouter une bannière sur leur site, qui invite les utilisateurs ayant une version d’Internet Explorer antérieure à la 7, à le mettre à jour :

Enfin, bien qu’un grand du Web tel que Google ait récemment cessé de supporter IE6 sur Google Docs et Google Sites (Gmail et Google Calendar suivront dans l’année), le navigateur est encore très largement répandu en entreprise, avec son OS Windows XP. De ce fait, nous ne serions que trop vous conseiller d’inviter vos clients respectifs à monter de version, notamment pour des raisons de sécurité et de compatibilité. Pour les autres, Microsoft assurera tout de même le support jusqu’en Avril 2014.

cdnjs.com un content delivery network pour javascript

cdnjs.com est, comme son nom l’indique, un Content Delivery Network pour javascript : un nouveau service en ligne utilisant l’infrastructure AWS d’Amazon pour mettre à disposition des bibliothèques javascript. Google et plus récemment Microsoft proposent déjà ce type de service, mais uniquement pour les bibliothèques javascript les plus populaires… d’après leur propre usage. L’idée de cdnjs.com est d’apprécier à travers les votes de la communauté les bibliothèques javascript les plus utilisées afin de les héberger. Les sites web utilisant ce service bénéficient alors d’un cache http commun.

Agilité

Traiter l’urgence dans une équipe agile

Serge Beaumont, notre confrère de Xebia Pays-Bas, vient de publier un intéressant article sur les différentes manières de traiter les situations d’urgence dans les équipes agiles. C’est un sujet toujours difficile, car, par définition, la charge de travail requise pour traiter ces situations est inconnue. Donc peu estimable et planifiable.
Il commence son article par regretter la bonne vieille époque des projets waterfall où il n’y avait jamais de maintenance à faire. Ahhh, le bonheur que ça devait être que de travailler sur des projets parfaits, sans bugs, sans… Ah, attendez: une lecture plus attentive précise que c’était en fait l’équipe de maintenance qui était chargée de corriger la pile de non-sens créée par d’autres. Les pauvres…
Sur un projet agile, les livraisons régulières responsabilisent les équipes elles-mêmes qui verront revenir plus rapidement leurs propres erreurs.
Plusieurs scénarios sont envisagés:

• un Product Owner jouant le rôle de « firewall » et élimine bon nombre de problèmes (qui bien souvent n’en sont pas !)
• ce même Product Owner peut mettre les urgences au planning du sprint suivant et n’accepter que les vraies urgences

Pour les vrais problèmes, ceux qu’on ne peut pas éviter de traiter immédiatement, il est envisageable de garder à chaque début de sprint un buffer leur étant destiné. Mais notre confrère nous met en garde sur le fait que ce serait sans doute une fausse bonne idée: dès que votre MOA aura connaissance de la présence de votre buffer, ils n’auront de cesse d’essayer de le remplir. D’où la règle numéro 1 du buffer: le buffer n’est pas pour les éléments du backlog. La règle numéro 2, pourtant extrême, permettra de relativiser l’importance des demandes: un remplissage du buffer entraîne un abandon du sprint en cours. Extrême ? Mais efficace ! Les gens réfléchirons par 2 fois à la priorité de leurs demandes. Le principal reste tout de même de fixer la cause racine et donc d’améliorer la qualité. Logique, non ?

Finalement, l’auteur donne un conseil pour les équipes qui doivent faire beaucoup de maintenance: Kanban bien que proche de Scrum propose un process plus adapté. Nous vous renvoyons à notre article sur « Kanban in action » à Devoxx.

NoSQL

Infinispan au Paris NoSQL User Group

Manik Surtani, est venu au Paris NoSQL User Group présenter Infinispan, la In Memory Data Grid de JBoss dont il est le lead technique. Nous retiendrons :

Objectif : concurrencer Coherence

L’objectif d’Infinispan est de proposer une alternative Open Source à Oracle Coherence, Gigaspace ou IBM eXtreme Scale.

Les topologies

Infinispan propose deux topologies de déploiement :

• Embedded Mode (aka peer-to-peer) : l’application est fusionnée avec la grille de données : les JVM qui portent la(les) application(s) participent à la grille et portent des données. C’est la mode d’intégration qui permet le plus grand nombre de fonctionnalités mais qui apporte aussi le plus grand couplage.

• Client-Server Mode :
  • L’application se connecte à la grille de données avec un connecteur comme elle se connecte à des SGBD.
  • Il existe quatre protocoles : REST/HTTP, MemCached, Hot Rod (protocole bi-directionnel interne d’Infinispan) et les Web Sockets. Hot Rod sera le protocole le plus riche qui facilitera la haute disponibilité grâce à l’autodécouverte de la topologie de la grille et permettra les continuous queries. Seul Hot Rod impose java côté client. Les WebSockets sont temporairement remises en cause par les failles de sécurité inhérentes à cette technologie.

Les APIs

Infinispan propose aujourd’hui une API bas niveau de style key-value store et travaille sur une API de haut niveau de style JPA qui manque cruellement à certains concurrents :-) . Ces APIs seraient utilisables en mode « Embedded » et en mode « Client-Server » avec le protocole Hot Rod.

Fort de l’expérience de JBoss sur les annotations JPA et Hibernate Search, on peut espérer une API élégante.

Le plus : Hibernate Search

Infinispan apporte une fonctionnalité originale qui le différencie de ses concurrents : l’intégration d’Hibernate Search qui permet de créer des index secondaires plus sophistiqués que ceux « à la SQL » qu’on voit dans les autres In Memory Data Grids. Il est tout de même probable que cette richesse d’indexation ne concerne que peu de cas d’utilisation.

La road map

Le projet est dynamique et prometteur et il reste encore beaucoup de travail comme :

• l’envoi de traitements dans la grille (map/reduce, entry-processors, etc) qui est encore en version beta,
• le choix de language de programmation pour réaliser des traitements dans la grille. La réflexion se place aujourd’hui autour d’un langage neutre comme javascript ou de java,
• des optimisations de la gestion de la mémoire pour gérer des JVM de grande taille (> 10 Go),
• l’intégration de JBoss Marshalling avec l’ajout d’une API de versioning pour sérialiser les données dans la grille,
• l’ajout d’une query language pour requêter les données.

Scénarios d’utilisation d’Infinispan aujourd’hui

Le principal scénario d’utilisation d’Infinispan aujourd’hui est un « distributed key-value store » qu’on peut même installer sous forme « Data as a Service » pour reprendre l’expression de Manik Surtani.

Les utilisations en In Memory Data Grid haute performance avec des traitements au coeur des données sont a réserver à un public averti :-).