RubyOnRails : un langage commun pour coopérer ?
Lors d'une discussion hier avec Olivier, j'ai émis le souhait de voir les membres ou associés de l'Ouvre-Boite construire progressivement une bibliothèque de fonctions permettant de prototyper rapidement des applications de plus en plus complexes (à la Ilog).
Le but est bien sur de coopérer pour pouvoir concurrencer les "belles américaines", en généralisant la fertilisation croisée des codes.
Comme chacun a tendance à privilégier le langage qu'il connait (Java, C, Perl, PHP, Python...), je crois qu'il sera difficile de s'accorder sur un langage commun (sinon en favorisant certains).
Je crois donc qu'il serait plus pertinent de partir sur une base neuve, inconnue de tous, et que nous pourrions découvrir ensemble. Je propose RubyOnRails (en attendant Axiome ?).
Pourquoi ? Parce que :
Une solution est de continuer à court terme les dev sous le langage de prédilection de chacun, tout en se formant sur RubyOnRails pour le moyen terme (par exemple les versions 2.0 des outils).
Une autre solution est que tous les outils proposent des API sous forme de Web Services...
Qu'en pensez-vous ?
Comme chacun a tendance à privilégier le langage qu'il connait (Java, C, Perl, PHP, Python...), je crois qu'il sera difficile de s'accorder sur un langage commun (sinon en favorisant certains).
Je crois donc qu'il serait plus pertinent de partir sur une base neuve, inconnue de tous, et que nous pourrions découvrir ensemble. Je propose RubyOnRails (en attendant Axiome ?).
Pourquoi ? Parce que :
- Ruby est un langage objet
- Ruby est un langage interprété
- Rails est un framework fait pour des prototypes
- Rails facilite les échanges (Web Services, API, Routage URL, etc.)
- Personne ne connait, et nous n'avons donc pas de retard sur les ricains.
Une solution est de continuer à court terme les dev sous le langage de prédilection de chacun, tout en se formant sur RubyOnRails pour le moyen terme (par exemple les versions 2.0 des outils).
Une autre solution est que tous les outils proposent des API sous forme de Web Services...
Qu'en pensez-vous ?
Ecrit par stephane-lee
le Jeudi 7 Avril 2005, 12:18
dans "Actualités"
Lu 9858 fois.
Article précédent - Répondre à cet article - Article suivant
Commentaires
Je préfére l'approche Web services !
Alain Lefebvre - le 07-04-05 à 18:59 - #
Surtout si ce sont des web services compatibles REST !
Répondre à ce commentaire
← Re: Je préfére l'approche Web services !
stephane-lee - le 08-04-05 à 09:52 - #
C'est vrai que les Web Services sont des interfaces. La boite noire peut donc utiliser n'importe quel langage. S'ils sont bien conçus, ça permet même de changer de langage sans changer d'interfaces...
PS : Connais-tu ARRESTED ?
Répondre à ce commentaire
Illusoire
ludovic - le 08-04-05 à 01:12 - #
Bonjour,
Il me semble illusoire de se standardisé sur un language unique. Comme Alain je pense que l'approche Web Service est la solution. Peut-importe le language du moment qu'on peut interagir avec le service de manière standard.
Une application doit être disponible en service indépendement du language dans lequel l'application est écrite.
C'est un challenge mais dans le cas de l'ouvre-boîte c'est un must !
Ludovic
Répondre à ce commentaire
← Re: Illusoire
stephane-lee - le 08-04-05 à 09:38 - #
C'est dans les plus grandes utopies que se crée le monde de demain...
Te souviens-tu des processus de création d'ARPANet, d'Unix, de Bind, d'Apache, de TCP/IP et HTTP ? L'héritage est grand, à nous d'en être digne ;-)
En route pour les Web Services (REST) alors...
Répondre à ce commentaire
Web Services
stephane-lee - le 08-04-05 à 09:31 - #
Eh bien qu'attendez-vous ?
Répondre à ce commentaire
← Re: Web Services
Stephane - le 08-04-05 à 10:51 - #
La plupart des applications ont déjà des web services : des fichiers RSS, Atom, FOAF etc. en sortie, et l'interface CGI existante en entrée. Les web services du pauvre si l'on veut, n'empêche que cela marche très bien, et c'est disponible maintenant.
Si on développait déjà quelques applis avec les moyens du bord, et ensuite on voit comment optimiser, généraliser, flexibiliser etc. ?
Moi j'aimerais bien qu'on fasse :
- l'import/export de listes de liens entre ViaBloga et BlogMarks, avec notification automatique entre les services lorsque la liste est mise à jour d'un coté ou de l'autre,
- l'import/export des textes entre ViaBloga et XWiki, avec également la même notification,
- l'import/export de la liste blanche/blogolist entre ViaBloga et 6nergies, avec toujours la notification. (Alain : j'ai mis quelques pistes en réponse à ton article sur les Demandeurs)
A priori, pour chacun de ces trucs, c'est un jour de code de chaque coté si on utilise les entrées/sorties existantes. C'est à peu près le temps total que cela à pris pour interfacer 36 Trucs et Social Computing.Répondre à ce commentaire
← Re: Re: Web Services
stephane-lee - le 08-04-05 à 11:05 - #
OK pour les Web Services du pauvre, à condition de les documenter un minimum, sinon ça reste du (multi-)proprietaire...
L'avantage des API documentées, c'est que n'importe qui peut apporter de la valeur, pas seulement ceux que tu as identifié :-)
Pour tes propositions, GO GO GO !
Répondre à ce commentaire
← Re: Re: Web Services
Nicolas Delsaux - le 08-04-05 à 11:09 - #
Répondre à ce commentaire
Pour !
Nicolas Delsaux - le 08-04-05 à 11:11 - #
Evidement, je suis pour, parce que Ruby est un super langage. Malheureusement, nous ne sommes que 2, apparement. Pas grave, on fera notre Ruby dans notre coin avec des interfaces Rest, et ça marchera très bien.
Répondre à ce commentaire
Oui, mais
FrAn - le 08-04-05 à 14:32 - #
Donc, tout le monde est d'accord pour REST.
Mais arretez-moi si je me trompe, mais il faudra sérieusement documenter le format des données échangées... ?
Répondre à ce commentaire
← Re: pour avancer
FrAn - le 08-04-05 à 23:33 - #
J'ai ouvert une page sur le wiki...
http://louvreboite.xwiki.com/xwiki/bin/view/Main/RfcForRest
Il manque plein de choses:
* Meilleurs définitions des règles communes de l'API
* Liste de services en projet
* Description *précise* de ces services
* Etc...
Répondre à ce commentaire
← Re: Re: pour avancer
stephane-lee - le 09-04-05 à 10:56 - #
Merci François.
Répondre à ce commentaire
Petite réaction du papa d'Axiome
Patrick Brunet - le 09-04-05 à 11:56 - #
Après lecture, je tiens à préciser le point suivant :
Axiome n'est pas un langage, ce n'est même pas un formalisme, c'est un méta-formalisme.
C'est à dire que son but n'est pas de permettre de rédiger du code directement opérationnel, et de même il se garde bien d'imposer un modèle de conception (tel que le formalisme objet par exemple).
Au contraire il a comme objectif de permettre la cohabitation des multiples formalismes correspondant à de multiples réalités de la modélisation de connaissances. Car c'est uniquement par cette ouverture que l'on peut espérer mettre en synergie ces connaissances sous une forme non mutilée.
Et ensuite, si on a pu faire ça, alors il devient trivial de produire à volonté des applications formulées dans le langage adéquat pour chacun de leurs éléments. La raison d'être d'Axiome, c'est cette prise de recul-là.
Par exemple :
- Le choix du Web lui-même, avec ses protocoles, comme support d'échange est une application... Faut-il qu'elle soit gravée dans les connaissances échangées ? A mon avis, non, sauf ciblage de connaissances appropriées.
- Toute connaissance à échanger peut-elle être formulée en objets sans s'en trouver dénaturée ? D'expérience je réponds non.
Je n'ai pas non plus envie de jeter aux orties mon expérience de concepteur & développeur, mais je me rends compte que ce capital est aussi un boulet à traîner. Il faut le rendre plus réactif en s'imposant de ne pas repartir de son code bien-aimé, mais des contenus et savoir-faire fondamentaux qui l'ont engendré.Par exemple :
- Quand je poste une note sur mon blog, je pars d'un texte source en plain-text dans lequel j'encode à la main les *gras*, les /italiques/ et les _soulignés_, ainsi que les 1) listes et tout et tout, parce que je sais bien qu'un jour je vais devoir les transporter ailleurs et que les convertisseurs automatiques sont facétieux.
- Et de même un algorithme pur, ou une structure-type de données, peuvent aisément être traduits en C++, en Java, en Ruby ou autre langage, pourvu que ce soit conceptuellement possible. Je dirais-même que ça évite au correspondant de devoir (dénicher puis) apprendre la RFC rien que pour vous comprendre.
Sur ce dernier point, je me rends bien compte que la documentation minimale qui accompagne une telle prestation de code, ainsi que le travail d'explication à prévoir dès que ça commence à intéresser du monde, peut très vite vous consommer vos ressources, et c'est la même chose pour le récepteur de l'échange.A mon avis, c'est l'une des raisons pour lesquelles, même lorsque cette information est disponible, on trouve moins coûteux de réinventer la roue que d'investir sans certitude dans le travail d'un autre. Même avec la meilleure volonté, on ne peut pas humainement se taper les centaines de lignes de code divers de 3 ou 4 projets candidats simplement parce que leurs auteurs affirment que ça peut coller pas mal à votre besoin.
Paradoxalement donc, il me semble que l'essentiel d'un tel échange de savoir-faire peut-être dit en langage naturel, avec des contraintes de communication orientée "choix par l'utilisateur potentiel" :
- introduction concise : c'est quoi et ça fait quoi ?
- contexte plus détaillé : requis, limites, performances, compatibilité, etc.
- principes et conception, toujours en human-readable.
... et si cette forme-là emporte l'adhésion, alors le transfert / remise en forme / réécriture du code ne sont qu'une part subsidiaire du problème.
Bref c'est de la promotion commerciale, même quand c'est bénévole : on doit faire la promotion efficace de son idée, plutôt que donner dans le "j'ai ça dans un coin, si ça peut te servir...".
Axiome pourra à terme intégrer de manière très automatique ce modus operandi, mais dans la tente, ça me fait tout drôle d'être celui qui le dit, mais discuter en dialecte humanoïde offre toujours la meilleure compréhension entre de tels systèmes !
Cordialement,
PZB
Répondre à ce commentaire
← Re: Petite réaction du papa d'Axiome
Fix - le 11-04-05 à 12:46 - #
> Bref c'est de la promotion commerciale, même quand c'est bénévole : on doit faire la promotion efficace de son idée, plutôt que donner dans le "j'ai ça dans un coin, si ça peut te servir...".
Oh que oui. Pro-motion, en suivant le sens étymologique : faire bouger vers. Autrement dit, communiquer, avec d'autres humains (cf. ton human readable). Et l'un des sens de commerce est : conversation.
A beaucoup d'égards, SourceForge (comme beaucoup d'endroits analogues) est un dépôt de brocante. On y flanque son machin, sans préciser aucunement à quoi ça peut servir - les aspects usages, marchés, commerciaux, business - . Il y a quelques renseignements, du genre de ceux qu'un dépositaire met sur une fiche "c'est en fer, avec un peu de verre". Bref, le paradis du brocanteur, par les brocanteurs et pour les brocanteurs.
Ré-utiliser des choses trouvées sur SF ? Impossible de relire et tester tous les codes "faisant à peu près la même chose". Ou ... ré-utiliser les compétences des personnes ayant fabriqué ces choses ? Ou ... potentialiser les échanges que pourraient (qu'auraient pu avoir), par exemple, les (trop) nombreux codeurs d'un bidule de P2P ? Ou encore, réécrire entièrement son code, après avoir entièrement réécrit sa conception. On aimerait, pour s'en tenir au strict aspect technique, que SF (et autres) permettent un partage (human readable) des étapes avant-code, en utilisant un formalisme ou méta-formalisme.
Pour en revenir à la promotion : de bons vieux panonceaux, étiquettes (des tags). Circuler dans l'univers des brocantes : cartographies. Visiter une brocante : si on est plutôt pressé, un accompagnateur est utile. En asynchrone : discussions. En synchrone : IM, et usages mobiles.
Lisibilité, accessibilité. Comme le dit le papa d'Axiome :
- introduction concise : c'est quoi et ça fait quoi ?
- contexte plus détaillé : requis, limites, performances, compatibilité, etc.
- principes et conception, toujours en human-readable.
Un objet (au sens le plus général), pour être visible, compréhensible, utilisable par un humain, doit pouvoir être perçu selon différents points de vue, différents degrés de détail ou d'agrégation. Il faut pouvoir naviguer, matériellement (interface Web) et intellectuellement entre tous ces différents.
Il serait très intéressant de pouvoir formaliser et méta-formaliser les maquettes de l'ouvre-boîte. On y va ?
Mots clés et tags : tags cartographie formalisme
Répondre à ce commentaire
← Re: Re: Petite réaction du papa d'Axiome
Patrick Brunet - le 11-04-05 à 15:06 - #
Je suis enchanté que mon texte ait été interprété comme je le souhaitais. A Olivier qui s'en inquiétait peut-être, j'avais expliqué en ces termes :
Donc en fait je faisais une mise en garde sur le fait d'échanger du code, préconisant à la place de commencer par échager les principes qu'il apporte, exposés en Français.
De même, je mets en avant la différence qui existe entre l'objectif et les moyens qui le servent : le premier ne doit jamais être conditionné par les seconds même quand c'est sournois.
Par exemple : une société dont l'activité consiste même essentiellement en services Web ne doit voir dans le Web qu'une interface pour son activité, qui doit donc être formalisée avec une abstraction suffisante. Sinon on part dans le fantasme 100% online qui a fait les délices de la bulle Internet 1 !
Bref en un mot, une formalisation assez précise de l'objectif est de mise avant de choisir les outils vers lesquels axer la conception d'une solution. Paradoxalement 95% des gens l'oublient, même quand ce sont des développeurs qui ont déjà passé des nuits blanches à payer cette erreur ... C'est forcément dans la nature humaine. Saviez-vous que (surprenant), lorsqu'on leur soumet ces questions-pièges évidentes où tout le monde est sûr de se tromper, les scientifiques, ingénieurs et autres sujets bons en calcul et en logique font globalement un score à peine meilleur que le vulgus pecum ? (il y a eu un dossier là-dessus dans Sience & Vie).
Donc, quel que soit le projet, rien ne vaut un bon puzzle bien visuel, formé de schémas d'ensemble, de listes récapitulatives, de scénarios de base, etc.
Et c'est là qu'Axiome, avec ses éléments de base, peut constituer la base d'un formalisme adapté pour les différentes catégories de pièces de ce puzzle.
L'avantage, c'est que de telles guidelines, exploitant la cohérence interne d'Axiome, offrent des garanties pour la cohérence et la complétude du puzzle. Parce qu'hélas dans une autre vie, j'ai déjà vu un groupe de travail distant accoucher finalement d'un diagramme arborant fièrement 2 boîtes, 3 bonshommes et une dizaine de flèches ... Oui, et après ça ?!?!?
J'aimerais beaucoup avoir vos avis, aussi bien de techniciens initiés que d'utilisateurs potentiels non techniciens, sur l'aspect abordable des élements principaux d'Axiome dans cette optique. Le document Exposé Général du Modèle, présent sur le site www.redres.net, en décrit tous les détails.
Cordialement,
PZB
Répondre à ce commentaire
← Re: Re: Re: Petite réaction du papa d'Axiome
stephane-lee - le 11-04-05 à 16:08 - #
Patrick,
Un article spécifique sur Axiome (sur ce blog) serait peut-être plus approprié.
Il suffit que tu t'inscrives...
Répondre à ce commentaire
← Re: Présenter Axiome
Patrick Brunet - le 13-04-05 à 17:54 - #
Bonjour.
Oui, pourquoi pas... Je vais voir comment définir mon profil (même sur notre site, il n'est pas vraiment à jour, je suis sur un chantier plus urgent).
Pour ce qui est de la présentation d'Axiome, vous trouverez en ligne des documents qui ont justement été écrits dans ce but, à l'adresse suivante :
http://redres.blogs.com/redres/5_documents_techniques/index.html
Le plus abordable pour un tour d'horizon commenté est le dernier de la liste : Axiome pour les Incrédules (42 pages en PDF). Il est conçu comme une démonstration d'intérêt public du projet.
Ensuite pour les détails, le premier : Exposé Général du Modèle Axiome.
Ceci donc conformément à la démarche que je recommandais : "c'est quoi et à quoi ça sert, etc.".
Cordialement,
PZB
Répondre à ce commentaire
Lien croisé
Anonyme - le 11-04-05 à 19:20 - #
Quoi ? - Outils pour le maquettage : "istant est intéressante. Ce pourrait être l'occasion pour l'ouvre-boîte de maquetter ... des usages améliorés ou intéressants de l'outil (cela pourrait éventuellement amener une discussion sur coûts, etc).- Un outil pro de formalisation du concept de la maquette, permettant ensuite une réalisation indépendante du langage etc. Pourquoi pas Axiome ?- Un outil de gestion de projet (par ex. le prometteur Trac). Complété par un frontal permettant aux utilisateurs de la maquette un dialogue simple sur les priorités / fonctionnalités.- Un outil de gestion du temps passé. Puisqu'une maquette est supposée"
Répondre à ce commentaire