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.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
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.
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.
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.
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.
Op, en marque page, ca a l'air vachement bien fait et complet merci.Envoyé par Mookie
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
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.
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.
Tout pour plaire, juste quelques interrogations
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.
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.
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.
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 ...
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".
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!
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 ?
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).
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 ?
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.
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 ?).
Répondre avec citation
Partager