La version précédente de RoR avait un problème rédhibitoire, le serveur était mono threadé. Donc, pour bosser et faire une démo qui impressionne, ça passe, sinon, ça devient de suite plus compliqué. Il faut lancer tout un tas de serveur, et utiliser un serveur web comme lighttpd qui fait du roundrobin sur tout ça. Du cluster sur une seul machine. J'ai peut être pas les yeux en face des trous, mais je n'ai pas vu si la version 2 corrige ce problème.
Autre problème, RoR est une application, sans possibilités de contraindre simplement l'utilisation mémoire ou le temps maxi pour exécuter une page, ce qui le rends inutilisable sur un hébergement mutualisé dans le genre de Free.
Autre fantasme, la migration d'un site en PHP qui va bien mais pas joli, vers du RoR qui rulez. Il y a eu récemment un post sur SlashDot sur ce sujet. Le type avait embauché un des dev de RoR pour faire la migration, et au bout de 2 ans, ils ont jeté l'éponge. RoR est un logiciel de prototypage, très bien pour créer from scratch un site, et surtout pas quelque chose vers quoi migrer.
La gestion des sessions en Cookie, comme évolution me parait tout simplement risible. La taille des cookie est limité, et les logiciels civilisé savent gerer les sessions en RAM, sauf si ils sont en cluster ou il faut passer à quelque chose de de suite nettement plus compliqué. PHP a le bon de laisser l'admin s'occuper du choix, sans faire passer une astuce pour une évolution.
La qualité indéniable de RoR est d'être un aiguillon pour tous les autres, il n'y a qu'a voir l'arrivé de Grail, PHPCake ou Django. Un serveur peut être simple, et le volume des fichiers de configurations ne doit pas dépasser le volume de code. Le MVC, l'ORM, l'intégration d'un framework JS, un outil de build, le REST et JSON font maintenant parti des ingrédients d'un bon framework web.
# ROR et ses limites
Posté par mister popo ポポ . En réponse à la dépêche Sortie de Ruby on Rails 2.0. Évalué à 7.
Autre problème, RoR est une application, sans possibilités de contraindre simplement l'utilisation mémoire ou le temps maxi pour exécuter une page, ce qui le rends inutilisable sur un hébergement mutualisé dans le genre de Free.
Autre fantasme, la migration d'un site en PHP qui va bien mais pas joli, vers du RoR qui rulez. Il y a eu récemment un post sur SlashDot sur ce sujet. Le type avait embauché un des dev de RoR pour faire la migration, et au bout de 2 ans, ils ont jeté l'éponge. RoR est un logiciel de prototypage, très bien pour créer from scratch un site, et surtout pas quelque chose vers quoi migrer.
La gestion des sessions en Cookie, comme évolution me parait tout simplement risible. La taille des cookie est limité, et les logiciels civilisé savent gerer les sessions en RAM, sauf si ils sont en cluster ou il faut passer à quelque chose de de suite nettement plus compliqué. PHP a le bon de laisser l'admin s'occuper du choix, sans faire passer une astuce pour une évolution.
La qualité indéniable de RoR est d'être un aiguillon pour tous les autres, il n'y a qu'a voir l'arrivé de Grail, PHPCake ou Django. Un serveur peut être simple, et le volume des fichiers de configurations ne doit pas dépasser le volume de code. Le MVC, l'ORM, l'intégration d'un framework JS, un outil de build, le REST et JSON font maintenant parti des ingrédients d'un bon framework web.