Christophe Le Bot

Simile (Semantic Interoperability of Metadata and Information in unLike Environments), initié par le MIT (Massachusetts Institute of Technology), développe des outils open source robustes et efficaces pour manipuler des données, le tout reposant sur les technologies du web sémantique.

Parmi ces outils, le framework Exhibit est l’un des plus démonstratifs. Il offre une interface riche pour trier, filtrer et consulter des données complexes, via une page web. Sa classification à facettes rend la sélection et la consultation de données très rapides.

Seul petit défaut : Exhibit ne parle actuellement que l’anglais, l’espagnol et le suédois. Pas pour longtemps puisque je viens de terminer la french version ! Elle sera intégrée dans la version stable (v.1.0) et la version 2.0 (bientôt disponible).

Pour valider ce travail, je fais appel à votre bonne volonté afin de tester quelques exemples et me remonter les erreurs et bogues que vous pourriez y trouver (via les commentaires). Une fois corrigée, la version française sera mise à disposition de tous sur le serveur de Simile.

Pour le moment, les exemples reprennent ceux du site officiel. Je n’ai pas traduit les fichiers de données puisqu’ils ne font pas partie d’Exhibit. Par contre, les éléments d’interface (actions, sélections, tris, filtres, copies, messages, aide…) devraient tous être en français. J’ajouterai sans doute un exemple utilisant toutes les options d’Exhibit avec un fichier de données en français. Ce sera plus simple !

Si vous avez déjà mis en place Exhibit sur vos sites, vous pouvez également tester la version française en modifiant (temporairement, bien sûr) le lien de la version Exhibit officielle :

<script src="http://static.simile.mit.edu/exhibit/api/exhibit-api.js?views=timeline" type="text/javascript"></script>

doit être remplacé par

<script src="http://demo.christophelebot.fr/simile-exhibit-fr/api/exhibit-api.js?views=timeline&bundle=false" type="text/javascript"></script>

Votre lien peut ne pas comporter de paramètre views. Par contre, il ne faut pas oublier le paramètre bundle (utile pour ce test seulement) qui permettra de basculer en français. Petit détail, votre navigateur doit être configuré pour afficher en priorité les contenus en français.

Liste des exemples à tester

• Prix Nobel
• Personnages de céréales
• Présidents des Etats-Unis
• CSAIL

Merci d’avance pour votre participation à ce test !

Cela fait un certain temps que je suis avec beaucoup d’intérêt les travaux du MIT (Massachusetts Institute of Technology) autour de Simile (Semantic Interoperability of Metadata and Information in unLike Environments). Ses intervenants défrichent le terrain du web sémantique avec beaucoup de talent et sans oublier de passer de la théorie à la pratique.

Le projet le plus connu est sans doute Timeline qui se veut le « Google Maps du temps ». J’avoue que le résultat est plutôt à la hauteur de la comparaison, d’autant que l’intégration de Timeline dans un site web est triviale !

Par contre, je suis un peu moins enthousiaste avec Exhibit. Ce framework permet de publier des données structurées et de les manipuler dans une interface web avec une déconcertante facilité. Le concept est génial mais je trouve certains choix techniques très discutables.

Pourquoi avoir créé des attributs HTML spécifiques à Exhibit ? Par exemple, pour réaliser un filtre à facettes, il faut écrire le code suivant :

<div id="exhibit-browse-panel" ex:facets=".discipline, .relationship, .shared, .deceased"></div>

Résultat, le code source n’est pas conforme et la page n’est pas accessible (au sens ergonomique). Des inconvénients qui vont à l’encontre du web sémantique ! Pourquoi ne pas avoir développé une syntaxe particulière pour les valeurs des attributs HTML officiels ? C’est le principe de diffusion adopté par les microformats.

Quant aux données, elles proviennent d’un objet Javascript (plus précisément d’un objet JSON). Adopter JSON est une excellente idée… sauf pour le référencement de la page web. En effet, pour un robot d’indexation, une page Exhibit est vide ! Il y a bien quelques pistes pour résoudre le problème, mais je suis loin d’être convaincu. Il me semblerait plus judicieux d’intégrer les données par défaut dans le code source HTML et de les manipuler via des méthodes non intrusives (unobstrusive Javascript) par le DOM du navigateur.

Et de votre côté, utilisez-vous Exhibit dans vos projets ? Avez-vous trouvé des réponses à ces contraintes ?

Exhibit a un tel potentiel que je ne voudrais pas être bloqué par ces deux défauts majeurs. Surtout qu’un autre projet va en décupler l’intérêt : Potluck (merci Christian pour cette découverte !).

Le Zend Framework passe en RC1 (release candidate 1). C’est donc la dernière étape avant sa sortie officielle prévue cet été (peut-être fin juin, disent certains).

Son arrivée dans l’arène bien encombrée des frameworks PHP a déclenché des débats passionnés, avec des clans résolument contre (« ce n’est pas un framework ! ») et des clans qui ne jurent que par lui (« il est soutenu par Zend et IBM autour du langage le plus populaire du web ! »). Je ne parle même pas des allergiques au PHP qui trouvent stupide de construire un framework autour d’un langage aussi immature…

Bref, chacun se fera son avis. Pour ma part, je trouve le projet très pertinent.

C’est vrai que Zend Framework n’est pas aussi complet que Symfony (un très beau projet, je vous conseille de l’étudier !). On peut effectivement le voir comme une bibliothèque d’objets respectant les principes classiques de l’architecture MVC (Modèle Vue Contrôleur). Dans ce cas, je pourrais aussi bien dire que prototype n’est pas un framework Javascript mais une collection de classes. C’est étrange, mais personne n’y songe…

On peut aussi se demander pourquoi ce framework n’est pas intégré directement dans PHP, suivi d’un bon ménage pour éliminer une myriade de fonctions inutiles. En cela, PHP est plus proche de Perl (36 façons de faire une chose) que de Python (1 seule façon de faire un chose). Mais il est difficile de mettre une croix sur ce qui a fait le succès de PHP : sa facilité de prise en main et son approche procédurale. PHP atteindra difficilement la beauté théorique d’une usine à gaz Java ou l’efficacité pragmatique d’un projet Ruby, mais il est partout.

Donc, considérons que le Zend Framework est un framework PHP léger. Quels sont ses avantages ? Pour moi, ils dépassent clairement le cadre purement technique, ce qui en fait déjà une solution incontournable :

• Il a été créé à l’initiative de Zend, the PHP company (comme elle le dit si bien), pour des applications professionnelles lourdes.
• Il est soutenu par des acteurs puissants (IBM en tête) qui garantissent sa pérennité.
• Il utilise le langage le plus répandu sur les serveurs web.
• Il repose sur les avancées majeures en programmation objet de la version 5 de PHP (il était temps…).
• Il fonctionne par simple inclusion, donc sur toutes les offres d’hébergement existantes (serveurs mutualisés, notamment).
• Il donne enfin un cadre de travail aux développeurs PHP (réputés comme les cancres de la programmation).
• Comme tout framework, il réduit le temps de développement par la mise en facteur des bonnes pratiques et une meilleure définition de l’architecture.
• Il offre une documentation complète, à jour et claire, un atout essentiel pour son adoption en entreprise.
• Il bénéficie de l’élan autour d’Eclipse, grâce au développement parallèle de PDT (PHP Development Tools).

Cette orientation très professionnelle, tout en gardant la simplicité de PHP grâce à un framework léger, devrait décider un bon nombre de développeurs et d’architectes à considérer ce choix.

L’avenir me dira si j’ai vu juste…

L’Association française des utilisateurs de PHP (AFUP) organise le 14 mai 2007 une soirée spéciale PHP pour l’entreprise. Andi Gutmans (co-architecte de PHP et co-fondateur de Zend) sera présent pour faire le point sur les évolutions d’un des langages les plus utilisés dans les applications web. Ce sera surtout l’occasion de montrer les atouts du Zend Framework dont la version 1.0 est attendue en septembre 2007.

La soirée est gratuite, mais l’inscription obligatoire.

» Voir le communiqué de presse

Canonical, éditeur des solutions Ubuntu, nous propose Launchpad (version 1.0 beta), un service dédié aux développeurs open source, similaire à SourceForge.

Après une visite rapide, cet outil me laisse une impression très positive. Tout a été pensé pour faciliter le travail quotidien des développeurs et les fonctionnalités sont riches (code repositories, gestion de versions via CVS et Subversion, bugs tracker, support, gestion des traductions, etc.).

Hormis les produits développés par Canonical, Launchpad héberge quelques projets essentiels, comme Zope ou Creative Commons. J’y mettrai peut-être aussi les projets que j’ai dans mes cartons…

Il n’y a qu’un truc que je n’ai pas trouvé : la liste des projets hébergés. Cette fonction m’est très utile dans SourceForge pour suivre l’actualité des projets open source et trouver des perles rares.
Mise à jour : si, si, on peut avoir la liste de tous les projets. Merci Christian pour ton oeil de lynx !

En attendant que s’impose un langage web qui réconcilie les développeurs, les marketeurs et les visiteurs (à mon avis, on en est très loin…), on est bien obligé de faire avec le HTML. Donc d’accepter un joyeux mélange dans le code d’une page web : contenu textuel et visuel, méta-données, informations de mise en page et de styles, appels à des comportements interactifs, paramètres d’objets externes, etc. Même avec la meilleure volonté du monde (par exemple, un site « 100% XHTML, 100% accessible, 100% CSS2″), il est impossible de séparer totalement le contenu, sa présentation et son comportement.

Après avoir critiqué cette situation absurde, Ben Dolan nous propose une solution simple et astucieuse pour la partie interaction, grâce à son script Behaviour. Son objectif : éliminer tous les appels aux comportements Javascript dans le code HTML et les déclencher grâce au DOM et aux sélecteurs CSS.

Une idée toute bête, encore fallait-il y penser. Du coup, toutes les interactions peuvent être modifiées sans toucher au code HTML. Du pur bonheur !

Alors que je suis en pleine période des acronymes de quatre lettres (CRUD et UDOD), je découvre ce matin un bon résumé d’ACID sur Le Journal du Net.

J’ajouterais à l’article de Xavier Borderie que ces quatre attributs d’une transaction de données (Atomicity, Consistency, Isolation, Durability) ne se limitent pas aux bases de données. Ils sont utiles dans bien d’autres contextes, comme par exemple la gestion d’un annaire LDAP ou les transactions entre un repository Subversion et ses utilisateurs. Sauf à considérer qu’il s’agit là de bases de données au sens large et théorique…

Par contre, il y a un contexte où ACID mériterait d’être strictement appliqué, c’est celui des transactions entre un serveur et un navigateur web ! Nous en sommes très loin car le socle technique n’a pas été prévu pour cela. Par exemple, on ne peut toujours pas savoir quand un utilisateur quitte un site ou une application web, ce qui est gênant quand l’application web fait des opérations par étapes successives avec confirmation de l’utilisateur pour chacune d’elles. Doit-on annuler les étapes précédentes ? Si oui, sous quel délai ? De plus, laisser une session ouverte sur le serveur représente un risque de sécurité.

On peut simuler la persistance des sessions et des objets par les cookies, mais la fiabilité n’est pas au rendez-vous (sauf en dérivant le navigateur par des extensions particulières, comme des applets Java). On peut faire un semblant d’atomicité en plaçant les pages web dans un buffer avant de les servir (pour éviter une validation d’un formulaire incomplet par exemple). On peut assurer la cohérence en contrôlant rigoureusement les requêtes HTTP. On peut gérer l’isolation par l’utilisation de « sémaphores maison ». Quant à la durabilité, je ne vois pas comment l’obtenir…

Il manque donc un maillon pour simplifier le développement et gérer la robustesse des applications web : si ACID est bien présent entre le serveur web (front office) et les entrepôts de données (SGBD, annuaires, systèmes de fichiers, échanges de données…), son absence entre le navigateur et le serveur web rend le développement et l’exploitation difficiles.

Allez, je me lance ! Ce soir, j’invente un nouveau concept : le UDOD (User documentation oriented design).

Après tout, chaque jour, les acteurs du web inventent de nouveaux « concepts », toujours révolutionnaires, avec leurs centaines de termes et abréviations à connaître par coeur pour rester « in » ! On recherche, on découvre, on apprend, on applique, on oublie et on recommence. C’est tout le charme d’internet ! En regardant de près (ou plutôt de loin si on veut prendre du recul), il y a peu de concepts réellement nouveaux, mais ça fait monter le « buzz » ! Le « web 2.0″ en est une caricature…

« Et UDOD, ça apporte quoi de neuf ? »

Evidemment, après avoir dit tout ce que je pense des « révolutionnaires du web », je vais avoir un peu de mal à vous convaincre d’utiliser UDOD… Mais comme je l’applique avec de bons résultats, je me dis qu’il y aura bien quelques intéressés !

Le principe de UDOD est simple : après avoir fait un brief rapide et fixer des objectifs assez larges pour votre nouvelle application (méthodologie Paper prototyping), vous commencez par écrire la documentation de l’utilisateur débutant (« User guide for beginners »). L’intérêt est de poser une fois pour toute une description claire, synthétique et compréhensible de votre application. On devrait donc y trouver au moins :

• une définition de l’application ;
• une présentation des notions fondamentales ;
• une description des fonctions principales et de leur utilisation ;
• une description de l’architecture et de son interaction avec d’autres sytèmes ;
• des annexes pour les détails techniques ;
• un glossaire ;
• un index.

Une architecture claire, des notions définies

Certes, cela a un coût. La rédaction est longue et doit être faite par un spécialiste. Cependant, on découvre vite l’intérêt de cette méthode :

• La définion de l’application facilite la compréhension des objectifs pour l’équipe de développement.
• Les notions fondamentales sont exhaustives et définies.
• La description des fonctions donnent l’étendue du travail (orienté tâches) de développement et de conception de l’interface.
• La description de l’architecture pose les bases du noyau de l’application.
• Les annexes précisent les contraintes pour les développeurs.
• Le glossaire définit tous les éléments de l’application.
• L’index permet de valider la cohérence des termes utilisés.

Entendons-nous bien, je n’ai pas dit qu’il fallait finir la documentation avant de faire autre chose, mais bien de commencer par elle. Les autres méthodes de conception viendront compléter UDOD sans accroc :

• Design participatif ;
• Méthodes agiles ;
• User task oriented design pour la conception de l’interfaces ;
• UML pour la modélisation de l’application ;
• Object oriented programming et Aspect oriented programming pour le développement du code ;
• Unit tests pour valider chaque brique fonctionnelle définie par UDOD ;
• et j’en passe…

Des utilisateurs impliqués

L’équipe interne a maintenant de quoi travailler sereinement. Mais il y a mieux encore : UDOD implique très vite les futurs utilisateurs de votre application. Ils peuvent la découvrir avant même qu’elle ne soit codée. Et bien sûr y apporter rapidement des remarques, des contraintes, de nouveaux besoins. Dans le cadre d’une application métier, la qualité des échanges est nettement améliorée. On applique au mieux les méthodes de design participatif !

Une documentation de qualité

Au bout du compte, vous aurez optimisé tous les cycles de développement. Et je garde le meilleur pour la fin : vous avez une documentation utilisateur claire et complète au lancement de l’application ! C’est tellement rare…

La théorie des graphes est très puissante pour modéliser les relations qui existent entre des entités. Purement théorique, son application à la programmation permet de concevoir des architectures à la fois robustes et souples.

Le seul problème, c’est de la maîtriser. Je vous conseille donc l’excellent site « Théorie des graphes » du Laboratoire Gilco, au contenu clair, précis et illustré.

Un fois ce savant cours ingurgité, la modélisation d’architectures relationnelles complexes sera un jeu d’enfants !

Théorie des graphes (document PDF)

La mode est aux « livres blancs » consacrés aux interfaces utilisateurs. Tout le monde semble découvrir les bienfaits de l’ergonomie et réclamer la simplicité d’usage. Il faut dire que les utilisateurs ont beaucoup grognés et insistés pour que les applications évoluent !

IBM nous propose sa version, joliment baptisée « Ease of use ».

Très pragmatique à défaut d’être simple, la documentation concernant l’interface utilisateur du projet Gnome a le mérite de poser tous les principes et définitions d’une classique interface 2D.