Appel à argument et info : contrer les sce ptiques Ruby on Rails

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é :wink:

----- 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èsliné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

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 :slight_smile:
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 N. [email protected]:

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 être fait assez rapidement.

J’ai déjà eu l’occasion d’animer une formation Ruby : un bonheur.

Il est tellement facile de prendre pied dans Ruby (et aussi dans Rails,
après c’est de l’experience). Si on déblaie adroitement les quelques
pièges
de compréhension qui peuvent freiner les premiers pas, la suite
s’enchaine
naturellement.

Et comme la découverte des choses bien pensées et digestes procure un
réel
plaisir, l’auditoire est vraiment agréable.

DONC : former des développeurs Ruby/Rails n’est vraiment pas un obstacle
(on
rique juste de les rendre accros :wink:

BTW : Si quelqu’un à besoin d’une formation d’initiation, il
me
sonne :slight_smile:


Web development is coming of age with Ruby on Rails
blog.lachaise.org

Le mardi 05 février 2008 à 07:41 +0100, Emmanuel N. a écrit :

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é :wink:

Je me permet de supposer que dans le monde réel avant de virer quelqu’un
on peut avant discuter avec lui, voir lui mettre une certaine
“pression”.
Pour prendre un exemple un peu extrême, j’ai connu une boite dont les
développeurs faisaient du cobol sous msdos et sont passés à du visual
cobol. Inutile de dire que ce genre de boite n’a pas d’avenir, hormis
péricliter sur un existant qui diminue chaque année.

Enfin je te souhaite bon courage pour ta boite piloté par tes devs :wink: