Le weblogue de SeB

Je vous ai souvent parlé du modèle de conception MVC et de ses avantages.

Ajaxian vient de relater un article de PHPied sur la mise en application du modèle MVC avec Ajax.

Selon l’auteur, avec Ajax, la vue contient des pages HTML, des feuilles de style CSS et des scripts Javascript pour la mise à jour du HTML. Le controleur contient des scripts Javascripts pour les comportements et du code PHP pour aiguiller les requêtes. Et pour finir, le modèle contient la logique métier en PHP.

A partir de ce modèle, l’auteur a écrit une petite démonstration dont le code source est accessible. Il propose même un squelette de projet pour les nouveaux projets. La couche Ajax est implémentée avec YUI.

L’approche, même si elle reste simpliste, est réellement intéressante. Elle permet de se poser des questions sur l’organisation du code dans les applications qui utilisent Ajax.

Lorsqu’un projet a une taille conséquente, il est nécessaire de répartir les tâches de développement entre les développeurs. Avec le développement multi-couche, cette répartition peut se faire de deux façon différentes :

• L’approche horizontale
• L’approche verticale

Selon EJB/index.tss" hreflang="en">Mastering EJB 3rd Edition^[1], l’approche horizontale permet d’avoir des personnes ultra-spécialisées dans un domaine technologique correspondant à la couche sur laquelle ils ont l’habitude de travailler. Alors que l’approche verticale permet aux personnes d’obtenir une excellente maîtrise du fonctionnel lié au métier.

La première approche donne naissance à des experts dans des domaines spécifiques. Et avec le second point de vue les intervenants sont des généralistes et progressent dans tous les domaines technologiques.

Par expérience :

• L’approche horizontale :
  • ralonge les temps de développements (à cause des problèmes d’intégrations)^[2]
  • réduit les retours lors de la recette (grâce aux contrôles des n développeurs travaillant sur le même use case et qui confrontent leur avis)
  • le planning est plus difficile à organiser et maintenir à cause des dépendances (avec la pyramide des composants, il faut être capable d’ordonnancer correctement les développements) à moins de faire de l’IoC (par exemple avec Spring)
  • risque d’ennui des développeurs s’ils sont toujours sur la même couche logicielle
• L’approche verticale :
  • optimise les temps de développements
  • les développeurs ont une vue d’ensemble du service
  • la plannification est beaucoup plus simple (grâce au découpage par use case)
  • les développeurs progressent dans plusieurs domaines technologiques simultanément^[3]

Aucune des deux approches ne semble surpasser l’autre. Personnellement^[4], je préfère la répartition horizontale car elle permet d’obtenir une meilleure qualité des développements (d’un point de vue fonctionnel).

Et vous, comment faites-vous ? Quelle approche préférez-vous ?

Pour fournir un logiciel de qualité, il est nécessaire de produire un code source de qualité. Je vous ai déja 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 !

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 JDBC, … Ajoutez à tout celà, 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 JDBC ? Pour celà, 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égligable 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éja, et vous vous concentrez le coeur du métier.

Comment concevoir une application multilingue ? Quelle architecture mettre en place pour internationnaliser 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’internationnalisation 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.

Internationnalisation

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 colloboratifs 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 convertion 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’internationnalisation ne dépend pas seulement du texte. D’autres éléments peuvent être pris en considération lors de l’internationnalisation, 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’internationnalisation. Néanmoins, elle couvre une grande partie des cas rencontrés généralement. Le dernier travail reste de trouver des traducteurs.

Les exceptions sont très utilisées. Pourtant, il n’est pas toujours évident de savoir comment les gérer correctement.

(more…)

De plus en plus présent. Mais cet outil est-il utilisé correctement ?

(more…)

Meilleurs amis ou meilleurs ennemis ?

(more…)

Les clients lourds ont été abondonné au profit des clients légers. Très limités d’un point de vue ergonomie, ils sont voués à disparaître pour laisser la place aux clients riches.

(more…)

S’il y a bien un élément sous estimé dans les interfaces Web, c’est bien l’aide contextuelle.

(more…)