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

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.