Software Design & Développement

Vaadin : la synthèse de deux mondes ?

2011-01-18T22:45:00.005+01:00

Que l'on soit éditeur de logiciels, ou responsable applicatif au sein d'une DSI, on se retrouve souvent confrontés aux mêmes problématiques. L'une d'entre elles est de faire accepter ses logiciels par leurs utilisateurs. A ce stade, l'interface graphique, son ergonomie, sa réactivité - en bref, tout ce que l'on désigne aujourd'hui sous le terme d'expérience utilisateur - joue un rôle déterminant.

Pour développer des IHM, il y a deux stratégies : les clients lourds et les clients légers.
Les clients lourds, malgré l'étiquette de technologies dépassées qui leur collent maintenant à la peau, ont encore beaucoup de qualités : richesse des composants disponibles, fluidité d'exécution, robustesse, possibilité de créer des applications MDI. Du point de vue du processus de développement également, les clients lourds ont de nombreux avantages : même langage de développement que pour la partie métier, existence d'un IDE fourni par l'éditeur, possibilité de débugger le code de la couche présentation (!!!).

Du côté des clients légers, il y a probablement moins d'avantages, mais l'un d'entre eux, essentiel, a fait leur succès dans les entreprises : l'absence de déploiement préalable à l'utilisation sur les postes clients. Par extension, ce point permet également de simplifier la maintenance de l'application pendant toute la durée de son exploitation. Souffrant de trop nombreux handicaps les clients légers laissent peu à peu la place aux clients riches. Dans la longue liste de frameworks de RIA l'un d'eux semble avoir réussi la synthèse optimale du client lourd et du client riche : il s'agit du framework Vaadin de la société IT Mill.

Vaadin est une framework de développement d'applications Internet riches fournissant des composants graphiques et des contrôles accessibles au travers d'une API particulièrement bien conçue. Mais la singularité de Vaadin réside dans son architecture, orientée serveur, ainsi que son mode de développement qui se fait à partir d'un unique langage, Java. En fait, avec Vaadin, on ne pense plus serveur web/navigateur/requête HTTP, mais on pense comme lorsque l'on développe en client lourd : on crée des composants, on les rattache à des conteneurs, on leur lie des évènements, des sources de données, et c'est le framework qui se charge de générer le code HTML/JS/CSS nécessaire (il s'appuie pour cela sur GWT), ainsi que de gérer (de manière optimale, grâce à un UIDL propriétaire) les appels Ajax permettant les échanges de données entre le serveur et le client.

Avec mes collègues, nous avons utilisé Vaadin pour réaliser le prototype d'une application de traitement et de validation de factures, avec dans l'idée de remplacer à terme une application plus ancienne développée avec une framework maison basé sur des pages JSP et quelques soupçons de jQuery ça et là.

Après quelques mois d'utilisation, mes impressions sont les suivantes :
- Pour ceux qui ont déjà réalisé des applications en client lourd (que ce soit en Swing, en C# ou en Delphi), le temps d'adaptation à la philosophie du framework est quasi nul. Lorsque l'on se surprend à débugger son code métier et son code présentation en une seule passe, on oublie vraiment que l'on est en train de générer une application web !
- Vaadin s'exécute à l'identique sur Chrome, Firefox et Internet Explorer (8). Il propose un rendu des composants au look sobre, très professionnel, assez proche de Flex, même s'il est vrai que la bibliothèque de composants est moins fournie que celle d'Adobe,
- Vaadin est beaucoup plus facile à utiliser que GWT, car il n'impose pas de séparer les classes serveur et les classes client lors du développement. De plus, Vaadin n'est pas sujet aux lenteurs de compilation propres à GWT,
- La communauté est très active, les documentations sont de qualité et les corrections de bugs sont fréquentes. Nous avons rencontré un seul bug, il s'agissait d'une fuite mémoire. Sa correction a été publiée la semaine dernière.
- La bibliothèque d'add-ons est encore mince, mais elle s'enrichit de semaine en semaine,
- La plupart des composants de Vaadin supportent le drag'n drop.
- Vaadin possède des dizaines d'autres fonctionnalités toutes plus intéressantes les unes que les autres : support de nombreux serveurs d'applications, du portail Liferay, projets Maven, intégration avec Spring, intégration de widgets GWT...

L'image ci-dessous montre un widget GWT que nous avons développé pour visualiser des factures. Il permet de zoomer et faire pivoter les images, ainsi que de naviguer parmi les différentes pages d'une facture. Une fois développé (sans avoir eu recours au HTML5), le widget GWT est compilé et intégré à l'application comme s'il s'agissait de l'un de ses composants natifs.

Malgré une relative jeunesse, ce framework ne souffre pas d'un manque de maturité. La bibliothèque de composants graphiques gagnerait certes à s'étoffer encore ; la séparation entre la vue et le contrôleur pourrait être mieux encadrée (voire encouragée) par le framework, mais en ayant réussi la synthèse du client léger et du client lourd, Vaadin a tous les atouts pour devenir un framework de référence pour le développement d'applications d'entreprise dans les années à venir...

Notifier une expiration de session utilisateur en Ajax

2010-07-07T17:36:00.002+02:00

La problématique :

Dans la plupart des applications Intranet ou Extranet, le serveur gère un délai d’inactivité pour les sessions utilisateurs. Concrètement, cela veut dire que s’il se passe un certain délai (deux heures, par exemple) pendant lequel le serveur ne reçoit aucune requête HTTP de la part du client, le serveur prend l’initiative de détruire immédiatement et définitivement la session utilisateur. Cela veut dire qu’à partir de ce moment là, les données de l’utilisateur qui étaient préalablement stockées en session ont disparu. Ce mécanisme est important pour différentes raisons :

Il permet de libérer de la mémoire devenue inutilisée sur le serveur
C’est un élément des mécaniques de sécurité, indispensables dans les applications comme le webmail ou l’accès à des comptes bancaires.

Du point de vue de l’utilisateur, l’approche n’est pas la même. En fin de matinée, Jean-Paul se connecte à notre application pour traiter un document. Puis quelques minutes plus tard, il verrouille sont poste de travail et part déjeuner avec ses collègues. A son retour, café brûlant en main, il consulte ses mails, passe un coup de téléphone, puis reprend le traitement de son document. Il saisit ses données, clique sur le bouton de validation, confirme, et là… c’est le drame ! Sa session a expiré. Il doit se reconnecter, mais surtout, il doit recommencer le traitement de son document.
Alors comment faire pour satisfaire Jean-Paul sans désactiver les sécurités présentes sur le serveur d’application ?

Une solution simple et efficace :

Voici une solution extrêmement simple et facile à mettre en œuvre :

Au chargement de la page HTML, déclencher un compte à rebours en Javascript sur le client.
Lorsque le compte à rebours se termine, faire un appel Ajax pour vérifier si la session est effectivement terminée.
Si la session a expiré, prendre l’action adéquate (i.e. rediriger l’utilisateur vers la page de connexion).

Le compte à rebours sur le client sera initialisé avec la durée du Timeout de session sur le serveur augmentée de quelques secondes par mesure de sécurité.

Mise en œuvre avec jQuery dans un environnement JSP :

Voici un exemple d’implémentation en jQuery et JSP. Ci-dessous, le code à intégrer dans les pages HTML.

A l’expiration du compte à rebours, un appel Ajax est déclenché vers la page checksession.jsp. Dans l’exemple donné ici, l’utilisateur est redirigé vers l’URL renvoyée par checksession.jsp. Voici le code de cette page :

L’idée est de tester la valeur d’un attribut de session connu que l’on sait non vide. S’il est vide, c’est que la session a expiré, et on renvoie dans la réponse HTTP la ressource vers laquelle rediriger l’utilisateur. Simple et efficace…

Améliorer le look and feel d’une application web

2010-07-07T10:21:00.006+02:00

La deuxième moitié des années 2000 a été le théâtre de bouleversements majeurs dans nos navigateurs : démocratisation de l’Ajax, Web 2.0, réseaux sociaux ou collaboratifs, wikis… Aujourd’hui, il est fréquent que les applications web que nous utilisons dans notre vie privée – GMail, Yahoo!, Facebook, Picassa, Flickr, blogs – soient plus ergonomiques que celles que nous utilisons dans notre vie professionnelle. Si les utilisateurs finaux doivent s’en accommoder (ont-ils vraiment le choix ?), cette situation n’est pas satisfaisante lorsque l’on est éditeur de logiciels ou responsable applicatif au sein d’une grande organisation. Alors que faire ?

La méthodologie :
Pour un tel projet, qui ne comprendra finalement principalement que des modifications de style et d'ergonomie, inutile d'annoncer le lancement d'une v3 de l'application! Un cycle en V semble également peu adapté, pour de nombreuses raisons :

les phases amont au développement (architecture, spécifications, conception détaillée) sont souvent produites sous forme de documentation qui seront difficiles à valider par une MOA ou un département marketing,
certaines phases en aval du développement comme les tests unitaires seront difficiles à réaliser dans ce contexte,
risque d’effet-tunnel avec des délais difficiles à maîtriser
risque de surprise des clients (département marketing, MOA, utilisateurs finaux) en cas d’écart entre ce qui a été produit et ce qui est attendu.

Pour ce genre de démarche, il faut oublier la lourdeur du cycle en V et préférer une méthode permettant de faire des livraisons fréquentes, comme une méthode itérative ou une méthode agile de type SCRUM. Les livraisons sont facilitées par l’architecture même des applications web qui nécessitent seulement un déploiement sur un serveur et permettent :

A l’équipe de développement de montrer que le travail avance régulièrement
Aux clients de s’approprier le nouveau look de l’application sans être déroutés
Aux clients de faire des retours et de soumettre leurs idées pertinentes

Une livraison toutes les 4 à 6 semaines (en fonction de la durée du projet) semble un bon rythme. Il est intéressant, si c’est possible, de formaliser les livraisons en présentant les nouveaux éléments aux clients. A chaque livraison, l’équipe de développement fera en sorte de livrer des tronçons complets pour ne pas donner l’impression de travail inachevé. Elle introduira également les retours sur la version précédente dans la mesure de ce qui a été convenu.

La stratégie :
Si l’objectif est d’améliorer l’expérience utilisateur, et de livrer quelque chose de visible tous les mois, il faut être efficace. Dans ces conditions, pas question de remplacer le vieux framework MVC maison par un standard du marché : la valeur ajoutée utilisateur est proche de zéro.
Inutile non plus de tenter une migration vers le dernier framework de développement RIA, genre GWT ou Flex. Cela ne serait pas compatible avec la démarche définie ci-dessus… et les risques de régressions fonctionnelles sont énormes, surtout s’il existe du code métier dans les pages faisant le rendu HTML, ce qui est fréquent !

Une stratégie à la fois raisonnable et efficace est de transformer progressivement l’application en remplaçant certains éléments existants, ou bien en ajoutant de nouveaux éléments. Pour cela, il faut choisir une librairie Javascript suffisamment riche pour :

Proposer nativement des éléments graphiques comme des fenêtres modales, des datepickers, des accordéons, onglets, etc.
Manipuler dynamiquement les éléments du document au travers de sélecteurs
Mettre en place facilement des appels AJAX
Permettre la création de plugins (pour pouvoir en réutiliser !).

La bibliothèque jQuery est particulièrement adaptée pour ce type de réalisation, car elle a un excellent équilibre entre sa valeur ajoutée intrinsèque et son niveau d’intrusion lorsqu’elle est insérée dans une application existante. Il faut dire qu’avec seulement quelques fichiers .js et .css à inclure (si l’on adjoint jQuery UI), il est difficile de faire moins intrusif ! De plus la clarté de sa documentation et la quantité de blogs de développeurs s’y référant rendent sa mise en œuvre rapide.

La mise en œuvre :
Voici quelques idées de transformations simples qui ont un impact immédiat :

Remplacement d’anciens calendriers s’ouvrant dans une fenêtre popup (utilisation du composant datepicker de jQuery)
Utilisation de tables triables et paginées dès que le nombre d’éléments à afficher dépasse quelques dizaines. Utilisation de cookies pour enregistrer ordres les tris et les choix de pagination
Utilisation du drag and drop pour sélectionner quelques éléments parmi une liste
Création d’un espace dans lequel l’utilisateur peut personnaliser l’application : choix d’un thème, des options de l’application,
Ajout d’un composant affichant en temps réel la complexité du mot de passe utilisateur lorsqu’il est modifié
Suppression des fenêtres popups qui compliquent la navigation (utilisation du composant dialog de jQuery)
Utilisation d’appels AJAX lorsqu’il faut mettre à jour une très faible quantité d’informations sur une page. Dans ce cas, retourner soit des chaînes de caractères pour du texte, soit un objet JSON pour des tableaux ou des objets structurés.
Restructurer les pages trop denses soit en les découpant, soit en utilisant des composants comme les onglets ou les accordéons
Dans les formulaires, ramener les contrôles de format sur le client : taille maximale, formats numériques, monétaires, codes postaux, etc. Cela évitera des rechargements de pages en cas d’erreurs de saisie
Valider que la navigation au clavier est opérationnelle dans tous les formulaires de saisie,
Dans les formulaires encore, ajout d’aides à la saisie, comme le format attendu d’une date, d’un n° de téléphone, ou encore le nombre de caractères restant lors d’une saisie dans une textarea.
Lors d’une erreur de saisie dans un formulaire, indiquer clairement dans quel champ se situe l’erreur, et quelle est la nature de l’erreur. Mettre bien évidemment le focus sur ce champ.

Lors de la mise en œuvre, le responsable des développements devra garder en tête que ce sont les petits ruisseaux qui font les grands fleuves…

5 clés pour intégrer des composants existants à une application SaaS

2010-06-22T08:54:00.003+02:00

Depuis plusieurs années maintenant, des éditeurs et des prestataires se lancent dans le SaaS pour compléter leurs gammes de services et de logiciels traditionnels. Cependant, pour réduire les coûts de développements et les délais de mise de sur le marché, la tentation est grande de réutiliser des composants existants en les intégrant au sein d’une plate-forme SaaS. Il peut s’agir de composants purement techniques (téléchargements, conversions d’images ou de documents bureautiques), de services métier à forte valeur ajoutée comme la LAD (lecture automatique de documents) ou encore de requêtes vers de services tiers.

Un schéma simple et efficace est de connecter à l’application SaaS des composants métiers ou techniques qui remplissent une ou plusieurs fonctions précises. Chacun de ces composants communique directement avec l’application principale par des files de messages ou des services web.
Lors de la mise en œuvre, il faut être particulièrement vigilent, car le monde du SaaS a des exigences très spécifiques. Voici un petit tour d’horizon des contraintes à connaître et des pièges à éviter :

Haute disponibilité :
L’objectif de disponibilité des applications SaaS est le 100%. Lors de l’intégration d’un composant existant à une architecture SaaS, il faudra donc définir une stratégie prenant en compte la gestion des pannes de ce composant, de ses montées de versions. De même si ce composant repose lui-même sur un composant tiers (i.e. une base de données), il faudra prendre en compte les indisponibilités (planifiées ou non) de ce sous-composant.
Dans tous les cas, l’application principale ne devra jamais se retrouvée bloquée.

Scalabilité :
La scalabilité peut être définie comme la capacité d’un système à étendre (ou réduire) facilement ses ressources à mesure que la charge augmente (ou diminue). Si une application SaaS est bien conçue, sa capacité de traitement évolue linéairement avec la quantité de processeurs/RAM qui lui est allouée.
Malheureusement, certaines applications ne sont pas capables de tirer correctement partie d’une architecture multiprocesseur. Dans ce cas, il faudra déployer l’application sur plusieurs machines (éventuellement virtuelles) et mettre en place un mécanisme de répartition de charge (load-balancing). Cela peut engendrer des coûts d’exploitation supplémentaires, ainsi que des délais de mise à disposition importants de ces nouvelles machines selon l’hébergeur.

Temps de réponse :
Dans le monde du web, l’utilisateur déteste attendre… et il a raison ! Quelques secondes, ou au plus quelques dizaines de secondes si une barre de progression est là pour le distraire. La maîtrise des temps de réponse est donc primordiale, pour gagner de nouveaux clients, mais surtout pour satisfaire et conserver ses clients actuels.
S’il y a des doutes sur la capacité d’un composant à s’exécuter dans un délai prévisible et raisonnable, il vaut mieux prendre ses précautions : on pourra lancer le service de manière asynchrone pour rendre la main immédiatement à l’utilisateur, puis dans un second temps le notifier du succès de l’opération.
On peut aussi déclencher au lancement du service un compte à rebours : si ce dernier se termine avant l’arrivé des résultats attendus, on pourra lui présenter des résultats partiels et éventuellement lui proposer de poursuivre la recherche pour obtenir de nouveaux résultats.

Exploitation :
Une fois que la plate-forme de production est installée chez l’hébergeur, pas question de se connecter tous les matins pour prendre la température des applications. Nos petits composants sont lâchés dans la nature, comme des skippers au milieu de l’océan. Il est donc primordial qu’ils soient capables de communiquer eux-mêmes en indiquant périodiquement leur état, en indiquant leurs défaillances dès qu’elles surviennent, ainsi qu’en prenant des mesures pertinentes dans leur environnement : espace disque, accès aux ressources externes, consommation de licences, etc. Les modes de communication peuvent être variés, voire même combinés : emails, alertes vers un outil de supervision de plates-formes (Patrol, $Universe), portail de supervision métier accessible en client léger, etc.

Documentation :
D’une manière générale, on documente pour éviter que les seules personnes capables de faire fonctionner un logiciel soient ceux qui l’ont développé ! Ceci prend tout son sens dans le monde du SaaS où il est fréquent que les équipes d’exploitation soient localisées dans des pays émergents et avec lesquelles la communication se fait obligatoirement en anglais. L’anglais entre non anglophones… quel bonheur !
Il est également important de garder à l’esprit que les exploitants n’ont aucune idée de ce que fait notre application. Les documents d’installation devront donc être le plus clair possible, et prévoir des procédures de vérification permettant à minima de s’assurer que l’application est bien opérationnelle à la fin de l’installation !

Bien nommer les classes et les méthodes d’une API

2010-06-04T17:47:00.023+02:00

Pour les classes, cela DOIT être facile...

Nommer une classe est normalement simple : il suffit de choisir un terme suffisamment général et décrivant le mieux la notion gérée par cette classe. Si la classe est bien conçue, et qu’elle respecte le principe de responsabilité unique, la nommer ne devrait pas présenter de difficultés.
Si lui trouver un petit nom s’avère difficile, ou qu’aucun nom ne paraît raisonnablement satisfaisant, il est probable que cette classe fasse trop de choses. Il n’y a alors qu’une seule chose à faire : la tronçonner ! Une autre astuce est de s’imposer de commenter la classe en une seule phrase. Si cette phrase est impossible à écrire, ou si elle n’a rien à voir avec le nom choisi, il faut changer le nom, ou bien découper la classe.

... c’est pour les méthodes que ça se complique !

Nommer correctement les méthodes publiques d’une classe a son importance. Récemment, j’ai dû enrichir les API d’un de nos logiciels. Celles-ci sont destinées à des développeurs tiers qui éventuellement ne font pas partie de notre société. Pas question donc de laisser des ambigüités ou des incohérences. Et lorsque on est en présence d’un package contenant des dizaines de classes, et que chacune d’entre elles comprend une ou plusieurs dizaines de méthodes, on se retrouve donc à fournir plusieurs centaines de méthodes, et quelques règles s’imposent :

Utiliser l’anglais : ne connaissant pas à priori quelle sera la nationalité des développeurs qui utiliseront l’API, il faut s’imposer la langue internationale de l’informatique : l’anglais.

Débuter les noms par un verbe indiquant aussi précisément que possible le type d’action réalisée :
countUsers() : compte le nombre d’utilisateurs
isExpired() : indique si le compte-utilisateur est expiré

Combiner des mots entiers jusqu’à décrire l’action réalisée par la méthode.
getExpirationDate() : retourne la date d’expiration
notifyAllClients() : notifie tous les clients

Eviter les informations inutiles : éviter de faire porter au nom de la méthode une information non indispensable, ou bien disponible ailleurs.
Ex : si une méthode renvoie tous les employés d’un service, et qu’elle s’applique soit sur un objet Service, soit qu’elle prend un objet Service en paramètre, il est inutile de l’appeler getEmployeesByService ; getEmployees est suffisant.

Ne pas pas utiliser le mot « And » : si le recours au mot « And » est requis, c’est que la méthode à nommer réalise plusieurs actions. Dans ce cas, il faut la tronçonner. En effet, le principe de responsabilité unique s’applique à tous les niveaux, y compris au niveau d’une méthode.

Conserver la même logique dans toute l’API : ce qui est important, ce n’est pas de se faire des nœuds au cerveau pour savoir si une méthode qui met à jour un objet métier doit commencer par update ou modify. En revanche, ce qui est important, c’est de faire un choix, et de l'appliquer à travers toute l'API.

Bien-sûr, ces quelques règles ne font pas le travail à la place des développeurs, et elles peuvent être complétées. Mais les respecter m’a permis de produire une API cohérente ce qui au final facilite le travail des utilisateurs.

Comment assurer la non régression fonctionnelle lors d’une migration technique ?

2010-02-08T23:09:00.016+01:00

Fini le weekend, les soirées arrosées, les grasses matinées, et les fantasmes futuristes que l’inventeur de SixthSence a fait naître dans ma tête. De retour à la réalité du lundi matin, et au projet qui m’attend : organiser le redéveloppement d’un de nos logiciels écrit en Java/JSP vers une architecture ou la partie serveur sera en J2EE (Hibernate, Spring, etc.) et la partie cliente en technologie Adobe Flex.

Pour rendre le projet plus intéressant, ajoutons que nous n’avons ni spécification fonctionnelle, ni documentation utilisateur, que les plans de tests sont pauvres, qu’il n’existe aucun script de test automatique, et qu’accessoirement, je suis loin d’être un expert du monde Java et je découvre le Flex ! La première pensée qui me vient à l’esprit est… vivement vendredi soir !

A vrai dire, les aspects techniques ne me font pas vraiment peur. L’équipe de développement tient la route, et elle produira les tests unitaires ! Ce qui me cause souci, c’est la qualification fonctionnelle et les risques de régressions. Comment les éviter ?

La matrice de compatibilité va me dicter une partie de la réponse. Notre logiciel doit pouvoir tourner sur 3 SGBD, 3 serveurs d’applications, Windows, Linux, et le plus grand nombre possible de navigateurs Internet. Bien entendu, j’échapperai à certaines combinaisons, genre SQL Server sous RedHat :-), mais tout de même, cela fait quelques dizaines de possibilités à explorer. Dans ces conditions, il n’y a qu’un seul moyen d’être exhaustif, c’est de passer par des outils d’automatisation des tests.

Concernant la qualification fonctionnelle, tout reste encore à construire. Comme je l’ai dit précédemment, l’application historique n’est pas accompagnée de spécifications fonctionnelles qui soient utilisables. Une option pourrait être d’entamer une phase de rétro-ingénierie visant à produire des spécifications, puis à implémenter selon ces spécifications et enfin à tester pour vérifier la conformité des développements. Mais avec ce système, toute erreur introduite durant la tâche rétro-ingénierie se transforme en régression dans l’application finale. Pire encore, les bugs de l’application historique seraient transposés dans l’application cible ! Ce n’est donc pas satisfaisant.

Pourtant, ce que je veux faire est simple : il faut que la même utilisation produise le même résultat dans les deux applications. Et si pour une fois la solution était aussi simple ? Produire des scénarii de tests, les dérouler sur les deux applications, et comparer les résultats : s’ils sont identiques, tout va bien ; s’ils sont différents, alors il faut regarder pour comprendre de quel côté est le bug, et corriger si besoin.

Il ne me reste plus qu’à me mettre en quête des outils adaptés, mais ça attendra demain!

Le futur a déjà commencé

2010-02-06T13:14:00.016+01:00

Pranav Mistry est l'inventeur de SixthSense, un équipement qui permet des interactions entre le monde des données et le monde réel. Sa vidéo de présentation est tellement époustouflante que j'ai du la regarder 3 fois de suite.
Avec des tels génies, on peut se dire que le futur a déjà commencé, et c'est tant mieux !

Le mécanisme de réflexion – partie 2

2009-12-18T00:10:00.026+01:00

Une extension du design pattern Strategy grâce au mécanisme de réflexion en .NET

Le contexte
Dans la société où je travaille, nous avons développé récemment un module d’acquisition de documents EDI. Ce module doit rematérialiser le document (générer une image à partir du contenu du fichier), puis l’injecter dans une chaîne de traitement métier pour analyse et export vers des systèmes informatiques cibles, genre ERP ou GED. Les documents traités sont des factures.
Un des principaux problèmes liés à l’EDI est la multiplicité des formats existant : EDIFACT, ANSI X12 pour les plus connus, mais surtout les formats non standards mais déjà abondamment utilisés dans des cadres de partenariats de dématérialisation, notamment dans le monde de la grande distribution. Le module doit donc pouvoir s’adapter facilement à un nouveau format EDI que nous découvririons lors de la mise en œuvre chez un client.

Dans les grandes lignes, le module est composé des trois fonctions suivantes :
1. Lecture du fichier EDI source
2. Rematérialisation du document
3. Injection dans la chaîne de traitement métier.

Solution 1
Nous optons pour le design pattern Strategy pour implémenter la lecture du fichier EDI source. La célèbre interface « Strategy » publiera une méthode qui pourra être implémentée autant de fois que nous aurons formats à gérer. Chaque implémentation concrète de l'interface crée une représentation objet du document EDI qui sera ensuite utilisée pour la rematérialisation et l’injection dans la chaîne de traitement métier.
Donc c’est parti, on développe, on teste, on compile, on livre et on met en production !
Quelques temps plus tard, le client annonce un nouveau format à gérer. C’est facile, le pattern Strategy permet d’ajouter de quoi lire ce nouveau format sans prendre de risque avec l’existant. Donc pas de problème, on développe donc une nouvelle implémentation de l’interface « Strategy », on modifie le programme principal, puis on recompile et on livre une nouvelle version du module d’EDI et le tour est joué !
Malheureusement, le client ne l’entend pas de cette manière ! Nouvelle version du module d’EDI veut dire nouvelle exécution des plans de tests d’intégration avec son SI. Il doit mobiliser son informatique interne, ses chefs de projets fonctionnels. Les délais de mise en production vont se chiffrer en semaines, voire en mois. Qui va payer ? Vous avez beau arguer que vous avez utilisé le design pattern approprié et qu’il n’y a pas de risques, il n’y a rien à faire. La situation avec le client s’est indéniablement dégradée !

Solution 2
L’idéal serait que la prise en charge d’un nouveau format se résume à déposer un nouvel assemblage et mettre à jour un paramètre décrivant dans quelles circonstances utiliser ce nouvel assemblage. Ceci est possible grâce à la réflexion. Si chaque implémentation de l’interface Strategy est isolée dans un assemblage, il suffit de récupérer dans les paramètres l’assemblage à charger (il peut être fonction de l’émetteur du document, par exemple) et la réflexion se chargera du reste.
L’interface Strategy s’appelle ici IEdiInvoiceParser. Elle propose une méthode Parse() qui prend un flux de données en entrée et renvoie un objet métier Invoice en sortie. En voici le code en C# :

Le code ci-dessous montre comment créer une instance d’une classe à partir du nom de l’assemblage et de la classe.

Noter la puissance de l’instruction CreateInstanceAndUnWrap() qui charge dans le domaine courant l’assemblage désigné, puis crée une instance du type passé en paramètre et enfin renvoie une référence vers cette instance. Naturellement, pour que le cast fonctionne, il faut que ce type implémente l’interface IEdiInvoiceParser définie ci-dessus !
Même si l’opération tient en une seule ligne, il peut être intéressant de l’isoler dans une classe. Dans la pratique, cette classe pourra également récupérer les informations assemblyName (nom complet de l’assemblage à charger) et className (nom de la classe préfixé par le namespace) à partir d’autres informations comme la source du fichier EDI, par exemple.

L’utilisation est des plus simples et des plus rapides. Il n’y a plus qu’à laisser fonctionner le polymorphisme !

Pour conclure...
La solution 2 est meilleure car elle allie vitesse d’exécution (grâce au polymorphisme) et découplage (grâce à la réflexion).

Une de ses limites est que les assemblages contenant les stratégies de lecture ne peuvent pas être déchargés car ils sont chargés dans le domaine courant de l’application. Cela pourrait donc poser des problèmes de consommation mémoire si on utilise cette technique pour implémenter un système de plugin. Dans ce cas, il sera préférable de charger l’assemblage dans un autre domaine, qui lui pourra être déchargé à la demande.

Le mécanisme de réflexion – partie 1

2009-12-08T23:18:00.026+01:00

En naviguant sur les forums de développement, il est assez fréquent de trouver une question relative à la réflexion, ou bien un intervenant qui propose d’utiliser la réflexion comme solution à un problème. Les exemples ci-dessous sont donnés dans l’environnement .NET, mais la mécanique est très proche en Java.

Quelles sont les possibilités offertes par ce mécanisme ?

Le mécanisme de réflexion offre un très large spectre de possibilités : chargement dynamique d’assemblages, exploration dynamique des types d’un assemblage, création d’instances de classes, déclenchement de méthodes, compilation de code à la volée, etc.

Quels sont les problèmes liés à son utilisation ?

Le mécanisme de réflexion présente certes des avantages, mais il a aussi des inconvénients qu’il est important de maîtriser :

Les performances : le déclenchement d’une méthode par l’intermédiaire de la réflexion (instruction Invoke) est beaucoup plus lent que son appel direct. Il est cependant possible d’optimiser ce chargement en utilisant des Interfaces.
La conception : La réflexion offrant un moyen d’accéder à chaque membre de chaque classe de chaque assemblage, elle peut occulter la nécessité d’une conception rigoureuse et l’utilisation de Design Patterns. Par exemple, la réflexion permet de connaître le type d’une classe dérivée depuis du code situé dans sa classe mère (c’est un peu tordu, mais c’est possible). Ce genre d’utilisation viole le principe LSP (Liskov Substitution Principle) et suggère un design médiocre qui sera tôt ou tard difficile à maintenir.
La clarté du code : la lisibilité du code source est très nettement dégradée. Ce critère n’est pas seulement subjectif et peut à terme être source de bugs et de régressions lors de la maintenance du logiciel.
L’obfuscation : elle empêche le chargement dynamique des classes puisque leur nom a été modifié.

Quand doit-on utiliser la réflexion ?

Compte-tenu de ses inconvénients, l’utilisation de la réflexion devrait être réservée au seul usage suivant : la manipulation par un assemblage A d’autres assemblages qui n’étaient pas connus au moment de la compilation de A. Dans la pratique, on trouvera 3 grandes familles d’applications :

L’exploration d’assemblages à l’exécution : les outils ildasm.exe, fxcop.exe ou encore .NET Reflector utilisent massivement la réflexion pour explorer les assemblages. Visual Studio l’utilise également dans son explorateur d’objets ou lors de la complétion de code.
Le chargement dynamique d’assemblages (late binding) : un assemblage A peut utiliser la réflexion pour charger explicitement un autre assemblage B si B n’était pas connu lors de la compilation de A. Cela permet par exemple de construire des mécanismes de plugins.
Compilation de code à la volée : Dans certains cas, on souhaitera compiler et exécuter dynamiquement du code. Cela peut être utile pour évaluer des expressions mathématiques qui sont fournies à l’exécution. Le temps perdu lors de la construction et la première compilation de l’assemblage est compensé par la vitesse des exécutions suivantes.

Un prochain article présentera une utilisation du chargement dynamique d’assemblages sans dégradation notable des performances.

Les 7 familles de bugs

2009-11-30T22:19:00.017+01:00

Ca-y-est, c’est la panique ! Le client est bloqué et menace de rompre le contrat si les problèmes ne sont pas résolus avant la fin de la semaine. Le directeur informe alors le responsable qui convoque le chef de projet (ou de produit) pour qu’il réquisitionne immédiatement ses développeurs afin de corriger les bugs au plus vite.

Déjà-vu ? Sans blague ! Et oui, encore une fois, les développeurs vont se mettre à l’œuvre, modifier quelques lignes de code qui seront livrées au client pour le débloquer. Et au final, que retiendra-t-on de cet évènement ? Qu’il restait un bug dans le code.

Alors c’est ça la fin de l’histoire ? Les départements informatiques, les équipes projets et les R&D grouillent de gens plus expérimentés, plus respectés, et mieux payés que les développeurs, mais au final, le bug et sa résolution resteraient le fait du développeur ?
Eh bien non ! C’est faux. Ils ne sont pas les seuls à faire des bugs. En voici pour preuve les 7 familles dans lesquelles il est possible de classer la quasi-totalité des bugs :

1. Le bug du débutant : il s’agit le plus souvent d’une mauvaise gestion des cas limites dans l’implémentation des algorithmes : non vérification de la valeur des paramètres d’entrée d’une fonction, dépassements de capacité d’une pile ou d’un tableau, tentative d’accès à une ressource non disponible. Ces bugs doivent être éliminés par les tests unitaires. A noter que ces bugs peuvent également apparaître lorsque le développeur est optimiste ou trop pressé.

2. Le bug du collègue : les développeurs s’appuient parfois sur le travail d’un collègue pour ne pas avoir à redévelopper une fonction, une classe ou un composant. Si le code du collègue contient des bugs, ceux-ci seront immanquablement intégrés dans le logiciel final. Depuis quelques années, la démocratisation des frameworks Open-Source a poussé la réutilisation de code jusqu’à un niveau jamais atteint. Dans ce cas, il s’agira plutôt d’un confrère que d’un collègue.

3. Le bug du testeur : le testeur doit mettre en place un environnement reflétant les futures conditions d’utilisation du logiciel. Il doit faire en sorte que la couverture fonctionnelle qu’il adresse soit complète, que les jeux de données ou les scénarii qu’il utilise soient représentatifs et permettent de couvrir tous les chemins possibles. Il doit tester dans les conditions réelles d’utilisation : versions de SGBD, serveur d’application, OS, middleware….

4. Le bug du release manager : le release manager est responsable de la production des livrables à partir du code source. Il doit veiller à utiliser la bonne version des sources et les bonnes options de compilation. Ces opérations, peuvent être jugées triviales, mais elles sont en réalité particulièrement délicates lorsqu’il s’agit de produire des correctifs de type Hot-fix, ou lorsque le même code source est destiné à produire plusieurs versions des livrables (multi OS, 32bits/64bits).

5. Le bug de l’architecte : ses symptômes peuvent être très variées : difficultés lors de l’intégration dans l’écosystème cible, incapacité à supporter la montée en charge, impossibilité d’intégrer des évolutions fonctionnelles pourtant « raisonnables ». De plus, il apparaît souvent tard dans le cycle de vie du logiciel, parfois bien après la mise en production. C’est pourquoi il est souvent difficile à diagnostiquer. Pourtant, ses causes sont souvent les mêmes : non respect des principes de base (KISS, SOLID, etc.), choix de composants tiers non adaptés, définition d’architectures non scalables ou difficilement testables, etc.

6. Le bug du chef de projet : l’incapacité à collecter une expression du besoin complète, l’incapacité à chiffrer correctement la charge de développement, l’incapacité à négocier un planning raisonnable avec le client, l’incapacité à maîtriser les évolutions du périmètre alors que les développements sont déjà en cours sont les bugs typiques du chef de projet.

7. Le bug du directeur : certains directeurs refuseront probablement d’admettre qu’eux aussi font des bugs, mais soyons réalistes ! Le refus d’approuver l’achat d’un composant à 1 000 € qui permettrait pourtant d’éviter un développement de 50 jours à faible valeur ajoutée ou complètement en marge du projet et qui ne pourrait de toute façon pas être testé correctement est clairement une source de bugs. Idem pour le refus d’investir dans des plates-formes matérielles ou logicielles qui reflètent les conditions réelles d’utilisation du logiciel.

Bref, pour résumer, les débutants font des bugs de débutant, les développeurs expérimentés ne font plus de bugs, et tous les autres bugs sont produits par des intervenants non développeurs ! Et pourquoi pas ?

Eh bien non ? Ca aussi c’est faux ! Et disons-nous le une bonne fois pour toutes, du débutant au directeur, tout le monde fait des bugs ! Et ce n’est pas parce qu’un développeur peut bricoler en quelques heures une parade à une anomalie bloquante que c’est lui qui était à l’origine du bug.

La vague de Google est un raz-de-marée !

2009-11-23T22:40:00.016+01:00

Hier, Google nous a conquis en ouvrant des chantiers qu’aucun autre acteur n’avait osé ouvrir auparavant, en tous cas pas dans des proportions équivalentes. Certaines des applications qui en ont résulté sont devenues incontournables, en allant la plupart du temps bien au-delà de ce que l’on pouvait imaginer :

Qui pensait qu’il serait possible d’indexer la quasi totalité du web mondial et de ses images ? Google l'a fait ;
A une époque où le SaaS se résumait souvent à des White Papers, qui avait réellement besoin d'une suite bureautique complète en mode hébergé ? Google a fait Google Docs ;
Qui avaient réellement besoin de pouvoir naviguer sur un planisphère et de zoomer au point de pouvoir compter le nombre de piscines dans sa rue ? Google a fait Google Maps,
Nous rêvions tous d’un client de mail léger, simple et rapide. Google a fait LE client de mail ultime : GMail.

Aujourd’hui, Google nous livre au travers de ses Vagues une vision des communications révolutionnaire où le mail, la messagerie instantanée, le forum, le réseau social, la suite bureautique et le wiki se combinent avec une intuitivité hors norme, et bien-sûr, dans notre navigateur !
Lars RASMUSSEN – le père de Google Maps – présente ses Vagues avec passion et beaucoup d’humour dans une très looooongue vidéo. De prime abord, son accent australo-écossais est déroutant, mais on s’y habitue rapidement.

« Google redéfinit la relation entre l’utilisateur et le logiciel. »

Au-delà des robots, gadgets et autres extensions que la communauté des développeurs a déjà commencé à apprivoiser (voir mon premier robot), c’est toute une philosophie que Google nous propose et qui dessinera certainement le contour des logiciels de demain :
La relation entre utilisateur et logiciel est redéfinie : ce n’est plus l’utilisateur qui interroge son application, mais c’est cette dernière qui diffuse l’information pertinente dès quelle est disponible.
L’information devient indépendante de sa forme et de son support. Il est possible d’intégrer indifféremment du texte, des images, des tableaux, des éléments de conversation, des gadgets (éventuellement connectés au Web) au même document. Le concept vieux de 25 ans de cette suite bureautique où un programme ne sait manipuler qu’un seul type de donnée est obsolète.
Les flux d’entreprise seront simplifiés : à quoi bon continuer à modéliser la circulation des documents entre différents contributeurs dès lors que ceux-ci peuvent effectuer à volonté des mises à jour chirurgicales qui seront historisées et instantanément répercutées vers tous ceux qui ont accès au document ?

« Une vague et quelques robots pourraient à eux seuls remplacer un ESB ! »

L’implémentation dans les applications métiers du Google Wave Federation Protocol permettra à terme de dépasser le cloisonnement existant aujourd’hui entre les applications d’entreprise : le vieux schéma où un collaborateur utilise sa messagerie ou des fichiers d’échange pour exporter des informations d’une application à l’autre va disparaître. Une vague et quelques robots pourraient à eux seuls remplacer un ESB !

« L’Entreprise 2.0 a trouvé son framework ! »

Enfin, l’utilisateur d’applications métiers ne sera plus isolé ; il sera désormais membre de communautés métiers, verticales ou transversales. Il ne subira plus son environnement, mais en sera l’acteur principal. Les applications seront moins rigides ; elles seront connectées entre elles. L’Entreprise 2.0 a trouvé son framework !

Google a une fois de plus fait un pas de géant et bouscule au passage des habitudes et des standards vieux de 30 ans. Et c'est le quotidien des développeurs d’applications qui promet d’être plus passionnant encore !

Oui au wiki !

2009-11-17T13:33:00.020+01:00

Voici comment j'ai proposé au manager de mon équipe d'utiliser d'un Wiki:

L’équipe de développement dans laquelle je travaille comporte une dizaine de personnes : un consultant Oracle, des fonctionnels SAP, des développeurs ABAP et des spécialistes du développement traditionnel dont je fais partie.

Nous ouvrons en ce moment même un chantier de développement qui durera un an au moins et dont l’objectif est de livrer une version majeure de notre gamme de logiciels :

Unification des accès à tous les applicatifs à travers un portail d’accès unique,
Rationalisation de tous les flux de communication inter-applications (notamment avec SAP et Oracle eBusiness Suite),
Création d’un framework permettant de plugger des « Business Solutions » orientées circulation de documents (factures, demandes d’achat).

L'ampleur de la tâche qui nous attend est immense !

Lors des réunions communes de cadrage qui ont eu lieu l’été dernier, je me suis souvent rendu compte du décalage culturel qui existait entre tous les membres de notre équipe. SAP est un domaine tellement vaste qu’à ma connaissance, aucun consultant n’en a fait le tour. Personnellement je n’y connais rien du tout, et jusqu’à présent j’ai très bien vécu ainsi. Mais j’ai également été surpris de voir que certains programmeurs ABAP ne connaissaient rien ou presque de ce qui fait mon quotidien : XML, HTTP, Service Web, .NET, Java… Tout ceci était du chinois ! Eh bien ces personnes et moi allons devoir collaborer étroitement.

De plus, qui a déjà essayé de faire valider par mail un compte-rendu de réunion à 10 personnes sait que cela relève de la prouesse visuelle.

Tes remarques, c’était celles en mauve ?

- Non ! moi, c’était les violettes ?

Daltoniens s’abstenir !

Le mode révision de Word montre également bien vite ses limites, dès que l’on commence à modifier des schémas, ou lorsqu’il faut intégrer les modifications de 3 collègues en même temps.

Je suis convaincu que le succès des projets ambitieux repose sur des critères autres que techniques.

La communication, la collaboration, la documentation, l’implication, la visibilité sont les clés de la réussite. J’ai donc cherché à proposer une organisation qui mettrait ces notions au centre de notre vie de tous les jours, et j’ai identifié l’outil pour ça : un wiki.

Après quelques recherches, j’ai donc téléchargé et installé sur un de nos serveurs Foswiki qui présente l’avantage d’être open-source, gratuit, et bien adapté au travail en entreprise avec la possibilité d’authentifier les utilisateurs et de contrôler finement les accès. Après environ 2 jours de paramétrages, j’ai fait une démo hier au manager de notre équipe qui a immédiatement été convaincu par la pertinence de cette solution.

Nous allons présenter cet outil aux autres membres de l’équipe cet après-midi. A suivre…