On dirait bien qu'il faut que les fichiers sources de génération, les méta-données, les diagrammes, les annotations... soient exprimés bêtement dans un langage fonctionnel. Langage fonctionnel, dont les documents « déclaratifs » XML, YAML, UML... sont des exemples primaires.
La frontière étant que le langage de programmation du code rajouté ne doit pas se mélanger aux « informations » (pour le coup, on est bien dans de l'information !) des méta-données. Tant que toute cette partie formelle est équivalente à une expression prouvable, on peut profiter de notre arsenal de preuve.
27 mai 2007
Génération de code vs. Annotations
Le sujet est un peu plus général que le titre, mais bon.
Il apparaît que dans le processus de développement logiciel, la génération de code qui s'appuie sur un formalisme (par exemple UML, XML, YAML...) est supérieure aux techniques inline qui s'embarquent dans le code lui-même : annotations, Generics, syntaxes de conventions à la RoR, reflection, JSP...
En pratique, cela se comprend quand le framework sous-jacent n'est pas bien mûr, ou pas maîtrisé : autant pouvoir s'appuyer sur du code produit par génération plutôt que sur un comportement « magique ». Mais en gros c'est une question de goût.
Cependant, du point de vue théorique, la génération de code est un opérateur qui a un inverse, et pas l'inlining. Dans les cas qui m'intéressent (principalement de la génération par XSLT), le code produit par génération est équivalent à la formalisation initiale du composant. Tandis qu'en inlining, non seulement on peut enrichir la formalisation avec du code (JSP...), on peut ou pas utiliser certaines techniques (Generics...), mais différents développeurs pourront avoir des techniques différentes. Certes, par rapport à la génération l'inlining a une richesse sémantique (cela du reste lorsque des gens trouvent intéressant de lire ce code), mais on n'a plus d'inverse.
L'inverse assure l'équivalence entre le code produit et la notation formelle. Ainsi un point de contrôle sur le code est équivalent à un point de contrôle sur la notation formelle. Ce n'est pas du tout le cas avec l'inlining : il faut écrire des points de contrôle spécifiques.
Le mieux qu'on puisse tirer est une extraction formelle à partir de code inlined : liste des annotations, etc. On obtient moults points de contrôles, mais on est forcément en-deçà du code lui-même. Et on perd évidemment toute la sémantique.
En conclusion : il ne faudrait plus mettre la sémantique dans l'inlining, mais dans une description autonome et disjointe. Et malgré les apparences il ne faut pas imaginer pouvoir suivre ce principe quand on utilise les annotations : on est toujours tenté par elles d'enrichir le code ou par le code d'enrichir icelles.
Il apparaît que dans le processus de développement logiciel, la génération de code qui s'appuie sur un formalisme (par exemple UML, XML, YAML...) est supérieure aux techniques inline qui s'embarquent dans le code lui-même : annotations, Generics, syntaxes de conventions à la RoR, reflection, JSP...
En pratique, cela se comprend quand le framework sous-jacent n'est pas bien mûr, ou pas maîtrisé : autant pouvoir s'appuyer sur du code produit par génération plutôt que sur un comportement « magique ». Mais en gros c'est une question de goût.
Cependant, du point de vue théorique, la génération de code est un opérateur qui a un inverse, et pas l'inlining. Dans les cas qui m'intéressent (principalement de la génération par XSLT), le code produit par génération est équivalent à la formalisation initiale du composant. Tandis qu'en inlining, non seulement on peut enrichir la formalisation avec du code (JSP...), on peut ou pas utiliser certaines techniques (Generics...), mais différents développeurs pourront avoir des techniques différentes. Certes, par rapport à la génération l'inlining a une richesse sémantique (cela du reste lorsque des gens trouvent intéressant de lire ce code), mais on n'a plus d'inverse.
L'inverse assure l'équivalence entre le code produit et la notation formelle. Ainsi un point de contrôle sur le code est équivalent à un point de contrôle sur la notation formelle. Ce n'est pas du tout le cas avec l'inlining : il faut écrire des points de contrôle spécifiques.
Le mieux qu'on puisse tirer est une extraction formelle à partir de code inlined : liste des annotations, etc. On obtient moults points de contrôles, mais on est forcément en-deçà du code lui-même. Et on perd évidemment toute la sémantique.
En conclusion : il ne faudrait plus mettre la sémantique dans l'inlining, mais dans une description autonome et disjointe. Et malgré les apparences il ne faut pas imaginer pouvoir suivre ce principe quand on utilise les annotations : on est toujours tenté par elles d'enrichir le code ou par le code d'enrichir icelles.
25 mai 2007
Plateformes applicatives
Le principe est le suivant : on met à disposition des utilisateurs une plateforme sur laquelle ils peuvent mêler eux-mêmes des composants applicatifs. Derrière, le métier, ou business, est lui regroupé non pas par utilisateurs, mais par services. Cela fait un maillage consistant, où chacun agrège ce qu'il veut : les utilisateurs font du drag&drop de widgets, les utilisateurs-développeurs font des mashups, les entreprises créent des partenariats pour se partager les données. Imaginez que vous puissiez faire installer par drag&drop un service Flickr sur votre page personnelle (modèle de NetVibes, voire d'AppExchange...), service qui propose des « objets » manipulables : des albums, des images, des personnes, des tags... et que cette manipulation permette les échanges avec les autres widgets : drag&drop d'image de Flickr vers un module de chat, recherche d'images analogues, retouche d'image... Ces fonctionnalités d'échanges ne sont pas apportés par les widgets eux-mêmes (très important), mais par la plateforme.
Oui, oui, ça date de 1984, et ça s'appelle Macintosh. Les applications y sont bien pensées, mais, surtout, elles prévoient dès leur conception de pouvoir échanger des « objets » avec les autres applications.
Imaginons qu'on arrive à ce modèle également pour le web.
Selon le point de vue adopté sur ces principes, on obtient les univers Netvibes (cohérence de la plateforme applicative), l'écosystème Netvibes (services publiés), la Facebook Platform (services publiés), AppExchange de SalesForce (services publiés, logique de partenariat entre métiers).
Un article de Fred Cavazza connexe : Réseau social + Web OS = Facebook Plateform
Et les Fûts ? Ben les Fûts c'est ça, mais pour les associations, open source, déployable sur le modèle Peer-to-Peer, et surtout, surtout, encore à l'état d'étude.
Oui, oui, ça date de 1984, et ça s'appelle Macintosh. Les applications y sont bien pensées, mais, surtout, elles prévoient dès leur conception de pouvoir échanger des « objets » avec les autres applications.
Imaginons qu'on arrive à ce modèle également pour le web.
Selon le point de vue adopté sur ces principes, on obtient les univers Netvibes (cohérence de la plateforme applicative), l'écosystème Netvibes (services publiés), la Facebook Platform (services publiés), AppExchange de SalesForce (services publiés, logique de partenariat entre métiers).
Un article de Fred Cavazza connexe : Réseau social + Web OS = Facebook Plateform
Et les Fûts ? Ben les Fûts c'est ça, mais pour les associations, open source, déployable sur le modèle Peer-to-Peer, et surtout, surtout, encore à l'état d'étude.
23 mai 2007
PHP vs Java
C'est moi, ou du code Java pourrave écrit à la va-vite, sans caching, sans pool de connexions, avec de l'introspection dans tous les sens, va plus vite que le code PHP ultra-optimisé avec les pconnect() de la mort-qui-tue qu'il était censé reprototyper ?
Déjà 100 ms de gagnées sur 130... Que reste-t-il à PHP ?
Déjà 100 ms de gagnées sur 130... Que reste-t-il à PHP ?
05 mai 2007
YAML vers XML
YAML est une notation fortement lisible et bien adaptée aux fichiers de configuration.
J'ai découvert YAML avec Ruby on Rails, et il m'a semblé pertinent de l'utiliser pour mes fichiers de configuration et de sources de génération de code.
Dès lors, afin de reboucler avec l'existant écrit XSLT ou autres mécanismes qui prenaient du XML en entrée, il est apparu intéressant de chercher un moyen de convertir du YAML en XML. Et là c'est absolument extraordinaire : alors que la spécification décrit en détail le modèle de représentation YAML, les essais de binding XML sont totalement désastreux.
J'ai bien trouvé quelques sources en Java :
Mais tout ça est orienté fichiers plats, périmètre restreint, échanges de données, et performances.
En Java, je ne trouve pas de documentation d'architecture. L'un parle fichiers plats, l'autre System.out.println(), l'autre type cast...
Je n'ai pour ma part aucun intérêt à utiliser YAML dans des échanges de données. Je préfèrerais voir cracher du bête XML, dans le bête respect de la spécification.
J'ai découvert YAML avec Ruby on Rails, et il m'a semblé pertinent de l'utiliser pour mes fichiers de configuration et de sources de génération de code.
Dès lors, afin de reboucler avec l'existant écrit XSLT ou autres mécanismes qui prenaient du XML en entrée, il est apparu intéressant de chercher un moyen de convertir du YAML en XML. Et là c'est absolument extraordinaire : alors que la spécification décrit en détail le modèle de représentation YAML, les essais de binding XML sont totalement désastreux.
J'ai bien trouvé quelques sources en Java :
- JYaml. Fin constatée des travaux : février 2006. Java 5 only.
- JvYAML. Activité constatée : de juin à septembre 2006.
- yaml4j. Juin 2005.
- JAML.
Mais tout ça est orienté fichiers plats, périmètre restreint, échanges de données, et performances.
En Java, je ne trouve pas de documentation d'architecture. L'un parle fichiers plats, l'autre System.out.println(), l'autre type cast...
Je n'ai pour ma part aucun intérêt à utiliser YAML dans des échanges de données. Je préfèrerais voir cracher du bête XML, dans le bête respect de la spécification.
01 mai 2007
Exhaustivité du Système d'Information
Mais quel intérêt de chercher à tout classifier, à tout contrôler ?
Pourquoi vouloir tout automatiser ?
Et pourquoi cette peur de la redondance des données ?
Un bon SI, c'est un SI au service des humains. Les humains préfèrent d'ailleurs un système fiable à un système qui se permet d'avoir des données incohérentes et qui en plus aurait des velléités de totalitarisme.
L'exhaustivité du SI, c'est un mythe idéologique. C'est une perversion. C'est souhaiter une plate-forme unique, qui contienne des données en correspondance à tout instant, dont la fiabilité serait assurée par la théorie, c'est-à-dire par un discours incomplet. C'est tomber systématiquement dans le travers de réfuter ce qui n'a pas été prévu par l'enthousiasme naïf du démiurge. « Pourquoi irais-je contrôler le résultat, puisque si tout a été fait comme prévu, le résultat est bon ». Aucune place pour la critique. Aucune certitude (sauf que les implémenteurs sont forcément mauvais). Et aucun humour, vous remarquerez.
Alors que d'un autre côté, on sait créer des systèmes souples, avec des traitements asynchrones et des contrôles dans tous les sens, en donnant à l'envi des indicateurs de fiabilité, en écrivant d'ailleurs ces contrôles avant le système lui-même. La fiabilité est donnée par l'usage. Et la fiabilité est forcément bonne. Pas parfaite dans un idéal, mais... bonne en pratique. Si les indicateurs sont publics, qui a intérêt à ce qu'ils soient mauvais ?
Pourquoi vouloir tout automatiser ?
Et pourquoi cette peur de la redondance des données ?
Un bon SI, c'est un SI au service des humains. Les humains préfèrent d'ailleurs un système fiable à un système qui se permet d'avoir des données incohérentes et qui en plus aurait des velléités de totalitarisme.
L'exhaustivité du SI, c'est un mythe idéologique. C'est une perversion. C'est souhaiter une plate-forme unique, qui contienne des données en correspondance à tout instant, dont la fiabilité serait assurée par la théorie, c'est-à-dire par un discours incomplet. C'est tomber systématiquement dans le travers de réfuter ce qui n'a pas été prévu par l'enthousiasme naïf du démiurge. « Pourquoi irais-je contrôler le résultat, puisque si tout a été fait comme prévu, le résultat est bon ». Aucune place pour la critique. Aucune certitude (sauf que les implémenteurs sont forcément mauvais). Et aucun humour, vous remarquerez.
Alors que d'un autre côté, on sait créer des systèmes souples, avec des traitements asynchrones et des contrôles dans tous les sens, en donnant à l'envi des indicateurs de fiabilité, en écrivant d'ailleurs ces contrôles avant le système lui-même. La fiabilité est donnée par l'usage. Et la fiabilité est forcément bonne. Pas parfaite dans un idéal, mais... bonne en pratique. Si les indicateurs sont publics, qui a intérêt à ce qu'ils soient mauvais ?
Inscription à :
Articles (Atom)