je suis heureux d'apprendre que Jython est beaucoup utilisé dans le domaine du calcul scientifique et de la visualisation. Je savais que c'était déja le cas pour CPython, grâce à différents systèmes d'interfaces avec C (SWIG, Pyrex), C++ (SWIG, BOOST, SIP, etc.) et Fortran - cf. http://wiki.python.org/moin/IntegratingPythonWithOtherLangua(...) - qui sont particulièrement utiles dans le domaine du calcul scientifiques.
Comme je l'ai écrit, Jython était une idée géniale au départ (même si d'autres langages de scripts, et notamment Tcl, avaient eu une implémentation sur la JVM avant Python, Jython offrait l'avantage de présenter un modèle objet similaire à celui de Java).
J'ai moi-même utilisé Jython il y a quelques mois pour scripter rapidement quelques tests sur Jackrabbit, au tout début de notre projet de migration.
Microsoft a récemment (il y a deux ans quand même) investi sur Python en embauchant le développeur d'IronPython, portage de Python sur la CLR .NET.
Face à cela, Sun semble avoir fait le choix de Ruby, en embauchant le mois dernier les deux développeurs de JRuby (portage de Ruby sur la JVM, tout le monde l'aura deviné).
La JSR 223 promet une bonne intégration entre l'environement Java et les langages de scripts qui ont été portés sur la JVM. Il y a déja une vingtaine de langages qui répondent à la spec, dont: Python, TCL, Ruby, JavaScript, PHP, Groovy, Scheme, Pnuts, Judoscript, etc.
On constate qu'aucun expert Python (aucun connu de moi, en tout cas), ne semble avoir participé au groupe d'expert dans le cadre du JCP: http://www.jcp.org/en/jsr/detail?id=223 Mais ce n'est sans doute pas un problème, ca montre juste un désintérêt, il me semble.
Maintenant, si personne ne se motive pour mettre Jython à jour avec la version 2.5 de Python (qui présente quand même de très gros changements avec la version 2.1, en fait c'est dans les 2.2, 2.3 et 2.4 qu'ont été introduits les "new style classes", les métaclasses, les annotations, etc. - bref toutes les features modernes de Python), il est clair que les gens vont se tourner vers d'autres langages de scripts pour scripter leurs applis Java.
J'en suis le premier désolé. C'est la règle du logiciel libre (et du logiciel en général): s'il n'y a personne pour développer, ca n'avance plus.
D'un autre côté, c'est un projet passionnant, je trouve, et il y a peut-être des lecteurs de LinuxFR à la recherche d'un projet dans le domaine de la compilation et de l'implémentation d'un langage moderne qui seront tentés. Peut-être même qu'il y a de l'inspiration à chercher du côté d'IronPython.
Bah oui, les temps changent vite dans le monde de l'informatique, et comme on dit aussi, il n'y a que les imbéciles qui ne changent pas d'avis (en particulier quand la réalité a changé entre temps).
Ce qu'on a toujours dit, et qui ne change pas, depuis l'article fondateur de John Ousterhout en 1998 (http://en.wikipedia.org/wiki/John_Ousterhout ), Scripting: Higher Level Programming for the 21st Century (http://home.pacbell.net/ouster/scripting.html ), c'est qu'il y a une place pour les deux types de langages, les langages de scripts et les langages de programmation de composants (qu'il appelle lui "langages de programmation système"), et que les deux sont complémentaires:
Scripting languages, on the other hand, have actually generated significant software reuse. They use a model where interesting components are built in a system programming language and then glued together into applications using the scripting language. This division of labor provides a natural framework for reusability. Components are designed to be reusable, and there are well-defined interfaces between components and scripts that make it easy to use components.
(Là c'est Ousterhout qui parle).
Donc la question n'est pas: tel langage est meilleur que tel autre, mais tel langage (+ l'ecosystème qui va avec, les librairies et les outils de développement, notamment) est plus adapté que tel autre à tel type de problème. Notre métier, c'est l'ECM, et pour faire des composants d'ECM, le meilleur choix aujourd'hui, à notre humble avis, c'est Java, indépendamment des qualités que Python (ou Ruby, ou Groovy, ou JavaScript/ECMAScript) garde par ailleurs. Ces composants d'ECM sont ensuite assemblés, configurés, scriptés, en utilisant des outils plus souples, notamment des descripteurs de types de documents (ex: schémas XML), de formulaires (ex: XForms), des fichiers de configuration de composants (XML), des règles métier, des workflows (ex: BPEL), des scripts.
1. Tu ne cites qu'un bout de la FAQ, celui qui t'arrange. Les raisons du changement sont doubles, techniques et commerciales, et, contraîrement à ce que tu as l'air de penser, les deux ne s'opposent pas. L'excellence technique n'a de sens que si elle peut être utilisée en vrai, dans le contexte d'un système d'information, avec des équipes à formers, etc.
2. Ta citation n'est pas extraite de la dépêche de LinuxFR, mais de notre site. La dépêche en elle-même se focalise sur les aspects techniques de notre annonce, les produits libre et les technologies ouvertes que l'on utilise, le fait que le code est disponible et qu'on a commencé à releaser un module intéressant (en attendant la suite...).
Donc non seulement je ne suis pas d'accord avec toi, mais l'intérêt suscité par cette dépêche dans la communauté LinuxFR (108 commentaires en 1 jour 1/2, ca me parait pas mal du tout :) ) m'incitent à renouveler l'initiative lorsque nous annoncerons de nouveaux modules, en suivant la roadmap (http://www.nuxeo.org/sections/about/roadmap ), à commencer par Nuxeo Core et Nuxeo EP.
Merci à tous pour vos commentaires, et à certains pour votre soutien.
A propos de la formation des gens à Python/Zope: former les développeurs à Python, normalement c'est pas trop dur. Une journée pour avoir de bonnes bases, et ensuite on apprend sur le tas. Bien sûr, entre la réalité et la perception, il y a un écart: il faut que les gens soient motivés pour apprendre, il faut que les responsables ne se braquent pas contre cette idée, etc. Donc effectivement, au niveau perception, on a un obstacle à franchir.
Le deuxième obstacle c'est Zope: Zope 2 est en voie d'obsolescence, le futur c'est Zope 3. Ou pas. En l'état, l'état de l'art consiste à mélanger du Zope 2 et du Zope 3 en utilisant un "bridge" baptisé Five. Donc en terme de formation, un développeur pour bien maitriser la plateforme doit connaitre Zope 2, Zope 3 (qui n'a plus grand chose à voir avec Zope 2, c'est vraiment des concepts complètement différents) et Five (qui a ses propres spécificités). Et la ca devien t vraiment difficile de motiver les gens pour apprendre ces trois technos, sachant qu'il y en a deux qui seront bientôt obsolètes (ou pas).
Zope était le choix rationnel quand on voulait faire du Web en Python en 2000, maintenant il y a Django et Turbogears. La communauté Python est partagée sur ce sujet. C'est assez compliqué à expliquer quand on ne suit pas tout ca de près, mais bon l'impression générale c'est qu'on voit pas trop où ca va.
A propos de Jython: Jython ( http://www.jython.org/ ) c'était une idée géniale en 2000, quelque chose de super prometteur, qui a été embarqué dans les 2-3 années qui ont suivi dans pas mal d'applications (libres et propriétaires, et oui!). Le problème, c'est que la version de 2006 n'a pas évolué (ou si peu) par rapport à la version de 2000. On est toujours bloqué à la version 2.1 de Python, alors que "CPython", l'implémentation "standard" vient de sortir en 2.5. Il y a donc des grosses différences entre les deux. Donc à l'heure actuelle plus grand monde ne s'intéresse à Jython, et il n'y a plus personne pour bosser dessus.
En l'état, on n'a pas encore choisi quel sera le langage de script de la plateforme Nuxeo 5. Mais rassure-toi, il y en aura un ! Pour l'instant on hésite encore entre JavaScript (et oui!), JRuby, Jython et Groovy. Le prérequis évident, c'est que le langage qu'on choisira devra tourner sur la JVM et s'interfacer avec Java conformément à la JSR 223 (http://jcp.org/en/jsr/detail?id=223).
"Tu imagines": c'est ca le pb, tu imagines des trucs mais bon c'est pas comme ca en vrai.
"Java est tout sauf libre": je ne parle pas dans ma phrase de Java (relis ce que j'ai écris), mais des outils et des librairies libres. Je parle d'Eclipse, de Jackrabbit, de Lucene, de JBoss, de jPBM, etc. Alors ne me fais pas dire ce que je n'ai pas dit STP.
"Java est plus vendeur que Python": ben oui, c'est ca l'objet (outre les aspects technologiques) du changement. Ca correspond mieux aux schémas directeurs dans pas mal de boites ou de ministères. C'est plus facile à faire accepter dans les SSII. C'est plus facile à intégrer dans les SI. Y a plus de librairies libres disponibles. Etc. Faire le meilleur logiciel du monde, si personne ne l'utilise, ca ne sert à rien. Donc c'est important d'utiliser des technologies que les gens acceptent facilement.
"Après on mets ses convictions de côté": Avoir des convictions, c'est bien, mais il faut aussi qu'elles soient conformes à la réalité. Et la réalité change, alors les convictions doivent aussi s'adapter. Le choix de Zope était pertinent pour nous en 2000, il ne l'est plus en 2006.
"Je ne suis pas décideur": je suis sûr que tu prends des décisions, la preuve. Je suis désolé que notre nouvelle orientation ne te convienne pas, notre objectif est bien qu'il y a des développeurs qui soient convaincus de la pertinence de notre choix. Mais si ce n'est pas toi, il y en aura d'autres.
Donc sans rancune, et on se donne RDV quand on aura les première versions "montrables" (i.e. d'ici un mois).
"Inventaire à la Prévert": comme je l'ai écrit dans d'autres commentaires, on est dans le cadre d'une architecture à base de composants. Il est important de bien identifier chacun des composants importants qui sont utilisés dans l'architecture, et aussi, et peut-être surtout, sur quelles spécifications standards ils s'appuient, lorsque c'est le cas (ex: JCR, aka JSR-170, JSF, aka JSR-252, etc.).
"je pense que le consortium ObjectWeb pèse de tout son poids idéologique": je pense surtout que c'est "le marché" qui pèse en faveur de Java EE. Le consortium ObjecWeb participe à son niveau à l'écosystème Java libre, comme la Fondation Apache, la fondation Eclipse, JBoss, et bien d'autres, petits ou grands. Il s'agit d'un mouvement de fond, modelé par de nombreux acteurs, aussi bien côté vendeurs que côté utilisateurs, et dans lequel l'excellence technique est un facteur important, mais aussi la capacité à susciter l'adhésions des autres acteurs autour d'une technologie donnée.
Merci de pointer vers notre annonce de recrutement, ca nous aidera peut-être à trouver les bonnes personnes.
Mais d'un autre côté, tu prends les choses un peu à l'envers:
1. Nuxeo cherche à recruter, parce que Nuxeo est une boite en croissance et que pour faire tous les projets qu'on a à faire (sans parler de tous ceux qu'on va arriver à vrendre plus facilement parce qu'on est passé à Java), on a besoin de développeurs.
2. Vu qu'on a changé de techno, autant que le profil du poste corresponde à ce que les gens vont faire une fois embauché: du Java, avec des outils et des librairies libres.
Maintenant, bien sûr qu'on a déja des compétences, vu la base de code qu'on a déjà écrite: http://svn.nuxeo.org/
Enfin, en ce qui concerne l'aspect commercial, ne t'inquiète pas: ce switch a été décidé en partie pour répondre aux attentes des clients et des partenaires.
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.
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.
"c'est une horrible nouvelle pour les performances": je ne vois pas ce qui te fait dire ca. Si on fait ce switch, c'est aussi parce qu'on pense avoir touché le plafond en terme de performance de Zope sur des grosses applications. Donc on pense bien, et les mesures actuelles le montrent, arriver à des gains très nets en performances et en scalabilité.
"marketologues gonfleurs de bulles": là je vois pas le rapport. JCR est une API Java standard depuis 1 an 1/2 (la JSR-170). EJB3 est le fondement de la nouvelle version de Java EE, Java EE 5, qui remplace J2EE. JSF est le framework de présentation standard de Java EE. OSGi est une technologie Java qui est le fondement du modèle de plugins d'Eclipse. Enfin Jackarabbit, Lucene, etc sont des composants, car la richesse du logiciel libre, c'est de pouvoir faire des applications complexes en assemblant des briques plus simples. C'est aussi pourquoi nous avons concu Nuxeo Runtime, pour bénéficier de cette "architecture de composants" qui nous facilite la vie en tant que développeurs (et facilite la vie des intégrateurs qui utilisent nos produits).
[^] # Re: Former des développeurs Python/Zope compétents
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 2.
S.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Former des développeurs Python/Zope compétents
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 3.
je suis heureux d'apprendre que Jython est beaucoup utilisé dans le domaine du calcul scientifique et de la visualisation. Je savais que c'était déja le cas pour CPython, grâce à différents systèmes d'interfaces avec C (SWIG, Pyrex), C++ (SWIG, BOOST, SIP, etc.) et Fortran - cf. http://wiki.python.org/moin/IntegratingPythonWithOtherLangua(...) - qui sont particulièrement utiles dans le domaine du calcul scientifiques.
Comme je l'ai écrit, Jython était une idée géniale au départ (même si d'autres langages de scripts, et notamment Tcl, avaient eu une implémentation sur la JVM avant Python, Jython offrait l'avantage de présenter un modèle objet similaire à celui de Java).
J'ai moi-même utilisé Jython il y a quelques mois pour scripter rapidement quelques tests sur Jackrabbit, au tout début de notre projet de migration.
Microsoft a récemment (il y a deux ans quand même) investi sur Python en embauchant le développeur d'IronPython, portage de Python sur la CLR .NET.
Face à cela, Sun semble avoir fait le choix de Ruby, en embauchant le mois dernier les deux développeurs de JRuby (portage de Ruby sur la JVM, tout le monde l'aura deviné).
La JSR 223 promet une bonne intégration entre l'environement Java et les langages de scripts qui ont été portés sur la JVM. Il y a déja une vingtaine de langages qui répondent à la spec, dont: Python, TCL, Ruby, JavaScript, PHP, Groovy, Scheme, Pnuts, Judoscript, etc.
On constate qu'aucun expert Python (aucun connu de moi, en tout cas), ne semble avoir participé au groupe d'expert dans le cadre du JCP: http://www.jcp.org/en/jsr/detail?id=223 Mais ce n'est sans doute pas un problème, ca montre juste un désintérêt, il me semble.
Maintenant, si personne ne se motive pour mettre Jython à jour avec la version 2.5 de Python (qui présente quand même de très gros changements avec la version 2.1, en fait c'est dans les 2.2, 2.3 et 2.4 qu'ont été introduits les "new style classes", les métaclasses, les annotations, etc. - bref toutes les features modernes de Python), il est clair que les gens vont se tourner vers d'autres langages de scripts pour scripter leurs applis Java.
J'en suis le premier désolé. C'est la règle du logiciel libre (et du logiciel en général): s'il n'y a personne pour développer, ca n'avance plus.
D'un autre côté, c'est un projet passionnant, je trouve, et il y a peut-être des lecteurs de LinuxFR à la recherche d'un projet dans le domaine de la compilation et de l'implémentation d'un langage moderne qui seront tentés. Peut-être même qu'il y a de l'inspiration à chercher du côté d'IronPython.
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: La pub débarque sur linuxfr!
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 5.
Ce qu'on a toujours dit, et qui ne change pas, depuis l'article fondateur de John Ousterhout en 1998 (http://en.wikipedia.org/wiki/John_Ousterhout ), Scripting: Higher Level Programming for the 21st Century (http://home.pacbell.net/ouster/scripting.html ), c'est qu'il y a une place pour les deux types de langages, les langages de scripts et les langages de programmation de composants (qu'il appelle lui "langages de programmation système"), et que les deux sont complémentaires:
(Là c'est Ousterhout qui parle).
Donc la question n'est pas: tel langage est meilleur que tel autre, mais tel langage (+ l'ecosystème qui va avec, les librairies et les outils de développement, notamment) est plus adapté que tel autre à tel type de problème. Notre métier, c'est l'ECM, et pour faire des composants d'ECM, le meilleur choix aujourd'hui, à notre humble avis, c'est Java, indépendamment des qualités que Python (ou Ruby, ou Groovy, ou JavaScript/ECMAScript) garde par ailleurs. Ces composants d'ECM sont ensuite assemblés, configurés, scriptés, en utilisant des outils plus souples, notamment des descripteurs de types de documents (ex: schémas XML), de formulaires (ex: XForms), des fichiers de configuration de composants (XML), des règles métier, des workflows (ex: BPEL), des scripts.
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: La pub débarque sur linuxfr!
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 3.
1. Tu ne cites qu'un bout de la FAQ, celui qui t'arrange. Les raisons du changement sont doubles, techniques et commerciales, et, contraîrement à ce que tu as l'air de penser, les deux ne s'opposent pas. L'excellence technique n'a de sens que si elle peut être utilisée en vrai, dans le contexte d'un système d'information, avec des équipes à formers, etc.
2. Ta citation n'est pas extraite de la dépêche de LinuxFR, mais de notre site. La dépêche en elle-même se focalise sur les aspects techniques de notre annonce, les produits libre et les technologies ouvertes que l'on utilise, le fait que le code est disponible et qu'on a commencé à releaser un module intéressant (en attendant la suite...).
Donc non seulement je ne suis pas d'accord avec toi, mais l'intérêt suscité par cette dépêche dans la communauté LinuxFR (108 commentaires en 1 jour 1/2, ca me parait pas mal du tout :) ) m'incitent à renouveler l'initiative lorsque nous annoncerons de nouveaux modules, en suivant la roadmap (http://www.nuxeo.org/sections/about/roadmap ), à commencer par Nuxeo Core et Nuxeo EP.
Merci à tous pour vos commentaires, et à certains pour votre soutien.
Amitiés à tous ceux qui me connaissent.
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Former des développeurs Python/Zope compétents
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 4.
Le deuxième obstacle c'est Zope: Zope 2 est en voie d'obsolescence, le futur c'est Zope 3. Ou pas. En l'état, l'état de l'art consiste à mélanger du Zope 2 et du Zope 3 en utilisant un "bridge" baptisé Five. Donc en terme de formation, un développeur pour bien maitriser la plateforme doit connaitre Zope 2, Zope 3 (qui n'a plus grand chose à voir avec Zope 2, c'est vraiment des concepts complètement différents) et Five (qui a ses propres spécificités). Et la ca devien t vraiment difficile de motiver les gens pour apprendre ces trois technos, sachant qu'il y en a deux qui seront bientôt obsolètes (ou pas).
Zope était le choix rationnel quand on voulait faire du Web en Python en 2000, maintenant il y a Django et Turbogears. La communauté Python est partagée sur ce sujet. C'est assez compliqué à expliquer quand on ne suit pas tout ca de près, mais bon l'impression générale c'est qu'on voit pas trop où ca va.
J'avais essayé de synthétiser la situation il y a 8 mois avec un schéma, maintenant c'est encore plus compliqué (et ca m'intéresse moins): http://blogs.nuxeo.com/sections/blogs/fermigier/2006_01_22_u(...)
A propos de Jython: Jython ( http://www.jython.org/ ) c'était une idée géniale en 2000, quelque chose de super prometteur, qui a été embarqué dans les 2-3 années qui ont suivi dans pas mal d'applications (libres et propriétaires, et oui!). Le problème, c'est que la version de 2006 n'a pas évolué (ou si peu) par rapport à la version de 2000. On est toujours bloqué à la version 2.1 de Python, alors que "CPython", l'implémentation "standard" vient de sortir en 2.5. Il y a donc des grosses différences entre les deux. Donc à l'heure actuelle plus grand monde ne s'intéresse à Jython, et il n'y a plus personne pour bosser dessus.
En l'état, on n'a pas encore choisi quel sera le langage de script de la plateforme Nuxeo 5. Mais rassure-toi, il y en aura un ! Pour l'instant on hésite encore entre JavaScript (et oui!), JRuby, Jython et Groovy. Le prérequis évident, c'est que le langage qu'on choisira devra tourner sur la JVM et s'interfacer avec Java conformément à la JSR 223 (http://jcp.org/en/jsr/detail?id=223).
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Bonne nouvelle ?
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 9.
"Java est tout sauf libre": je ne parle pas dans ma phrase de Java (relis ce que j'ai écris), mais des outils et des librairies libres. Je parle d'Eclipse, de Jackrabbit, de Lucene, de JBoss, de jPBM, etc. Alors ne me fais pas dire ce que je n'ai pas dit STP.
"Java est plus vendeur que Python": ben oui, c'est ca l'objet (outre les aspects technologiques) du changement. Ca correspond mieux aux schémas directeurs dans pas mal de boites ou de ministères. C'est plus facile à faire accepter dans les SSII. C'est plus facile à intégrer dans les SI. Y a plus de librairies libres disponibles. Etc. Faire le meilleur logiciel du monde, si personne ne l'utilise, ca ne sert à rien. Donc c'est important d'utiliser des technologies que les gens acceptent facilement.
"Après on mets ses convictions de côté": Avoir des convictions, c'est bien, mais il faut aussi qu'elles soient conformes à la réalité. Et la réalité change, alors les convictions doivent aussi s'adapter. Le choix de Zope était pertinent pour nous en 2000, il ne l'est plus en 2006.
"Je ne suis pas décideur": je suis sûr que tu prends des décisions, la preuve. Je suis désolé que notre nouvelle orientation ne te convienne pas, notre objectif est bien qu'il y a des développeurs qui soient convaincus de la pertinence de notre choix. Mais si ce n'est pas toi, il y en aura d'autres.
Donc sans rancune, et on se donne RDV quand on aura les première versions "montrables" (i.e. d'ici un mois).
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Bonne nouvelle ?
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 3.
"je pense que le consortium ObjectWeb pèse de tout son poids idéologique": je pense surtout que c'est "le marché" qui pèse en faveur de Java EE. Le consortium ObjecWeb participe à son niveau à l'écosystème Java libre, comme la Fondation Apache, la fondation Eclipse, JBoss, et bien d'autres, petits ou grands. Il s'agit d'un mouvement de fond, modelé par de nombreux acteurs, aussi bien côté vendeurs que côté utilisateurs, et dans lequel l'excellence technique est un facteur important, mais aussi la capacité à susciter l'adhésions des autres acteurs autour d'une technologie donnée.
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Bonne nouvelle :)
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 3.
Ta société = SCUB (http://www.scub.net) ?
Peut-être aura-t-on l'occasion de bosser ensemble un de ces jours ;)
S.
--
Stefane Fermigier, PDG, Nuxeo -- http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Bonne nouvelle ?
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 9.
Mais d'un autre côté, tu prends les choses un peu à l'envers:
1. Nuxeo cherche à recruter, parce que Nuxeo est une boite en croissance et que pour faire tous les projets qu'on a à faire (sans parler de tous ceux qu'on va arriver à vrendre plus facilement parce qu'on est passé à Java), on a besoin de développeurs.
2. Vu qu'on a changé de techno, autant que le profil du poste corresponde à ce que les gens vont faire une fois embauché: du Java, avec des outils et des librairies libres.
Maintenant, bien sûr qu'on a déja des compétences, vu la base de code qu'on a déjà écrite: http://svn.nuxeo.org/
Enfin, en ce qui concerne l'aspect commercial, ne t'inquiète pas: ce switch a été décidé en partie pour répondre aux attentes des clients et des partenaires.
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Poisson
Posté par Stefane Fermigier (site web personnel) . En réponse au journal Pierre Tramo a frappé !. Évalué à 1.
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
[^] # Re: Et les clients actuels?
Posté par Stefane Fermigier (site web personnel) . En réponse au journal Pierre Tramo a frappé !. Évalué à 1.
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
[^] # Re: Bonne nouvelle ?
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 10.
"marketologues gonfleurs de bulles": là je vois pas le rapport. JCR est une API Java standard depuis 1 an 1/2 (la JSR-170). EJB3 est le fondement de la nouvelle version de Java EE, Java EE 5, qui remplace J2EE. JSF est le framework de présentation standard de Java EE. OSGi est une technologie Java qui est le fondement du modèle de plugins d'Eclipse. Enfin Jackarabbit, Lucene, etc sont des composants, car la richesse du logiciel libre, c'est de pouvoir faire des applications complexes en assemblant des briques plus simples. C'est aussi pourquoi nous avons concu Nuxeo Runtime, pour bénéficier de cette "architecture de composants" qui nous facilite la vie en tant que développeurs (et facilite la vie des intégrateurs qui utilisent nos produits).
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
# Le site d'apogee est en ligne + mailing list apogee
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Moteur XForms libre pour Eclipse/SWT disponible. Évalué à 1.
lists.nuxeo.com/mailman/listinfo/apogee
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Paquets Debian
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche CPS 3.2.3 (stable) et 3.3.0 (devel) disponibles. Évalué à 2.
Voici les bonnes URLs:
For CPS 3.2.x (stable releases) add in your /etc/apt/sources.list :
For CPS 3.1.x and CPS 3.3.x (development releases) add in your /etc/apt/sources.list :
"There's no such thing as can't. You always have a choice." - Ken Gor
# Paquets Debian
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche CPS 3.2.3 (stable) et 3.3.0 (devel) disponibles. Évalué à 2.
For CPS 3.2.x (stable releases) add in your /etc/apt/sources.list :
deb http://www.cps-project.org/debian/testing/(...(...)) ./
deb-src http://www.cps-project.org/debian/testing/(...(...)) ./
For CPS 3.1.x and CPS 3.3.x (development releases) add in your /etc/apt/sources.list :
deb http://www.cps-project.org/debian/unstable/(...(...)) ./
deb-src http://www.cps-project.org/debian/unstable/(...(...)) ./
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Ou parle-t-on de CourierCPS ?
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Sortie de CourierCPS, une solution de gestion de courrier. Évalué à 3.
"There's no such thing as can't. You always have a choice." - Ken Gor
# Plus d'infos sur l'annonce
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Sortie de CourierCPS, une solution de gestion de courrier. Évalué à 6.
http://www.nuxeo.com/news/49(...)
et dans cet article de ZSNet:
http://www.zdnet.fr/actualites/technologie/0,39020809,39153407,00.h(...)
"There's no such thing as can't. You always have a choice." - Ken Gor