Je comprends tout à fait votre vision, mais d'un autre coté il existe un pool de développeurs rails ou ruby qui n'attendent que de pouvoir exprimer leurs talents :) Quant à la "formation" à Rails et meme à Ruby, ca ne me semble pas insurmontable lorsque l'on a à faire à un développeur relativement compétent et peut etre fait assez rapidement.
2008/2/5 Emmanuel Netter <[EMAIL PROTECTED]>: > > 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] -~----------~----~----~----~------~----~------~--~---
