Revue de Presse Xebia

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

Actualité éditeurs / SSII

Agilité

Le coin de la technique

Agilité

Intégration continue – taux de couverture de code

Un serveur d’intégration continue qui déroule les tests unitaires du projet, c’est très bien. Le serveur donne le nombre de tests unitaires qui sont passés, le nombre de tests échoués, notifie les intervenants du projet, et génère des rapports et des graphiques à partir des résultats donnés par JUnit. Mais il manque tout de même une information importante… Quel est le pourcentage de code couvert par les tests unitaires ?

Clover, après son récent rachat par Atlassian, vient de sortir en version 2 avec son lot de nouveautés :

les rapports présentent désormais à la fois le taux de couverture des tests et le résultat des tests,
on connaît couverture de code par test,
le module d’affichage des sources en HTML a été amélioré

Clover est un outil commercial nécessitant une licence payante. Dans le monde opensource, les alternatives se nomment Cobertura et EMMA. Ces outils peuvent être couplés au processus de build (Ant ou Maven), et les résultats peuvent (parfois, suivant les plugins disponibles sur tel ou tel serveur) être affichés dans les rapports du serveur d’intégration continue.

Estimations Agiles

Mike Griffiths, praticien agile ayant participé en 1994 à l’élaboration de la méthode agile DSDM, vient d’initier une série de billets sur les estimations agiles. Dans ce premier billet, il aborde notamment la problématique de l’estimation initiale et commence par rappeler que, approche agile ou non, cet exercice sera toujours difficile du fait du caractère unique de chaque projet. Ainsi, les estimations initiales peuvent considérablement varier par rapport à la réalité comme l’illustre parfaitement bien le désormais célèbre cône d’incertitude de Barry W. Boehm. Avec les méthodologies agiles, les estimations peuvent être affinées après quelques itérations en fonction de la vélocité mesurée du projet. Mais en début de projet, que la méthodologie adoptée soit agile ou traditionnelle, le problème reste le même – estimer le temps nécessaire pour construire un système unique avec une équipe inexpérimentée – et nous devons donc accepter que les approches seront similaires. Mike livre ici quelques techniques qui peuvent vous aider.

Le coin de la technique

Continuum 1.1 Beta 4 et Archiva 1.0 Beta 3

Semaine riche sur la planète Maven avec les annonces, à quelques jours d’intervalle, de Continuum 1.1 Beta 4 et Archiva 1.0 Beta 3. Au menu pour Continuum (non exhaustif) : de nombreuses corrections de bogues, une nouvelle page permettant de visualiser la queue de build et la possibilité d’utiliser des templates de mail configurables. Pour plus de détail, vous pouvez consulter les release notes. Pour Archiva, cette nouvelle beta qui sera a priori l’avant dernière avant la 1.0 finale contient essentiellement des corrections de bogues et quelques améliorations. De même, les release notes vous donneront tous les détails. Félicitations aux équipe Continuum et Maven Archiva !

RIA – qui utilise Flex aujourd’hui ?

Le taux de pénétration d’une technologie est un facteur important (prédominant?) pour les décideurs informatiques. Les deux technologies qui sortent du lot pour développer des applications RIA (Rich Internet Application) sont AJAX (et sa flopé de frameworks) et Flex d’Adobe.

Flex est un environnement de développement permettant de créer des applications RIA multiplateformes, la partie présentation est en Flash (le taux de pénétration du plugin Flash est excellent, proche de 100%, il n’y a donc pas de problème de déploiement), et les applications Flex peuvent consommer des services distants (web services, EJB, etc.). L’environnement de développement FlexBuilder est basé sur Eclipse, mais est payant, tandis qu’Adobe a récemment passé Flex sous licence opensource.

Flex est aujourd’hui utilisé par de nombreuses compagnies, cet article chez InfoQ liste certaines d’entre elles.

Buildr premier projet Ruby à rejoindre l’incubateur de la fondation Apache

Buildr semble être l’alternative à Maven 2 qui monte… Cet article d’InfoQ est un bon point d’entrée pour en apprendre un peu plus sur l’outil.
Buildr est donc un outil de build pour projets Java, mais est codé en Ruby. L’outil semble être plus rapide que Maven 2 et est surtout beaucoup plus facilement extensible.

Il ne sera tout de même pas être évident de déloger Maven 2 mais les deux projets sont désormais sous l’ombrelle de la fondation Apache, nous verrons bien ce qu’il en sortira.

Encodage des messages avec Websphere MQ

La gestion des encodages avec Websphere MQ est toujours un sujet délicat à traiter (EBCDIC, CCSID et autres joyeusetés). IBM met à jour Data Conversion Under WebSphere MQ. C’est l’occasion de rappeler quelques bonnes pratiques pour prévenir ces problèmes auxquels nous ne sommes pas habitués :

JMS et son pendant XMS (.Net, C et C++) sont les API de prédilection pour accéder à MQ depuis des applications d’informatique de gestion :
JMS Performance with WebSphere MQ for Windows 6.0
Using JMS connection pooling with WebSphere Application Server and WebSphere MQ
XMS Clients
Tibco Enterprise Messaging Service (EMS)
Le format MQRFH2, autrefois difficile à manipuler avec les APIs MQI, se généralise avec les APIs JMS/XMS et le support de SOAP (cf. WMQ SOAP Listeners).
L’utilisation de TextMessage pour transporter des documents XML est le standard de-facto. Cependant, ce choix nécessite de maintenir en synchronisation le ccsid du message MQ et l’attribut « encoding » du document XML (cf MQSeries.net : XML in JMSTextMessage or JMSBytesMessage). Une règle de précaution est de systématiquement utiliser UTF-8, l’encodage par défaut en XML (voir infra).
UTF-8 est un très bon candidat comme encodage standard d’échange des messages MQ. Il est supporté de façon transparente par les APIs JMS et XMS et est l’encodage par défaut des documents XML.