Derniers journaux de account :

Journal : Pierre Tramo a frappé !

Posté par account () le 27 septembre 2006
0
Je n'ai vu personne ici s'émouvoir du fait que Nuxeo, l'éditeur du célèbre CPS, abandonne la plateforme Zope/python pour se tourner vers Java : http://www.nuxeo.com/news/nuxeo-passe-aux

Java tout bouffer !

> Lire le journal (23 commentaires, moyenne: 2,7).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Zope

Posté par vrm (page perso, ) le 27/09/2006 à 13:37. (lien). É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 lordcow () le 27/09/2006 à 14:16. (lien). É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..

    --
    Je est un autre.
    • [^]Re: Zope

      Posté par Aurélien Bompard (Jabber id, page perso, ) le 27/09/2006 à 14:33. (lien). É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 Fabimaru! (Jabber id, page perso, ) le 27/09/2006 à 15:43. (lien). É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.

      --
      Pas de bureau 3d libre sans drivers libres!
      • [^]Re: Zope

        Posté par pipo_molo () le 28/09/2006 à 08:03. (lien). É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 kadreg (page perso, ) le 28/09/2006 à 09:07. (lien). É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 pipo_molo () le 28/09/2006 à 14:40. (lien). É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 Sylvain Sauvage () le 28/09/2006 à 17:15. (lien). Évalué à 2.

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

        • [^]Re: Zope

          Posté par Fabimaru! (Jabber id, page perso, ) le 28/09/2006 à 17:54. (lien). É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.

          --
          Pas de bureau 3d libre sans drivers libres!
          • [^]Re: Zope

            Posté par Fabimaru! (Jabber id, page perso, ) le 28/09/2006 à 18:07. (lien). É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!

            --
            Pas de bureau 3d libre sans drivers libres!
  • [^]Re: Zope

    Posté par Nicolas Évrard (Jabber id, page perso, ) le 27/09/2006 à 14:32. (lien). É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.

    --
    Le scheme c'est bien.

Poisson

Posté par Aurélien Bompard (Jabber id, page perso, ) le 27/09/2006 à 14:31. (lien). É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 chl (page perso, ) le 27/09/2006 à 14:49. (lien). Évalué à 2.

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

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

  • [^]Re: Poisson

    Posté par Nicolas Cuny (page perso, ) le 27/09/2006 à 15:50. (lien). É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 sylware () le 28/09/2006 à 09:07. (lien). É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 Stefane Fermigier (page perso, ) le 28/09/2006 à 15:54. (lien). É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/

    --
    Stefane Fermigier, CEO, Nuxeo
    ECM et GED open source
    www.nuxeo.com | www.nuxeo.org

Et les clients actuels?

Posté par Fabimaru! (Jabber id, page perso, ) le 27/09/2006 à 16:11. (lien). Évalué à 2.

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

--
Pas de bureau 3d libre sans drivers libres!
  • [^]Re: Et les clients actuels?

    Posté par Maillequeule () le 27/09/2006 à 17:11. (lien). É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 golum () le 27/09/2006 à 19:16. (lien). É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 Clément varaldi (page perso, ) le 28/09/2006 à 07:38. (lien). É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 Stefane Fermigier (page perso, ) le 28/09/2006 à 15:47. (lien). É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/

    --
    Stefane Fermigier, CEO, Nuxeo
    ECM et GED open source
    www.nuxeo.com | www.nuxeo.org

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

Posté par Stéphane KLEIN (page perso, ) le 28/09/2006 à 07:52. (lien). É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 blackshack () le 30/09/2006 à 12:11. (lien). É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...

Revenir en haut de page