Je suis tout à fait d'accord avec ta vision du monde réel. Je travaille dans une PME et en effet, nous faisons 'avec' les développeurs que nous avons, et les compétences qu'ils possèdent. C'est compliqué opérationnellement parlant de gérer la transition vers une nouvelle techno.
Quand à virer ses équipes sous prétexte qu'elles ne seraient pas suffisamment adaptables comme cela a été suggéré dans une réponse à ton post, c'est peut être faisable dans les Sims édition développeur, dans la réalité c'est plus compliqué ;) ----- Message d'origine ----- De: pierrederome <[EMAIL PROTECTED]> Env: lundi 4 février 2008 19:54 À: Railsfrance <[email protected]> Objet: [RailsFr] Re: Appel à argument et info : contrer les sceptiques Ruby on Rails. bonjour, j'ai choisi Ruby on Rails pour mon projet actuel de services Web grand public. J'étais CTO de Club-Internet jusqu'à récemment. Je crois qu'il ne faut pas trop argumenter sans bien en peser les implications. Les forces de ROR, on les connait, pour les "preuves qui restent à faire", je crois qu'il faut effectivement donner le temps au temps et ne pas promettre que tout va bien se passer... Certains arguments ne doivent pas être contrés par des mots, mais plutôt par des résultats concrets et visibles. Dans une boîte de taille moyenne à grosse, il n'est pas raisonnable de lancer de grands projets de développement sur des technos aussi récentes et si peu éprouvées. On a des équipes habituées à des environnements de développement précis, et on sait assez bien en combien de temps,avec quel niveau de qualité, et de performance on fera tel ou tel projet. Les projets sont aussi très souvent des extensions ou des évolutions de systèmes existant, pour lesquels on ne va pas changer la techno en cours de route. Je crois aussi qu'adapter des bases de données existantes à Rails doit être assez pénible. Ceci étant, dans ce type de boîte, on a aussi régulièrement de nouveaux projets de taille petite à moyenne relativement indépendants des SI existants, avec seulement des besoins d'interface. C'est sur ce type de projet qu'il est pertinent d'introduire de nouvelles technos. Les arguments du développement agile, et DRY ont de quoi séduire tout CTO, mais dans un contexte où on gère les risques: i.e. projet de taille petite/moyenne, avec pas trop de dégats si les perfs ne sont pas immédiatement au rendez-vous (l'exemple donné dans un post précédent de faire une maquette en ROR est pas mal; et les maquettes bien faites ont tendance à évoluer en produit final plutôt que disparaître). Après, ROR fera ses preuves tout seul... Après, il ne faut pas sous-estimer non plus la difficulté à faire changer de techno des développeurs experts en PHP ! Mon expérience est qu'il y a une courbe d'apprentissage non négligeable que tout le monde n'a pas nécessairement envie de suivre... même si pour ma part, je trouve que ça en vaut la peine. sinon sur la liste d'arguments contre: - performances faibles ou inconnues - c'est déjà assez difficile de trouver de bons développeurs Java, alors Ruby on Rails !!! - on m'avait dit la même chose sur Python/Django (et là vous pouvez aussi remplacer par tous les frameworks récents à la mode), et ça ne s'est pas imposé...i.e. mode/tendance ? - qui utilisera Ruby on Rails dans 2, 3 ans ? - API pas stabilisées, toujours besoin de migrer (péniblement) vers les versions les plus récentes (e.g. migration vers Rails 2.0) - pas assez de plugins, notamment plugins insuffisants pour authentification - prototype et scriptaculous sont des librairies javascript... et pas du tout besoin de ror pour faire de l'AJAX !!! (et franchement expliquer l'intéret de RJS, ce n'est pas facile à faire sans entrer dans les détails) - faire fonctionner RoR dans le monde réel est aussi bien plus difficile que PHP, i.e. avec Apache, plusieurs serveurs et du load balancing... - ouais, ben ok pour MVC, mais on va essayer de la faire avec Cake PHP... Perso, je suis convaincu de l'intéret des modèles MVC, de la nécessité des principes de développement DRY, des interfaces REST. Je crois que les méthodes de développement "agile" sont prometteuses et peuvent nous sortir de certains "marasmes" d'un mode de développement très linéaire et formel avec specs super détaillées, en tout cas pour des applis web (et je crois que les applis du futur seront surtout web). Je trouve que RoR m'aide à faire tout cela, mais je ne suis pas convaincu que ce soit le meilleur choix, et sûrement pas pour tout le monde. Pour l'instant, pour moi, je fonce sur RoR --~--~---------~--~----~------------~-------~--~----~ 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] -~----------~----~----~----~------~----~------~--~---
