• # Zope

    Posté par  (site web personnel) . Évalué à 2.

    A un moment c'était annoncé comme la révolution puis .. on en entend plus trop parler. Le buzz est retombé ou RoR a volé la vedette ?

    • [^] # Re: Zope

      Posté par  . Évalué à 2.

      a l'epoque, j'avais essayé.
      Toute la programmation se faisait dans le browser.

      Faut etre motivé quand meme pour coder tes objets dans un text edit de navigateur web..

      • [^] # Re: Zope

        Posté par  (site web personnel) . Évalué à 6.

        Euh, non quand même.

        Tu peux coder des petits scripts dans l'interface d'admin de Zope, mais les grosses applis Zope c'est des fichiers normaux dans des répertoires normaux dans le répertoire Products de Zope.

      • [^] # Re: Zope

        Posté par  (site web personnel) . Évalué à 5.

        Expérience personnelle (d'un mec qui aime beaucoup python): la doc était pourrie, même avec toute la volonté du monde, ça a finit par me gaver.

        • [^] # Re: Zope

          Posté par  . Évalué à 3.

          la doc est pourrie ? le zope book et le zope developer guide, ca fait quasi 600 pages en pdf!

          Ensuite, le code c'est du python avec des docstrings bien comme il faut, je ne vois vraiment pas ce qu'il peut manquer.

          • [^] # Re: Zope

            Posté par  . Évalué à 9.

            Tu juges la qualité de la documentation à son nombre de pages ? Tu souffres d'un complexe sur la taille de ton zigouigoui ?

            • [^] # Re: Zope

              Posté par  . Évalué à 2.

              non, pas vraiment. mais même en répétant 15 fois, y'a moyen de dire pas mal de trucs en 600 pages. Et pour avoir passé le temps qu'il faut pour le lire, y'a pas photo.

              • [^] # Re: Zope

                Posté par  . Évalué à 2.

                Tu n'as jamais expérimenté les docs IBM de la belle époque…

          • [^] # Re: Zope

            Posté par  (site web personnel) . Évalué à 3.

            Je ne me rappelle plus des détails techniques (ça date un peu), mais je voulais accéder à certaines fonctionnalités d'objets Zope, et il n'y avait pas de doc bien fichue, genre celle de Python par exemple, avec les classes et leurs données/fonctions membres bien rangées.

            Quand je regarde cette page http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/(...) ça ne me donne pas envie.

            • [^] # Re: Zope

              Posté par  (site web personnel) . Évalué à 2.

              Juste un mot pour dire que c'est juste mon humble avis. C'est l'impression que j'ai eu par rapport à beaucoup d'autres docs que j'ai eu à utiliser jusqu'à présent. Et je n'ai pas jeté l'éponge rapidement!

    • [^] # Re: Zope

      Posté par  (site web personnel) . Évalué à 1.

      Disons que depuis lors python est passé à des frameworks plus légers et plus simples : turbogears, django, ...

      J'ai aussi tâté du Zope 2, Zope 3, et si je trouve le dernier particulièrement bien réussi du côté design, quand j'ai codé le site pour la liste de mariage d'un ami j'ai utilisé cherrypy + sqlobject + cheetah (d'ailleurs quand turbogears a été annoncé, je me suis dis qu'il ressemblait étrangement à ce que je faisais, l'AJAX en plus).

      Et même si je n'ai pas suivi les derniers dévellopement dans le monde de la programmation web avec python, je pense qu'on va dans le sens des frameworks légers avec de temps en temps de la place pour le mastodonte qu'est Zope 3.

  • # Poisson

    Posté par  (site web personnel) . Évalué à 2.

    Le 1er avril arrive en avance cette année ?

    Non mais quand même ! Y'a forcément un piège, là. Faudrait que Nuxeo remplace 80% de ses devs, non ?
    Ou alors ils n'ont pas supporté la compétition avec Plone et font un monstrueux virage stratégique ?

    Là, quand même, c'est gros.

    • [^] # Re: Poisson

      Posté par  (site web personnel) . Évalué à 2.

      Tout le monde sait developper en Java, regarde les offres d'emploi, meme ceux qui developpaient en Python !

      ==========> [ ]

    • [^] # Re: Poisson

      Posté par  (site web personnel) . Évalué à 2.

      > Faudrait que Nuxeo remplace 80% de ses devs, non ?

      Non juste un seul : http://fr.lolix.org/search/offre/offre.php3?id=6192
      Si on se fie à cette annonce, ils vont utiliser JBoss.

      • [^] # Re: Poisson

        Posté par  . Évalué à 0.

        JBOSS tourne sur une VM libre?
        Car un OS proprio et une VM proprio, c'est la même chose.

    • [^] # Re: Poisson

      Posté par  (site web personnel) . Évalué à 1.

      Oui, on fait un virage stratégique. Cf. la FAQ: http://www.nuxeo.com/java-switch/about-nuxeo5/

      Maintenant on le fait en plein succès, avec des projets énormes en cours et des clients et partenaires qui nous suivent à 100%. Ou si on préfère, c'est en parlant à ces clients et partenaires qu'on est arrivé à cette idée de changement - après avoir été convaincus que techniquement on aurait uns solution non seulement qui tient la route, mais qui nous permet d'allier la souplesse de Zope avec la robustesse de Java EE tout en tirant parti de tous les composants libres de l'écosystème Java.

      --
      Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/

      "There's no such thing as can't. You always have a choice." - Ken Gor

  • # Et les clients actuels?

    Posté par  (site web personnel) . Évalué à 2.

    Je doute qu'ils vont pouvoir migrer des solutions Zope vers des solutions Java...

    • [^] # Re: Et les clients actuels?

      Posté par  . Évalué à 2.

      Moi je ne doute pas que des clients décident de migrer vers Java, par contre avec la même société c'est toujours moins sûr après ce genre de virage.

      C'est assez gonflé de la part de Nuxeo j'avoue ... c'est quitte ou double dans ce genre d'aventure ... et rarement double si j'en crois mes archives (sauf dans le cas de progiciel bien établis).

      A suivre ...

      M

      • [^] # Re: Et les clients actuels?

        Posté par  . Évalué à 3.

        C'est quand même pas comme si ils n'avaient pas préparé le terrain.
        Ils ont pris quelques précautions
        http://linuxfr.org/2006/02/14/20356.html

        • [^] # Re: Et les clients actuels?

          Posté par  . Évalué à 6.

          Je ne pense pas qu'on puisse contester les compétences des gens de chez Nuxeo. C'est plutot une question politico commerciale. J'avais une solution Nuxeo chez moi, ils changent radicalement de technologie... Est-ce à dire que l'ancien choix technologique était un mauvais choix ? L'ancienne solution était-elle vraiment si sûre, viable et fiable qu'ils me l'ont vendu ?
          Et la nouvelle donne, j'en fais quoi ? Est-elle plus pérenne que l'ancienne ? Oui parce que s'ils changent comme ca, comme ils changent de chemise le matin, qu'en sera-t-il de leur nouvelle solution Java ?
          Et mon ancienne solution qui tournait avec CPS, sera-t-elle encore maintenue ? Combien de temps ? A quel surcout ?
          J'étais client, je viens de me faire mettre en marge du système, je suis "obsolète" ?

          Le client va être plus frileux, il croyait pouvoir faire confiance en leur fournisseur, mais est-ce vraiment le cas, si lui-même ne semble pas sûr des solutions technologiques avancées ?

          Des gens comme Tarek commençaient à faire référence dans le monde python (de par leurs compétences et leurs écrits) étaient chez nuxeo... Quelles sont les compétences de l'équipe en Java ?

          Beaucoup d'interrogations, qui me font penser comme le dit un autre plus haut : c'est quitte ou double, mais c'est très rarement double. J'espère juste avoir faux.

    • [^] # Re: Et les clients actuels?

      Posté par  (site web personnel) . Évalué à 1.

      Pour les clients actuels, on a prévu de continuer à supporter leurs applications pendant 3 ans, et de les accompagner si ils le souhaitent vers la nouvelle plateforme. Cf. la FAQ: http://www.nuxeo.com/java-switch/about-cps

      Pour ce qui est de l'équipe, on est développeur avant tout, et probablement plus expert d'un domaine d'application (l'ECM) que d'un langage (Python vs. Java).

      Mon témoignage personnel: j'ai découvert Java comme tout le monde en 1996, et Python quelques mois après. J'ai fait de Python mon langage de choix, et je me suis un peu investi dans sa promotion en France. Maintenant j'aime toujours Python (le langage) mais je constate que dans l'univers Java, il y a une pléthore (i.e. plus qu'en Python) de librairies libres utilisables et d'outils de développement qui rendent la vie du développeur plus facile. Ca évite d'avoir à "réinventer la roue" dans bien des domaines, ou utiliser des librairies à moitié finies.

      Bref, il y a une place pour Python (ou Ruby, ou Groovy, ou d'autres langages de scripts) mais aussi pour un langage comme Java. L'idéal étant d'arriver à faire jouer les deux ensemble, ce qui est malheureusement suboptimal dans le cas de Python, dans la mesure où l'implémentation de Python pour la JVM, Jython (http://www.jython.org/), très novatrice à son époque (circa 2000), ne bouge plus depuis des années, et en est toujours à la version 2.1 des spécifications du langage alors que celui-ci vient tout juste de passer à la version 2.5.

      --
      Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/

      "There's no such thing as can't. You always have a choice." - Ken Gor

  • # Les débuts dans Zope sont très difficiles mais le concept est novateur

    Posté par  (site web personnel) . Évalué à 1.

    Je pense que si les débuts dans Zope sont difficile (je parlerais que de Zope 3) c'est parce qu'il utilise fortement la POO et surtout les Design Patterns. Le principe de développement est totalement différent de PHP, RoR, Turbogears... Pour ce qui est d'une comparaison avec Java ( JBoss, des EJBs)... je ne prononcerais pas, car je n'ai pas de réél expérience sur cette plateforme.

    • [^] # Re: Les débuts dans Zope sont très difficiles mais le concept est novate

      Posté par  . Évalué à 3.

      juste une chose quand tu dis "c'est parce qu'il utilise fortement la POO et surtout les Design Patterns" en parlant de Zope 3 et tu continue avec "Le principe de développement est totalement différent de PHP, RoR, Turbogears... ", tu as tord au moins pour RoR qui est, comme ruby, pure Objet et ne fonctionne que sur la base des MVC, entre autres, donc basé entièrement sur les design patterns -d'autre notion des design patterns sont apportés déjà par ruby même.
      Je pense que tu n'a pas très bien regardé ce qu'est RoR pour réponde, tu aurai du faire comme pour Java, et ne pas faire de comparaoson hative...

Suivre le flux des commentaires

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