J’ai un client qui souhaite développer une appli en mode SaaS et bien
que convaincu de la puissance de RoR, il est résolument tourné vers la
technologie PhP, principalement pour des raisons de disponibilité des
compétences.
Comment convaincre un client d’utiliser Ruby on Rails quand son
principal argument est : “oui mais ce sera plus dur de trouver des
développeurs RoR pour maintenir l’application”?
Sinon (à contrecoeur), quel framework PhP est le plus adapté pour
développer une appli quand on connait bien Rails? (aboutissement du
framework, disponibilité des plugins, RESTful, …)
D’une manière plus générale, avez-vous déjà été confronté à ce
problème?
J’ai un client qui souhaite développer une appli en mode SaaS et bien
que convaincu de la puissance de RoR, il est résolument tourné vers la
technologie PhP, principalement pour des raisons de disponibilité des
compétences.
Comment convaincre un client d’utiliser Ruby on Rails quand son
principal argument est : “oui mais ce sera plus dur de trouver des
développeurs RoR pour maintenir l’application”?
Il a pas complétement tord. Même si c’est avec ce genre d’attitude qu’on
manque de ressource aussi. C’est un cercle vicieux.
Ce que tu peux lui répondre est que le nombre de ressource ne fait pas
la qualité de la ressource. Les ressources RoR sont plus des personnes
qui ont découvert et aimé RoR pour sa philosophie et tenteront d’y
coller. En PHP, la quantité de mauvais développeurs est incroyable. Oui
tu as de bon développeur. Mais combien de bon pour 40 développeurs du
dimanche qui ne connaissent même pas la base de la POO.
Sinon (à contrecoeur), quel framework PhP est le plus adapté pour
développer une appli quand on connait bien Rails? (aboutissement du
framework, disponibilité des plugins, RESTful, …)
Tous les frameworks PHP sont plus lent que RoR, c’est une certitude.
Seul PHP de base est plus rapide que RoR.
D’une manière plus générale, avez-vous déjà été confronté à ce
problème?
C’est un classique comme pour RoR vs Java.
Personnellement mon argumentaire est dans ce sens :
Le fun, le ruby est un langage fun et a été fait pour ça. Le fun dans
le développement peux permettre d’avoir une meilleur ambiance dans son
équipe. Un développeur heureux est un meilleur développeur.
Les test unitaires. La communauté Ruby est tourné vers la logique TDD
(de manière général et il faut l’entretenir). Beaucoup d’outil sont
prévu pour ça. Faire des test unitaire en PHP est plus difficile au
premier abord. Il faut commencer par créer les briques nécessaire pour
avoir un environement de test valable.
Le cloud computing. PHP a selon moi un gros défaut que Java a moins
typiquement. C’est sont sandboxing dans Apache. Si tu veux faire du
cloud avec PHP. Soit tu as un load-balancer en front et tu push sur
différent Apache soit tu utilises un autre langage pour faire du
scripting avec tes workers de queue. Ruby est en train d’exploser avec
la logique du cloud computing. Car il est très simple de sortir de son
application et de rester en ruby.
Enfin le ruby et ensuite RoR ne sont pas si compliqué que ca à utiliser
et apprendre. Selon moi il suffit d’un “expert” dans une équipe de 5
personnes. Du code review et hop on a 5 développeurs confirmé en 2 mois.
Il ne faut pas hésiter à chercher des développeurs non Raileurs si on a
déjà des bons raileurs.
Personnellement j’ai tres vite switché de Symfony en php à ruby on
rails,
revenir à symfony n’est pas toujours simple mais j’en ai beaucoup
mieux compris les arcanes grâce à RoR. (Mais que c’est dure de devoir
placer des “;” partout)
Pour dire que Symfony s’inspire fortement de RoR donc il sera le plus
proche de ce que tu connais
C’est vrai qu’il y a moins de dev Ruby que PHP, mais, le ticket
d’entrée (apprentissage de ruby) est faible je trouve. Il suffit de
connaitre un peu l’objet, et d’être curieux. En gros, un dev java
(çay’en a plein sur le marché) peut apprendre (et souvent veut apprendre)
ruby rapidement…
C’est un argument qui marché (on dirait) chez le client chez qui je
suis actuellement.
Bon courage.
ps: L’effet cercle vicieux dont parle Cyril est intéressant à mentionner
aussi.
Enfin, l’argument du cercle vicieux, un client s’en tape les
coucougnettes
dans une porte-fenêtres : c’est pas son problème de voir apparaitre Ruby
on
Rails sur l’autel de la gloire.
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.
Enfin, l’argument du cercle vicieux, un client s’en tape les coucougnettes
dans une porte-fenêtres : c’est pas son problème de voir apparaitre Ruby on
Rails sur l’autel de la gloire.
C’est malheureusement vrai … c’est le notre de problème…
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.
discussion.
5) un vieil article du Journal du Net
Community", c’est une plateforme communautaire de blog, de
présentation de projets et de joab board. Le design est vraiment
chouette, et les étudiants seraient fiers qu’on l’utilise pour
promouvoir RoR en France. Pensez-vous que ce type de démarche serait
utile? Si l’association Rails France souhaite donner un petit
rafraichissement graphique à son site actuel, cela peut aussi être une
bonne oportunité.
Si le projet est open source, l’association RubyFrance serait
effectivement intéressée.
Pour information, l’association RailsFrance n’existe pas.
Si le projet est open source, l’association RubyFrance serait
effectivement int ress e.
Oui, l’idée est de le rendre open-source et à disposition de la
communauté française/francophone des utilisateurs de RoR. Il y a
certainement un peu de maintenance à effectuer sur le projet et on
pourrait même ajouter des fonctionnalités. Les étudiants étaient
débutants en dév mais assez expérimentés en design et je trouverais
çabête que le projet tombe aux oubliettes une fois le semestre
terminé.
Je vous montre ça en fin de semaine.
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.
Je suis complètement d’accord avec tous les arguments que tu as
développés, ainsi que les arguments développés plus haut dans la
discussion.
Il y a sans doute encore un vrai besoin pour des non-techniciens
d’avoir une visibilité sur les avantages de cette technologie.
Le décideur non-technicien va certainement taper “ruby on rails” dans
Google France et tombera en première page sur:
un vieil article du Journal du Net
Les liens suivants mélangent des articles de blogs en français ET en
anglais!
Je pense que cela pourrait être pas mal de développer l’article de
Wikipedia, en parlant de la culture qui gravite autour de la techno
(TDD, Agile, Small and Special, Getting Real, etc.) et des témoignages
de sociétés qui ont fait ce choix, vos arguments manquent dans cet
article!!
Je suis également formateur RoR dans une école de création web à
Paris, et l’un des groupes a réalisé un projet nommé “Rails
Community”, c’est une plateforme communautaire de blog, de
présentation de projets et de joab board. Le design est vraiment
chouette, et les étudiants seraient fiers qu’on l’utilise pour
promouvoir RoR en France. Pensez-vous que ce type de démarche serait
utile? Si l’association Rails France souhaite donner un petit
rafraichissement graphique à son site actuel, cela peut aussi être une
bonne
oportunité.
La tendance est favorable, c’est sûr. Mais elle n’est pas aussi
fulgurante qu’on le pensait il y a 5 ans (quand Ruby on Rails a commencé
à être médiatique). C’est d’ailleurs il me semble la conclusion d’une
session du dernier RailsCampParis.
Pour moi c’est le temps normal pour la France. Toujours 5 ans de retard
en IT.
Faut arrêter de se flageller en France. De ce que j’en ai vu, en
Allemagne ou au Canada (plus précisément Montréal), ils ne sont pas plus
avancés que nous.
Des sociétés comme Ubisoft ( à Montréal ) utilise RubyOnRails. Aucune
grosse société, n’ose le pas du Ruby, car les autres grosse société ne
le propose pas.
Le jour où Capgemini me dira que leur pôle nouvelle technologie ne fait
plus du Java 1.4 ( véridique ) et a des projets en Python ou Ruby, alors
je me dirais que la ces technos sont vraiment arrivé sur le
marché.Entendre par le Directeur nouvelles techno de CapGemini, qu’il ne
connait pas RubyOnRails, ca fait bizarre…
–
Vous avez reçu ce message, car vous êtes abonné au groupe “Railsfrance”
de Google G…
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]
