Avis objectifs

Community FR
1

Bonsoir,

Je viens poster pour la première fois sur cette ML dans le but de
recueillir quelques avis objectifs.

Nous sommes aujourd’hui face à une problématique d’entreprise.

En tant qu’agence Web, nous avons entrepris de modulariser les
applications développées. Cette démarche a déjà bien avancé mais sur un
Framework PHP - que je ne citerais pas - mais en tous les cas, qui ne
satisfait nos exigences.

L’idée est pour nous de choisir une technologie sur laquelle
redévelopper notre existant et bien entendu poursuivre dans cette voie.

Fidèles à PHP depuis plusieurs années maintenant, nous avons logiquement
débuter par mener un petit benchmark sur les frameworks utilisant ce
langage. Symfony est apparu comme le plus abouti, et surtout le plus
adéquat dans un contexte pro (doc. complète, communauté réactive, etc.).

Un test concluant a été mené au cours d’un premier projet spécifique.

Aujourd’hui, c’est donc toute la méthodologie de l’entreprise que nous
souhaitons remettre en ordre.
Quit à se remettre en question, je me dis que la barrière du langage
n’est clairement pas infranchissable. J’arrive donc tout droit sur ROR
qui semble être la source qui a largement influencé Symfony (en tous cas
pour de nombreux points).

Les seules choses qui me gènent dans Symfony :

  • ORM pas clairement choisi : le livre ne parle encore que de PROPEL qui
    est lent et pas suffisamment suivi. sfDoctrine est développé en
    parallèle mais rien n’est établi. On parle même d’une version “home-made”…
  • L’aspect “copié”… Ne va-t-on pas toujours avoir une longueur de retard
    ?
  • Les performances faibles ont souvent été montrées du doigt (mais
    Yahoo! l’utilise, que penser ?)
  • Pas de base de CMS utilisable

Ce qui me fait peur dans ROR :

  • N’est-ce qu’une mode, ou va-t-on tous migrer pour de vrai raisons ?
  • Peut-on vraiment tout développer (je pense notamment à des
    applications en mode FAH qui requièraient certaines particularités)
  • Comment développer modulairement ? (briques news, blog, agenda,
    contact, portfolio, etc.)
  • Les CMS existant sont-ils conforment à notre perfectionnisme (SEF très
    poussé, accessibilité, etc.) ?
  • La documentation semble abondante mais très confuse (sauf côté livres)
  • En combien de temps peut-on être opérationnel (appréhension +
    redéveloppement de notre existant) ?

J’ajoute que les problématiques d’hébergement ne nous concernent pas,
nous avons nos serveurs dédiés.

Un grand merci d’avance pour vos remarques et opinions !

Nicolas CHARLOT

2

Bonsoir,

Pour la doc il y a celle de l’api et le livre. Pas besoin d’avoir de
doublons :slight_smile:

Contrairement à PHP tout est fait en ROR pour développer
modulairement. Il n’y a qu’à regarder les contrôleurs et les layouts
pour que ça saute aux yeux.

Pour voir si ROR n’est qu’un effet de mode ou une réelle opportunité
il suffit de regarder les vidéos qui montrent qu’en peux de temps on
peut développer qqch de fonctionnel avec peu d’effort. Ensuite une
expérience intéressante est de reprendre un projet en PHP pour le
coder ac ROR.

En cmb de tps peut-on être opérationnel? Le tps de lire le livre qui
est très facile d’accès !

Le 01/03/07, Nicolas CHARLOT[email protected] a écrit :

3

Alexis B. a écrit :

Pour la doc il y a celle de l’api et le livre. Pas besoin d’avoir de
doublons :slight_smile:
De quel livre parle-tu précisément ?
Contrairement à PHP tout est fait en ROR pour développer
modulairement. Il n’y a qu’à regarder les contrôleurs et les layouts
pour que ça saute aux yeux.
Le design pattern MVC est présent dans beaucoup de frameworks PHP
aujourd’hui. AMHA, il n’y a pas que cela pour parler véritablement de
modularité.Une brique - à notre sens - c’est :

  • un modèle de données
  • une application front
  • une partie intégrable dans un back-end unifié
  • une intégration dans le site (menus, plan du site, fil d’Ariane)
  • éventuellement, des dépendances avec d’autres briques ou en tous cas
    des comportements variables selon les autres briques présentes

Pour voir si ROR n’est qu’un effet de mode ou une réelle opportunité
il suffit de regarder les vidéos qui montrent qu’en peux de temps on
peut développer qqch de fonctionnel avec peu d’effort. Ensuite une
expérience intéressante est de reprendre un projet en PHP pour le
coder ac ROR.
Côté vidéos, on a exactement la même chose avec Symfony
(http://www.symfony-project.com/), et à priori, le générateur d’admin en
plus.

4

Bonjour,

Le 01/03/07, Nicolas CHARLOT a écrit :

Ce qui me fait peur dans ROR :

  • N’est-ce qu’une mode, ou va-t-on tous migrer pour de vrai raisons ?

je doute que les entreprises ayant choisie Rails l’aient fait sur une
simple
question de mode.
Ce genre de choix impacte directement sur la productivité de
l’entreprise et
ça tombe bien Rails l’améliore :slight_smile:

  • Peut-on vraiment tout développer (je pense notamment à des

applications en mode FAH qui requièraient certaines particularités)

Les applications louées nécessite en général une haute disponibilité. On
en
a déjà discuté sur cette liste, cherche Mongrel, pen, nginx …
http://blog.lienweb.fr/2006/11/20/138-conference-paris-on-rails-slides-de-la-conference-hebergement-haute-disponibilite-d-applications-ruby-on-rails
Voir capistrano pour le déploiement.

  • Comment développer modulairement ? (briques news, blog, agenda,

contact, portfolio, etc.)

Tu peux développer des plugins et des webservices.

  • Les CMS existant sont-ils conforment à notre perfectionnisme (SEF très

poussé, accessibilité, etc.) ?

Voir http://radiantcms.org/ par exemple, mais si vous êtes
perfectionniste
autant développer le votre.

  • La documentation semble abondante mais très confuse (sauf côté livres)

Ca tombe bien, il existe justement des livres très bien écrit et en
français. Voir chez Eyrolles et O’Reilly.

  • En combien de temps peut-on être opérationnel (appréhension +

redéveloppement de notre existant) ?

Tout dépend des compétences et de la motivation de ton équipe. Si les
notions objets sont déjà acquises cela devrait aller vite pour maîtriser
le
langage et le framework en moins d’un mois. Sinon la personne la plus
capable apprend l’outil et ensuite fait un transfert de compétence, cela
devrait être une bonne solution.

5

Le 01/03/07, Nicolas CHARLOT a écrit :

Cette étape était un peu délicate avec notre framework actuel. Comment

faire ça simplement avec rail (sans mode rewrite à ce niveau biensûr) ?

http://dev.rubyonrails.org/browser/plugins/account_location

Tu peux développer des plugins et des webservices.

Il faut que je creuse ça, car le terme “plugins” me laisse plus penser Ã
des extensions qu’à des modules indépendants.

alors regarde du côté des engine.

On est tous OK sur la POO. Et puis on connait Symfony :wink: Le
fonctionnement semble vraiment similaire.

Ce n’est pas trop ce que j’avais lu, cakePHP serait plus similaire.

6

Pour le côté “modules” il y a le projet Cells qui permet d’utiliser une
architecture par composants.
Jamais testé par moi-même mais le projet m’avait l’air intéressant quand
je
suis tombé dessus.
http://rubyforge.org/projects/cells/
http://nick.smt.de/trac/nick/wiki/Cells

Frédéric a parlé des Engines dans un style équivalent il y a une série
de
plugins publiés sur le site http://www.pluginaweek.org/ dont un
“appable_plugin”. Le but initial était de faire ce que faisaient les
engines mais uniquement avec des “simples” plugins, vu que les Engines
sont
devenus des “simples” plugins depuis la version 1.2 l’intérêt tombe un
peu…
Ceci dit je n’ai utilisé ni les engines ni le appable_plugin et ses
petits
copains donc c’est plus des pistes que je te donne que des
recommandations.
(Par contre je suis intéressé ar des retours d’expérience)

Stéphane.

7

Première chose, tu es ici sur une mailing list dédiée à Rails et il est
donc fort probable que nos avis ne soient pas objectifs…

Ensiute, voici comment s’est passé l’apprentissage de Rails dans ma
boîte (et d’ailleurs on a eu exactement les mêmes retours lors de la
conférence Paris on Rails) : tu prends un petit projet pour lequel le
choix de la techno n’aura pas trop d’effets de bord. Ca te permettra
d’apprendre et de développer en même temps ton application. Et tu
comprendras alors très vite l’intérêt de Rails :slight_smile:
Ceci est rendu possible parce que l’apprentissage de Rails est très
linéaire, des choses très simples aux choses très complexes (la barrière
à l’entrée pour J2EE et .Net me semble assez haute et tu vas te rajouter
bcp de tâches purement administratives en plus de ton code utile, tandis
que du côté de PHP, c’est très simple au début, mais on a très vite “faim”).
De plus, il y a plein de gens compétents sur cette mailing list pour
t’assister de manière éclairée (voir également de manière
“professionnelle”).

++

yk

Nicolas CHARLOT a écrit :

8

Yann K. a écrit :

linéaire, des choses très simples aux choses très complexes (la
yk
Je suis persuadé que ROR conviendra parfaitement pour un petit projet “à
part”. Nous avons déjà testé Symfony dont l’approche est réellement très
semblable (constatez par vous-même). La question est de savoir si ROR
correspondra à notre façon de travailler. L’aspect “modulaire” est
notamment une priorité. D’un côté nous menons des projets 100% sur
mesure, mais d’un autre nous souhaitons capitaliser un maximum de code
produire plus rapidement des sites de qualité avec des fonctionnalités
régulièrement semblables.
Pour tout le reste, les avantages d’un tel framework en entreprise sont
nombreux. Pour ne pas que parler d’agilité - puisque c’est le terme en
vogue -, ROR fait partie des frameworks qui offrent une réelle méthode
de travail (documentation, tests, mise en prod, IDE, etc.).

Encore merci pour vos réponses :wink:

Nicolas

9

Nicolas CHARLOT a écrit :

La question est de savoir si ROR correspondra à notre façon de travailler.
OK, je vais répondre un peu plus clairement.

Quoi de mieux pour savoir si ROR correspond à votre manière de
travailler que de l’essayer sur un petit projet ? De cette façon, pas la
peine de te poser 15000 questions méta-philosophiques, passe à l’action !

++

yk

PS : évidemment, comme nous tous ici, tu ne seras pas déçu du voyage et
tu ne regretteras pas le PHP…

10

Yann K. a écrit :

Quoi de mieux pour savoir si ROR correspond à votre manière de
travailler que de l’essayer sur un petit projet ? De cette façon, pas
la peine de te poser 15000 questions méta-philosophiques, passe à
l’action !
Bon OK.

Nous avons un projet à réaliser. Il nous faut un CMS multi-lingues
accessible et orienté “client final” (simple) et autour duquel viendront
se greffer nos fameuses briques.

Radiant est bien loin du compte. Que me conseillez-vous ?

11

Les applications louées nécessite en général une haute disponibilité.
On en a déjà discuté sur cette liste, cherche Mongrel, pen, nginx …
http://blog.lienweb.fr/2006/11/20/138-conference-paris-on-rails-slides-de-la-conference-hebergement-haute-disponibilite-d-applications-ruby-on-rails
http://blog.lienweb.fr/2006/11/20/138-conference-paris-on-rails-slides-de-la-conference-hebergement-haute-disponibilite-d-applications-ruby-on-rails
Voir capistrano pour le déploiement.
Pour le load-balancing, j’ai déjà lu ça. Je pensais à des difficultés
notamment pour qu’un même front controller puisse générer des pages
différentes en fonction du sous-domaine.
Par exemple :

Cette étape était un peu délicate avec notre framework actuel. Comment
faire ça simplement avec rail (sans mode rewrite à ce niveau biensûr) ?

Tu peux développer des plugins et des webservices.

Il faut que je creuse ça, car le terme “plugins” me laisse plus penser à
des extensions qu’à des modules indépendants.

Voir http://radiantcms.org/ par exemple, mais si vous êtes
perfectionniste autant développer le votre.
N’y a-t-il rien de plus abouti (URL personnalisées, etc.) ?

Tout dépend des compétences et de la motivation de ton équipe. Si
les notions objets sont déjà acquises cela devrait aller vite pour
maîtriser le langage et le framework en moins d'un mois. Sinon la
personne la plus capable apprend l'outil et ensuite fait un
transfert de compétence, cela devrait être une bonne solution

On est tous OK sur la POO. Et puis on connait Symfony :wink: Le
fonctionnement semble vraiment similaire.

12

Le Jeu 1 mars 2007 18:54, Nicolas CHARLOT a écrit :

Je viens poster pour la première fois sur cette ML dans le but de
recueillir quelques avis objectifs.

Une liste de diffusion engagée (celle ci l’est) n’est que très rarement
objective. Ceci dit ça n’en retire pas forcément le crédit.

Coté symfony je réagis juste sur les perfs. Le fait que ce soit utilisé
par Yahoo ne change rien. Beaucoup de choses sont utilisées par Yahoo,
IBM, [mettre une grosse entreprise ici], etc. Si symfony était utilisé
directement sur le portail principal yahoo ça serait un argument (et
encore, je vois mal ce que ça prouverait vu que yahoo doit être à 99% à
base de cache et que la recherche elle même n’est pas en symfony).

Symfony est lent, Rails aussi. Mais leur “lenteur” n’est probablement
pas
un facteur très limitatif pour grand monde. Parler de perf me rappelle le
moment où on parlait de Java vs PHP. PHP est monstrueusement plus lent sur
le papier, encore plus si on rajoute un framework/cms. Ca ne l’empêche pas
d’être utilisé majoritairement sur le Web. La performance est
très trèstrès très rarement le critère principal (parce que le coût d’un serveur
est finalement relativement faible).

Ce qui me fait peur dans ROR :

  • N’est-ce qu’une mode, ou va-t-on tous migrer pour de vrai raisons ?

Ca dure, donc il y a des chances qu’on ait déjà dépassé l’effet de mode.
Ceci dit il n’y a pas encore de poids suffisamment lourd pour garantir
que
ce sera encore fortement présent dans deux ans (je repense à
Plone/Zope/python qui a beaucoup fait parlé mais qui reste encore super
anecdotique). Pour cela je peux simplement me baser sur mon ressenti et
AMHA Ruby a tous les atouts nécessaires pour rester.

  • Peut-on vraiment tout développer (je pense notamment à des
    applications en mode FAH qui requièraient certaines particularités)

Oui et non. C’est un langage de développement, on peut donc techniquement
tout faire. Maintenant ça vise une certaine problématique, ce n’est pas
une baguette magique. D’ailleurs globalement si tu cherches la baguette
magique qui fait tout parfaitement tu peux dors et déjà arrêter de
chercher.

Pour Rails on va dire : applicatif Web.
Rails ne va pas forcément gérer le middleware de la poste. Rails ne va pas
non plus gérer le moteur de recherche de Google. Rails va encore moins
faire fonctionner mon téléphone portable. Maintenant pour les applicatifs
Web ça tourne.

Si je voyais une limitation dans les applicatifs Web ça serait “reprise et
intégration avec un existant”.

  • La documentation semble abondante mais très confuse (sauf côté livres)

Je confirme

  • En combien de temps peut-on être opérationnel (appréhension +
    redéveloppement de notre existant) ?

Expérience perso :
expertise de 10 ans sur PHP où j’ai développé des framework, des applis,
des ORM … j’ai mis moins d’un an a être plus efficace en rails/ruby.

J’ajoute que les problématiques d’hébergement ne nous concernent pas,
nous avons nos serveurs dédiés.

Ne pas sous estimer la problématique d’hébergement. Avoir des serveurs
dédiés ne résout pas le problème, ça veut au contraire dire que ça sera à
vous de gérer le probléme.

–
Éric Daspet
http://eric.daspet.name/

13

Merci Eric.

Si je ne m’abuse, tu es le co-auteur du livre “PHP 5 avancé” ?

Puisque tu sembles avoir sauté le pas, peux-t-on en déduire que, selon
toi, ROR est à présent plus avantageux que PHP (et ses nouveaux
frameworks) pour la majorité des projets Web d’aujourd’hui ?

Pour quels usages continues-tu à utiliser PHP ?

14

Le 02/03/07, Nicolas CHARLOT a écrit :

se greffer nos fameuses briques.

Radiant est bien loin du compte. Que me conseillez-vous ?

Eclipse :wink: