“Décision Informatique”, le magazine de 01net, consacre 4 pages à Ruby
on Rails, dans son numéro 711.
Je viens de parcourir très rapidement l’article, et ce qu’il en
ressort, c’est que c’est une technologie certes jeune, mais qui séduit
beaucoup les développeurs grâce à sa facilité d’une part, et les
entreprises de l’autre, grâce à une productivité hors-norme.
Si la question de l’hébergement et des serveurs à utiliser est réglé
pour l’auteur de l’article et les personnes citées, c’est toujours le
problème de l’intégration à un modèle de données existant qui revient.
Parmi les personnes interrogées, on notera Richard P.,
fondateur du portail RailsFrance et organisateur de Paris on Rails
(entre autres !).
–
Guillaume DESRAT / Zifro AKA guillaumed
Secrétaire de l’association Ruby France
http://www.rubyfrance.org/
Le 22/03/07, Guillaume Zifro DESRAT a écrit :
problème de l’intégration à un modèle de données existant qui revient.
Je pense que c’est un faux problème. J’ai le “plaisir” de travailler sur
ce
genre de modèle de données, on dirait que les noms des tables et des
champs
sont passés à un générateur de chaîne aléatoire. Utilisation de multiple
clés composées là ou une table associative serait la norme, redondance,
suite de booléen concaténés dans un champ, relation entre des tables
situées
dans des bases différentes, j’en passe et des meilleurs.
Alors accuser Rails qu’il est incapable de reprendre ce genre de modèle
est
un peu fort. D’une part le “problème” serait avec N’IMPORTE quel
framework,
d’autre part le vrai problème est l’entreprise qui ne souhaite pas
refaire
un vrai modèle de données. Mais il est sûrement plus facile d’accuser
l’outil que de se remettre en question …
Rails est un framework qui permet de travailler dans un cadre de travail
propre car régie par des règles. Si l’entreprise souhaite utiliser un
tel
cadre tout en conservant une base bancale, il ne faut pas se plaindre du
résultat bancal. L’Entreprise est schizophrène ça on le sait, mais il
faut
arrêter les FUD.
Salut,
Je pense que c’est un faux problème. J’ai le “plaisir” de travailler sur ce
genre de modèle de données,
[ snip]
L’Entreprise est schizophrène ça on le sait, mais il faut
arrêter les FUD.
FUD! Tu y vas fort…
Il y a juste un tout petit problème (pour le décideur), l’article est
titré “Rails: développer plus vite, plus propre”.
C’est, je crois, honnète de lui expliquer que ce ne sera pas le cas
avec un modèle de données bancal.
J’ai l’honneur d’avoir fait parti des interviewés et j’avais demandé au
rédacteur de modifier la phrase incriminée par un truc plus soft visant
Ã
nuancer un peu ses propos. Cela n’a visiblement pas été pris en compte.
Rails est “capable” de prendre en compte de modèles de données “non
conformes” mais ce qui est en jeu c’est l’un des avantages de Rails qui
est
la rapidité de développement. Si l’on s’attaque à des modèles existants
“non
conformes” le gain de productivité est moindre.
Sam
Le 23/03/07, Frédéric Logier [email protected] a écrit :
Ou plus
précisément, j’aimerais savoir qu’elles solutions on a quand on veut
simplement héberger un “petit” site.
si le site est vraiment petit (quasiment pas de connexions multiples
simultanées), les solutions low-cost de dédiés marchent bien (20 à 30€
HT par mois).
gUI
Guillaume “Zifro” DESRAT a écrit :
Si la question de l’hébergement et des serveurs à utiliser est réglé
pour l’auteur de l’article et les personnes citées,
J’aimerais bien connaître les solutions qu’ils proposent. Ou plus
précisément, j’aimerais savoir qu’elles solutions on a quand on veut
simplement héberger un “petit” site.
Pour info, je m’oriente en ce moment vers du serveur virtuel (chez sivit
pour être précis).
++
yk
Mon avis personnel est qu’au lieu d’adapter le framework à une base
bancale, le mieux est de passer du temps à faire l’inverse.
Non conforme à Rails ne veut pas nécessairement dire bancal non ???
Et puis je ne sais pas si c’est si conséquent que ça l’adaptation en fait…
gUI
–
Guillaume B. : (05 61) 19 40 65 / bureau 602N
Le 23/03/07, Mathieu C. a écrit :
avec un modèle de données bancal.
Alors autant être honnête jusqu’au bout et ne pas pointer le doigt sur
Rails. J’aurais plutôt mis :
Si votre modèle de données ne respecte pas les conventions de base de
nommage et de relation entre les tables alors il y a un temps assez
conséquent à adapter le framework à ce modèle. Et comme le dit Samuel
l’avantage est moindre.
Mon avis personnel est qu’au lieu d’adapter le framework à une base
bancale,
le mieux est de passer du temps à faire l’inverse. Une base est le coeur
du
SI, si celle-ci est bancale cela impact l’ensemble du SI … Ne vaut-il
pas
mieux passer un peu de temps à refaire une base puis un script de
migration
pour envisager les développements futurs et l’évolution du SI plus
sereinement ?
Ceci est un autre débat, mais représente le problème numéro 1 des PME :
évoluer sans faire d’efforts de réflexion, n’avoir une vision qu’à court
terme. Pour ces entreprises ce n’est pas uniquement le framework web qui
apportera la solution, aussi bien soit-il.
En résumé si l’application est stratégique, alors cet effort est
indispensable.
Le 23/03/07, Guillaume B. a écrit :
Mon avis personnel est qu’au lieu d’adapter le framework à une base
bancale, le mieux est de passer du temps à faire l’inverse.
Non conforme à Rails ne veut pas nécessairement dire bancal non ???
Dans Rails la convention veut qu’une clé primaire s’appelle “id” et pas
“Pmacleenbois” dans la table1 et “Pmacledesbois” dans la table2, idem
pour
les FK “id_table” au lieu de trucmuche. Ceci est facilement changement
dans
les modèles Rails ou l’on peut nommer son modèle à sa manière et
utiliser
set_table_name et set_primary_key. Mais c’est une perte de temps, le
vrai
problème c’est que bien souvent il n’y a pas de convention du tout en
entreprise. Alors évidement un framework tel que Rails révèle bien plus
les
problèmes que lorsqu’on gruik ses requêtes SQL en PHP.
Et puis je ne sais pas si c’est si conséquent que ça l’adaptation en
fait…
Tout dépend du modèle. Lorsqu’il s’agit de n’utiliser que des
set_table_name
et set_primary_key c’est simple. Mais lorqu’il faut commencer à jongler
avec
le plugin composite_primary_keys et des Model.establish_connection parce
que
des clés composées inutiles à 90% pullulent et des relations entre des
tables de bases différentes sont définies, c’est une autre paire de
manche
… Quand on en vient à refaire virtuellement le modèle de données dans
Rails au lieu de développer l’applicatif, il y a un réel soucis. Et
Rails
n’en n’est que le révélateur.
Le 23/03/07, Lionel B. a écrit :
En fait à moins qu’on ait à faire face à des modèles très complexes,
Oui le débat concerne bien sûr ce type de modèle.
Frédéric Logier wrote the following on 23.03.2007 11:39 :
Alors autant être honnête jusqu’au bout et ne pas pointer le doigt sur
Rails. J’aurais plutôt mis :
Si votre modèle de données ne respecte pas les conventions de base de
nommage et de relation entre les tables alors il y a un temps assez
conséquent à adapter le framework à ce modèle.
En fait à moins qu’on ait à faire face à des modèles très complexes,
l’adaptation n’est pas très difficile. La première étape est de faire
tourner une migration qui transforme le schema de la base en un schema
adapté à ActiveRecord et le tour est joué. Jusqu’ici je n’ai pas
rencontré de bases dont le schema nécessitait plus d’une petite semaine
pour le comprendre puis scripter la transformation (et de toute manière,
il faut bien comprendre le schema, ce qui est le plus long à mon sens).
Le vrai problème, c’est lorsque l’appli Rails n’est pas la seule Ã
accéder à la base. C’est assez commun et il n’est pas forcément aisé ou
même possible de faire évoluer les autres composants du système. Dans ce
cas soit on peut travailler sur une autre base et envoyer les
modifications par batch sur la base d’origine, soit on rame (et il est
parfaitement possible que faire évoluer l’appli d’origine au lieu de la
recoder devienne la meilleure approche)…
Lionel.
Salut,
Alors autant être honnête jusqu’au bout et ne pas pointer le doigt sur
Rails.
C’était presque “pire” dans le dossier précedent publié par
01-Informatique en octobre dernier.
-cite--------------
…/…
Dernière limite, conceptuelle celle-là. Rails s’avère très mal adapté
à la reprise
d’applications existantes, surtout si le modèle de données existe déjà
et qu’il n’est pas parfait. « Rails est surtout adapté au
développement de nouvelles applications métier, et autour de gros
projets dans lesquels on manipule et met en forme de nombreuses
données. Le gain sera encore plus significatif si le besoin
d’interaction avec les données devient très intense », analyse Nicolas
Cavigneaux, ingénieur développement spécialiste de Rails.
…/…
Frédéric Logier wrote the following on 23.03.2007 13:46 :
Le 23/03/07, Lionel B. a écrit :
En fait à moins qu'on ait à faire face à des modèles très complexes,
Oui le débat concerne bien sûr ce type de modèle.
Dans ce cas, le temps mis à analyser le modèle existant n’est-il pas du
même ordre que celui nécessaire pour coder une migration (c’est ce que
je pense en tout cas) ? Si c’est le cas, on est probablement plus
rentable en faisant l’effort de la migration : on code beaucoup plus
vite le reste de l’application.
Lionel
Bonjour à tous,
on dirait que les noms des tables et des champs sont passés à un
générateur
de chaîne aléatoire. Utilisation de multiple clés composées là ou une
table
associative serait la norme, redondance, suite de booléen concaténés
dans un
champ, relation entre des tables situées dans des bases différentes…
Ca m’a bien fait rire, car c’est la misere que je vis depuis maintenant
1
an.
Comment reprendre l’existant, quand il est pourri à ce point ?
-
L’existant doit continuer à tourner tant que le nouveau projet n’est
pas
fini, testé, debuggué…
Ca c’est un parametre qui a son importance. Faire évoluer l’existant :
Impossible, il y a trop de programmes, eux memes pourris (VB, macros Xls
et
j’en passe…) qui sont super interdépendants. Meme quand on touche Ã
rien
ça buggue, alors imaginez si on commence à modifier les tables !!!
-
Refaire tout à partir de 0 : Beh oui c’est ce que je suis en train de
faire ! Mais comment récupérer les données de l’existant ?
Faire un batch ? Mon doigt dans l’oeil oui ! C’est bien trop
compliqué…
Imaginez 14 bases de données distinctes, avec des tables sans clefs
primaires, des relations fantomes, des clefs concaténées de plusieurs
champs, qui eux meme ont changé de table entre temps…
Il me faudrait un temps hallucinant à faire un parser, et surtout le
tester,
etre sûr que toutes les données sont bien arrivées là où elles doivent
aller, que les relations qui n’existaient pas se sont bien mises en
place…
Rien que le travail de vérification, je vais aller plus vite à tout
ressaisir.
Et le temps, j’en ai besoin pour développer, pas pour faire un parser en
bois que j’effacerai lorsqu’il aura fait son travail.
Mon avis perso, c’est qu’il vaut mieux passer du temps, et meme si ça
coute
une fortune à l’entreprise, pour tout refaire propre.
A vouloir économiser, travailler avec un modele en bois, c’est une perte
de
productivité au quotidien…
Certes il y a une grosse période d’anxiété, mais si le patron est
intelligent, il aura compris qu’il sera gagnant demain.
Et puis les truffes qui écrivent leur torchon à 2 francs (“Décision
Informatique” ou autre), ils disent n’importe quoi, du moment qu’on
achete
leur papier-cul, c’est rien que ça qui les interesse.
Lol je me relis, et je me rends compte que je suis pas trés positif !
Bon allez, je vais poser des rails, ça va me faire du bien 
A tous, ++
Le 23/03/07, Mathieu C. [email protected] a écrit
:
Salut les blasés ! Pour qui vous allez voter dans 1 mois ? Besancenot,
Laguiller, les entreprises si méchantes et tellement bêtes qu’elle ne
comprennent même pas que dépenser de l’argent à tout va peut servir
parfois
à quelquechose sont les entreprises qui vous font vivre… Enfin je dis
ça
je dis rien.
Au fait, si ça vous plait pas les articles, pourquoi n’en ecrivez-vous
pas ?
Si les entreprises ne sont pas capables de vous comprendre pourquoi ne
pas
créer la votre ?
Le 23/03/07, Frédéric Logier [email protected] a écrit :
Le 23/03/07, Samuel DECHOMETS a écrit :
Salut les blasés ! Pour qui vous allez voter dans 1 mois ? Besancenot,
Laguiller, les entreprises si méchantes et tellement bêtes qu’elle ne
comprennent même pas que dépenser de l’argent à tout va peut servir parfois
à quelquechose sont les entreprises qui vous font vivre… Enfin je dis ça
je dis rien.
Heu en quoi le fait qu’une entreprise te paye t’empêche de réfléchir, de
regarder la réalité en face et de faire des critiques constructives ?
Tiens c’est marrant le post de Frédéric est justement en ce sens :
“Mon avis perso, c’est qu’il vaut mieux passer du temps, et meme si ça
coute
une fortune à l’entreprise, pour tout refaire propre.
A vouloir économiser, travailler avec un modele en bois, c’est une perte
de
productivité au quotidien…”
Tu dérives dans le troll mon Samuel 
Au fait, si ça vous plait pas les articles, pourquoi n’en ecrivez-vous
pas ?
Si les entreprises ne sont pas capables de vous comprendre pourquoi ne pas
créer la votre ?
Perso mon objectif dans ce fil est de détruire ce FUD au moins sur cette
liste. Le reste ne concerne que ma vie privée
Le 23/03/07, Frédéric Jay a écrit :
Lol je me relis, et je me rends compte que je suis pas trés positif !
Bon allez, je vais poser des rails, ça va me faire du bien
A tous, ++
Frédéric, tout simplement merci. Voilà la triste réalité des PME en
France :
le problème N’EST PAS Rails. Le problème sont les gens en position de
prendre les décisions qui ne le font pas pour ne prendre aucun risque.
Leur
crédo est : Tant que ça marche faut pas toucher.
L’article de Décision Informatique est dans l’ensemble très positif
hormis
ce FUD, mais nous y viendrons à bout
Le Vendredi 23 Mars 2007 16:02, Samuel DECHOMETS a écrit :
Salut les blasés ! Pour qui vous allez voter dans 1 mois ? Besancenot,
Laguiller, les entreprises si méchantes et tellement bêtes qu’elle ne
comprennent même pas que dépenser de l’argent à tout va peut servir parfois
à quelquechose sont les entreprises qui vous font vivre… Enfin je dis ça
je dis rien.
Dans la bande à Ségo, il ont choisit Rocard. Y’a pire