Articles précédents : Logiciel
- [20] Hyla 0.7.0
- [9] Men are ants
- [29] Sylpheed-Claws 2.5.0 est sorti !
- [84] OpenOffice.org prend désormais en compte la nouvelle orthographe française
- [34] Salto Consulting se met à l'Open Source
- [124] Nvu, Kompozer et Mozilla Composer
- [16] Asterisk 1.4 beta est disponible
- [109] Sortie du noyau Linux 2.6.18
- [80] Subversion 1.4.0 est disponible
- [54] La correction grammaticale sous Linux x86 avec Antidote
Liens connexes
- Nuxeo 5 (1185 hits)
- La FAQ sur le passage à Java (575 hits)
- Nuxeo CPS (179 hits)
- Interview de l'équipe technique sur InfoQ (167 hits)
- Le module Nuxeo Runtime (107 hits)
Dépêche modérée par
Dépêche éditée par
Logiciel : Nuxeo CPS tournera sous Java
Posté par Stefane Fermigier (page perso, ). Modéré le 28 septembre 2006.
Le logiciel a été au passage renommé Nuxeo 5, et devrait sortir au novembre d’après la feuille de route du projet. Il sert à réaliser des applications à la fois en environnement serveur (Java EE) et en environnement client riche (RCP).
Il repose sur
- un module qui fournit un système de composants extensibles et faciles à déployer et baptisé Nuxeo Runtime. Ce module peut d’ailleurs être utilisé dans tout type d’application Java. La version 1.0 a été annoncée cette semaine,
- un “coeur de gestion documentaire”, Nuxeo Core qui fournit les fonctions de base de la gestion documentaire, et qui peut être embarqué aussi bien dans des applications serveurs que clientes. La version 1.0 sortira en octobre
Nuxeo 5 utilisera la licence LGPL.
![[en]](../../../images/en.png)
Nuxeo 5 (1185 hits)![[fr]](../../../images/fr.png)
La FAQ sur le passage à Java (575 hits)-
Interview de l'équipe technique sur InfoQ (167 hits)
-
Le module Nuxeo Runtime (107 hits)
-
Nuxeo CPS (179 hits)
> Lire la dépêche (175 commentaires, moyenne: 2,6).
et bien...
c'est pas ça qui va faire baisser le prix de la RAM!
-
[^]Re: et bien...
Posté par PasChauve PasOunet () le 28/09/2006 à 15:09. (lien). Évalué à 5.c'est pas ça qui va faire baisser le prix de la RAM!
Ca compensera avec le gain en CPU.
Et Python ça pue du Zope ?
Jeu de mot pourri mis à part, que deviens Zope ?
Zope était super à la mode il y a quelques années à l'époque ou Python devait régner sur l'univers. Mais depuis que c'est Ruby qui est le futur empereur intergalactique du web je n'en entends plus trop parler.
Y a-t-il encore des projets actifs basés sur Zope ?
-
[^]Re: Et Python ça pue du Zope ?
Posté par NiCoS (page perso, ) le 28/09/2006 à 15:24. (lien). Évalué à 3.- django ( http://www.django-project.org )
- turbogears ( http://www.turbogears.com)
et d'autres frameworks web (pylons, etc.)
Pour zope, zope 3 devrait arriver mais je suis plus trop son actualité...-
[^]Re: Et Python ça pue du Zope ?
Posté par NiCoS (page perso, ) le 28/09/2006 à 15:25. (lien). Évalué à 4.Oups pardon, je réponds pas à la question.
Donc oui il reste des projets sur python.
Sur zope, il reste notamment plone ( http://www.plone.org )
-
[^]Re: Et Python ça pue du Zope ?
Posté par Borax (page perso, ) le 29/09/2006 à 05:16. (lien). Évalué à 4.Zope 3 est sorti depuis assez longtemps maintenant.
Plus exactement, la version 3.3 stable vient de sortir il y a quelques jours.
Le produit a donc atteint une certaine maturité ; mais l'architecture complète du serveur d'applications a été totalement revue et on ne dispose pas encore d'autant de "produits" complémentaires que dans Zope2...
-
Bonne nouvelle ?
J'avoue être assez dubitatif en lisant l'article :
- c'est certainement une bonne nouvelle pour CPS car peu d'entreprises ont la capacité, ou l'intention, d'entretenir et de gérer des compétences Python/Zope et Java. Ce portage devrait donc convaincre beaucoup de réticents.
- c'est une mauvaise nouvelle pour Zope qui perd l'exclusivité d'un très bon produit.
- c'est une horrible nouvelle pour les performances.
Au passage je constate avec amertume que les marketologues gonfleurs de bulles, et vendeurs de "nouvelle économie" sont de retour et bien décidés à nous en remettre plein la vue :
'... Java EE 5, et utilise un grand nombre de technologies standards (JCR,
EJB3, JSF, OSGi
) et de produits libres (Apache Jackrabbit, Lucene, JBoss AS, jBPM, JBoss Rules, Seam
)' sauf que là c'est 'standard' et 'libre', donc on va en avoir encore plus pour notre argent et pour nos yeux : ressortez les Ray-Ban les gars ! :-)
Montre moi ton code, je te dirais qui tu es.
-
[^]Re: Bonne nouvelle ?
Posté par PasChauve PasOunet () le 28/09/2006 à 15:17. (lien). Évalué à 10.- c'est une horrible nouvelle pour les performances.
C'est marrant mais j'aurais dis exactement le contraire , python n'est vraiment pas célèbre pour ses performances.-
[^]Re: Bonne nouvelle ?
Posté par Yannick Beynet (page perso, ) le 28/09/2006 à 15:19. (lien). Évalué à 6.vous avez raison tous les deux :)
-
[^]Re: Bonne nouvelle ?
Posté par Nicolas (page perso, ) le 28/09/2006 à 15:20. (lien). Évalué à 0.Et s'il faisait nuxeo6 en php ? :-)
-
[^]Re: Bonne nouvelle ?
Posté par Grumbl (page perso, ) le 28/09/2006 à 15:24. (lien). Évalué à 1.Si les performances étaient l'objet du débat, ya bien une certaine VM de Perl6 qui arrachaise sa mère de son short.
-
-
-
-
[^]Re: Bonne nouvelle ?
Posté par Stefane Fermigier (page perso, ) le 28/09/2006 à 15:29. (lien). Évalué à 10."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).
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/-
[^]Re: Bonne nouvelle ?
Posté par Nicolas (page perso, ) le 28/09/2006 à 15:48. (lien). Évalué à 4.["marketologues gonfleurs de bulles": .....]
Je trouve tout de même que cela ressemble énormément à cela. Tes arguments sont sûrement légitimes et je ne permettrais pas de te mettre en doute sur les points que tu mets en avant. Mais auprès du décideur pressé java ça fait nettement plus sérieux que python.
De plus, nuxeo certfie à ses clients depuis des années que zope/python sont des technologies robustes éprouvées, maitrisées en interne... Il va falloir embaucher un super commercial pour expliquer au client pourquoi la technologie d'hier ne sera plus celle utilisée demain. Comment expliquer au client qui a capitalisé sur zope/python/cps depuis des années, qu'il peut tout jeter et se mettre à java ?
Nuxeo cherche à embaucher un développeur java:
http://fr.lolix.org/search/offre/offre.php3?id=6192
Il n'y a pas de compétences en interne ? Personnellement ça ne m'inciterait pas à migrer.
Les développeurs déjà présents chez nuxeo vont-ils rester ? Qu'en pensent-ils ? Je pense notament à Tarek. Je le vois mal se mettre à java!!-
[^]Re: Bonne nouvelle ?
Posté par Stefane Fermigier (page perso, ) le 28/09/2006 à 16:20. (lien). Évalué à 9.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.
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/-
[+] [^]Re: Bonne nouvelle ?
Posté par Nicolas (page perso, ) le 28/09/2006 à 18:46. (lien). Évalué à -1.Merci de pointer vers notre annonce de recrutement, ca nous aidera peut-être à trouver les bonnes personnes.
Tant mieux. Je pense que le battage se fait très bien sans moi.
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.
J'adore cette façon d'éluder les questions. J'imagine que le changement de techno a dûr être difficile et que cela n'a pas dû être une mince affaire de convaincre les développeurs de cps d'abandonner python au profit de java. Mais si je comprends bien tout ce qu'on lit sur la page d'accueil du projet cps, c'est du vent ? La plateforme zope robuste ? Non, on va utiliser jboss! etc
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.
java est tout sauf libre. Je veux bien admettre à la rigueur qu'il soit opensource mais absolument pas libre. Ne parlons même pas de la machine virtuelle.
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.
On va finir par y arriver! C'est ce que je disais dans mon message un peu plus haut. java c'est plus vendeur que python auprès du décideur pressé. Après on mets ses convictions de côté.
Je ne voudrais pas être le premier client qui va essuyer les plâtres du passage de cps à nuxeo5.
Je ne suis pas décideur mais un simple développeur qui commençait à lorgner du côté de cps. Je vais passer mon chemin.-
[^]Re: Bonne nouvelle ?
Posté par TImaniac (page perso, ) le 28/09/2006 à 19:12. (lien). Évalué à 0.java est tout sauf libre. Je veux bien admettre à la rigueur qu'il soit opensource mais absolument pas libre. Ne parlons même pas de la machine virtuelle.
Oué d'ailleur on s'est bien connu, la FSF et ses softs GNU sont pas du tout libre, "à peine" open-source, comme le compilateur Java GCJ ou le projet de bibliothèque de classes GnuClassPath.
D'ailleur la licence qu'ils utilisent est pas libre du tout, et ca a contaminé pleins de projets autour de Java, ces traitres étant cités dans cette dépêche. Certains ont même fait l'affrond d'utiliser une licence encore moins libre du type MIT/X11, vous vous rendez compte ?
Java c'est vraiment pas libre.
-
[^]Re: Bonne nouvelle ?
Posté par Stefane Fermigier (page perso, ) le 28/09/2006 à 19:45. (lien). Évalué à 9."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).
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/-
[+] [^]Re: Bonne nouvelle ?
Posté par Yannick Beynet (page perso, ) le 29/09/2006 à 06:59. (lien). Évalué à -10.Vous avez bien raison.
Je vous propose de faire un patch du kernel linux. Le passer en java serait aussi plus vendeur :)
-
[^]Re: Bonne nouvelle ?
Posté par Alexandre Garel () le 02/10/2006 à 12:01. (lien). Évalué à 2.Bonjour,
Perso je comprends tout à fait le choix de Nuxeo.
Ceci ne m'empêche pas de pleurer la perte d'une entreprise qui utilisait Python avec brio.
Je suis développeur Java et j'aimerais plutôt trouver un job python tellement je trouve ce language (et sa dynamique de communauté) plus attrayant.
Je comprends bien que vous aviez vraiment atteint des limittes de ZODB mais sur ce point, il suffisait d'utiliser une base SQL plutôt que ZODB pour certains objets.
Je suis peiné d'une décision qui me semble avant tout marketing En effet j'ai vraiment l'impression qu'il faut surtout rassurer les décideurs des administrations qui on fait le choix de java et qui n'ont pas confiance dans leur développeurs pour intégrer des choses nouvelles.
-
-
[^]Re: Bonne nouvelle ?
Posté par jcs (page perso, ) le 28/09/2006 à 20:42. (lien). Évalué à 2.java est tout sauf libre. Je veux bien admettre à la rigueur qu'il soit opensource mais absolument pas libre. Ne parlons même pas de la machine virtuelle.
Erreur, la JVM est elle aussi "open source" (sinon il n'y aurait pas de JVM sous BSD) mais simplement elles ne sont pas distribuées avec le JDK.-
[^]Re: Bonne nouvelle ?
Posté par stephwww () le 29/09/2006 à 09:28. (lien). Évalué à 1.Je connais asser mal le milieu Java et ta remarque me laisse perplexe, je
comprends pas grand chose avec les licences Java :
Les outils comme la JVM, Jboss, gcj & co peuvent être libres et distribués
librement, mais pas le JDK, c'est le kit de dev ? Quand tu développes en Java
il te faut forcément un JDK, non ? Pour écrire du code Java il faut une licence ?-
[^]Re: Bonne nouvelle ?
Posté par jcs (page perso, ) le 01/10/2006 à 08:30. (lien). Évalué à 4.Je voulais simplement dire que les sources du JDK et de la JVM de Sun sont disponibles (http://www.sun.com/software/communitysource/j2se/java2/downl(...) ) sous une licence Sun Community Source qui, à ce que j'en sais, n'est pas libre. Cependant ces sources sont utilisées pour disposer d'un JDK sous FreeBSD qui n'est pas maintenu par Sun.
Sinon il existe aussi le projet Harmony (http://incubator.apache.org/harmony/ ) qui couvre pour le moment environ 90% de l'API de Java 1.5
-
-
-
[^]Re: Bonne nouvelle ?
Posté par clearstream () le 28/09/2006 à 21:08. (lien). Évalué à 10.> java est tout sauf libre.
Quel java ? Celui de Sun ?
Effectivement il n'est pas libre.
Celui dans gcj/etc ?
Ils sont libres.
Pour indication, gcj/etc est dans par Fedora Core et RHEL (et sûrement beaucoup d'autre). Or le responsable juridique de Fedora Core et RHEL est Red Hat ! Ce dernier est le concurrent le plus sérieux de Solaris (Red Hat pique plein de clients à Solaris).
Afin après l'achat de JBoss par Red Hat, Red Hat commence à se faire pas mal de pognon avec java :
http://www.redhat.com/about/news/prarchive/2006/earnings_200(...) :JBoss-related revenue of $7 million
S'il y avait le moindre problème avec gcj/etc :
- Red Hat retirerait gcj/etc.
- Sun attaquerait Red Hat
-
[^]Re: Bonne nouvelle ?
Posté par boubou (page perso, ) le 29/09/2006 à 09:37. (lien). Évalué à 10.java est tout sauf libre. Je veux bien admettre à la rigueur qu'il soit opensource mais absolument pas libre. Ne parlons même pas de la machine virtuelle.
C'est vraiment pénible de lire encore et toujours de telles stupidités. Je vais encore faire ma pub, mais je te conseille vivement de lire mon article paru dans linux mag il y a deux ans (http://apiacoa.org/publications/2004/lm-java-dotnet-free.pdf ) tu comprendras peut être que :
1) on peut implémenter Java (jre+jdk) sous une licence libre et c'est ce que font les projets classpath, harmony, kaffe, etc.
2) open source ne devrait être utilisé que dans le sens des inventeurs du terme, l'OSI. Dans ce cas il veut dire libre.
Enfin, Sun a annoncé officiellement le passage intégral de son implémentation de Java en open source (cf http://community.java.net/jdk/opensource/ ). On devrait voir les premiers morceaux en octobre. Si tu veux des détails, je te suggère de lire le prochain numéro de linux mag (la semaine prochaine) pour mon nouvel article sur Java et .NET (et pour tous les autres articles du mag, bien sûr).
-
-
-
[^]Re: Bonne nouvelle ?
Posté par TImaniac (page perso, ) le 28/09/2006 à 16:24. (lien). Évalué à 7.De plus, nuxeo certfie à ses clients depuis des années que zope/python sont des technologies robustes éprouvées, maitrisées en interne... Il va falloir embaucher un super commercial pour expliquer au client pourquoi la technologie d'hier ne sera plus celle utilisée demain
Si t'as lu tout l'article, tu constateras que c'est aussi une demande des clients ce changement technologique : pour beaucoup d'entre eux il est difficile d'avoir des personnes compétentes/acteurs compétents en Python. Même si la techno est robuste et éprouvée, faut pas perdre de vue tout l'ecosystème qui gravite autour. Et forcé de constater que Java est beaucoup plus garni dans ce domaine.
En fait c'est un problème bien connu de dépendance envers des solutions "exotiques" qui obligent l'utilisateur/client à être dépendant d'un nombre réduit d'acteurs.-
[^]Re: Bonne nouvelle ?
Posté par Michel Galle () le 28/09/2006 à 20:21. (lien). Évalué à 10.je confirme que mon supérieur et moi même on a été au début supris de l'annonce car nuxeo était un gros contributeur de zope.
mais cps 4 annonçait déjà l'usage de java
et oui, en tant qu'admin systeme qui fera du développement autour de nuxeo (car on utilise déjà cps ) le passage à Java est très intéressant.
Peu de gens ont des compétences zope. Nous avons beaucoup d'outils autour de nous pour travailler avec java. Il nous sera plus facile de nous mettre au développement java que zope.
alors bien sur il y a foule de terme techniques commençant en J et pour certains cela semble être du marketing vide. Java est très standardisé, à tous les niveaux : api, déploiement, modélisation de l'application, etc. On a de nombreux outils qui sont pour la plupart mature. De plus , je ne pense pas qu'on puisse considérer Lucene, les projets apache et autre Jboss comme des projets vides à la "startup". Ils existent depuis des années et sont utilisés dans de nombreuses entreprises.
pour le déploiement d'applications web, franchement, où se situe zope/python ?
entre j2ee/java et apache/php ? qu'apporte-t-il concrètement ? Java est complexe, java est lourd à mettre en oeuvre, mais zope ne l'était pas moins. et au moins on profite de la GALAXIE de développements autour de Java. Java est déjà pérennisé. Les gens sont formés à Java. Il n'y a pas de monopole de technologies Java, on peut contacter je ne sais combien de SSII pour travailler sur java. du point de vue d'entreprise c'est très dur de convaincre avec une autre technologie.
Quand j'ai commencé à m'intéresser à la gestion documentaire et à CPS, zope/python m'a clairement _rebuté_.
Je suis obligé de me farcir ZopeDB etc pour pratiquement UN seul logiciel (cps., qui va me parler d'autre chose ? plone ? ). Java au contraire je le retrouve dans je ne sais plus combien des autres outils d'entreprise.
je peux comprendre python pour créer des applications Gnomes et du développement rapide, mais en tant que langage pour applications d'entreprises je ne vois pas .
Zope/python n'est pas plus rapide, n'est pas plus simple, il a moins d'outils dédiés à son développement que java, à moins d'entreprises qui contribuent à son amélioration, est + obscure que java, moins documenté, moins de composants s'interfaçant avec, etc.
la seule tâche à java c'est que sun n'a pas encore mis la jvm sous une licence libre qui autorise sa distribution dans tous les linux.
"Prétendre que tout le monde gagne à cette uniformisation c'est faux : comme avec Microsoft ce sont des centaines de solutions technologiques alternatives telles que Zope qui risquent de disparaître à long terme."
c'est le marché et des gens comme moi qui font que cela disparaisse ou non.
S'il y a toujours une demande zope, zope continuera.
Linux, personne ne l'attendait, dans un monde tout windows, mais il y avait un Besoin, une NECESSITE, et ca a pris son temps mais ca n'a fait que grandir et mûrir.
ici, nous ne sommes pas dans une bataille de "libre contre propriétaire".
mais plutôt dans une nostalgie, où l'on voit qu'une technologie est très implantée et victorieuse et où le challenger, de qualité certes, ne décolle pas.
peut être un jour nous verrons pareil avec Ruby et Php.-
[^]Re: Bonne nouvelle ?
Posté par Nicolas (page perso, ) le 28/09/2006 à 20:57. (lien). Évalué à 0.Michel a bien résumé ce que j'ai en vain essayer de dire:
"Prétendre que tout le monde gagne à cette uniformisation c'est faux : comme avec Microsoft ce sont des centaines de solutions technologiques alternatives telles que Zope qui risquent de disparaître à long terme."
c'est le marché et des gens comme moi qui font que cela disparaisse ou non.
Je suis juste déçu par la direction que prend nuxeo.
Après si un jour il faut faire du web avec un serveur d'application tournant avec java, pourquoi devrai-je utiliser un nouveau produit (nuxeo5) et pas un produit ayant fait ses preuves tel que documentum par exemple ? C'est une question très sérieuse. Pourquoi nuxeo qui change de techno comme de chemise plutôt qu'une autre société qui a fait le "pari" de java dès le départ ?-
[^]Re: Bonne nouvelle ?
Posté par Eric Barroca (page perso, ) le 28/09/2006 à 23:21. (lien). Évalué à 3.Parce que Documentum n'a pas du tout fait le pari de Java dès le départ? Parce que Nuxeo5 offre plus d'avantages que Documentum? Parce qu'il est meilleurs techniquement, fonctionnellement et moins cher à mettre en oeuvre?
Pour info, Documentum c'est du bon vieux C avec une architecture qui date de 15 ans...
Bonne soirée,
EB.-
[^]Re: Bonne nouvelle ?
Posté par Gabriel () le 30/09/2006 à 05:50. (lien). Évalué à 1.Et pour avoir discuté avec des gens qui ont utilisé cet outil, Documentuum, c'est un parcours du combattant, entre bugs et manques de fonctionnalités... un mot en 5 lettres me vient à l'esprit
--
Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying
-
-
[^]Re: Bonne nouvelle ?
Posté par Boa Treize (page perso, ) le 29/09/2006 à 06:00. (lien). Évalué à 10.Pourquoi nuxeo qui change de techno comme de chemise
Pourquoi tous les commentateurs disent-ils que Nuxeo change de techno comme de chemise ?! Parce qu'il n'y a pas eu de pré-annonce et de plan média auparavant ?
Garder quelque chose six ans et mettre plus de six mois à se décider à en changer, j'appelle pas ça changer de chemise. Ou alors, nous n'avons pas les mêmes valeurs. Moi c'est une fois par jour, et ça me prend une dizaine de secondes pour choisir quelle chemise mettre.
-
-
-
-
-
[^]Re: Bonne nouvelle ?
Posté par Loïc Ibanez () le 28/09/2006 à 16:43. (lien). Évalué à 6.Je regrette que pour faire la promotion d'un bon produit Nuxeo se sente obligé de faire un inventaire à la Prévert de composants J2EE. Ca n'impressionne plus guère et ça éveille surtout les soupçons de ceux qui ont le spectre de la bulle internet en mémoire.
Pour ce qui est de Java/J2EE, je pense que le consortium ObjectWeb pèse de tout son poids idéologique...--
Montre moi ton code, je te dirais qui tu es.-
[^]Re: Bonne nouvelle ?
Posté par Stefane Fermigier (page perso, ) le 28/09/2006 à 17:59. (lien). Évalué à 3."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.
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/-
[^]Re: Bonne nouvelle ?
Posté par Loïc Ibanez () le 28/09/2006 à 19:54. (lien). Évalué à 7."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." Stop Stefane. La dialectique science-pipo ça ne m'impressionne plus, et pour cause. Ton "mouvement de fond" est assez simple à décortiquer : - pour les développeurs c'est augmenter la probabilité de trouver un emploi en ne maîtrisant qu'un language : Java - pour les entreprises c'est limiter les risques de dérapages salariaux en ne gérant qu'une population homogène d'informaticiens : des développeurs Java. D'où Ie fait que tes clients te poussent à faire du Java. Prétendre que tout le monde gagne à cette uniformisation c'est faux : comme avec Microsoft ce sont des centaines de solutions technologiques alternatives telles que Zope qui risquent de disparaître à long terme. Maintenant je ne t'en veux pas : tu dois avant tout assurer la pérennité de ton entreprise et il est clair que dans ce cadre porter CPS sous Java était une nécessité. Au passage bravo à Nuxeo pour sa créativité et ses talents.
--
Montre moi ton code, je te dirais qui tu es.-
[+] [^]Re: Bonne nouvelle ?
Posté par Stéphane TRAUMAT (page perso, ) le 29/09/2006 à 14:41. (lien). Évalué à -1."Java - pour les entreprises c'est limiter les risques de dérapages salariaux "
mmmm As tu vu le salaire moyen des développeurs Java ?
Je peux te dire que si tu veux éviter les dérapages salariaux, mieux vaut chercher des développeurs windev ou php.
De plus, il y a quand même une sacré pénurie de ce type de développeur....-
[^]Re: Bonne nouvelle ?
Posté par Larry Cow () le 29/09/2006 à 20:24. (lien). Évalué à 4.Je peux te dire que si tu veux éviter les dérapages salariaux, mieux vaut chercher des développeurs windev ou php.
Tout dépend ce que tu entends par "dérapages salariaux". Si c'est rapport au salaire, il est clair qu'un bon dév Java te coutera plus cher qu'un des sus-nommés.
Maintenant, si tu cherches un développeur qui sait coder, mieux vaut éviter le développeur Windev ("hein? c'est quoi un algorithme?" - authentique) et le codeur PHP ("gruiiiik!"). BIen entendu, ça reste statistique, mais c'est des langages dont l'écosystème est rempli de boulets incompétents qui auraient mieux fait de rester dans l'agriculture (pour Windev) et de djeunz nourris au web "de zéro" (pun intended) plus habitués à faire des sites vite fait pour le groupe de rock des potes qu'à concevoir une application complexe.
Après, faut pas me faire dire ce que j'ai pas dit : je doute qu'il existe un langage dont la communauté soit exemplaire. Je suis même plutôt convaincu qu'un développeur ayant plusieurs cordes à son arc (et si possible des cordes assez éloignées, pas trop "C/C++/C#/Java", si vous voyez ce que je veux dire) sera largement plus adaptable. Après, évidemment, si ce qu'on veut c'est de le rentabilité à court terme et un renouvellement à moyen/long terme... autant prendre du jetable ("Écoute Jean-Guy, le Java ça paye plus cette année, faudrait voir à nous virer tous les petits gars du 3è et à les remplacer par des ingénieurs C#, ok?").
-
-
-
-
-
-
[^]Re: Bonne nouvelle ?
Posté par Stéphane TRAUMAT (page perso, ) le 28/09/2006 à 15:59. (lien). Évalué à 5.Je pense qu'il suffit de tester Hibernate, EJB3, Spring, JUnit, JSF pour voir qu'il y a bien plus que du marketing... Rien que l'IOC et l'AOP devrait en épater plus d'un.
-
[+] [^]Re: Bonne nouvelle ?
Posté par TazForEver () le 28/09/2006 à 17:22. (lien). Évalué à -3.non. On passe d'un produit libre sur une plateforme libre à un produit libre sur le produit non libre de Sun. C'est dommage d'avoir travaillé en JEE5 au lieu de 2. Quel gâchi :/ En attendant que gcc et cp avancent ...
-
[^]Re: Bonne nouvelle ?
Posté par Stéphane TRAUMAT (page perso, ) le 29/09/2006 à 08:13. (lien). Évalué à 1.VOUS ETES LOURD :)
Sun est en train de libérer le JDK... vous pouvez pas attendre 3 à 6 mois ?-
[^]Re: Bonne nouvelle ?
Posté par Pierre Jarillon (page perso, ) le 30/09/2006 à 09:09. (lien). Évalué à 5.Sun est en train de libérer le JDK...
Depuis le temps qu'on en parle, ça finit par ressembler à l'Arlésienne... Ou à Duke Nukem.-
[^]Re: Bonne nouvelle ?
Posté par JPz (page perso, ) le 30/09/2006 à 09:17. (lien). Évalué à 2.Mauvaise foi a l'etat pur, Sun va publier le JDK complet sous une licence opensource. Le processus est en cours, et ils regardent meme quel gestionnaire de SCM utiliser.
Mais bon c'est tellement plus simple de faire du Java-bashing ...
-
-
-
Pierre Tramo a frappé !
C'est le titre d'un journal qui parlait déjà de ce sujet hier: https://linuxfr.org/~account/22766.html
Bonne nouvelle :)
Félicitations pour ce passage, c'est très intéressant !
Perso, nous sommes passé de PHP, ASP, Delphi... à Java... et on a vu une nette amélioration en terme de qualité, temps de développements, réutilisation et performances.
Pour information, cet avis est celui de ma société et n'est pas valable dans tous les cas, pour toutes les sociétés et toutes les applications :)
-
[^]Re: Bonne nouvelle :)
Posté par Stefane Fermigier (page perso, ) le 28/09/2006 à 16:29. (lien). Évalué à 3.Salut Stéphane,
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/-
[^]Re: Bonne nouvelle :)
Posté par Stéphane TRAUMAT (page perso, ) le 29/09/2006 à 08:28. (lien). Évalué à 1.Oui Scub et ma société et j'en suis le dirigeant :)
J'espère bien que l'on pourra bosser ensemble un jour !
En tout cas, on va pouvoir proposer vos produits (et oui, avantage de Java, on pourra s'nterfacer facilement car nuxeo va respecter les standards).
A bientôt j'espère :)
-
[+] Harcèlement Marketeux
Alors là... Je ne sais pas combien de journaux on a eu droit sur le sujet. Bluffant...
Est-ce que ce nouveau CPS tournera sur une VM libre??
Parce qu'il faut le souligner, une VM proprio ou un OS proprio c'est la même chose.
Je tiens à rappeler qu'il est possible de faire la même chose en beaucoup plus libre avec python/ruby/perl/php/C/C++ etc etc...
Je vous encourage à être le plus libre possible dans vos choix de plateformes technologiques.
-
[^]Re: Harcèlement Marketeux
Posté par vrm (page perso, ) le 28/09/2006 à 16:41. (lien). Évalué à 0.Merci pour ce gentil rapel moraliste.
L'intégrisme te dit merci.
-
[^]Re: Harcèlement Marketeux
Posté par TImaniac (page perso, ) le 28/09/2006 à 16:43. (lien). Évalué à 2.Je tiens à rappeler qu'il est possible de faire la même chose en beaucoup plus libre avec python/ruby/perl/php/C/C++ etc etc...
Comme je l'ai précisé plus haut, tout dépend de quelle liberté tu parles. Pour beaucoup d'entreprise, ils s'en cognent d'être dépendant d'une VM proprio (souvent elle ne coûte rien ou presque). Ce qu'ils veulent comme liberté, c'est pouvoir choisir les acteurs avec lesquels ils vont travailler, faire jouer la concurrence, trouver des collaborateurs compétents dans la techno, etc.
La liberté de choisir ne peut malheuresement pas être imposée dans une licence logicielle, seule une adoption massive par les acteurs du secteur informatique et la présence de nombreuses implémentations permet de garantir une certaine "liberté" de choix.
C'est pour ca que maintenant je réfléchi à 2 fois quand je parle à un "décideur" sur les libertés qu'apporte certains logiciels libre, ca les fait doucement rire car pour eux c'est souvent synonyme de dépendance et d'enfermement avec un acteur compétent spécifique.-
[^]Re: Harcèlement Marketeux
Posté par vrm (page perso, ) le 28/09/2006 à 16:45. (lien). Évalué à 0.et surtout la liberté d'utiliser une architecture qui va supporter la montée en charge.
-
[^]Re: Harcèlement Marketeux
Posté par Michel Galle () le 28/09/2006 à 20:29. (lien). Évalué à 4.c'est exactement ainsi qu'il faut me parler.
Attention, je suis très convaincu par la GPL, par la nécessité du libre et aussi l'opensource; j'ai appris linux, freebsd, apache, etc à une époque où les gens s'en moquaient, mais avoir un logiciel "gpl" ne suffit pas pour "libérer" sa propre entreprise.
alors, bien sur une technologie sous licence libre va favoriser l'éclosion d'une myriade de sociétés fournissant la dite technologie et on pourra les mettre en concurrence et au final tout le monde y gagne en indépendance, en liberté, en souplesse etc
mais des fois y a des technologies certes "libre" mais que personne ne maîtrise. et vous êtes dépendants de la seule petite boîte ou petite communauté derrière et vous n'y gagnez rien (sauf à devoir devenir soit même contributeur. pas toutes les sociétés ont les raisons et possibilités de le faire).
"C'est pour ca que maintenant je réfléchi à 2 fois quand je parle à un "décideur" sur les libertés qu'apporte certains logiciels libre, ca les fait doucement rire car pour eux c'est souvent synonyme de dépendance et d'enfermement avec un acteur compétent spécifique."
Très vrai.
c'est aussi pour cela que je privilégie dans le libre tout ce qui semble devenir "industriel" .
la liberté pour une société doit se traduire en POSSIBILITE concrète et DISPONIBLE.
pas seulement en "potentiel" d'une licence.
-
Former des développeurs Python/Zope compétents
nos clients et nos partenaires nous ont rapporté avoir d'importantes difficultés à trouver ou former des développeurs Python/Zope compétents.
On entend souvent ce discours comme quoi il manquerait de programmeurs python, avec ici une couche supplémentaire disant qu'ils sont difficiles à former. Je trouve ça vraiment très bizarre car python est vraiment un des langages les plus facile a apprendre, et spécialement au sein de Nuxeo il doit y avoir largement de quoi former les nouveaux arrivants (en interne ou pour des clients).
Alors que la tendance actuelle est de plus en plus orienté langages de script, que ce soit chez MS avec ironpython ou chez Sun avec jython et jruby, est-ce que jython a été envisagé pour tirer partie du meilleur des deux mondes ?
-
[^]Re: Former des développeurs Python/Zope compétents
Posté par calvin0c7 () le 28/09/2006 à 19:42. (lien). Évalué à 4.Ce n'est pas si simple.
N'oublie pas que tous les développeurs ne sont pas des adeptes du libre, loin loin de là. Beaucoup ne souhaite pas s'investir dans une technologie dont il n'ont jamais entendu parler.
Aujourd'hui il reste plus facile de trouver un développeur java qu'un développeur python.
Et même si on en trouve un il reste la peur de se retrouver seul utilisateur d'une technologie que tout le monde a fini par abandonner (qui se souvient de Pacbase...)-
[^]Re: Former des développeurs Python/Zope compétents
Posté par ... a little wood elfe () le 29/09/2006 à 05:50. (lien). Évalué à 3.Et même si on en trouve un il reste la peur de se retrouver seul utilisateur d'une technologie que tout le monde a fini par abandonner (qui se souvient de Pacbase...)
Moi ! J'ai été formé à Pacbase il y a un an et demi et depuis je n'ai pas arrêté de coder avec (projet mis en prod il y a quelques jours).
Pacbase est toujours trés utilisé dans les banques et les assurances françaises (qui refusent que IBM en cesse le support d'ailleurs). La seule chose qui a changé c'est qu'on ne fait plus d'écrans 3270 mais qu'à la place on a un pont permettant d'appeler le site central depuis une appli J2EE.
J2EE que par ailleurs je trouve immonde, enfin surtout les jsp. Je n'aime pas du tout cette façon de faire de mélanger dans une seule page de code plusieurs langages (html et java en l'occurrence, voire javascript en plus bien souvent - mais c'est pareil avec php d'ailleurs).
-
[^]Re: Former des développeurs Python/Zope compétents
Posté par Boa Treize (page perso, ) le 29/09/2006 à 06:04. (lien). Évalué à 3.Le problème dont tu parles à propos des JSP (mélange de genres) est connu depuis de nombreuses années et de très nombreux frameworks, API, et standards ont pour objectif de gérer ce problème en minimisant voire annulant la présence de code Java et JavaScript dans les JSP.
Seul un vraiment mauvais programmeur te fera un mix ingérable de HTML et Java dans une JSP.-
[^]Re: Former des développeurs Python/Zope compétents
Posté par Papa Furax (page perso, ) le 29/09/2006 à 08:18. (lien). Évalué à 2.C'est vrai, et à chaque fois il faut se retaper l'étude du framework en question, différent d'un projet à un autre, avant de pouvoir pondre une page.
De ce coté là je préfère nettement l'approche des templates de turbogears (kid) ou rubyonrails: tu connais le langage (python ou ruby) => tu peux écrire les templates dans ce langage-
[^]Re: Former des développeurs Python/Zope compétents
Posté par Nelis (page perso, ) le 29/09/2006 à 09:46. (lien). Évalué à 4.Excuse moi mais c'est stupide ce que tu dis ...
Déjà, avec la JSTL (la librairie de tag standard des JSP), tu ne dois quasiment plus mettre de code Java dans les JSP. A côté de ces tags, la plupart des frameworks utilisent des JSP avec quelques tags supplémentaires (Struts, Spring MVC, ...).
Ensuite, quel que soit le framework, tu dois quand même le comprendre pour l'utiliser, qu'elle que soit le langage. Et tu changes rarement de framework 10x par jour.
Je ne vois pas en quoi les templates de RoR (que je connais un peu) diffère de Java : tu connais le langage (Java) => tu peux écrire les templates dans ce langage--
Vache qui rit, à moitié dans son lit-
[^]Re: Former des développeurs Python/Zope compétents
Posté par Papa Furax (page perso, ) le 29/09/2006 à 10:17. (lien). Évalué à 2.Excuse moi mais c'est stupide ce que tu dis ...
Merci, ça fait toujours plaisir
Déjà, avec la JSTL (la librairie de tag standard des JSP), tu ne dois quasiment plus mettre de code Java dans les JSP. A côté de ces tags, la plupart des frameworks utilisent des JSP avec quelques tags supplémentaires (Struts, Spring MVC, ...).
Je ne dis pas qu'il faut mettre du java dans ses JSP, d'ailleurs je ne le fais pas.
C'est justement les taglib que je n'aime pas: cette manie de faire de la programmation en XML, désolé mais ça me saoule. D'ailleurs rien à vois mais ça m'y fait penser: ant est pas mal non plus à ce niveau là.
Ensuite, quel que soit le framework, tu dois quand même le comprendre pour l'utiliser, qu'elle que soit le langage. Et tu changes rarement de framework 10x par jour.
Ben des fois tu change de projet, de client ou tu bosses sur plusieurs en même temps.
Je ne vois pas en quoi les templates de RoR (que je connais un peu) diffère de Java : tu connais le langage (Java) => tu peux écrire les templates dans ce langage
Ce que j'aime pas avec les jsp, c'est qu'il te faut connaitre tout un tas de taglib, dont les mots clé sont evidemment différent de ceux de java, et la sémantique pas toujours très claire. Et accessoirement il faut aussi connaitre EL.
Regarde l'exemple fourni sur le site de KID :
http://www.kid-templating.org/trac/wiki/KidExamples
C'est quoi dans les attributs? ben c'est du python: j'ai rien de plus à savoir. pas de langage pour les expression, ou autre taglib.
-
-
-
-
-
[^]Re: Former des développeurs Python/Zope compétents
Posté par Papa Furax (page perso, ) le 29/09/2006 à 08:14. (lien). Évalué à 1.J'ai fais l'effort d'apprendre python, car ce langage m'intéressait, notamment pour mes projets universitaire, il y a 5-6 ans maintenant.
Mais je n'ai jamais pu travaillé en python en entretreprise, car tout le monde ne jure que par Java, et je trouve que c'est dommage.
Donc je fait du java, comme tout le monde, et souvent je peste...-
[^]Re: Former des développeurs Python/Zope compétents
Posté par ptifeth () le 29/09/2006 à 10:22. (lien). Évalué à 9.Just do java and be right: it's more than time to come out and be proud !
We all have to concentrate and favour the industrie's choices in order to build the magnificent world of tommorrow !
Let me also urge everybody to comment in english, because this is the only free language.
Of course french has qualities, and is also technically free, but not economically: so few people can anderstand anything but english that we might restrict ourselves to a very little shortlist of potential commenters if we don't switch asap.
-
[^]Re: Former des développeurs Python/Zope compétents
Posté par Alexandre Garel () le 02/10/2006 à 13:14. (lien). Évalué à 1.Pareil, je ferais volontier du Python mais je ne vois rien sur Lyon autour de ça.
-
[^]Re: Former des développeurs Python/Zope compétents
Posté par wilk (Jabber id, page perso, ) le 02/10/2006 à 14:14. (lien). Évalué à 2.Y a quelques mois il y avait un poste très intéressant sur Lyon chez Fluendo... Et apparement ils avaient beaucoup de mal a trouver des compétences en Python. C'est un cercle vicieux, pas de compétences donc pas d'investissement etc.
Le mieux c'est de sortir de ce vislard de cercle et se mettre à son compte, on peut faire du Python toute la journée :-).-
[^]Re: Former des développeurs Python/Zope compétents
Posté par Alexandre Garel () le 03/10/2006 à 08:42. (lien). Évalué à 2.
Ouip à l'époque j'ai postulé mais mon profil n'était pas celui recherché (trop d'études, trop d'expérience). J'étais prêt à négocier mais il ne m'en ont pas laissé le temps. Après un échange par mail il ne m'ont plus jamais répondu.
-
-
-
-
-
[^]Re: Former des développeurs Python/Zope compétents
Posté par sylware () le 28/09/2006 à 19:58. (lien). Évalué à 2.Il faut sortir la tête du sable: Python est un des langages les plus facile à maîtriser.
De plus, les langages (je devrais dire plateformes) reposant sur une compilation de code statique pour ensuite tourner sur des VMs, et bien c'est pas très futé (j'aurais tendance à être beaucoup plus cassant...).
Ces derniers cumulent les désavantages des langages compilés nativement, c'est à dire bien plus complexes à maîtriser que les langages dynamiques comme python (et les autres!), ajoutés des désavantages des langages dynamiques, comme tourner sur une VM (parfois prioprio... donc encore pire... ça ne vaut gère mieux qu'un OS proprio... mais je me répète). Pour enfoncé le clou, ils ont inventé la compilation JIT, qui est un aveu même de la lenteur d'exécution de ces langages: A quoi bon avoir la complexité et la lourdeur d'une VM (allez proprio pendant qu'on y est) avec une compilation JIT, si c'est pour tourner en natif?? C'est particulièrement c... ahem... disons plutôt: "It's not a limitation... it's a feature!"
La technique est simple: tu prends une boîte qui bosse pas avec tes technos et qui a une certaine crédibilité dans un milieu où il y a des dèvs/geeks/entousiates qui roxent. Tu passes "un partenariat" ou tu mets un gros paquet de pognon sur la table avec le deal suivant: "vous laissez tomber vos technos et passer aux nôtres en hurlant que les nôtres sont plusse meilleures". Bin voilà... le tour est joué! Personnellement ça m'éc½ure...-
[^]Re: Former des développeurs Python/Zope compétents
Posté par TImaniac (page perso, ) le 28/09/2006 à 20:31. (lien). Évalué à 8.Moué alors on peut très bien prendre tous tes arguments et les tourner dans l'autre sens :
"Ces derniers cumulent les désavantages des langages compilés nativement,"
Pour moi ils tirent justement des langages compilés les atouts : à savoir la typage statique (souvent propre aux langages compilés même si pas toujours vrai), et justement la possibilité de compiler le code de la VM en code natif, donc avec des performances décentes.
"joutés des désavantages des langages dynamiques, comme tourner sur une VM "
C'est encore un avantage : abstraction de la plateforme matérielle, ce qui est le but premier, sans pour autant sacrifier les perfomances (le problème des perfs vient plutôt de la présence services ajoutés : gestion mémoire, sécurité, isolation, etc.).
"A quoi bon avoir la complexité et la lourdeur d'une VM (allez proprio pendant qu'on y est) avec une compilation JIT, si c'est pour tourner en natif"
Parcque justement le jeu d'instruction d'une VM est plus simple (et non plus complexe) car de plus haut niveau qu'un jeu d'instruction assembleur. Le compilateur JIT n'est pas un aveu de lenteur puisqu'il fait partie intégrante de la solution. Ce qui compte c'est le résultat : c'est du code machine qui s'exécute, on ne sacrifie pas la portabilité, pas trop les perfs, on garde du code de haut niveau, avec la possibilité d'y adjoindre de nombreux services qui participent à la qualité du code : sécurité, gestion mémoire, introspection, etc.
"It's not a limitation... it's a feature!"
Exactement, elles ont été conçu pour ca, et non l'inverse : le code machine n'offre pas la possibilité d'adjoindre tous les services que j'ai cité : il faut proposer un modèle plus "restreind" et de plus haut niveau : une machine virtuelle.
Bin voilà... le tour est joué! Personnellement ça m'éc½ure...
Peut être que le jour où tu participeras au développement d'une grosse solution logicielle de plusieurs dizaines de milliers de lignes de code, tu apprécieras tout les services de ces plateformes, qui n'ont d'autre objectif que de te rendre plus productifs et donc globalement plus agréable à utiliser.-
[^]Re: Former des développeurs Python/Zope compétents
Posté par sylware () le 01/10/2006 à 23:26. (lien). Évalué à 0.Pour moi ils tirent justement des langages compilés les atouts : à savoir la typage statique (souvent propre aux langages compilés même si pas toujours vrai), et justement la possibilité de compiler le code de la VM en code natif, donc avec des performances décentes.
Effectivement, ce que tu avances c'est que ce genre de langage n'apporte rien de significatif par rapport aux langages compilés nativement. Par contre ils ont l'immense désavantage de dépendre d'une VM lourde et complexe (souvent proprio d'ailleurs).
Parcque justement le jeu d'instruction d'une VM est plus simple (et non plus complexe) car de plus haut niveau qu'un jeu d'instruction assembleur. Le compilateur JIT n'est pas un aveu de lenteur puisqu'il fait partie intégrante de la solution. Ce qui compte c'est le résultat : c'est du code machine qui s'exécute, on ne sacrifie pas la portabilité, pas trop les perfs, on garde du code de haut niveau, avec la possibilité d'y adjoindre de nombreux services qui participent à la qualité du code : sécurité, gestion mémoire, introspection, etc.
De ce que j'ai lu des jeux d'instructions des VMs est beaucoup plus proche des services offerts par un OS/bibliothèques de base que d'un jeu d'instructions assembleurs.
C'est pour cela que je dis qu'une VM proprio ne vaut guère plus qu'un OS proprio.
Aujourd'hui avec l'offre des bibliothèques du libre on tourne sur plus de plateformes que les VMs SANS dépendre d'une VM. De plus la portabilité n'est pas l'exclusivité des VMs...
Au final, ces langages n'apportent rien de significatif par rapport à ce qu'offre le vrai libre: C/C++/python/ruby/perl/php etc. Je dis le vrai libre car ces langages ressemblent plus à des putch marketeux sur l'informatique. Ils ne sont pas révolutionnaires, même plutôt maladroits pour les raisons que j'ai évoquées précédement.
Peut être que le jour où tu participeras au développement d'une grosse solution logicielle de plusieurs dizaines de milliers de lignes de code, tu apprécieras tout les services de ces plateformes, qui n'ont d'autre objectif que de te rendre plus productifs et donc globalement plus agréable à utiliser.
Outres les attaques personnelles à coup de "j'ai la plus grosse", j'apprécie énormément tous les services que m'offrent les bibliothèques du libre d'une portabilité sans éguales qui sont un véritable plaisir à utiliser et qui me rendent plus productifs sans avoir à dépendre de technologies lourdes ,complexes, maladroites et au final inutiles dont l'indépendance est très discutable.-
[^]Re: Former des développeurs Python/Zope compétents
Posté par TImaniac (page perso, ) le 02/10/2006 à 08:22. (lien). Évalué à 5.Effectivement, ce que tu avances c'est que ce genre de langage n'apporte rien de significatif par rapport aux langages compilés nativement.
Tu fais exprès ou quoi ? La portabilité binaire c'est pas significatif ? Tous les services que j'ai décris c'est pas significatif ? La sécurité c'est pas significatif ?
Par contre ils ont l'immense désavantage de dépendre d'une VM lourde et complexe
T'utilises les adjectifs qui t'intéresse sans rien démontrer, sans un cas c'est "pas significatif", dans l'autre c'est "immense". Alors montre moi les "immenses" désaventages d'une VM pour des plateformes de type Java/.NET.
C'est pour cela que je dis qu'une VM proprio ne vaut guère plus qu'un OS proprio.
On s'en tape, on est sur LinuxFR, et on parle de logiciels libres, alors permet moi de ne considérer que les VM libres. D'ailleur au même titre qu'il y a des VM proprio il y a des compilos pour des langages "compilés en natif" qui sont tout aussi proprio. Je vois vraiment pas où tu veux en venir.
De ce que j'ai lu des jeux d'instructions des VMs est beaucoup plus proche des services offerts par un OS/bibliothèques de base que d'un jeu d'instructions assembleurs.
Bravo ! Tu viens de trouver un autre avantage largement significatif des VM : l'indépendance vis-à-vis de l'OS !
De plus la portabilité n'est pas l'exclusivité des VMs...
Euh, la portabilité binaire en code natif je demande à voir... A moins de t'amuser à faire des universalbinaries comme Apple, qui multiplie par 2 la taille de ton code et qui te demande du travail en amont, désolé, je vois pas.
Au final, ces langages n'apportent rien de significatif par rapport à ce qu'offre le vrai libre: C/C++/python/ruby/perl/php etc.
Oué, y'a le vrai libre et le faux libre. C'est vraiment n'importe quoi ton raisonnement. Tu cherches des arguments techniques complètement bidons pour justifier au fond une préférence éthique envers les LL.
Tu ferais bien de te poser une question : pourquoi n'y a-t-il pas d'équivalent avec une techno libre (une vraie comme tu dis) à J2EE ? Parcque les langages interprétés de type Python&Co n'ont pas été conçu pour ca, et les langages natifs de type C/C++ le sont encore moins.
Ils ne sont pas révolutionnaires, même plutôt maladroits pour les raisons que j'ai évoquées précédement.
Evidemment qu'ils ne sont pas révolutionnaire, mais ce sont des évolutions non négligeable.-
[+] [^]Re: Former des développeurs Python/Zope compétents
Posté par sylware () le 02/10/2006 à 10:38. (lien). Évalué à -4.Tu fais exprès ou quoi ? La portabilité binaire c'est pas significatif ? Tous les services que j'ai décris c'est pas significatif ? La sécurité c'est pas significatif ?
Je passe outre une fois de plus sur le début de tes propos. La portabilité binaire? Sur des logiciels libres donc open source? Allons un peu de sérieux. A quoi sert la portabilité binaire avec des logiciels open source? Allez... on va dire quasiment à rien.
Tous les services que tu décris et la "sécurité" (très à la mode) ne sont en rien l'exclusivité de ces VMs. C/C++/ruby/python/perl/php offrent la même gamme de services, d'ailleurs souvent ses services sont des librairies en commun à toutes ces plateformes et langages.T'utilises les adjectifs qui t'intéresse sans rien démontrer, sans un cas c'est "pas significatif", dans l'autre c'est "immense". Alors montre moi les "immenses" désaventages d'une VM pour des plateformes de type Java/.NET.
Quand un composant logiciel qui fait des milliers de lignes de codes, et qu'il ne m'apporte rien de significatif et bien pour moi c'est un immense désaventage.
En fait, il faut plutôt retourner la question: qu'est-ce que m'apporte l'utilisation d'une VM (dont l'indépendance est très discutable en plus) dans le monde libre/open source pour des langages non dynamiques?
Euh, la portabilité binaire en code natif je demande à voir... A moins de t'amuser à faire des universalbinaries comme Apple, qui multiplie par 2 la taille de ton code et qui te demande du travail en amont, désolé, je vois pas.
Bof la portabilité binaire dans le monde du libre/open source. Pas la peine de revenir dessus.
Bravo ! Tu viens de trouver un autre avantage largement significatif des VM : l'indépendance vis-à-vis de l'OS !
Je faisais remarquer que tu avais tord en comparant le byte code des VMs (que j'ai eu l'occasion de survoler) au jeu d'instructions des langages machines, mais qu'il fallait plutôt le comparer aux fonctions qu'offrent un OS/bibliothèques de base. Quand à l'indépendance de l'OS, une fois de plus, cela est loin d'être l'exclusivité de ces VMs.
Oué, y'a le vrai libre et le faux libre. C'est vraiment n'importe quoi ton raisonnement. Tu cherches des arguments techniques complètement bidons pour justifier au fond une préférence éthique envers les LL.
Pfff... ce que tu peux être aggressif. Là j'avoue que pour le libre, j'ai aussi une préférence éthique: comme le dit Linus, on est sur un modèle de travail collaboratif et on a prouvé qu'on pouvait faire du travail aussi bon voir meilleur que sur le modèle de la compétition acharnée. Bon, il faut relativisé dans le sens où ça n'est pas vrai pour tous les domaines. Ça serait trop beau! J'en suis tellement convaincu, qu'il est pour moi immorale de fournir mes compétences à tout autre type de logiciels. Attention tout n'est pas blanc ou noir et ma moralité n'est pas sans faille. C'est une question de feeling... en général je procède par élimination: si je ne peux pas utiliser un soft GPL/LGPL je regarde du côté des softs BSD et si toujours je n'y arrive pas je passe au propriétaire si il existe. Si vraiment je juge que la fonction du soft est importante pour mon travail et que l'existant ne me convient pas, je n'hésiterai pas une seconde à monter un projet GPL/LGPL.
Tu ferais bien de te poser une question : pourquoi n'y a-t-il pas d'équivalent avec une techno libre (une vraie comme tu dis) à J2EE ? Parcque les langages interprétés de type Python&Co n'ont pas été conçu pour ca, et les langages natifs de type C/C++ le sont encore moins.
Ça n'est pas vrai. L'ensemble des logiciels libres couvre largement ce que sait faire J2EE/.NET aussi bien ou mieux et sans les soucis d'indépendance de ces technologies vis-à-vis de leur entreprise mère respective.
Evidemment qu'ils ne sont pas révolutionnaire, mais ce sont des évolutions non négligeable.
reBof... évolution... non, plutôt pétard mouillé technique mais bombe H marketing. Les tirages de couverture entre Sun&Co et MS me gonfle. Heureusement, il y a une troisième voix.
Personnellement, je ne perdrais pas mon temps avec ces technologies. Je suis très bien avec la qualité de l'offre libre/open source en C/C++/python/ruby/perl/php/lua/erlang/haskell/bash/openssl/gnutls/apache/
cheerokee etc etc... je serais pas fute-fute de me lier à ces technos si discutables alors que j'ai une plétor technos sans ce soucis et parfaitement opérationnelles à porté d'un click sur le net.-
[^]Re: Former des développeurs Python/Zope compétents
Posté par TImaniac (page perso, ) le 02/10/2006 à 11:14. (lien). Évalué à 3.Allons un peu de sérieux. A quoi sert la portabilité binaire avec des logiciels open source? Allez... on va dire quasiment à rien.
T'as déjà écrit une application répartie ? T'as déjà déployer une application sur plus d'une plateforme ?
Monsieur le client, c'est open-source, démerdez-vous pour recompiler, et tant pis pour l'application répartie !
T'as aucune idée de ce qu'apporte une plateforme de type Java/.NET, et ca se voit.
C/C++/ruby/python/perl/php offrent la même gamme de services, d'ailleurs souvent ses services sont des librairies en commun à toutes ces plateformes et langages.
Mais arrête d'affirmer n'importe quoi sans argumenter !
Explique moi comment tu peux offrir en C/C++ les services d'isolation mémoire offert par les VM ? Montre moi le super service d'introspection qu'offre C/C++ histoire de rigoler un coup !
et qu'il ne m'apporte rien de significatif et bien pour moi c'est un immense désaventage.
C'est pas en faisant l'autiste qui se répète avec force "c'est pas significatif" que ca va rendre ton affirmation plus vraie.
Bof la portabilité binaire dans le monde du libre/open source.
Oué c'est clair, d'ailleur c'est pour ca que tous les langages modernes de l'open-source (Ruby, Python & co) utilise une VM pour s'abstraire du matos. C'est pas parcque t'as les sources que ton appli va forcement tourner sur toutes les plateformes quand elle est écrite dans un langage bas-niveau. T'as tous les problème d'alignement mémoire, les types de base (entier, etc.) qui n'ont pas la même représentation sur toutes les machines, enfin bref, un vrai bordel. Et t'as intérêt d'avoir des "bons" programmeurs qui savent éviter tous ces problèmes.
Ah oui, et tout le monde n'est pas sur slackware, y'a même des linuxiens qui utilisent des distributions basés sur un système de package binaire, et rien de plus "pète couille" que d'avoir des repositories non compatibles pour la simple et bonne raison que tout le monde recompile dans son coin les mêmes appli. (Exemple typique de problème de déploiement).
Je faisais remarquer que tu avais tord en comparant le byte code des VMs (que j'ai eu l'occasion de survoler) au jeu d'instructions des langages machines, mais qu'il fallait plutôt le comparer aux fonctions qu'offrent un OS/bibliothèques de base.
Non c'est tout à fait comparable. Une VM offre un jeu d'instruction qui s'apparente à l'assembleur. Il n'y a effectivement pas "seulement" ca, mais il y a "aussi" ca. Y'a effectivement de nombreux services annexes qui peuvent pour certains s'apparenter à des fonctionnalités d'un OS.
Quand à l'indépendance de l'OS, une fois de plus, cela est loin d'être l'exclusivité de ces VMs.
Euh, par définition, pour être indépendant de l'OS/machine, il faut créer une couche d'abstraction... et c'est la définition même d'une VM : "machine virtuelle". Mais vas-y, plutôt que d'affirmer encore une fois de plus quelque chose, montre moi.
Là j'avoue que pour le libre, j'ai aussi une préférence éthique
Ben on est au moins d'accord sur un point.
i. L'ensemble des logiciels libres couvre largement ce que sait faire J2EE/.NET aussi bien ou mieux et sans les soucis d'indépendance de ces technologies vis-à-vis de leur entreprise mère respective.
Et une affirmation, et une !
C'est quoi cette plateforme alors ?
Nan parcque ca intéresserait des millions de développeurs/entreprises.
C/C++/python/ruby/perl/php/lua/erlang/haskell/bash/openssl/gnutls/apache/
T'as en partie compris le problème du libre : il n'y a aucune plateforme cohérente qui propose l'ensemble des services que propose Java/.NET. Zope est une des rares solutions à proposer un serveur d'application. Mais Zope est loin de proposer tout ce que fourni J2EE par exemple. Et visiblement le choix d'un langage interprété dynamique montre ces limites. C'est même pas imaginable en C/C++, c'est bien qu'il manque une brique indispensable entre les 2. Devines laquelle.-
[^]Re: Former des développeurs Python/Zope compétents
Posté par Boa Treize (page perso, ) le 02/10/2006 à 11:37. (lien). Évalué à 1.tout le monde n'est pas sur slackware, y'a même des linuxiens qui utilisent des distributions basés sur un système de package binaire
Huh ? Slackware est basée sur un système de package binaire. Tu confonds avec Gentoo je pense.-
[^]Re: Former des développeurs Python/Zope compétents
Posté par TImaniac (page perso, ) le 02/10/2006 à 11:42. (lien). Évalué à 2.Euh oué au temps pour moi, désolé.
-
-
[^]Re: Former des développeurs Python/Zope compétents
Posté par sylware () le 02/10/2006 à 13:19. (lien). Évalué à 1.T'as déjà écrit une application répartie ? T'as déjà déployer une application sur plus d'une plateforme ?
A mon tour :) ! Puisque tu es à plein temps sur les journaux et que j'ai un peu de temps on va s'amuser! Je vois que tu as vu que j'avais placer Erlang. Framework pour la mise au point d'applications distribuées. Pour dire vrai, la dernière fois qu'on a m'a proposer un poste dans la téléphonie mobile, ct pour gérer l'infrastructure de déploiement de programmes sur les JVM certifiées J2ME. Bin il avait des matrices de compatibilité dans tous les sens car la portabilité binaire ct du pipo.
Monsieur le client, c'est open-source, démerdez-vous pour recompiler, et tant pis pour l'application répartie !
T'as aucune idée de ce qu'apporte une plateforme de type Java/.NET, et ca se voit.
Hum... en tout cas, ce qui ce voit même pour un non initié, c'est ton aggressivité.
Mais arrête d'affirmer n'importe quoi sans argumenter !
Isolation mémoire? C'est pas un service de l'OS par hasard? Processus? Je sais que la VM est un OS au dessus de l'OS mais bon, pas la peine de le rappeller à chaque fois. Introspection? Je sais qu'ils travaillent dessus sur les gobjects de la glib et qu'ils s'en servent pour générer les bindings de python (ruby quelqu'un?). À part cela je n'ai jamais été confronté à ce jour à l'utilité de l'introspection.
Explique moi comment tu peux offrir en C/C++ les services d'isolation mémoire offert par les VM ? Montre moi le super service d'introspection qu'offre C/C++ histoire de rigoler un coup !
C'est vrai que je réduis en parlant seulement de C/C++/python/ruby/perl/php etc etc... il faut que je mettre aussi l'OS dedans pour essayer d'avoir un tout plus cohérent fonctionnellement. Donc linux dans mon cas.
C'est pas en faisant l'autiste qui se répète avec force "c'est pas significatif" que ca va rendre ton affirmation plus vraie.
Je n'ai jamais eu la prétention de détenir la vérité absolue. Et toi?
Oué c'est clair, d'ailleur c'est pour ca que tous les langages modernes de l'open-source (Ruby, Python & co) utilise une VM pour s'abstraire du matos. C'est pas parcque t'as les sources que ton appli va forcement tourner sur toutes les plateformes quand elle est écrite dans un langage bas-niveau. T'as tous les problème d'alignement mémoire, les types de base (entier, etc.) qui n'ont pas la même représentation sur toutes les machines, enfin bref, un vrai bordel. Et t'as intérêt d'avoir des "bons" programmeurs qui savent éviter tous ces problèmes.
Hum, la VM dans les langages comme python, ruby and co, sont probablement adapté au dynamisme de ces langages. Je pense même qu'il est plus préférable d'utiliser le terme "d'interpréteur" pour ces langages.
Ah oui, et tout le monde n'est pas sur slackware, y'a même des linuxiens qui utilisent des distributions basés sur un système de package binaire, et rien de plus "pète couille" que d'avoir des repositories non compatibles pour la simple et bonne raison que tout le monde recompile dans son coin les mêmes appli. (Exemple typique de problème de déploiement).
Non c'est tout à fait comparable. Une VM offre un jeu d'instruction qui s'apparente à l'assembleur. Il n'y a effectivement pas "seulement" ca, mais il y a "aussi" ca. Y'a effectivement de nombreux services annexes qui peuvent pour certains s'apparenter à des fonctionnalités d'un OS.
J'ai considéré le byte code dans ça globalité. Pour moi cela reste plus proche des services d'un OS que d'un jeu d'instructions en assembleur.
Et une affirmation, et une !
L'ensemble des OS/Langages/bibliothèques libres. Hum... là tu as raison... il ne faut pas diminuer les efforts pour mettre au parfum un maximum de monde et d'entreprises sur la "troisième voix".
C'est quoi cette plateforme alors ?
Nan parcque ca intéresserait des millions de développeurs/entreprises
C/C++/python/ruby/perl/php/lua/erlang/haskell/bash/openssl/gnutls/apache/
Et après c'est moi qui affirme sans argumenter... Ce qui va faire pencher la balance c'est la sensibilité de chacun. Le tout est de bien avoir été exposé à un maximum d'arguments afin de faire un choix qui convient le mieux.
T'as en partie compris le problème du libre : il n'y a aucune plateforme cohérente qui propose l'ensemble des services que propose Java/.NET. Zope est une des rares solutions à proposer un serveur d'application. Mais Zope est loin de proposer tout ce que fourni J2EE par exemple. Et visiblement le choix d'un langage interprété dynamique montre ces limites. C'est même pas imaginable en C/C++, c'est bien qu'il manque une brique indispensable entre les 2. Devines laquelle.
Plateforme cohérente? Ça veut dire que les autres sont incohérentes :D! Tu veux dire que le prix de l'indépendance vis à vis de l'appropriation de l'informatique par un oligopole d'entreprises est avoir de nombreux composants intéropérables pour former une informatique cohérente? Si ça n'avait pas été le cas, très vite tout le logiciel libre aurait été noyauté par le petit nombre d'entreprises que l'on connait bien.
Perso, je conseille vivement à ceux qui nous lisent de faire évoluer les solutions basées sur les linux/C/C++/python/ruby/perl/php.... Dans la majorité des cas, je pense qu'elles vont donneront pleinement satisfaction, et si il vous manque une brique, n'hésitez pas à monter des projets libres pour que le développement soit collaboratif.-
[^]Re: Former des développeurs Python/Zope compétents
Posté par TImaniac (page perso, ) le 02/10/2006 à 14:13. (lien). Évalué à 2.Bin il avait des matrices de compatibilité dans tous les sens car la portabilité binaire ct du pipo.
Oué, c'est J2ME, chacun y va se son implémentation et de sa sous partie des API qu'il a envie de définir. Restons côté J2SE/J2EE ok ? :)
Hum... en tout cas, ce qui ce voit même pour un non initié, c'est ton aggressivité.
Désolé mais t'es gonflant à sortir des affirmations gratuites sans la moindre argumentation ou exemple pour ettayer.
Isolation mémoire? C'est pas un service de l'OS par hasard?
Si bien entendu, mais il est limité à une séparation des adresses mémoires entre les processus. Cela peut être géré de manière beaucoup plus fine et intelligente au niveau d'une VM, sans d'ailleur à avoir à se soucier de ce que fait tel ou tel OS (qui a dit application portable ?).
Je sais qu'ils travaillent dessus sur les gobjects de la glib et qu'ils s'en servent pour générer les bindings de python (ruby quelqu'un?).
C'est pour ca que je te disais : montre moi le "super" service d'introspection. C'est vraiment limité, bien souvent c'est du "parsing" de source (yahoo), et à l'exécution t'as rien du tout, la génération de code dynamique tu peux également te toucher, enfin bref, c'est pas ce que j'appel un service d'introspection digne de ce nom.
Je n'ai jamais eu la prétention de détenir la vérité absolue. Et toi?
Non, mais au moins après avoir dis ca tu arrêtes enfin de répéter "non significatif" sans argumenté :) But atteint ;)
Je pense même qu'il est plus préférable d'utiliser le terme "d'interpréteur" pour ces langages.
Ces langages peuvent tout de même être compilés, il existe par exemple IronPython, une implémentation de Python pour .NET/Mono. Le résultat : gains de perfs et accès à toutes les bibliothèques de la plateforme. C'est où les inconvénients ?
Pour moi cela reste plus proche des services d'un OS que d'un jeu d'instructions en assembleur.
Si tu veux, mais tu veux démontrer quoi exactement ?
il ne faut pas diminuer les efforts pour mettre au parfum un maximum de monde et d'entreprises sur la "troisième voix".
Mais c'est quoi la 3ème voix ? Elle est où la plateforme qui intègre tout ce qui est nécessaire pour faire des appli n-tiers avec serveur d'applications, clients lourds, pages web dynamiques, un modèle de composant et des perfs décentes ?
t si il vous manque une brique, n'hésitez pas à monter des projets libres pour que le développement soit collaboratif.
Ben justement, c'est ce que fond tous ceux qui implémente des JVM, des serveursr d'applications J2EE et tout le tintouin.
Visiblement le libre est incapable de gérer une plateforme d'une telle taille de manière cohérente, alors il se contente de "singer" le proprio. C'est dommage, mais en attendant on n'a pas d'alternative, à moins de se "contenter" des technos hétéroclytes que tu cites, en ayant la moitié des services en moins, pleins d'incohérences, de difficultés d'intéractions, des problèmes de déploiement, des technos très différentes à assimilés pour un résultat... ben non y'en a pas.
(J'exagère, puisque Zope existe, mais comme le montre cette news, avec des limites).
-
-
-
-
-
-
-
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.