Bonjour,

Catalogues de l'existant

Il y a un lien dans la page http://www.rubyonrails.org "Who is using Rails ?" avec des tas d'exemples d'applications réelles Rails. En continuant dans les liens, on est amené sur http://happycodr.com/
en particulier http://happycodr.com/folio/tag/CMS
J'espère que cela correspond à votre recherche.

Le site RAA (Ruby Application Archive) est aussi un excellent endroit pour trouver tout ce que l'on cherche. Tout est rangé par catégorie, avancement du développement, bref, tout ce qu'il faut :
http://raa.ruby-lang.org/search.rhtml?search=Rails
http://raa.ruby-lang.org/cat.rhtml?category_major=Application;category_minor=Content%20Management

Dans tous les cas, Ruby On Rails est particulièrement adapté au CMS, GED et autres applis communautaires, comme vous pouvez le voir un peu partout. La communauté est très active et de nombreux plugins ont été écrits, n'oubliez pas avant de coder de vérifier s'il n'existe pas déjà le plugin existant :
http://wiki.rubyonrails.com/rails/pages/Plugins

Bien entendu, vous pourrez profiter des développements de la communauté, et comme vous l'utilisez professionnellement, améliorer et finaliser certains plugins en développement, puis les proposer à nouveau à la communauté : bref, créer une bonne synergie qui sera avantageuse pour tous.

Capacités techniques, charge...

Je dirais que le qualitatif dépend surtout de l'équipe de développeurs, de leurs outils et méthodes de travail (TDD!), donc bien sûr, en tant qu' "opinionated software", il faut adhérer à la philosophie et 'jouer le jeu', mais personnellement elle me convient parfaitement. Ca semble être le cas pour tout le monde sur Railsfrance et je souhaite à vos développeurs de découvrir enfin la liberté et le bonheur de coder en Ruby :D !

Pour le quantitatif, on a déjà vu des centaines de débats et trolls à ce sujet. Je pense que Rails est effectivement *un peu* lent lorsque la charge grossit. Cependant, il n'est pas impossible de résoudre ce problème par une bonne mise en place et administration des serveurs, et un peu d'analyse des 'bottlenecks', bref, faire de l'optimisation à la fin du développement.
Il y a de plus en plus de 'success stories' en Rails, elles tournent très bien et tiennent parfaitement la charge. En fait, avec le temps que Rails peut gagner contre une solution type Java, on peut coder très vite quelque chose de fonctionnel et évolutif, sans s'embêter à optimiser le moindre petit truc, et seulement à la fin, analyser comment ça tourne et speeder un peu tout ça.
Il y a des témoignages sur le blog de DHH ou sur le site de 37 signals, un peu de Google et vous trouverez.

Considérations philosotechniques

> 1. J2EE semble tendre à évoluer vers une simplification
> inspirée de RoR (par élévation du niveau d'abstraction) ;
Tant mieux ! C'est pas trop tot ^^

> 2. J2EE semble également vouloir s'articuler avec ROR ;
Tant mieux.

> 3. RoR semble développer des outils permettant d'exploiter
> les données enregistrées par J2EE (en XML) ;
Tout à fait. RoR gère parfaitement le XML, l'AJAX, et même le javascript grâce à ses nombreuses bibliothèques. Et s'il en manquait, il est très simple d'en ajouter : le Ruby permet à Rails d'être très extensible !

> 4. L'ensemble de ces tendances (parmi d'autres) semble promettre
> des formes d'intégration entre J2EE et RoR (certaines
> commencent-elles à voir le jour ? Où ?).
Je ne sais pas. Il existe des tas de comparatifs Java/RoR, il y a même plusieurs threads à ce sujet rien que sur Railsfrance, et je vous invite à les lire, mais j'avoue qu'évaluer le futur de J2EE sort complètement de mes compétences.

> Serait-il erroné de produire massivement des contenus dans le cadre
> de JCMS (pour pallier l'apparente indisponibilité actuelle
> d'applications aussi solides et évoluées que JCMS en RoR), avec le
> risque éventuel d'avoir à tout ressaisir dans une application RoR
> dans quelques années ?

Je pense que oui. S'enfermer dans une solution propriétaire est un risque certain. En revanche, en utilisant une solution open source (gratuite, déjà) il est plus facile d'exporter et d'importer comme vous le souhaitez, si les fondations devaient changer par la suite.

> Inversement, serait-il erroné de produire ces contenus dans le
> cadre d'une application RoR (laquelle ?) en espérant qu'elle
> évolue dans le sens escompté ?

Justement, votre contenu ne sera pas du "contenu RoR". Vous allez le
ranger avec une certaine norme, dans certains formats (filesystem, base de données, que sais-je...) qui sont facilement interchangeables. Rails est très bien découpé et ses diverses couches d'abstraction (en particulier le MVC) permettent de ne modifier qu'une partie du code lors de changements drastiques : si je change des choses dans mon modèle, je n'aurai que peu de modifications dans les contrôleurs, et il est possible que ma vue n'ait même pas besoin d'être changée ! Si vous décidez de passer d'une BDD MySQL à PostGreSQL, c'est ActiveRecord qui s'adaptera et vous n'aurez quasiment rien d'autre à faire !

> Comment penser la chose en prenant en compte les évolutions
> actuelles du Web ?
En étant Agile :)

Méthode de lancement de votre produit

> Est-il pertinent d'interroger comme je le fais ou devrais-je
> suivre une méthode ?
Votre sujet est très vaste et nécessite des compétences pointues. Je ne saurais que trop vous recommander de prendre contact avec des professionnels de Rails et/ou d'expliciter très précisément votre cahier des charges : ni moi ni même vous ne savons par où commencer notre réflexion sur le sujet, et ce n'est pas par le biais d'un forum que nous trouverons une solution.

En revanche, du peu de contraintes que vous nous montrez, je pense pouvoir dire sans risque que RoR est une solution viable. Pas *la* solution, mais *une* solution, qui présente l'avantage d'être libre et ne pas vous fermer de portes. Si votre mise en place de JCMS devait vous faire abandonner certaines fonctionnalités prévues, je vous en prie : revenez voir Rails, il pourrait bien être capable de le faire :)

Il y a enfin un dernier point qui est très important dans votre post d'extensions à la réflexion : le côté humain. La communauté Rails est très vaste et très dynamique, mais vous ne pouvez à mon avis pas prétendre unifier les CMS. Cependant, je pense que vous pourrez sans problèmes créer une synergie efficace entre la communauté et votre société pour faire évoluer votre produit.

Pour exemple, prenons les moteurs de blogs : rien qu'en Rails, il en existe déjà une poignée, sans compter les gens qui se codent le leur. Je ne suis pas bloggueur ni expert en la matière, mais quand on les regarde, ils semblent à peu près tous sympa, puissants, etc... Et la communauté autour de chacun de ces blogs engines semble soudée aussi. Mais je suis à peu près sûr qu'il n'y aura jamais de fusion et que la concurrence restera encore quelques bonnes années.

Alors, créer le CMS ultime, je ne suis pas contre, et je salue l'initiative, surtout que c'est avec ce genre de volonté que l'on arrivera à un produit correct.

Mais ça ne sera jamais (AMHO) l'unificateur de tous les CMS :)

Bonjour,

Je n’ai pas encore fait les devoirs que vous m’avez donnés. Avant d’y plonger, je ne puis m’empêcher de vous dire que je suis enchanté de votre accueil. Vos réponses sont précises, opérationnelles et complètes, en même temps qu’elles témoignent d’une riche profondeur. Le tout avec une aisance qui donne envie de vous rejoindre afin de tout bêtement collaborer. En effet, la tentation est telle qu'une chute dans Ruby me semble toujours plus inévitable.

Je réagis de suite à votre dernière phrase. L’idée d’un « projet commun » pouvant servir de base de travail susceptible de susciter la « coopération » entre les équipes actuellement engagées dans le développement de différents CMS en RoR, dans mon esprit, c’est tout sauf un désir d’unification (je suis foncièrement allergique à toute forme d’union, de fédération ou de fusion : comme si elle faisait la force…). Donc pas question ici d’unifier les CMS. D’autant qu’il ne s’agit pas uniquement de CMS, mais davantage d’un site (sorte de web véritable). Qu’un bac à sable collectif permette à chacun de contribuer à la conception d’un « CMS ultime » me convient davantage, pour peu qu’il ne soit pas conçu comme ultime en soi (sorte de challenge purement technique), mais bien dans le contexte spécifique d’une application hautement problématisée.

Pour ne dire qu’un mot de cette problématique, un mot digne (j’espère) de l’humour génial inhérent à Ruby, je suis tenté de réduire la nature de l’opération de développement local envisagée (depuis 33 ans) en la décrivant comme une application illustrative de la philosophie de Ruby au champ socioéconomique, donc comme une sorte de « rubification » territoriale, d’ailleurs indissociable du « common » tel que conçu dans la sphère GNU (on aura remarqué que pareille phrase pâtit des lendemains de fête…).

Si j’ai parlé d’unifier, cela se limitait aux deux enjeux que constituent le développement local (la sphère des modes de vie) et le développement logiciel. Et en termes de partenariat. J’y faisais allusion à certains avantages, en amont des concepts susceptibles de se dégager de la démarche. A moi de fournir les éléments substantiels d’une telle réflexion (ou perspective). C’est-à-dire les contenus de ce que vous appelez « créer une bonne synergie qui sera avantageuse pour tous ». Une synergie évolutive entre les réalités informatiques maîtrisées par votre communauté et les virtualités dont mon équipe est porteuse (une fondation de recherche est en formation et le collège des partenaires informatiques est encore vide à ce jour).

Question technique : Vous avez compris qu’une approche sémantique de haut niveau constituait une des exigences centrales de notre projet. Qu’en est-il de la gestion de thésaurus (et de clusters) dans le monde de RoR ? Même question pour les dispositifs d’analyse du langage naturel (analyse de texte et indexation automatique) et leur corrélatif : les fonctions de recherche avancées. Je parle ici du top de la GED actuelle, car un des deux volets de notre projet consiste à forger un outil de recherche transdisciplinaire collaborative.

Questions pratiques :
1. Qu’est-ce que le blog de DHH ? Parlez-vous de David Heinemeier Hansson ? Donc de www.loudthinking.com, de weblog.rubyonrails.org ou autre ?

2. Où exposer les éléments de notre cahier des charges ? En suivant quel canevas ? J’avais pensé utiliser une structure de forum afin de transformer chacun de mes paragraphes en billet, qu’une discussion puisse s’ouvrir point par point, donc en permettant une lecture à la fois horizontale (d’un paragraphe à l’autre) et verticale (consultation des critiques, questions et suggestions). Dois-je abandonner cette idée ? J’en préfère une autre : exposer ces éléments dans le cadre du CMS en RoR le plus susceptible de correspondre à nos attentes, de sorte que mon travail contribue à son développement. Est-ce mieux ? Dans ce cas, lequel (parmi quelle sélection le choisir) ? Sans doute serai-je à même de répondre dès que j’aurai consulté les documents que vous m’avez indiqués.

Penser agile… No problem.
Un grand merci !

PS : Vous-même êtes engagé dans quelle sublime galère ?

> Qu’en est-il de la gestion de thésaurus (et de clusters)
> dans le monde de RoR ?

Je vous renvoie à la réponse plus spécialisée de rvalyi :)

> Même question pour les dispositifs d’analyse du langage
> naturel (analyse de texte et indexation automatique) et
> leur corrélatif : les fonctions de recherche avancées.

Aucun probleme. Il y a sur RAA un outil de lexing/parsing en Ruby (comme flex/bison) mais je n'ai pas le lien sous la main. Je ne l'ai pas examiné en détail non plus.

J'ai fait un projet en ligne de commande pour des utilisateurs débutants en informatique : création de playlist et recherche de chansons sur plusieurs critères, et ma gestion de la ligne de commande permet d'entrer des commandes (que je trouve personnellement) très naturelles. Ca prend du temps, mais c'est facile de parser une ligne de commande à la main en Ruby.

> Questions pratiques :
> 1. Qu’est-ce que le blog de DHH ?
www.loudthinking.com

> 2. Où exposer les éléments de notre cahier des charges ?
Aucune idée :) Votre site ? Ici ?

> En suivant quel canevas ? J’avais pensé utiliser une
> structure de forum afin de transformer chacun de mes paragraphes
> en billet, qu’une discussion puisse s’ouvrir point par point,
> donc en permettant une lecture à la fois horizontale (d’un
> paragraphe à l’autre) et verticale (consultation des critiques,
> questions et suggestions). Dois-je abandonner cette idée ?

Perso, j'aime pas les forums. Mais pourquoi pas, c'est peut-être le moyen le plus 'pratique' en effet, sauf que l'information sera fragmentee, on répondra à un billet sans avoir connaissance du reste... Et naviguer sur un forum prend vraiment beaucoup de temps.

> J’en préfère une autre : exposer ces éléments dans le cadre du
> CMS en RoR le plus susceptible de correspondre à nos attentes,
> de sorte que mon travail contribue à son développement.
> Est-ce mieux ?

Bonne idée, mais dans ce cas vous n'aurez pas de conseils sur le choix du CMS, puisqu'il sera déjà fait :)

> PS : Vous-même êtes engagé dans quelle sublime galère ?

Etudes d'ingénieur en informatique, actuellement bac +4 :)
Formation *tres* technique (plein de langages, plein de projets) et tres poussee (donc, pas beaucoup de sommeil :D )

Salut,

mon boulot actuel est de développer des CMS en JEE avec Jahia, donc j'ai un peu d'expérience sur la question. En ce qui concerne Jahia et sa kyriade de briques Open Sources du JEE qui la compose, je dirais que c'est très compliqué pour pas grand chose au final.

Notamment les technos JSP basées sur des DSL avec des taglibs tels que Struts ou Jahia lui même s'avèrent une expérience très décevantes: ces DSL sont des bâtards lourdos dont il faut se taper à main le XML et sortir à tout bout de champ car ils sont trop limités aux cas simplissimes. Ces JSP n'auraient de justification que dans le contexte d'IDE graphiques traitant ces DSL ou au moins de complétion automatique toujours documentée et souple, hors ce n'est toujours pas le cas à cette heure. Rails, lui est beaucoup plus puissant et reste lisible.

Pour moi, les seuls avantages comptés du JEE sont:
* un marché de développeurs abondant et plus favorables aux recruteurs
* plus de briques open source toutes faites à intégrer
* le typage statique est structurant sur les projets devant impliquer de nombreux développeurs sur la durée
* un site optimisé en JEE tient plus de charge avec moins de CPU.

Mais donc si vous n'êtes pas dans ces cas très précis: très gros projet devant impliquer beaucoup de développeurs sur la durée et très haute exigence de charge sur CPU limité, alors je dirai tentez Rails, vous avez énormément de chances de sortir gagnant avec de la marge.

Egalement intéressé par des CMS en rails, je suis de très près le prometteur Rubricks: http://rubricks.org/index_en.html
Si vous comparer la taille du code de Rubricks+Rails par rapport à Jahia (JEE) par exemple sur le même périmètre de compétence, vous devriez vite comprendre qu'une solution Rails paraît beaucoup plus saine.

Bonne chance à vous.

Raphaël Valyi

PS: par ailleurs, je monte actuellement un site Rails avec du clustering thématique dans des forums. Pour cela j'utilise des algos genre Max Edge Betweenness que j'implémente en C avec SWIG ou rb-gsl (binding Ruby de la Gnu Scientifical Library) histoire de pallier au manque de rapidité de Ruby. Pour ce qui est de la recherche (non sémantique) et de l'indexation, Ferret est réputé plus rapide que le Lucene du monde Java...