Bonjour, Une des possibilités est aussi de lui dire de contacter d'autres équipes. Je dirige l'équipe technique d'une scté française qui travaille dans le SaaS et nous avons tout "misé" sur RoR et l'avons fait après mure réflexion.
Pourquoi ? Beaucoup de raisons d'inégales importances, je ne vous cite pas la raison "le framework est élégant" qui veut dire beaucoup pour moi... mais peu pour les autres décideurs étrangers au domaine technique. Si ce n'est que "élégant" veut dire au minimum "bien fait" : - Profil des développeurs généralement plus compétents et intéressés, on ne fait pas du RoR par dépit (en tout cas pas encore !). - Adapté au méthodologies les plus récentes. Les méthodes agiles ne sont pas seulement une "mode", c'est aussi un constat basé sur d'autres évolutions de la théorie des organisation (ex: le lean) que l'on ne peux pas faire de l'informatique comme on construit une voiture. La capacité du framework par exemple à faciliter les tests unitaires (et plus avec cucumber, rspec...) est un énorme atout pour produire du logiciel de qualité, la "culture rails" autour de cela est aussi un atout. Après pour que cela soit un réel atout il faut que l'équipe s'en serve, soit "agile" et ne tombe pas dans les travers de type "on testera ça plus tard", "Arrêtez tout on change ça"… - Quelques témoignages positifs et argumentés notamment de personnes participant à struts. - La possibilité d'utiliser quand même des outils basés sur Java, le fait que les interconnexions restent possibles facilement (SOAP, XML, JSON). - La rapidité de maquettage... et le fait que l'on passe rapidement d'une maquette à du vrai ! - C'est partisan, mais ruby est un langage vraiment plus facile à maintenir que ne l'est PHP et beaucoup moins verbeux que Java (à condition de ne pas trop s'amuser avec la méta programmation qui peut vite devenir complexe à suivre). Les outils de rails (console, debugger…) sont aussi un fort plus. - Possibilité de l'insérer dans des architectures plus grandes (rabbitMq, JMX…) - Quelques possibilités de ruby très spécifique comme la facilité d'écriture de DSL. Au final cela a un impact réel sur les coûts de développement, la rapidité de mise en ligne du service et (si l'équipe suit) la qualité. On a parlé de développeurs heureux plus haut... c'est aussi assez vrai. Pour ce qui est du recrutement (d'ailleurs on recrute... Sur Paris et Montpellier pour les intéressés) ça n'est pas un vrai problème. Nous ne cherchons pas spécifiquement de personnes connaissant rails mais des développeurs suffisamment expérimentés en technologies objet et les formons à rails. Les principales qualités d'un bon dev ne sont pas la bonne connaissance d'un langage et de ses libs mais beaucoup plus. Un "bon" dev java deviendra normalement vite un "bon" dev RoR (et il sera plus heureux etc etc...). Il faut cependant que l'entreprise soit prête à entrer dans cette logique qui est à posteriori un bon choix stratégique, mais peut effectivement faire peur. Les sujets sur les quels je ne choisirais pas (encore) RoR ? Des développements très lourds (>100k lignes) avec de grosses équipes dispersées. Je ne dis pas que cela n'est pas adapté, simplement que j'aurais une appréhension à le faire alors que j'ai déjà vu des grosses équipes (ou plusieurs personnes ne savent pas ce que font les "autres", ça arrive assez vite en fait… vu vers 30-50 pers) bien marcher sur les technos Java (le fond de mon argument est que je crois plus au tapage statique sur ces organisation… mais c'est un autre débat). J'arrive un peu tard pour te donner un avis, mais si cela peut être utile. Raphaël On 26 jan, 17:49, Thomas <[email protected]> wrote: > J'ai tout de même l'impression que la tendance est légèrement > favorable. Aux Etats-Unis, elle a l'air plutôt très favorable. Ou est- > ce que je regarde trop de sites en Ruby? > > Pour ce qui est du client, les arguments ont fait leur petit effet, > merci à Cyril et Philippe. J'attends la décision finale. -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected]
