Discussion :

[berceker united]

En effet, j'ai vu un phénomène de pillage de Ror surtout au niveau du MVC. Même si ce principe existait depuis un temps Ror à surtout communiqué sur ça. Les autres s'y sont mis fortement.

[lex2004]

Personnellement, je ne connais pas Ruby. Mais j'ai parcouru quelques articles qui en disaient beaucoup de bien. Il n'y a cependant rien d'étonnant à ce que cette technologie tarde à s'imposer en entreprise. En effet, peu de technologies de développement ont pu s'imposer dès leur création dans le secteur du développement d'applications professionnelles. La réalité est toute simple: les habitudes ont la peau dure et personne ne renonce à son outil de prédilection pour un nouvel outil quoi qu'on en dise. C'est pas pour rien que Fortran et Cobol continuent d'exister de nos jours: certains développeurs sont tellement accoutumés à ces langages que même un cataclysme ne les ferait pas migrer vers un nouveau langage. A moins d'être un éditeur extrêmement puissant comme Microsoft ou de trouver un vide parfait dans le domaine qu'on cible, il faut toujours compter sur un changement de génération (des développeurs et des chefs d'entreprise) pour faire adopter son outil par les entreprises. Même Java est passé par là: même si dès le départ on en disait beaucoup de bien, il a quand-même fallut attendre près d'une décennie pour que cette technologie s'impose enfin comme une des solutions leaders en matière de développement d'applications. Elle est même passée quelques fois par de phases de réelle désapprobation (on disait qu'elle est lente, orientée vers l'écriture de grands volumes de code brut, gère mal le fenêtrage, que son langage n'est qu'un clone de C++ et que c'est le meilleur moyen de perdre ses clients, entre autres...). Si Java s'est finalement faite adopter par le plus grand nombre, il y a lieu d'espérer que d'autres technologies suivront; et Ruby (d'après ce qu'on en dit) me semble être une bonne candidate. Son intégration récente dans les plates-formes Java (JRuby) et .NET (IronRuby) augure d'un avenir prestigieux sinon comme langage de programmation générale, du moins comme langage de script (un statut peu exigent en performances). Ajoutons aussi que si le développement de Ruby était pris en charge par une grosse boîte (ainsi que Python l'a été), il s'en trouverait grandement accéléré. Ne soyons donc pas pressés de juger (comme si on se sentait menacé par la nouveauté) et laissons le temps (et la sélection naturelle) décider de ce qui survit et de ce qui périt.

[mathbzh]

Personnellement je ne connais pas Ror.

Cependant étant depuis longtemps un partisan de Python, je confirme ce que disent certains sur le temps nécessaire pour qu'un langage s'impose.

Avec Python (Que j'ai utilisé en gros pour remplacer Perl et awk et faire deux trois trucs un peu plus évolué) sur mon CV voici en gros l'évolution que j'ai eu:

Phase 1: la hype
Tu "fais" du Python? C'est cool, ça marche fort en ce moment, on va peut être pouvoir te proposer un projet un de ces 4...

Phase 2: plus rien, pas même le "Tu connais Python? Intéressant..."

Phase 3: Python (jython) est le langage de script du progiciel sur lequel je bosse (sont proposés jython et rhino, c'est jython qui a été choisi). Python est installé par défaut sur tout les serveurs de la boite, pas mal de petits outils "d'administration" maison sont développés avec.
Bref, la technologie a trouvé sa place. Ca n'a pas remplacé java, mais ça le complète bien. Ca a complétement (là ou je bosse) remplacé perl.

Par contre, il n'en reste pas moins que sur le projet, j'étais le seul à connaitre Python avant de commencer. On avait tous des notions plus ou moins poussées en C/C++/java/SQL/XML/shell. Par contre Python restait une nouveauté pour beaucoup (comme Ruby l'eut été pour moi). Pas simple pour qu'une technologie s'impose.

C'était il y a longtemps, mais le cheminement avait été un peu le même avec java (à une autre échelle tout de même).

Bref, à un moment un langage trouve sa place... ou pas...
Rien de plus normal.

[Jérémie A.]

Comme beaucoup, Ruby et Rails, ce sont des technologies où plus d'une fois je me suis dit "allez je m"y mets à fond" avant de finalement reporter (bien qu'ayant des connaissances de base).
J'ai aussi remarqué qu'on en parlait moins, probablement le "hype" du début, ceci dit, les concepts continent à m'intéresser. Ceci dit, j'ai l'impression que le "hype" est passé de Ruby et RoR à Python et Django (et TurboGear?), mais ce n'est qu'une impression parce que je m'y intéresse personnellement plus en ce moment.
Quoiqu'il en soit, on peut en dire tout le bien qu'on veut, certaines technologies sont très bien implantées (comme PHP et JAVA), et je ne vois pas à Ruby d'autre avenir à moyen terme que celui de projets par des passionnés avertis voulant essayer quelque chose de neuf.

La communauté anglophone ne cesse de s'agrandir, la documentation est complète et de qualité (http://guides.rubyonrails.org)

Op, en marque page, ca a l'air vachement bien fait et complet merci.

[Côme]

Quoiqu'il en soit, on peut en dire tout le bien qu'on veut, certaines technologies sont très bien implantées (comme PHP et JAVA), et je ne vois pas à Ruby d'autre avenir à moyen terme que celui de projets par des passionnés avertis voulant essayer quelque chose de neuf.

Oui, sauf que Java est utilisé depuis maintenant plus de 10 ans. Or 10 ans, si cela paraît peu, c'est pourtant à peu près le cycle observé pour passer d'une génération de langage à l'autre.

Si on reprend l'historique en arrondissant un peu sur les années :

70's COBOL
80's: C
90's: C++
00's: Java

Donc qui va gagner en 2010 ? Et 2010, ce n'est pas du moyen terme mais plutôt du court terme.

Côme

[Kapha]

Ah enfin on parle un peu de rails

Le sujet porte bien sur ruby on rails qui est à la base un ensemble de bibliothèques ruby bien cimentées. Si ror n'a pas tout rasé sur son passage c'est peut être que les gens se sont intéressés à ror avant ruby. Or faire du ruby on rails sans bien connaitre ruby ça devient rapidement ingérable.

Les développeurs sont encore aujourd'hui des bidouilleurs qui aiment trouvé des solutions originales lorsqu'ils programment. Rails n'invite pas à être créatif, il s'agit d'adopter les conventions. Beaucoup de développeurs voient les conventions comme un moyen de brider leurs créativités. Les conventions de rails ce sont des règles de pensées édictées en principe. L'ingéniosité et l'originalité du programmeur sont bridées avec rails qui ne reconnait qu'une façon de procéder. Cette façon est la meilleur c'est à partir de là que rails impose des conventions. De ce point de vue il est en contradiction avec ruby où l'on peut faire la même chose de plusieurs façons. Tout ça est assez flou mais l'idée c'est que rails est un framework particulièrement intrusif d'un point de vue psychique, il formate le programmeur. Ce mépris de rails envers la pluralité des manière de pensée et la réticence des programmeurs à se former à ruby en plus de rails (alors que l'idée est qu'en se formant à ruby on a compris 90% de rails mais qu'en se formant à rails on a compris 10% de ruby) a rendu rails impopulaire.

Bien sur il est possible d'adapter les normes de rails et de programmer à sa manière sous ce framework. Mais cela engage à bien connaitre ruby et rails et à casser certains mécanismes qui ont fait la publicité de rails. Par exemple le scaffolding qui consiste à créer une application web dynamique en une ligne de code est une blague. L'erreur de rails a été de mettre l'accent sur ce genre de mécanisme qu'on utilisera pas tel quel sur de vrais projets.

Enfin rails n'étais pas assez accessible(peu d'hébergeur, très lent sans optimisation, entièrement objet et basé sur des design patterns)pour des programmeurs amateurs/novices habitués à php.
Et rails est trop différent et pas assez "rentable" pour convaincre les professionnels qui change de technologies quand il n'y a pas moyen de faire autrement. Ror n'a séduit que les start up et les programmeurs avertis
frustrés et/ou à la recherche de nouvelles expériences.

Enfin comme ça a été dit les bonnes idées de rails ont été reprises par les frameworks python et php. Cependant rails n'est pas en perte de vitesse, il n'a simplement pas eu le sucés que l'euphorie lors de sa sortie laissait entrevoir, même si il a pour moi toujours un train d'avance sur les autres mais ça c'est un autre débat.

[Jérémie A.]

Si ror n'a pas tout rasé sur son passage c'est peut être que les gens se sont intéressés à ror avant ruby. Or faire du ruby on rails sans bien connaitre ruby ça devient rapidement ingérable.

Je crois que tu mets le doigt sur un problème important concernant Ruby et RoR en effet. J'avoue qu'à chaque fois que j'y pense, je me dis "je me mettrais bien à RoR", et non pas "je me mettrais bien à Ruby". Pourquoi? tout simplement parce que c'est RoR qui a fait "beaucoup de bruit", et non la technologie sous jacente.

[berceker united]

Je crois que tu mets le doigt sur un problème important concernant Ruby et RoR en effet. J'avoue qu'à chaque fois que j'y pense, je me dis "je me mettrais bien à RoR", et non pas "je me mettrais bien à Ruby". Pourquoi? tout simplement parce que c'est RoR qui a fait "beaucoup de bruit", et non la technologie sous jacente.

Deuxième doigt dessus, pour ma part j'ai plus entendu Ror que Ruby et en effet au moment ou ça émergé ou du moins quand c'est devenu "hype" c'est à l'arrivé de Ror alors que je pense que Ruby était déjà dans les bacs depuis un temps.

[Atlan_a_paris]

Le monde ne se limite pas à la France!
Rails n'a clairement pas encore fait son entrée chez nous mais ça arrivera.

Je trouve cela complètement hallucinant que des développeurs se limitent à la documentation francophone! Et encore plus fou que certains puissent donner un avis sans avoir réellement testé la technologie.

La communauté anglophone ne cesse de s'agrandir, la documentation est complète et de qualité (http://guides.rubyonrails.org) et il y a un nombre de blog impressionnant avec tous les jours de nouveaux articles.

J'ai développé pendant des années en PHP et en Java (Spring, Hibernate, JSF, ...) et je ne développe maintenant presque plus qu'en Rails, tant pour mes projets personnels que professionnels. Je ne regrette pas une seule seconde d'avoir fait ce choix.

Pourquoi? Parce que je peux développer les mêmes applications plus rapidement, et surtout, parce que ces applications sont nettement plus faciles à maintenir par la suite. Ce n'est pas un slogan publicitaire, c'est une réalité.

Je trouve vraiment très drôle de lire que "des projets commencent en Rails mais ne sont pas achevés". On n'inverserait pas les rôles? Je serai très curieux de connaître le pourcentage d'échecs dans le développement de projets en Java?!

Ce nombre important d'échecs permet justement de prouver que nous avons un problème avec nos technologies. Et c'est la que Rails apporte un renouveau en proposant une technologie agile.

Vous préférez la configuration par rapport à la convention, vraiment? Est-ce vraiment nécessaire de se farcir des fichiers XML pour déclarer des contrôleurs?
Et surtout, Rails ne vous empêche pas de configurer lorsque vous jugez cela nécessaire. Aucune magie ne se cache la dessous!

Je suis tout à fait d'accord que le peu d'offres au niveau de l'hébergement ne contribue pas à l'évolution de Rails. Il est temps que les hébergeurs se lancent, surtout que Rails peut maintenant être déployé presqu'aussi simplement qu'une application PHP en utilisant un module Apache.

Et qu'on arrête avec cette lenteur associée à Ruby. Ce n'est certes pas le langage le plus rapide du monde mais avec Ruby 1.9 et JRuby, c'est bel et bien PHP qui a repris la place de la tortue.
De plus, de nombreux efforts sont mis en place pour améliorer les performances d'une application Rails : http://railslab.newrelic.com/scaling-rails
Et est-il vraiment nécessaire de rappeler que de très gros sites tournent déjà sans problème sous Rails?

Enfin, pour terminer, une nouvelle technologie ne peut pas s'imposer en entreprise si rapidement. Dans les grosses structures du moins.
Les gens sont habitués à J2EE, leur infrastructure est propre à J2EE et leurs développeurs ne connaissent que ça. Il est donc logique que tout ce qui n'est pas J2EE effraie les décideurs. Une fois de plus, JRuby on Rails sera peut-être la solution.

Alors SVP, avant de juger et critiquer, faites l'effort d'expérimenter.

Nou montons une startup avec une grosse plateforme web d'e-commerce social et multilingue, et je me pose réellement la question "ROR" ou framework PHP?

1) Je n'ai aucun doute sur la supériorité de ROR.
2) Avec ROR par ailleurs je suppose pouvoir dratisquement écourter les délais de développements et limiter d'autant les frais.

Mais je me pose des questions très pratiques :

-Trouverons-nous suffisamment de développeurs RAILS, disponibles, au bon niveau de compétence et à un coût qui ne fasse pas perdre tout le bénéfice que l'on peut attendre de ROR en terme de rapidité de développement et de coût?
- Ne serons-nous condamné à "importer" le développement?
- Le ROR est-il pérenne, sur 10, 20 ans?
- Une API est prévue pour des développements annexes, le choix de ROR ne limitera-t-il pas la portée de cette ouverture (comment interfacer des développement PHP?)
- Le choix de ROR ne limitera-t-il pas les possibilités d'interfaçage/mashup avec d'autres sites web.
- Ce choix ne risque-t-il pas d'effrayer les investisseurs?

Pour résumer, dans le cas d'une startup , au départ française qui plus est, qu'est-ce qui me ferait choisir ROR plutôt qu'un autre framework?

That is the question.

[mon_nom_est_personne]

je ne peux pas vraiment t'aider dans ton choix mais je peus te donner quelque reponse notement au niveau de l'api. Le secret c'est d'etre standard. Et malgres sa faible notoriete, il existe un standard pour les web services appelle SOAP (Simple Object Access Protocol). ce protocole est completement independant du langage de progammation du client et du serveur ce qui permet une interoperabilite total et de garder une notation object contrairement a une approche REST. C'est ce qu'on a fait au taff, le cote serveur est developer en php et on a des clients developes en java, flash, asp etc...
Ensuite d'un point de vue bizness, la question de trouver un certain nombre de dev competents en france peut effectivement etre un probleme. Je te recommanderais fort de ne pas externaliser ta production pour les raison suivante :
- Tout ce qui externaliser refait toujours un jour surface dans un autre projet qui peut-etre concurrent. C'est pour ca qu'en general on externalise que les development a faible valeur ajouter.
- Pour les investisseurs, car une des choses qui fait la valeur d'une start-up est souvent la technologie qu'ils ont cree. La plus part des start-up qui sont racheter ou sujet a un achat par un gros groupe dans la plus part du temps c'est pour acquierir une technologie (vous pensez reellement que google veux racheter twitter pour mettre des adsense dans les twitt ?) et malheureusement c'est toujours le scenario favorise des venture capital car c'est de l'argent assurer.

[Tommy31]

jexiste un standard pour les web services appelle SOAP (Simple Object Access Protocol). ce protocole est completement independant du langage de progammation du client et du serveur ce qui permet une interoperabilite total et de garder une notation object contrairement a une approche REST.

Pas du tout. Rest permet au même titre que soap la représentation d'objets. Et dans son cas précis, je ne saurais trop conseiller ce type d'approche par sa capacité à fournir plusieurs représentations d'une même ressource, dont une ciblant un client ajax.

[mon_nom_est_personne]

Apres si on commence a debattre REST vs. SOAP on en a pas fini. C'etait juste une precision. je cloturerais la parenthese par, surtout quand on gere une api, de l'importance du controle de cette derniere et de performance. L'avantage d'un couplage soap/wsdl permet de limite les test de type, d'ip etc.. au niveau du programme car bon nombre de mecanismes sont intrasec au protocol.
Enfin c'est ma position, apres les gouts et les couleurs ...

[Atlan_a_paris]

je ne peux pas vraiment t'aider dans ton choix mais je peus te donner quelque reponse notement au niveau de l'api. Le secret c'est d'etre standard. Et malgres sa faible notoriete, il existe un standard pour les web services appelle SOAP (Simple Object Access Protocol). ce protocole est completement independant du langage de progammation du client et du serveur ce qui permet une interoperabilite total et de garder une notation object contrairement a une approche REST. C'est ce qu'on a fait au taff, le cote serveur est developer en php et on a des clients developes en java, flash, asp etc...
Ensuite d'un point de vue bizness, la question de trouver un certain nombre de dev competents en france peut effectivement etre un probleme. Je te recommanderais fort de ne pas externaliser ta production pour les raison suivante :
- Tout ce qui externaliser refait toujours un jour surface dans un autre projet qui peut-etre concurrent. C'est pour ca qu'en general on externalise que les development a faible valeur ajouter.
- Pour les investisseurs, car une des choses qui fait la valeur d'une start-up est souvent la technologie qu'ils ont cree. La plus part des start-up qui sont racheter ou sujet a un achat par un gros groupe dans la plus part du temps c'est pour acquierir une technologie (vous pensez reellement que google veux racheter twitter pour mettre des adsense dans les twitt ?) et malheureusement c'est toujours le scenario favorise des venture capital car c'est de l'argent assurer.

Merci, je n'ai pas encore tranché entre RESP ou SOAP mais je trouve ta réponse en tout point intéressante et pleine de bon sens. Reste à trouver les bons devs... de les associer ou d'être bien conscient des risques "d'externalisation".

[mon_nom_est_personne]

Y'a pas de quoi, on est la pour se filler des coups de main et partager. ;-)

[Atlan_a_paris]

Y'a pas de quoi, on est la pour se filler des coups de main et partager. ;-)

C'est bien vrai et c'est agréable.

J'ai décidé de commencer les devs moi-même au moins pour la maquette, je pense que je vais le faire en Rails, je ne suis plus à un langage près et celui-ci m'amuse, c'est important pour la motivation, non? Le fun : un autre paramètre à prendre en considération. Par ailleurs quelque chose me dit que le business plan est sérieux, si quelqu'un est intéressé par l'aventure, qu'il me le fasse savoir. Ah! J'adore entreprendre!

[tibotibo69]

J'arrive un peu tard dans la discussion mais je ne pense pas que rails soit un langage en voie d'extinction, c'est vrai qu'il ne concurrence pas PHP au niveau de la notoriété peut-être du fait que dans les écoles informatiques ou dans les fac on n'apprend pas ce langage. Du coup, on se doit de l'apprendre de façon auto-didacte pour l'utiliser.

Rails vantait son architecture MVC qui est maintenant reprise par de multiples framework PHP, pourquoi apprendre un autre langage si il n'apporte pas de nouvelles fonctionnalités ?

[Xitog]

Rails est un framework.
Ruby est un langage.

Au niveau du framework, de nombreux clones (CakePHP, Symfony) existent à présent pour PHP, permettant aux utilisateurs de ce langage de bénéficier des nombreux apports de la "percée" de Ruby On Rails. Même si la progression du langage en lui-même est plutôt faible, son impact a été grand dans la manière de déveloper du web.

Après, avis personnel, PHP est d'une laideur affreuse par rapport à la beauté de Ruby (concept, syntaxe, élégance, cohérence).

[Pierre Louis Chevalier]

Ruby est à la hausse en Amérique du Nord mais de décolle pas en France

Selon une nouvelle étude de Evans Data, Ruby est à la hausse en Amérique du Nord. Sur une année l'utilisation de Ruby a augmenté de 40 pour cent jusqu'en en 2009.

Mais, même avec l'augmentation, Ruby est encore loin d'être généralisée. Evans' étude a révélé que seulement 14 pour cent des développeurs en Amérique du Nord utilisent de temps en temps Ruby. D'après les prévisions, le nombre devrait passer à 20% en 2010.

Le marché francophone est beaucoup plus petit et à donc tendance à se focaliser sur les solutions les plus utilisées, comme par exemple PHP, Java, ASP.NET ou Python.

Ce qui s'est passé sur la francophonie c'est qu'il y à eu un très gros "battage médiatique" organisé par des fournisseurs de produits et solutions comme par exemple par les éditeurs de livres, et relayé par la presse, mais que dans les faits la technologie est encore peu utilisée, comme on le voie sur ce sondage : 1,50% d'utilisateurs.

Bref l'impression "bizarre" viens donc du fait que des médias par le passé ont consacrés énormément de place à Ruby on Rails, alors que à l'arrivée sur la francophonie on parles d'1,50% d'utilisateurs, ce qui est minuscule face à PHP, ASP.NET, Java et Python...

Qu'en pensez-vous ?

[berceker united]

Rails est un framework.
Ruby est un langage.

Au niveau du framework, de nombreux clones (CakePHP, Symfony) existe à présent pour PHP certes.
Mais PHP est d'une laideur affreuse par rapport à la beauté de Ruby (concept, syntaxe, élégance, cohérence).

Si c'est Ruby est là pour faire beau au développeur pourquoi pas mais c'est pas ce genre de critère que retient un entreprise.

[Xitog]

Un programmeur heureux est un programmeur productif.
On peut compter sur sa vie personnelle ou lui offrir des outils sympa.
Si j'étais chef d'entreprise, je pencherai pour la seconde

Plus sérieusement, toute décision technique devrait aussi prendre en compte (même en facteur mineur) comment l'équipe de dev réagira à l'outil. C'est un luxe certes, mais la mauvaise foi et la reluctance sont très contre-productives.

Attention, c'était un avis personnel, je suis sûr qu'il existe des gens qui préfèreront 100 fois utiliser PHP au lieu de Ruby, comme je connais des gens qui préfèront 100 fois le procédural à l'objet (comment ça ceux sont les mêmes ? ).