Journal J2EE vs RoR vs Python

Posté par (page perso) .
Tags : aucun
1
25
jan.
2007
Une vidéo longue (30min) et lourde (300Mo) d'une conférence donnée par un gars de la NASA à propos du développement d'une application web avec J2EE, RoR, Zope, Djengo, Turbogears et Jboss.

Cette vidéo m'a littéralement sciée. Bossant depuis 4 mois avec J2EE et Jboss, je dois avouer que tout ce qui est décrit est entièrement véridique et pas du tout exagéré ! (au contraire, il a même pas parlé de Spring et d'autres joyeusetés).

http://oodt.jpl.nasa.gov/better-web-app.mov

(ça vaut le coup de la regarder jusqu'au bout)

Un grand merci à Christophe Combelles pour avoir posté cette vidéo dans la news : http://linuxfr.org/2007/01/24/21956.html . J'ai trouvé qu'elle méritait un journal.

Maintenant, je me pose des questions :

- la démo de 3 minutes là, c'est bien, mais à long terme, pour une "grosse" app, est-ce toujours valable ?
- Jboss est très prisé et utilisé. Je n'arrive toujours pas à comprendre l'intérêt et je trouve cela d'une complexité absolument délirante. L'auteur de la vidéo semble d'accord avec moi. Quel point avons-nous raté ? (ze gros avantage/feature de jboss qui en fait un killer)
- entre zope, django et turbogears, vous choisissez quoi et pourquoi ? des retours d'expériences ? Des remarques de ceux qui en ont utilisé plusieurs d'entre eux ?
- zope semble un peu être le jboss de python. c'est juste une impression que j'ai ou c'est fondé ?


Entre nous, j'aimerais garder la discussion purement technique. Des arguments comme "est bien accepté dans le milieu professionnel", "est fort répandu" ou "existe depuis 10 ans" ne m'intéressent pas. Je prend le cas (fictif ?) d'une nouvelle application développée from scratch, sans donnée précédente, sans contrainte de backward compatibilité pour le moment par des développeurs compétents, sachant lire de la doc.
  • # et sa conclusion ?

    Posté par . Évalué à 6.

    Et pourrais tu indiquer sa conclusion en quelques mots ? Car d'ici là qu'on la télécharge et qu'on la visualise jusqu au bout...

    Merci ploum< .
    • [^] # Re: et sa conclusion ?

      Posté par (page perso) . Évalué à 3.

      Sa conclusion, en simple : J2EE et Jboss sucks grave et sont pas du tout amusant. Les 3 frameworks python et RoR rocks grave et sont super "funny".

      Après il y a les détails : le temps passé pour faire la même appli sur chaque framework, la gestion des erreurs, le nombre de problème "prise-de-tête" et surtout la réactivité et la facilité pour visualiser une modif.

      D'après sa vidéo, le tout grand gagnant est zope. Le tout grand perdant est Jboss.

      si qqn trouve une page récapitulative de sa vidéo, ça peut être très intéressant.
      • [^] # Re: et sa conclusion ?

        Posté par . Évalué à 10.

        ET sinon il parle un peu de tout petit trucs sans importance , les perfs , la scalabilité , la maintenance ... ?
        • [^] # Re: et sa conclusion ?

          Posté par (page perso) . Évalué à 2.

          nan, c'est pour ça que je poste ce journal avec des "?".

          Mais, de mon expérience, au niveau perf et maintenance, je ne vois pas physiquement comment on pourrait faire pire que JBoss.

          Après, une étude comparée de la scalabilité pourrait être intéressante. Je n'ai encore jamais utilisé ce genre de logiciels sur des projets avec un tel besoin.
          • [^] # Re: et sa conclusion ?

            Posté par (page perso) . Évalué à 8.

            Je ne sais pas pourquoi tu fais une fixation sur JBoss ... JBoss est un serveur d'application, pas une framework ou une librairie.

            Dans la pratique, dans 99% des cas Tomcat suffit (en tout cas pour le dev, après qu'on déploie sur un serveur plus robuste tel que Weblogic, ça ne change rien).

            Comparer JBoss et Ruby On Rails c'est comme comparer Apache à RoR ...
            • [^] # Re: et sa conclusion ?

              Posté par . Évalué à 2.

              J'agrée.
              Jboss n'est qu'un serveur d'application parmi d'autres, et si ses perfs sont décevante il ne faut pas les lier à J2EE.
              Comme dit plus haut dans 99% des cas tomcat suffit. Pour le 1% qui reste il est raisonnable d'envisager un serveur plus robuste comme celui de BEA ou IBM. De là à dire que Jboss ne sert à rien il y a un pas que je ne franchirai pas vu que je ne le connais que de (mauvaise) réputation.
      • [^] # Re: et sa conclusion ?

        Posté par (page perso) . Évalué à 5.

        D'après sa vidéo, le tout grand gagnant est zope.
        Pourtant question simplicité, je trouve pas zope très fun. Leur site donne plutôt envie de s'enfuir quand on le lit, alors que celui de django propose un tutorial ultra-simple pour installer et développer sa 1ere appli django (et pas besoin de cliquer partout sur le site pour le trouver, ce tutorial), qui donne vraiment envie d'aller plus loin.

        Mais cet avis n'engage que moi...
        • [^] # Re: et sa conclusion ?

          Posté par (page perso) . Évalué à 2.

          je suis plutôt d'accord et j'ai exactement le même a priori (qui m'a fait installer django plutot que zope ou turbogears).

          Cependant, à l'usage, peut-être que zop est meilleur ? Je ne sais pas...

          Il a fait des erreurs de toutes façons et il l'a reconnu sur son blog comme par exemple que Django supporte i18n out-of-the-box (contrairement à ce qui est dit dans sa présentation et il s'en excuse).

          aussi, il dit que la documentation J2EE est très bonne avec plein de livres. En quantité, c'est tout à fait vrai, mais en qualité...

          J'ai l'impression d'avoir fait des millions de tutoriels, officiels ou non, ces 3 derniers mois. Tous partent toujours du principe que tu connais déjà ce que le tutoriel est sensé t'apprendre et c'est ultra ennuyeux. Tu passes ton temps à essayer de deviner en lisant le code source d'exemples ci et là. Je sais que je vais paraitre encore un acharné de python, mais la doc python (et de la plupart des modules associés) est pour moi un vrai bonheur : tu suis pas à pas à partir du chapitre qui t'intéresse, bonne balance entre exemples et explications, etc..

          Là où java est vraiment bon, à mes yeux, c'est la javadoc pour les API. Si tu sais ce que tu recherches, c'est le pieds. Mais encore faut-il le savoir.
          • [^] # Re: et sa conclusion ?

            Posté par (page perso) . Évalué à 3.

            Zope c'est vraiment intéressant, cependant la version 2 actuelle est en lente obsolescence. Je m'y suis intéressé un moment, mais j'ai fini par découvrir la version 3 qui est une réécriture complète (non compatible), qui reprend toutes les technos intéressantes comme la base de données objet (zodb), le système de template par attributs xml (ZPT), mais qui ajoute des notions super interéssantes comme les interfaces et les adapters. Le tout étant complètement modulaire et extensible. Et tout est inclus de base, l'i18n, la sécurité, le xml-rpc, la génération et validation automatique des formulaires web, qu'on peut customiser à souhait grâce à des widgets perso, etc. Franchement moi je suis tombé amoureux de ce framework, même si je reconnais qu'il y a un petit cap à franchir pour « penser » Zope3 et y être autonome. Notamment il me semble 100% indispensable d'acquérir le (très récent) bouquin de Weitershausen pour espérer s'en sortir. Mais après... waw...!
      • [^] # Re: et sa conclusion ?

        Posté par (page perso) . Évalué à 6.

        Il faut comparer ce qui est comparable !

        Je suis totalement d'accord avec la vidéo et les conclusions qui sont faites à propos de J2EE.
        Cela dit, dans ce comparatif, il ne fallait pas inclure JBoss, mais Seam (qui fonctionne avec JBoss mais pas forcément lui) !

        Seam est un framework web, comme l'est RoR, Django ou TurboGears. Plone pour moi c'est encore une autre histoire : c'est déjà un CMS complet !

        Seam est du genre RoR : création rapide de projet, création de vue, création automatique d'un squelette d'appli à partir d'une base de donnée, etc ...

        Si on utilise seam-gen, que l'on utilise la base de donnée préconfigurée, je pense qu'on est très proche d'un RoR.

        C'est fun de créer une appli web avec Seam ... avec J2EE *brut*, c'est du suicide !

        J'ai pas d'actions JBoss hein, c'est juste que je trouve la comparaison un peu injuste.

        • [^] # Re: et sa conclusion ?

          Posté par . Évalué à 2.

          Tu connais d'autres bons frameworks ? Justement une appli web en J2EE *brut* (c'est à dire, jsp + servlets + EJB) me fait tellement peur que j'en suis encore à me demander si ça vaut le coup de se faire assomer dès le début pour marcher plus vite à la fin...

          Cette solution est très interessante niveau robustesse (je trouve), sachant que j'ai aucune idée pour le python (pour comparer), je vais bientôt m'y mettre.
          • [^] # Re: et sa conclusion ?

            Posté par (page perso) . Évalué à 2.

            Essai seam, c'est vraiment bon ! Je ne pourrais plus jamais faire du J2EE pur.

            Il y a un forum assez actif et la doc est conséquente. Tu peux avoir du support commercial si tu en as besoin (mais on peut très bien faire sans).

            Il n'y a qu'une chose qui me manque actuellement mais qui arrive bientôt : la gestion de la sécurité. C'est prévu pour la version 1.5 pour dans quelques semaines.

            Bon bien sur, faut aimer le java. Ca utilise notamment pas mal les annotations (je trouve ca plutôt sympa).

            Si non, c'est vrai que plone en tant que CMS, c'est vraiment puissant, j'aime bien ...

            Ca dépend de tes besoins et de tes préférences.
          • [^] # Re: et sa conclusion ?

            Posté par (page perso) . Évalué à 2.

            Spring MVC est vraiment très bien pour les applications web. Maintenant, c'est pas aussi "wizard" que RoR mais le framework est simple et très flexible.
  • # JBoss est compliqué

    Posté par . Évalué à 5.

    Il me semble que JBoss est volontairement compliqué (au niveau de la config) pour que celà pousse à se tourner vers l'éditeur pour des formations, du support, de l'installation, du paramétrage, etc...
    En tous cas cela fait partie des critiques habituellement entendues envers JBoss.

    Bon je ne l'ai jamais utilisé, je pense que je préférerais me tourner vers du JONas pour qqchose de plus simple.
  • # Seaside et squeak :-)

    Posté par (page perso) . Évalué à 10.

    Hum, dans un tel monde virtuel, je choisirais alors l'environnement Seaside + squeak + gemstone + "ce qui va bien avec" pour construire une nouvelle application n-tier avec interface Web :-D

    Mais, suis je bête, dans un tel monde, nous serions déjà dans des environnements virtuels 3D de type OpenCroquet qui reposerait sur un OS de type Plan9 et la construction de telles applications reposeraient sur le système collaboratif transparent de l'environnement qui lui même reposerait sur l'infrastructure distribuée transparente de l'OS ! Il s'agirait alors plus qu'à récupérer par drag&drop des objets par ci par là et de les assembler en décrivant leur relation (description syntaxique et sémantique), d'écrire de nouveaux objets graphiquement (aussitôt écrit, aussitôt instancié), puis d'exécuter le tout en modifiant à la volée le flot d'exécution pour corriger les éventuels bogues ou pour rajouter des évolutions sans remettre en cause l'exécution courante !

    Bref, on a du chemin encore à faire ...
    • [^] # Re: Seaside et squeak :-)

      Posté par . Évalué à 10.

      Hep réveil toi, tu dors encore en pleine réunion ! Bon, c'est pas tout ça mais faut retourner coder des applis bancaires en cobol
    • [^] # Re: Seaside et squeak :-)

      Posté par . Évalué à 2.

      Fieew! Impressionant ;)

      J'adore Smalltalk, et Seaside est effectivement très impressionant.
      Par contre, et ce sont de vrai questions:
      - Qu'est-ce que tu utilises pour la persistance (l'image c'est bof non ?)
      - Une image, c'est pas évident pour le déploiement?
      - Comment ça se passe le travail en équipe et la gestion de configuration avec Squeak.
      - C'est quoi gemstone ?

      Sinon, moi j'aimerai bien un framework web en Haskell.

      Un autre truc qui me parait interessant, comme tu le souligne, c'est de pouvoir modifier les objets à la volée.
      Un peu a la manière de pata pata http://patapata.sourceforge.net/

      Pour ça, je suis persuadé que les langages à base de prototypes sont intéressants (par exemple Io http://www.iolanguage.com/ )
      • [^] # Re: Seaside et squeak :-)

        Posté par . Évalué à 4.

        Sinon, moi j'aimerai bien un framework web en Haskell.


        Hmmm, y a rien d'aussi "sexy" que RoR/Django/... actuellement, mais on peut quand même noter l'existence de :

        http://happs.org
        http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH(...)
        http://www.cs.chalmers.se/~d00nibro/hsp/
        http://darcs.haskell.org/~lemmih/hasp/

        C'est pas encore très organisé et je ne sais pas si ça correspond exactement à ta demande et tes besoins. Happs est celui qui a le plus le vent en poupe, récemment il a été utilisé pour écrire http://hpaste.org
        • [^] # Re: Seaside et squeak :-)

          Posté par . Évalué à 1.

          J'avais déjà regardé wash, les autres je ne connaissait pas.

          En fait j'ai pas de réel besoin dans ce domaine, c'est plus pour le fun ;)
          Mais j'aime de plus en plus Haskell, je trouve que ça combine plutôt bien l'expressivité et le typage statique.

          De plus comme je lisais récemment, les langages fonctionnels purs sont des bons candidats pour tirer partie des multi-coeurs/processeurs.

          Mais on s'éloigne des framework web.

          Effectivement RoR, Django et Turbogears sont sexy, personnellement, j'ai un peu peur de ce que certains dev pourraient écrire avec Ruby, et l'enfer de la maintenance qui pourrait en découler. J'ai une tendance naturelle vers la simplicité, et Ruby est tout sauf un langage simple, il n'y a qu'a regarder sa grammaire pour s'en convaincre.
      • [^] # Re: Seaside et squeak :-)

        Posté par (page perso) . Évalué à 1.

        - Pour la persistance, tu as à ta disposition un certain nombre de bases de données objet écrites en Smalltalk : Gemstone, celui que j'ai cité, est le plus connu, sinon il y a aussi Magma ou Glorp.

        - L'image est au contraire idéale pour le déploiement car une image peut être chargée via le réseau à partir de ton environnement Smalltalk ou encore il suffit juste alors de saisir en ligne de commande par exemple : squeak monimage quelque soit la plate-forme.

        - Dans squeak, toute la gestion de configuration et le travail en équipe est gérée de façon transparente. Pour gérer les différentes versions, en fait l'environnement sauvegarde chaque modification de ton image dans un fichier .changes qui contient toutes les modifications. Ce qui fait que si tu perd ton image, à partir de l'image d'origine, l'image finale peut-être reconstruite à partir de ce dernier fichier. Pour partager ton code et assurer de façon partagée la gestion de configuration, tu as ce que l'on appelle des serveurs squeaksource, équivalent aux sourceforge et l'outil Montecillo pour la gestion des révisions (+ d'autres outils). Tu as même des serveurs qui te permettent de travailler directement à partir de ton navigateur Web en utilisant le plugin squeak correspondant pour ce faire.
  • # Django

    Posté par . Évalué à 4.

    Je suppose que tu voulais parler de Django http://www.djangoproject.com/

    Sinon mon avis rapide:
    - JEE c'est effectivement lourd, mais une fois qu'on maîtrise, on peut coder quasiment sans réfléchir (ce qui n'est pas drôle en fait...) :
    Le problème c'est que les API sont souvent "over engineered", c'est concu pour résoudre tous les problèmes, y compris ceux dont la chance de rencontre est quasi nulle.
    Une petite parenthèse, Spring simplifie plutôt les chose dans ce domaine, au contraire de ce que tu semble penser en employant le terme "joyeuseté"

    - Zope: j'ai essayé très brièvement, et ça ne m'a pas vraiment séduit,
    mais je regarderai la video dès que je serai de retour chez moi ;)

    - Django, RoR, et Turbogears sont tous les trois de très bons frameworks. J'ai une préférence pour Turbogears et Django, principalement pour des raison de lisibilité du code (AMA pour un développement en équipe Python est un meilleur choix que Ruby au niveau lisibilité), mais surtout pour la documentation.
    • [^] # Re: Django

      Posté par (page perso) . Évalué à 0.

      pour info: il ne parle pas de django pour python, ni de zope, mais de Plone qui est un cms tres complet par dessus zope (mais pas tout a fait un framework a mon avis)

      la video est assez ancienne, et django etait preque inconnu à l'époque

      Pour ceux que ca interesse, aujourd'hui les framework web efficaces, puissants et fun sont django et rails

      perso je m'interesse plutot a django, quelques lien:

      www.djangoproject.com

      premiers pas en django si vous causez pas english:
      http://www.biologeek.com/journal/index.php/traduction-franca(...)

      la meme chose et bien plus en anglais sur www.djangoproject/documentation

      le livre en cc ecrit par les auteurs de django
      www.djangobook.com

      la version 1.0 de django va arriver dans quelques semaines

      son test est pas super je trouve, mais il met en evidence la difficulté de faire des choses rapidement et simplement en java.

      ce qu'il fait avec plone est discutable je trouve... mais bon

      en vous remerciant
      • [^] # Re: Django

        Posté par . Évalué à 2.

        Ploufplouf, tu as oublié de parler de django-fr.org, la communauté francophone en cours de construction avec des débuts de traduction de la doc de Django !!

        http://www.django-fr.org/
        • [^] # Re: Django

          Posté par (page perso) . Évalué à 1.

          j'ai pas oublié, je me disais meme que c'etait une bonne occasion, mais on est pas pret ;-)

          enfin voilà:
          www.django-fr.org
          le site des web gitans


          en vous remerciant
    • [^] # Re: Django

      Posté par (page perso) . Évalué à 3.

      principalement pour des raison de lisibilité du code (AMA pour un développement en équipe Python est un meilleur choix que Ruby au niveau lisibilité)

      Pourquoi ? En quoi python serait plus lisible ?

      Si je demande ça c'est que je fait le constat inverse... je trouve ruby bien plus agréable et facile à lire que python.
      Il est vrai que ruby a quelques côtés un peu étrange, ou plutôt qu'on peut étendre très facilement le langage donc on peut se trouver dans des situations qui sortent des langages plus classiques, mais dans ce cas ce serait confondre lisibilité et méconnaissance.
      Car dans un cas comme dans l'autre, il faudra tôt ou tard apprendre réellement le langage pour pouvoir l'utiliser et non plus simplement le lire.

      Mais je trouve justement ruby suffisament verbeux et bien concu pour être facile à lire tout en restant relativement concis.

      (ou alors c'est mon côté perl qui me fait trouver ruby tout à fait lisible...)
  • # Mes impressions

    Posté par . Évalué à 10.

    Pour me situer, je dirais que j'ai fais et je fais toujours pas mal d'applis en PHP. J'ai utilisé Zope avec CPS (gestion documentaire en gros), et développé des produits dessus. Je connais RoR de nom et vois à peu près la simplicité.

    J'ai récemment utilisé le framework Symfony (PHP) qui s'approche de RoR et je me met à J2EE par JBoss/Seam et les EJB3.

    Commençons par Zope. C'est un serveur d'appli en python qui à mon sens vieillit un peu. Ca fait quelques années qu'ils comptent généraliser Zope3, mais force est de constater que ça prend pas. Le gros problème avec Zope c'est pour le déploiement.
    Tu fais des modifs dans la ZMI (Zope Management Interface) en interface Web, mais pour packager le tout, il faut bien faire des produits en Python, redéployer, redémarrer le serveur etc... Les IDE ne sont pas légion. Nuxeo, la société qui développe CPS (sous Zope) a récemment migré la solution sous Jboss/J2EE, ils donnent les raisons sur leur site.

    Je vais parler de Symfony qui est à mon avis un très bon Framework en PHP, qui se veut l'équivalent de RoR pour PHP. J'ai beaucoup aimé le découpage en module, l'ORM (object relational mapper), le routing utilisé avec le Path info... Enfin la doc est très bien foutue, en une après midi, j'avais finie ma première appli avec support Ajax etc... La seule réserve est sur les performances avec la montée en charge que je ne peux pas trop mesurer pour l'instant mais 300ms pour servir une page en mode Debug je trouve ça beaucoup.

    Enfin, la dernière techno à laquelle je me mets, J2EE/Jboss. J'avais essayé il y a quelques années, mais j'avais trouvé ça énormément lourd en terme de configuration. Pour afficher une simple table avec des Beans, il fallait je sais pas combien de fichiers de conf....
    EJB3 semble changer la donne et tirer parti des avantages de Java5. C'est beaucoup (beaucoup) plus simple à configurer et à lire. Le framework Seam propose un petit utilitaire qui crée automatiquement un projet Eclipse et les première vues, il n'y a plus qu'à mettre un peu de code pour tes bean et ça fonctionne pas trop mal. Seam enlève en plus la lourdeur des managed beans et ajoute pas mal de facilité (gestion des workflow métiers etc...)
    Ca semble lourd et comme il a été dit précédemment c'est un peu over-engineeré dans le sens où tout a été prévu pour beaucoup de cas. Je pense que pour de très grosses applications où ça communique beaucoup, l'architecture EJB est très intéressante. C'est très facile de faire des WebServices, et des frameworks Ajax s'intègrent plutot bien dedans.
    L'autre avantage que je vois c'est la standardisation de certaines pratiques via les JSR. Par exemple les JSR sur les portlets. Si je fais un appli qui implémente cette JSR (168 il me semble), ça me permet d'inclure cette appli dans tout portail gérant cette spécification. Au fur et à mesure, ça permet d'intégrer des modules parlant ensemble (on peut inclure des portlets codés en PHP ou autre je crois...)

    Mon impression globale, c'est que pour une application relativement autonome, je choisirais des framework du type de RoR (j'inclue Symfony) et pour des plus grosses applications il me semble (j'en ai absolument pas la certitude) que J2EE apporte des fonctionnalités de scalabilité que n'ont pas PHP ou Python. En PHP par exemple, ton application recommence à chaque requête de zéro. Il faut réinstancier les composants essentiels, réévaluer le contexte etc.... Avec J2EE, les objets restent "vivants" sur le serveur et du coup le contexte applicatif ne se recharge pas à chaque requête.

    Ce ne sont que des impressions, je peux bien sur me tromper. Autant je connais très bien PHP, autant je débute avec les EJB. L'impression que j'ai c'est qu'il se sont quand même grandement améliorés.
    • [^] # Re: Mes impressions

      Posté par . Évalué à 2.

      Pour Symphony j'en ai aucune idée, mais pour J2EE c'est aussi mon avis. Pour les grosses applis (genre Ebay), J2EE est une solution à prendre en compte dans le cahier des charges. Niveau scalabilité je peux juste dire qu'il faut de gros serveurs, rien qu'en local tu luttes un peu en faisant des tests... (le déployement d'un Helloworld peut durer 30~50 sec sur un centrino 1.6).
    • [^] # Re: Mes impressions

      Posté par (page perso) . Évalué à 6.

      Associer Symfony et RoR c'est pas mal de marketing, et au mieux une franche rigolade.

      On est franchement loin de Ror au niveau feeling, utilisation, installation/configuration ...

      Ca fait de l'ajax, c'est mvc, il y a une interface en ligne de commande. Passer ces trucs super bateaux, le reste est franchement différent. Perso j'associerai beaucoup plus symfony aux frameworks java (config séparée du code, génération de la couche orm statique, peu de "magie" et beaucoup de cadre) qu'à Ror (totalement dynamique, peu ou pas de config, beaucoup de magie dans les comportements ...)
      • [^] # Re: Mes impressions

        Posté par . Évalué à 2.

        Bon et bien je vais aller voir du côté de RoR alors.

        En parlant de magie, Jboss/Seam en fait pas mal dans le monde J2EE. Je détaille pas encore parce que je débute, mais il y a des choses intéressantes.
      • [^] # Re: Mes impressions

        Posté par . Évalué à 2.

        Ca fait de l'ajax, c'est mvc, il y a une interface en ligne de commande. Passer ces trucs super bateaux, le reste est franchement différent.

        C'est vrai.
        Perso j'associerai beaucoup plus symfony aux frameworks java (config séparée du code, génération de la couche orm statique, peu de "magie" et beaucoup de cadre) qu'à Ror (totalement dynamique, peu ou pas de config, beaucoup de magie dans les comportements ...)


        Je ne suis plus d'accord là, à vrai dire je vais défendre un peu symfony.

        Tout dépend de quel coté on se place, il y a un peu deux mondes qui s'affrontent à coup de troll : celui de ceux qui maitrisent leurs bases et ceux qui maitrisent le code. Un petit tour d'horizon totalement pas exhaustif :
        - D'un coté, on parle de pérénité des données, contraintes sur les tables champs etc, maîtrise de la cohérence toussa et l'interface doit s'adapter à la base.
        - De l'autre on peut parler d'environnements et applications rapides à developper, d'abstraction de la base, de la gestion des contraintes et cohérence des données depuis les couches applicatives, de non multiplication des languages, etc.

        Moi, je cherche quelque chose de souple, permettant de jouer sur les deux tableaux et c'est là que je ne suis plus d'accord avec toi.
        RoR t'impose bel un bien un cadre dont on peut trés peu s'affranchir : c'est la fameuse règle "convention plutôt que configuration". Si tu as déjà une base de donnée existante, cette règle devient plutôt handicapante...

        Ce que j'ai trouvé de bien avec symphony (et les projets qu'il a fait naître autour), c'est justement qu'il te permet d'utiliser une base existante, qu'il va aller fouiner trés loins dans celle-ci pour en déterminer l'architecture et les contraintes et te produire une fameuse couche orm statique.
        MAIS, cette couche orm statique, tu n'y touche pas. Les modifications et ajouts que tu apportes (et c'est l'esprit de tout le framework, pas seulement pour la couche orm) tu le fait dans des classes héritiaires qui elles sont conservées d'une génération de l'orm à l'autre.


        Bref, Symphony pour moi, c'est beaucoup plus de souplesse, une maitrise du code et de la base.

        Maintenant, il est bien connu qu'un framework dépassera rarement les 80/90% du travail avec toutes les outils qu'il t'apporte...C'est le reste qui te posera problème et prendra le plus de temps de travail...

        mes 2¢ comme ils disent tous...
    • [^] # Re: Mes impressions

      Posté par (page perso) . Évalué à 2.

      En PHP par exemple, ton application recommence à chaque requête de zéro. Il faut réinstancier les composants essentiels, réévaluer le contexte etc.... Avec J2EE, les objets restent "vivants" sur le serveur et du coup le contexte applicatif ne se recharge pas à chaque requête.

      Perso en Rails, mais ça doit être possible en PHP, je stocke mes objets en session. Par exemple j'ai un objet par page et je retrouve donc bien mon contexte.
      • [^] # Re: Mes impressions

        Posté par . Évalué à 1.

        Oui, je fais aussi ça pour PHP, mais pas pour mes objets Application, ou controleur etc... Je fais ça pour les objets qui ont besoin d'être dans la session (l'utilisateur courant, le contexte etc...).

        En J2EE l'objet (servlet, bean etc...) survit à la requête web autrement qu'en sérialisant ta session. Ta servlet est instanciée à la première utilisation, c'est un objet qui vit dans le conteneur (Tomcat, Jboss etc...). Un requête web attaque juste la méthode doGet ou doPost de cet objet. Si il y a beaucoup de requête, le conteneur peut décider d'instancier une nouvelle Servlet pour mieux gérer le bazarre, c'est pour ça qu'en terme de scalabilité c'est mieux en théorie (j'ai aucune idée sur la pratique).
      • [^] # Re: Mes impressions

        Posté par . Évalué à 1.

        Oui et puis y'a une gestion du cache aussi avec Symfony ou d'autres frameworks (RoR je sais pas, jamais essayé), qui est bien pratique pour booster un peu les perfs.
  • # Mon avis pro-Ruby on Rails

    Posté par (page perso) . Évalué à 1.

    Je n'ai jamais utilisé de framework Python à part une petite expérience avec Zope, j'ai pas trop apprécié l'interface d'admin un peu déroutante pour les débutants. Puis j'ai eu une expérience avec J2EE+Springs et j'ai trouvé ça plutôt lourd, compliqué mais bien architecturé et structuré.

    Vu que je n'avais que de l'expérience en PHP de base, j'ai apprécié ce dernier point. J'ai cru un instant qu'il n'existait pas de framework qui puisse allier la rapidité, la facilité et la souplesse de PHP avec les avantages de J2EE sans les inconvénients.

    Après j'ai effectué un stage de licence où j'ai développé des petites applis internes en PHP 5 avec les bibliothèques PEAR et ça m'a plu. Enfin un peu de développement rapide en PHP, sans perdre de temps avec la validation des formulaires, l'accès au BdD (ORM simple), etc. Mais ce n'était toujours pas structuré, "cadré".

    En faisant des recherches sur PEAR, je suis tombé par hasard sur le site de Ruby on Rails et ça a été très rapidement le coup de foudre ;).

    Ce que j'ai fait : j'ai très rapidement acheté le livre "Agile Web Development with Rails" écrit par les développeurs de RoR.

    J'ai lu beaucoup de livres informatiques, mais rarement un livre aussi bien écrit. J'étais littéralement scotché par ce livre, par sa manière de présenter le framework RoR, le faire découvrir à des développeurs dont la plupart n'ont jamais développé en Ruby, sa philosophie de développement (méthode "agile"), ses touches d'humour... Un livre extrêmement complet, couvrant tout le développement d'une application Web, de la conception sous forme de schéma, le développement, l'AJAX, les Webservices (REST), la sécurité, jusqu'au déployement.

    C'est simple, que vous veniez de Java, d'un autre framework ou que vous soyez simple développeur amateur PHP, procurez-vous ce livre en version PDF et/ou papier, vous ne regreterez pas.

    http://www.pragmaticprogrammer.com/titles/rails/index.html

    Bon fini la pub, j'ai pas d'actions chez eux :-).

    Si vous voulez avoir une belle et courte introduction gratuite de ce framework, je vous conseille ce beau PDF en français :
    http://people.no-distance.net/ol/documents/rails-intro/rails(...)

    Je développe aujourd'hui qu'avec Ruby on Rails, je me considère encore comme un débutant, j'en apprends tous les jours, je suis souvent étonné par certains points, par l'aspect "magique" de ce framework (bien que rien ne soit magique, mais j'adore le côté Convention over Configuration). Je trouve la documentation de l'API vraiment "pro" et proche des docs d'un logiciel d'entreprise (http://api.rubyonrails.org) alors que la doc de certains frameworks ressemblent plus à du wiki.

    J'adore la manière de créer des formulaires autour d'un objet relié à une base, la validation, le mappeur BdD objet vraiment très complet, dynamique et compatible avec tous les SGBD connus (y compris Oracle et MS SQL Server), la gestion de l'AJAX et les vues RJS qui permettent d'utiliser Script.aculo.us et ses effets entièrement en Ruby, les nouveautés de Rails 1.2 : gestion parfaite de REST, ActiveResource...

    Sans compter que le futur de Ruby on Rails est rose : Ruby 2 va arriver avec une belle explosion des performances (Ruby n'aura plus à craindre les benchmarks contre PHP et Python) et Mongrel, le mini serveur Ruby avance vite et permet de développer ET déployer en prod des applications Rails à vitesse grand V.
    • [^] # Re: Mon avis pro-Ruby on Rails

      Posté par (page perso) . Évalué à 2.

      Je trouve un peu dommage de mélanger les vues et les templates. Le principe des pages HTML remplies de TAGS invalides (au sens XML) avec des <% ce n'est pas très moderne et c'est le même principe que le php, asp, ou le DTML dans Zope2 qui a été abandonné dans Zope3.

      Une vue ne doit pas nécessairement être une page web, c'est censé être une vision particulière d'un contenu (par ex un objet). Donc ça peut générer une sortie PDF, une vue par FTP ou par WEBDAV ou en HTML, et dans ce cas une vue doit _utiliser_ un template, mais pas être un template. Il faut limiter au maximum le code contenu dans les templates, car c'est le boulot de la vue.

      Dans zope3 une vue peut aussi être juste un morceau de page (un viewlet), qui est intégré dans un gestionnaire de viewlet et qui peut (ou non) utiliser un template pour son rendu. Ca permet de faire des pages avec des boites et des contenus complètement variables et dépendants du contexte, de manière très souple et très intéressante.

      C'est vraiment regrettable que la doc et la visibilté de zope3 soient si faibles car les principes utilisés sont vraiments intéressants (on en retrouve dans j2ee, mais pas forcément de la même façon, et sans la soupless de python) et c'est un framework qui est maintenant très stable et très mûr.
      • [^] # Re: Mon avis pro-Ruby on Rails

        Posté par . Évalué à 1.

        Si j'ai tout compris, c'est le fonctionnement de rails pour la vue : on sort ce qu'on veut, du pdf, des mails, du xml... en fait l'idée est d'avoir le bon template en fonction de la demande. Enfin en théroie, je n'ai jamais utilisé rails que pour du html
        • [^] # RESTfull + ActiveResource

          Posté par (page perso) . Évalué à 1.

          Exactement. Dans Rails 1.2 (REST), Rails peut directement fournir au client du XML, HTML, etc selon la requete.

          Ce qui est tueur dans Rails 1.2 c'est d'associer l'application RESTful avec le plugin ActiveResource.
          ActiveResource reprend un certain nombre des fonctions du mappeur BdD objet ActiveRecord comme find, delete, etc. En faisant un find(1) il va automatiquement aller fetcher le XML correspondant et l'intégrer dans un objet.

          Au final, on a une abstraction complète de la source des données (qui peut etre un SGBD en local ou un serveur Web au Japon) tout en utilisant des technologies ultra-standard (XML et HTTP).

          Exemple tout bête :
          employe = Employe.find(1)
          employe.prenom ==> "Nicolas"

          Si Employe est un objet ActiveRecord, en backoffice on a un SELECT dans une base quelconque puis un mapping objet.
          Si Employe est un objet ActiveResource, en backoffice on a un fetch http://serveur_distant/employes/1 qui va retourner un XML puis un mapping objet.
          On peut meme gérer la suppression d'enregistrement, l'édition, etc, avec possibilité de gérer une authentification à distance via HTTP(S) Auth.

          Vraiment très bien pensé, absolument simple et efficace.

          Et pour ceux qui trouvent ça déjà avancé, ne vous inquiétez pas, Rails est aussi génial pour faire des choses basiques : formulaires HTML, accès aux bases, etc...
          • [^] # Re: RESTfull + ActiveResource

            Posté par (page perso) . Évalué à 2.

            globalement on est donc tous d'accord avec la conclusion de la vidéo. Même si c'est vrai qu'elle ne compare pas les bonnes choses.

            A mon avis, le bon comparatif serait :

            Rails / Django / Turbogears / Grok (qui arrive lentement)
            et :
            Zope3 / J2EE

            (Quant à Zope2 il a toujours été un peu à part et ne compte plus vraiment.)
            Et je ne sais pas quels seraient les équivalents dans le monde microsoft.
            • [^] # Re: RESTfull + ActiveResource

              Posté par (page perso) . Évalué à 2.

              Et je ne sais pas quels seraient les équivalents dans le monde microsoft.
              Dans le monde microsoft, ou dans les produits microsoft ?

              Parce qu'il me semble que certains de ces logiciels tournent aussi sous Windows.

              Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.