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

Community FR
#21

Frédéric Logier a écrit :

monolithique de Linux dépassée, mais dans la réalité c’est le
pragmatisme de Linus qui réussi.

Je rajouterai un point sur cette comparaison Weblocks/Rails: lisp =
beurk! :stuck_out_tongue:

#22

Le jeudi 31 janvier 2008 à 10:54 +0100, philippe lachaise a écrit :

Quand au manque de “conception” et de “vision” je ne pense pas que
l’auteur à passé des mois à coder en Rails. Il y aussi fort à parier
que les frameworks “bien pensés” ne sont pas encore assez avancés
pour aborder les soucis de détail que Rails (+plugins) résoud de façon
pragmatique.

Un peu comme Linux vs Hurd on dirait :slight_smile:
Hurd (micro-kernel) sur la papier c’est top et la conception
monolithique de Linux dépassée, mais dans la réalité c’est le
pragmatisme de Linus qui réussi.

#23

une des personne qui a dénigré rails m’a dit qu’il y avait eut un gros
buzz Webdev (surtout parceque ça permettait de programmer en français)

Ptet qu’au lieu de la pluralisation en Nnglais Webdev de base sur
l’accord
du participe en Français :wink:

Blague à part, programmer en Français comme critère de choix ça situe le
niveau : on parle pas au bon public.

Ce qui m’amène à déplacer le débat : chez qui s’adresser en premier pour
vendre du Rails ? Quelles sonnettes tirer pour ne pas trop avoir à nager
contre le courant ?

Le bon public pour Rails est-ce les mêmes que pour Java ou bien ceux qui
ne
sont pas encore passé au web “enterprisey” ?
Savons nous même les trouver ?

#24

Hurd (micro-kernel) sur la papier c’est top et la conception
monolithique de Linux dépassée, mais dans la réalité c’est le
pragmatisme de Linus qui réussi.

Ce qui est rigolo, c’est que Linux était déjà dépassé lors de sa
conception (1992). Cf le débat Linux/Tanenbaum, dont j’ai trouvé une
traduction ici :
http://www.velic.com/publications/tribunelibre/fr-appa.html

(-:

gUI

–
Pour la santé de votre ordinateur, préférez les logiciels libres.
Lire son mail : http://www.mozilla-europe.org/fr/products/thunderbird/
Browser le web : http://www.mozilla-europe.org/fr/products/firefox/
Suite bureautique : http://fr.openoffice.org/

#25

Le jeudi 31 janvier 2008 à 14:00 +0100, Guillaume B. a écrit :

Hurd (micro-kernel) sur la papier c’est top et la conception
monolithique de Linux dépassée, mais dans la réalité c’est le
pragmatisme de Linus qui réussi.

Ce qui est rigolo, c’est que Linux était déjà dépassé lors de sa
conception (1992). Cf le débat Linux/Tanenbaum, dont j’ai trouvé une
traduction ici :
http://www.velic.com/publications/tribunelibre/fr-appa.html

En effet, mais c’est surtout le modèle de développement, bazar, de Linus
et son release early, release often, révolutionnaire à l’époque face au
modèle cathédrale qui ont fait le succès de Linux. De plus Minix n’était
pas libre à l’époque.

#26

Pour continuer mon post précèdent et pour ceux qui ne les auraient
lus, voici 2 grands classiques

Ce sont pour moi les meilleurs argumentaires de Rails

#27

Ce qui m’amène à déplacer le débat : chez qui s’adresser en premier
pour vendre du Rails ?

Je crois que pour bien parler de Rails il faut se souvenir de la
philosophie de DHH en créant Rails

  • Pragmatisme : Ca fait pas tout, mais ça le fait bien. Faut pas
    essayer de refaire YouTube en Rails. Rails à été fait pour un projet,
    et tout ce qui ressemble à Basecamp, en terme de fonctionnalité ou de
    business plan, sera plus
    approprié.- Opinionated software (Je sais pas comment traduire ça) : DHH a fait
    des choix “idéologiques” donc forcément ça ne peux pas plaire à tout
    le monde. Mais c’est pour ça qu’on aime Rails. Et il en auront
    toujours qui vont détester.
  • Programmer Happiness : Donc gain de productivité. Pour moi c’est le
    principal argument de Rails, on peut avoir un site qui tourne à 80%
    des ‘cases stories’ en très peu de temps.

Je pense donc qu’on réussi à vendre Rail :

  • quand on a à faire avec des décideurs qui comprennent ces concepts
  • quand le plaisir des programmeurs est pris en compte dans le choix
    de l’outil
  • quand le projet se prête bien à Rails (Truc à la mode sans trop de
    charge, Intranet, Quick release, …)

Et pas quand :

  • On doit convaincre une assemblée de consultant, le compris ira vers
    Java.
  • On doit convaincre un décideur qui a peur de prendre des risques :
    il choisira alors une solution qui a fait ses preuves.
  • On doit faire l’usine à gaz d’une banque.

En résumé, mon opinion c’est qu’il y aura toujours des sceptiques, et
des enthousiastes. Et les septiques, nous rejoindrons dans 5 ans quand
tous les problèmes (objectivement, il y en a encore) de Rails seront
résolus.

Petite astuce pour réussir à vendre Rails : J’ai entendu parlé d’un
projet d’intranet où ils ont proposé Rails pour faire une petite
maquette fonctionnelle, et ils sont resté sur Rails pour la mise en
production, parce que ça marchait.

#28

J’ai mis le texte en ligne sur un pseudo wiki.

Il faut quand même un mot de passe pour modifier. Pour être sur qu’il ne
soit pas découvert par n’importe qui, j’ai choisit le mot de passe:

rails

Vous pouvez donc apporter vos modifications

http://railsfudanihilation.pbwiki.com/

#29

quand le projet se prête bien à Rails (Truc à la mode sans trop de
charge, Intranet, Quick release, …)

J’espère prouver le contraire :

  • J’ai une quarantaine de controlleurs (en restful ça monte vite)
  • Le site (grand public) a une ambition nationale, e-commerce, pas
    vraiment
    mode.
  • La logique est simple mais l’application est globalement assez
    complexe

Ca avance néanmoins bien (touch wood !), à suivre … :slight_smile:

#30

Je pense que ça suffira, donc inutile de se créer du tracas à mettre en
place un hébergement de wiki pour l’instant.

philippe lachaise a écrit :

#31

Super !

Sinon tu veux toujour un hébergement de wiki ou celui-ci suffira ?

#32

Le 31 janv. 08 à 15:43, Christophe Guégan a écrit :

Et pas quand :

  • On doit convaincre une assemblée de consultant, le compris ira vers
    Java.
  • On doit convaincre un décideur qui a peur de prendre des risques :
    il choisira alors une solution qui a fait ses preuves.
  • On doit faire l’usine à gaz d’une banque.

Argh, mais vous avez quoi contre les banques ? :wink:
Pour rappel, Sylvain Perez a expliqué que, chez RBC Dexia Investor
Services, Rails a été adopté avec un cadre bien défini. Rails, oui,
mais pas pour tout. Le reste se fait en JAVA.

J’ai acheté ce livre et j’en suis bien content ; à lire, d’autant que
l’on peut le faire par bouts de 5 minutes, en passant d’un essai à un
autre.

Guillaume “Zifro” DESRAT
Président de l’association Ruby France
http://www.rubyfrance.org/

#33

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

#34

Le lundi 04 février 2008 à 10:54 -0800, pierrederome a écrit :

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.

Ca revient à niveler par le bas le niveau de l’entreprise … Au même
titre que lorsqu’une entreprise refuse de passer à OpenOffice sous
prétexte qu’une secrétaire n’a pas envie de faire l’effort, minime, de
changer ses habitudes.

Si un développeur, dit expert, n’est pas capable d’étudier un nouveau
langage qui potentiellement peut apporter beaucoup à l’entreprise, il
doit la quitter, ce n’est pas à l’entreprise de s’adapter à ses
salariés.

Prétexte bidon donc, même si c’est une triste
réalité.

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 ?

Il me semble que l’effet de mode a disparu depuis un moment et qu’il
existe suffisamment d’exemples d’applications Rails et même Django.

  • 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

Restful_auth, AAA, etc etc

  • 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)

Evidement si tu travailles dans une boulangerie qui veut un site web en
Rails parce que le boulanger lit pc expert, tu vas avoir du mal. Soyons
sérieux, on parle de société qui possède des développeurs ou pas ?

  • 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…

Ce ne sont pas les prestataires spécialisés en hébergement Rails qui
manquent … Bearstech, Typhon, …

De plus si le site nécessite du load balancing car forte charge, on
suppose que l’entreprise possède les compétences en administration
système si elle a la prétention de se dispenser d’un prestataire.

  • ouais, ben ok pour MVC, mais on va essayer de la faire avec Cake
    PHP…

Un substrat de Rails …

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

Il n’est pas question d’être convaincu mais d’admettre la réalité que
développer avec un framework MVC coûte moins cher à l’entreprise en
temps de développement et en maintenance.
Après c’est Darwin, celles qui font l’impasse disparaîtront.

#35

pierrederome a écrit :

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.
Dans le cas d’une évolution d’un projet existant, évidemment qu’il faut
y réfléchir à deux fois. Les personnes auxquelles je me suis heurté
partait sur des projets nouveau (vierge), de taille très raisonnable (un
seul développeur qu’il n’avait pas encore recruté, donc pas de
compétence php à mettre à la poubelle). Bref, selon moi des conditions
idéales. Malgré ça, les personnes pensaient que Rails étaient un mauvais
choix, qui risquait plus de les “trainer dans la boue” que PHP.
Je crois aussi qu’adapter
des bases de données existantes à Rails doit être assez pénible.

Normalement, ce n’est pas rails qui s’adapte à la base de données?

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.

C’est sur ce type de projet que je me suis heurté à des peurs

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.

Il n’y avait pas de développeur PHP, il n’y avait que moi.

sinon sur la liste d’arguments contre:

  • performances faibles ou inconnues

Là je dis bof, y’a quand même des sites visités qui tournent en ruby +
rails. Et puis on a vu à la railsconf que le serveur glassfish allait
nous amener de la puissance de feu made in SUN

  • c’est déjà assez difficile de trouver de bons développeurs Java,
    alors Ruby on Rails !!!

Ca c’est effectivement le point qui fait peur au gens

  • 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)

C’est vrai que c’est embêtant de migrer. Pour moi le passage à la 2.0
s’est faite en une après midi au plus, mais quand même.

  • pas assez de plugins, notamment plugins insuffisants pour
    authentification

Rails est le framework MVC disposant du plus grand nombre de plugins je
crois

  • 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…

Même remarque que précédemment: Si tu commence à avoir des gros besoin
de performance, c’est que tu as un peu de sous pour les assurer. Après
le load balancing ou autre, c’est pas sorcier quand on suit un tuto.
Pour moi c’est une peur qui ne correspond pas à une réelle
difficulté.> - ouais, ben ok pour MVC, mais on va essayer de la faire avec Cake

PHP…

C’est vrai que j’ai pas testé. A vrai dire, ruby c’est quand même plus
agréable pour moi à écrire que PHP. Je pense notamment à tout ce qui est
méta-programmation (mais je me trompe peut-être, c’est vrai que je n’ai
pas approfondi 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

Le but de mes argument était de convaincre ceux qui sont dans de très
bonne conditions pour commencer une appli en rails, en supprimant les
peurs qui n’ont pas lieu d’être.

#36

OK pour le jugement du CTO, on ne prend paqs de risques à la légère si
on
est reponsable (Ã tous les sens du terme).

ouais, ben ok pour MVC, mais on va essayer de la faire avec Cake PHP
J’ai essayé, j’ai aussi regardé Symphony.

C’est bien essayé mais ça reste du PHP, et surtout, ça fourmille de
détails
à maitriser qui font que, hormis les grands concepts MCV, c’est retour Ã
la
case départ.

Mon sentiment sincère Rails => Cake = Régression.

qui utilisera Ruby on Rails dans 2, 3 ans ?

Bien là y’a quelque-chose que les juges appellent l’intime conviction :
je
sais pas dire pourquoi, mais ce sera encore là dans 10 ans et je parie
ma
chemise dessu, surtour sur Ruby (j’ai pensé la même chose pour C++ en 89
et
pour XML en 96).

2008/2/4 Frédéric Logier [email protected]:

titre que lorsqu’une entreprise refuse de passer à OpenOffice sous

  • prototype et scriptaculous sont des librairies javascript… et pas
    difficile que PHP, i.e. avec Apache, plusieurs serveurs et du load

linéaire et formel avec specs super détaillées, en tout cas pour des

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

#37

Le 30/01/08, Yann KLIS a écrit :

Aujourd’hui, ils existe de nombreuses entreprises de
service en informatique qui proposent des services sur ce
framework en france
http://www.nuxos.fr/
http://www.pierlis.com/
http://www.webpulser.com/competences/ruby-on-rails
(Ce serait bien de compléter la liste)

Novelys, http://www.novelys.com

Ascian ?
http://www.ascian.fr

Ils font du “Développent de pointe” d’après http://www.ascian.fr/thech

– Jean-François.

–
Ruby ( http://www.rubyfrance.org ) on Rails ( http://www.railsfrance.org
)

#38

Ascian ?
http://www.ascian.fr
Ils font du “Développent de pointe” d’après http://www.ascian.fr/thech

LOL ! Bon vous moquez pas les gars :wink:
On court tous après le temps donc le site web il patiente …

J’voulais pas en parler avant que tout ça soit montrable et proprement
mis
en route mais puisque quelqu’un à “renversé les pois” et laissé le chat
sortir du sac j’avoue :

Alors pour info :

Ascian est né de la réunion d'anciens collègues qui se sont retrouvés grace à Rails. Tous ont de la bouteille (business et/ou technique) L'objectif correspond bien à ce que vous avez pu lire et si ce n'st pas déjà plus avancé c'est que JUSTEMENT : c'est encore la croix et la bannière de vendre du Rails en France !

Mais comme on est convaincus que ça vaut la peine de patienter on va
démarrer.
On fera même du PHP ou du .NET s’il le faut en attendant mais
comptez-nous
d’avance parmis les boites qui font du Rails en France :slight_smile:

Philippe.

2008/2/6 Jean-François Trân [email protected]:

Ruby ( http://www.rubyfrance.org ) on Rails ( http://www.railsfrance.org )

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

#39

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.

C’est sur ce type de projet que je me suis heurté à des peurs

Pareil ! Des tout petits projets, sans grosse charge prévisible ni
réelle
complexité. Qui plus est, ils avaient déjà été démarrés from scratch en
Rails.

La peur l’a emporté.

  • Les contre arguments puaient le FUD (un bon vendeur de PHP qqpart
    c’est
    sûr)
  • Aussi, il faut l’avouer ça avait mal commencé : l’apprentissage de
    Rails
    par les pionniers a laissé pas mal de cadavres d’applications boiteuses
    (ben
    oui, il y a un début à tout, faut bien faire des conneries pour
    apprendre
    :wink:
    Donc il y a aussi à effacer ça et là des mauvais souvenirs de foirages
    dûs
    au manque de maturité (normal) sur le nouvel outil.

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

#40

Tiens, pour l’argument “qu’est-ce que je fais de mon armée d’experts
PHP” :

“Rails for PHP Developers”
http://www.pragprog.com/titles/ndphpr

C’est tout frais ça vient de sortir :slight_smile:

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