Le weblogue de SeB

Pour fournir un logiciel de qualité, il est nécessaire de produire un code source de qualité. Je vous ai déjà présenté des outils pour mesurer des indicateurs de qualité du code source et pour vérifier le respect des conventions de codage. Cependant, ces outils ont leurs limites. Ils tendent à améliorer le code source en contrôlant le respect des normes de codage ou en identifiant les défauts de conception. Par contre, ils ne permettent pas d’identifier les anomalies fonctionnelles.

Cédric Beust présente son point de vue sur l’intérêt de la revue de code. La revue de code permet d’identifier des bugs avant de les rencontrer au moyen d’une relecture du code source par un développeur expérimenté.

La mise en place d’une revue de code systématique pendant la phase de développement et de correction, les développeurs se responsabilisent encore plus^[1]. Car ils savent que leur travail sera automatiquement évalué^[2]. Ce système permet d’améliorer la qualité du code source écrit. De plus, le relecteur pourra identifier des bugs ou des axes d’amélioration^[3].

Trois processus de revue de code existent :

• Revue de code bloquante : tout développement doit être relu avant d’être commité dans le référentiel du code source. Ce mode est un frein au développement car certains développement peuvent se retrouver en attente d’une relecture de développement dont ils dépendent.
• Revue de code non-bloquante : tout code source commité dans le référentiel du source source doit être relu. Cette méthode permet au développeur de continuer son travail sans attendre la relecture. De même, le relecteur n’est pas obligé de se précipiter pour relire le code.
• Revue de code avec le développement par binôme : c’est une conséquence de l’extrême programming. Cependant le travail en binôme influence le jugement du relecteur direct.

La revue de code non-bloquante semble être la meilleure solution. Des produits permettent de mettre en place ce système. Certains sont même disponibles sous la forme de plugins pour les IDEs tel que Jupiter pour Eclipse.

La revue de code augmente les charges de développement d’un projet. En revanche, cette première passe permet d’éviter de nombreux retours lors de la phase de recette. La charge de recette et de correction sont alors réduites. Le produit livré sera mieux perçu par les premiers utilisateurs.

A vos relectures !

Notes

[1] Plus attentif aux potentielles erreurs, documentation du code, …

[2] Attention, l’évaluation doit être respectueuse du travail initial fourni.

[3] Optimisation du code source, documentation, …

• La tête de la compétition des frameworks MVC ? Car d’autres frameworks semblent plus actifs.
• La tête des leaders du projet ? Car certains demandent une réorganisation, voire une séparation !
• La tête ou en d’autres termes la raison ? Car le projet semble se disperser.

A lire, le dernier sujet lancé par Don Brown, on peut se poser des questions ! En effet, depuis l’annonce de Struts 2 Struts Shale, les développeurs utilisateurs sont un peu perdu entre les différentes versions de Struts :

• Struts Action 1 (anciennement Struts Classic)
• Struts Action 2 (anciennement Struts Titanium ou Struts Ti pour les intimes)
• Struts Shale (anciennement et de façon très ephémère Struts 2)

Même si chacun, tente d’expliquer les différences pour Struts Titanium ou la position de Struts Shale, l’orientation du projet perturbe beaucoup de monde. Struts s’est forgé depuis des années une solide réputation. Au point de devenir un quasi standard. Pourtant, ce framework n’est pas des plus simple à mettre en place^[1]. C’est pour cela, qu’il a su s’appuyer sur des solutions plus simples telles que WebWork. De plus, de vrais standards^[2] tels que JSF bousculent le projet au point d’être obligé de revoir l’architecture de Struts pour donner Struts Shale.

Aujourd’hui, le projet héberge trois frameworks et donne l’impression de se disperser. De plus, les membres de l’équipe de développement ne sont pas tous du même avis sur la stratégie à adopter :

• Faut-il conserver et maintenir indépendamment ces trois outils ?
• Faut-il concevoir un socle commun et proposer le choix entre trois modules différents ?
• Faut-il séparer ces trois frameworks en autant de projets complétement indépendants ?

Il est nécessaire d’assurer la maintenance de SAF1. Cela en va de la crédibilité de l’équipe de Struts mais aussi de la communauté dite Open Source. Par contre SAF2 et Shale ont une approche totalement différentes. Au point de les séparer ?

Néanmoins, il ne faut pas oublier la force Struts réside dans le fait qu’il ne s’est pas arrêté à l’implémentation du modèle de conception MVC. En effet, la multitude de sous-projets apporte autant d’atouts au projet^[3]. Alors faut-il mettre en commun ces sous-projets pour chaque framework de la suite Struts ?

Il faut espérer que cette situation se débloque rapidement afin que l’équipe puisse se concentrer sur le développement et proposer des nouvelles versions plus régulièrement. La qualité des membres de l’équipe laisse penser qu’ils se ressaisiront rapidement. Et ainsi la situation devrait se clarifier pour le meilleur des utilisateurs.

Dans la série des billets sur les sites traitant de l’ergonomie, voici un nouveau site très intéressant : Ergologique. Son objectif est de sensibiliser et de conseiller les concepteurs d’IHM sur l’ergonomie et l’utilisabilité^[1].

Vous pourrez trouver sur ce site des présentations, de nombreux conseils et des liens vers l’actualité. L’équipe de ergologique met à votre disposition des documents très riches sur l’ergonomie. Les amateurs de conception web ou multimédia devraient se régaler.

Je vous ai déjà présenté la conception d’une application multilingue. Lors de cette présentation j’avais évoqué quelques pistes à suivre pour aller plus loin lors de l’internationalisation d’une application. Suite à la découverte du site l’ergonome, j’ai trouvé un excellent document sur les aspects ergonomiques de l’internationalisation des sites web. Les auteurs posent les bonnes questions. Et notamment, ils mettent en avant les éléments concernés par l’internationalisation :

• le texte
• les formats de nombres, de date et d’heure
• les images
• les symboles
• les couleurs
• les flux d’information
• les fonctionnalités

Avec cet article, vous aurez en votre possession tous les éléments pour mettre en œuvre une internationalisation de qualité pour vos sites web^[1]. Attention, certains points nécessitent un investissement important en terme de ressource, temps et finance.

On entend de plus en plus parler de l’ergonomie et des ergonomes. Loin d’être un effet de mode, ce domaine est un réel métier. Peu connu, il gagne en reconnaissance.

Afin de faire connaître la discipline et de sensibiliser les concepteurs d’IHM, le site l’ergonome propose un ensemble de réflexions et d’articles sur le sujet de l’ergonomie. Dans la même veine que le site Ergolab présenté précédemment, vous y trouverez des documents intéressant pour améliorer l’ergonomie de vos applications^[1].

Si la section ergonomie continue de s’étoffer, je vais devoir ajouter une sélection de liens^[2] sur le sujet.

Sans revenir sur les détails du modèle de conception appelé singleton, ce dernier permet de n’avoir qu’une seule instance de classe. Parfois, dans un contexte d’application d’entreprise possédant plusieurs applications web, il est nécessaire d’avoir une seule instance de classe pour l’ensemble de ces applications. Or cela n’est pas toujours aussi trivial.

En effet, selon la stratégie de gestion des classloaders employée par les serveurs d’applications, les applications web au sein de la même application d’entreprise peuvent avoir un classloader différent^[1]. Dans ce cas, chaque application web aura sa propre instance de classe (géré par le singleton).

En général, un classloader est également défini pour l’application d’entreprise. Ainsi, si le singleton appartient à ce classloader, il pourra être partagé avec toutes les applications web. Afin d’obtenir ce résultat, il faut seulement modifier la façon de générer le fichier EAR.

Par exemple, si le singleton est défini dans une bibliothèque externe appelée util.jar. Au lieu de placer ce JAR dans le répertoire WEB-INF/lib de chaque application web, il faut placer ce fichier à la racine de l’EAR. Ensuite, pour chaque application web, il faut ajouter dans la variable Class-Path du fichier META-INF/MANIFEST.MF la référence à la bibliothèque externe^[2].

Voici un exemple plus concret de l’arborescence de l’EAR :

META-INF/application.xml
 util.jar
 mywebapp1.war
   META-INF/MANIFEST.MF:
     Manifest-Version: 1.0
     Class-Path: util.jar
   WEB-INF/web.xml
 mywebapp2.war
   META-INF/MANIFEST.MF:
     Manifest-Version: 1.0
     Class-Path: util.jar
   WEB-INF/web.xml

Cette solution est très fortement inspirée de l’article de Nicolas Martignole sur la gestion des ressources JARs dans un projet J2EE. Et pour une utilisation plus avancée, vous pouvez consulter l’article officiel : Packaging Utility Classes or Library JAR Files in a Portable J2EE Application.

Notez que cette solution permet en même temps de réduire la taille de l’EAR. Avec ces éléments, vous serez capable de mieux gérer vos ressources JAR dans vos applications livrées sous forme d’EAR.

Notes

[1] C’est le cas par exemple avec le serveur d’applications JOnAS.

[2] Cette référence correspond au chemin relatif à partir de la racine de l’EAR.

La réutilisation de couche logicielle existante ne date pas d’aujourd’hui. Mais ce modèle de conception est encore plus d’actualité avec l’essor des applications web.

En effet, pour réaliser une application web, nous allons choisir un serveur d’application, un framework MVC, une couche de persistance, un accès JDBC, … Ajoutez à tout cela, d’autres couches applicatives pour le cache, la répartition de charge, le workflow et vous vous retrouvez avec une pléthore de composants !

Christophe J. présente un article de Peter Thomas illustrant très bien ce fait. Dans son article, il se demande quelle proportion son travail occupe-t-il entre une requête HTTP et l’accès à la base de données en JDBC ? Pour cela, il a utilisé un profiler pour afficher la pile d’appels^[1].

C’est assez terrifiant, mais extrêmement réaliste. Le code spécifique à l’application occupe une part très limitée de la pile d’appels. Votre participation dans l’application est-elle insignifiante ? Oui et non^[2]. Certe, votre code ne représente pas grand-chose dans l’ensemble de l’application. Mais c’est la valeur ajoutée qui fait la différence. De plus, il ne faut pas oublier tous les fichiers de configurations^[3]. Ceux-ci ne sont pas visibles dans la pile d’appels. Pourtant, ils représentent une part significative dans la logique de l’application.

Donc, même si votre participation dans l’écriture du code d’une application diminue progressivement, vous apportez une valeur ajoutée non négligeable et essentielle. Aujourd’hui, le travail des développeurs s’apparente à de la plomberie. Et ceci est en partie rassurant. En effet, vous ne perdez plus votre temps à réécrire ce qui existe déjà, et vous vous concentrez le cœur du métier.

Comment concevoir une application multilingue ? Quelle architecture mettre en place pour internationaliser une application ?

Le contexte applicatif

Avant d’aller plus, loin il est nécessaire de définir les différents contextes applicatifs qui peuvent conditionner le choix d’une solution multilingue.

Les données

Les données à traduire peuvent être séparées en deux groupes :

• les données statiques : qui correspondent aux messages de l’application^[1].
• les données dynamiques^[2] : ce sont des informations, généralement stockées en base de données, qui sont saisies par les utilisateurs.

Les utilisateurs

Une application peut être mono-utilisateur ou multi-utilisateur. Pour une application mono-utilisateur, seules les données statiques ont besoins d’être multilingues. En revanche, dans une application multi-utilisateurs, deux cas sont possibles :

• les données applicatives sont exclusivement réservées à chaque utilisateur
• les données applicatives sont partagées entre les utilisateurs

Dans le premier cas, l’internationalisation des données applicatives n’est pas nécessaire. Car chaque utilisateur produit ses propres informations dans sa langue. Par contre, le second cas mérite plus d’attention. Surtout si les utilisateurs n’ont pas tous la même langue.

Internationalisation

Les données statiques

Pour les données statiques, il suffit seulement d’externaliser tous les messages dans des fichiers de ressources^[3]. Ensuite, il suffit d’écrire autant de fichier de ressources que de langues supportées par l’application. Ainsi, lorsque l’utilisateur accède à l’application, les messages sont récupérés à partir du fichier correspondant à sa langue.^[4].

Les données dynamiques

Les données utilisateurs qui doivent être traduites doivent être stockées en base de données. Et c’est la base de données qui gère les traductions. Pour cela, il faut définir une table listant les langues. Puis pour chaque entité qui peut être traduite, il faut utiliser deux tables :

• la première contient les champs qui ne sont pas traduits
• la seconde contient les champs qui peuvent être traduits et est liée à un enregistrement de la première table et une langue

La seconde table contient autant d’enregistrement qu’il y a de langue pour un enregistrement de la première table. De cette façon, les données à retourner par la base de données dépendront de la langue de l’utilisateur.

Les limitations

Gérer des données dynamiques dans plusieurs langues oblige à saisir ces informations dans toutes les langues. De plus, cette étude ne prend pas en compte les contextes collaboratifs multilingues.

Aller plus loin

Les devises, le format des dates et les nombres ne sont pas abordés ici. Cependant, il ne faut pas oublier de les gérer. Une piste intéressante serait de stocker en base de données ces informations dans le format d’une locale par défaut^[5]. Ensuite pour chaque utilisateur, il serait nécessaire de reformatter les données que ce soit à la saisie ou à l’affichage.

L’encodage des données n’est pas évoqué non plus. Mais il faut penser à encoder correctement des données dès le départ ! Car la conversion d’un encodage vers un autre est une expérience très chaotique.

De plus, cet article traite seulement des éléments textuels. Or, l’internationalisation ne dépend pas seulement du texte. D’autres éléments peuvent être pris en considération lors de l’internationalisation, comme par exemple les images, les couleurs, la mise en page^[6], …

La solution proposée est une bonne base pour rendre vos applications multilingues. Cette étude ne prétend pas résoudre tous les problèmes d’internationalisation. Néanmoins, elle couvre une grande partie des cas rencontrés généralement. Le dernier travail reste de trouver des traducteurs.

Ce n’est pas la nouvelle année et son lot de bonnes résolutions. Ce n’est pas non plus le printemps avec son grand ménage. Pourtant, c’est bien l’heure des changements sur ce weblogue. Et après avoir décidé de changer le style d’écriture, c’est l’habillage qui prend un coup de jeune.

Après quelques essais, c’est le thème Zero v4 qui est utilisé^[1]. J’espère surtout que les couleurs ne sont pas trop froides. Si cela peut vous rassurer, vous avez échappé à un thème sur les dominantes bleue/orange suite à une rencontre avec une bouteille de Cristalline contenant du Punch !

Cette nouvelle mise en page fait suite à la précédente annonce sur l’amélioration de l’ergonomie du site. Elle est destinée à être améliorée selon vos remarques. Par la suite un bilan sera fait par rapport aux objectifs initiaux.

En relisant mes tous premiers billets, je me suis rendu compte que ces derniers étaient devenu au cours du temps de plus en plus impersonnel. Et il est temps de reprendre tout cela en main !

Donc, à partir de ce billet, j’utiliserai plus souvent la première personne du singulier. De plus, je souhaiterai mettre à contribution mes précieux lecteurs en posant des questions ou entament des sujets ouverts. Ceci permettra à chacun de réagir de façon libre et instantané^[1]. En effet, le ton impersonnel de certain sujet freine les contributions extérieures. Or, un weblogue ne doit pas se résumer en une succession de monologues !

Tout ceci pourquoi ? Et bien, j’espère rendre ce site plus vivant. De plus, la plus petite participation de chacun contribue à améliorer la qualité globale du contenu pour tous.

Et vous, comment faite-vous pour animer votre weblogue ?