Re: Business Loto
ça ne marche pas avec java 6 ni IcedTea ? (je suppose que c'est sur la roadmap ?)
J'aurais du écrire "il faut Java 5 ou plus". On développe principalement sous Java 5 et Java 6, c'est vrai que pour l'instant on ne teste pas sous IcedTea mais ca ne saurait tarder.
le truc cassé là c'est normal ?
Oui et non ;) C'est une page de test (sandbox) pour la syntaxe wiki, le lien est bidon.
parlons-en de la présentation dans un format demandant flash9
Pour un PDF: http://www.nuxeo.org/static/doc/webengine-intro.pdf
et vous recommandez quoi pour le développeur pour développer ? L'intégration est-elle faite avec NetBeans ou Eclipse ou autre pour faciliter le boulot ?
Pour WebEngine, un éditeur de texte "pour développeurs" (vim, emacs, kate...) suffit vu que l'accent est mis sur l'utilisation de langages de scripts, et que ceux-ci n'ont en général pas besoin d'IDE sophistiqués.
Mais vu comment les IDE (Eclipse et Netbeans notamment) sont en train d'ajouter du support pour les langages de scripts en ce moment (en particulier Groovy, Python et Ruby), on peut aussi recommander l'un ou l'autre.
Un retour d'expérience ou exemples d'utilisation concrètes seraient sympathique
Absolument, mais dans quelques mois quand les premiers sites seront en prod'.
[ Répondre ]
Re: Business Loto
N'étant pas modérateur de LinuxFR, je n'en connais pas les lacunes techniques.
Le "t'as qu'a" me parait légitime: plutôt que de publier la dépêche en la critiquant après-coup (et en faisant après-coup des propositions d'amélioration), il aurait été beaucoup plus constructif de les faire en amont de la publication.
Personnellement je suis très ouvert à toutes les suggestions d'amélioration, c'est d'ailleurs comme ca qu'on fait avancer notre projet.
[ Répondre ]
Re: Business Loto
l'ECM ça ne dit _rien_ à personne
Ca dit sûrement des choses aux gens qui font de l'informatique d'entreprise, comme l'ERP, le CRM, la PKI, le BPM, etc.
L'informatique est faite d'acronymes à 3 lettres (TLA). Si on doit tout expliquer en 10 lignes (longueur de l'accroche d'une dépêche) ce n'est pas possible. ECM, par exemple, a un lien Wikipédia (ce n'est pas moi qui l'ai mis, merci pour l'éditeur qui a fait cet ajout), ca me parait suffisant pour éduquer le lecteur qui se sent perdu sans alourdir la lecture pour ceux qui connaissent.
ouah un nouveau wiki, spip, forum, génial : en quoi ça se différencie des existants, ça juste marche à l'installation ?
Ce n'est pas un produit fini (même si ca intègre un wiki comme démonstrateur des possibilités du framework), mais un framework pour développeurs. On ne peut pas le comparer à "un nouveau wiki, forum, spip".
(parce que bon tu te paies déjà une install' de Jboss c'est pas pour faire 10 jours de dév' pour montrer une démo à une MOA hein)
Ben non justement, comme expliqué dans la dépêche, il y a une version standalone embarquée dans Jetty, qui se lance en 4 secondes sans config particulière.
les buzzwords qui ne le font pas (d'habitude c'est moi qui les dit en journée :p), clairement pour le commun des mortels comme toi et moi devant son PC le soir pour trouver un troll
Honnêtement, des buzzwords vides de sens je n'en vois pas dans la dépêche. J'ai même pas mis "SOA" :)
(c'est bon j'ai resitué le contexte ? généraliste, toussa, étudiant, professionnel mais cherchant extension de GNU/Linux dans son entreprise)
La plateforme Nuxeo est multiplateformes, elle n'est pas spécifique à Linux. Il faut une machine virtuelle Java 5, ce qui le fait sous Linux, Mac OS X, Solaris (et quelques autres Unix) et Windows.
n'étant pas du métier, je n'ai pas de screenshots ni de démo ? je montre quoi à celui que je voudrais convaincre que c'est super bien ? (c'est plus clair maintenant ?)
La démo c'est le site de WebEngine, qui est donné en premier lien: http://www.nuxeo.org/webengine/Download
Il y a aussi des screenshots dans le slideshow (ex: slide 41).
Mais bon, encore une fois, c'est une démo de l'application par défaut, avec une jolie CSS qu'on a fait justement pour que les gens trouvent ca joli. Mais ce qui est important c'est le framework, autrement dit comment les développeurs vont pouvoir développer par-dessus, et ca c'est pas forcément super-sexy (même si on essaie de développer dans les slides).
[ Répondre ]
Re: Business Loto
Si tu avais des idées pour améliorer la dépêche, rien ne t'empêchait de demander à ce que je la complète, il me semble (à moins que le système de publication de LinuxFR ne permette pas ce genre de workflow, ce qui serait vraiment dommage).
Pour répondre aux questions:
- Pas encore (à ma connaissance) testé avec IcedTea, on développe principalement sous Java 5 et Java 6.
- Pour ce qui est de l'environnement de développement, n'importe quel éditeur (vim, emacs, texmate, notepad ;) ...) suffit pour développer sous WebEngine. Evidemment, ca aide par exemple d'avoir de la colorisation syntaxique dédiée à Groovy (si c'est le langage de script que l'on choisit) ce qui n'est pas forcément disponible partout.
S.
[ Répondre ]
Re: Business Loto
A priori linuxfr n'est pas un site qui s'adresse à 99% des gens mais à des gens branchés par l'informatique, des "bitouilleurs" aux professionnels.
Nuxeo est un framework de développement, autrement dit un logiciel qui s'adresse avant tout aux développeurs, et en particulier aux développeurs Java et aux développeurs web en général, et pour lesquels des mots OSGi ou REST correspondent à des technologies qu'ils connaissent (ou dont ils ont au moins entendu parler).
De même, JBoss et Jetty sont des logiciels libres bien connus dans le monde Java.
Quand à "paradigme", c'est un mot du langage courant qui signifie, dans ce contexte et selon wikipedia: "un système de représentations largement accepté dans un domaine particulier. "
S.
[ Répondre ]
Re: Business Loto
Pourquoi ?
Entreprise 2.0 c'est effectivement un terme un peu hype, mais qui correspond à une vraie évolution des pratiques informatiques en entreprise.
SLATES, c'est un acronyme qui résume un certain nombre de ces pratiques émergente.
Cf. par exemple http://en.wikipedia.org/wiki/Enterprise_2.0
REST, c'est quand même le fondement du web, mais certains principes de l'approche REST (notamment les URLs "RESTful") ne sont pas implémentés par certains frameworks web.
Enfin, les écosystèmes et les plateformes sont devenus une réalité incontournable du monde du logiciel (et des systèmes en général):
http://www.amazon.com/Software-Ecosystem-Understanding-Indis(...)
http://www.amazon.com/Invisible-Engines-Platforms-Innovation(...)
Enfin, si tu veux plus d'info sur comment ca marche WebEngine, comme je l'ai indiqué dans la dépêche, tu peux aller voir sur http://www.nuxeo.org/webengine/FrontPage pour la doc technique. (Je ne pense pas qu'un tel niveau de technicité aurait trouvé sa place dans la dépêche).
S.
[ Répondre ]
Re: Coût d'une telle solution
Mais d'après ce que j'ai compris vous avez prévu les deux solutions.
En effet, pour nous les deux approches sont complémentaires (et on sait aussi faire du Flex au-dessus de notre plateforme si nécessaire, etc.).
[ Répondre ]
Re: Coût d'une telle solution
Donc, avec Ajax, développement difficile mais déploiement pas cher...
Oui, à condition qu'une condition soit bien remplie: que le parc de navigateurs web chez les utilisateurs soit homogène et parfaitement contrôlé.
En pratique, ca peut arriver dans certaines organisations, mais c'est plutôt l'exception. Et quand ca arrive, ce n'est pas la version du navigateur que les développeurs utilisent, ou que les bibliothèques Ajax veulent utiliser, etc.
Bref, ca peut dégénérer assez facilement.
Au fait : est-ce que vous avez jeté un œil sur XUL?
Amusant que tu poses la question: notre première réponse à l'appel d'offres de l'AFP reposait sur XUL, mais après en avoir parlé à des développeurs Mozilla qui ont eu la gentillesse de nous faire part de leur expérience sans cacher les problèmes, nous avons préférer proposer à l'AFP, qui a accepté, de partir plutôt sur Eclipse RCP. Le message de l'époque (il y a 3 ans) était qu'il fallait attendre Mozilla 3 pour avoir quelque chose de stable...
[ Répondre ]
Re: Coût d'une telle solution
Qu'est-ce qu'un « gain de productivité » ?
Je me base sur un cas très concrêt: celui de l'AFP, où les responsables informatiques ont mesuré un gain de productivité de 40% des journalistes entre la nouvelle console, basée sur RCP, et l'ancienne. Cf. cet article de 01 Net:
http://www.01net.com/editorial/373461/l-agence-france-presse(...)
Ce gain de productivité s'explique dans cet exemple par une interface plus riche que l'ancienne en termes de gestion des flux d'information, de recherche, et d'édition en ligne du texte et des images.
Si on devait comparer une interface RCP à une interface web ajaxifiée, on ne retrouverait sûrement pas 40%, mais peut-être 10% ou 20%, en fonction des besoins des utilisateurs. Ici, on se place dans le cadre de gens qui ont besoin de gérer beaucoup d'information en même temps (y compris sur plusieurs écrans, ce qui à ma connaissance n'est pas évident à faire sur un navigateur), qui ont a travailler des informations multimédia, etc.
Cf. par exemple cette photo: http://flickr.com/photos/nuxeo/2082947465/ où on voit le rédacteur en chef du desk multimédias de l'AFP à Paris avec ses deux écrans, la dépêche et la photo sur lesquels il est en train de travailler sur l'écran de gauche, et les différents flux de dépêches textes et d'images à partir desquels il compose ses dépêches multimédias, ainsi que les flux de dépêches qu'il a à valider, sur l'écran secondaire, à droite.
Pourquoi un coût « pas forcément moins élevé » ?
Le développement d'interfaces utilisateurs en client riche Java (qu'on utilise les techno Eclipse RCP, autrement dit SWT/JFaces ou les technos Sun comme Swing) reposent sur des concepts qui sont maintenant connus et maîtrisés depuis des années, alors que les interfaces riches en client Web (autrement dit Ajax) sont encore toutes récentes (2-3 ans), avec un foisonnement de bibliothèques et un outillage (support des IDE) encore moyen. Je n'ai à ce jour pas suffisamment de données pour dire laquelle de ces deux approches est la moins lourde, en tout cas pour des applications relativement complexes, avec beaucoup de dépendances entre les éléments d'interface, etc., ce qui est le cas qui nous intéresse. Mais il me semble qu'il y a de bons arguments pour dire qu'à partir d'un certain niveau de complexité, c'est le client riche (ou lourd) qui gagne.
Par ailleurs, pour ce qui concerne les gains de productivité ou en tout cas la diminution de la charge de développement sur un projet d'ECM basé sur Nuxeo par rapport à des technologies similaires, propriétaires ou open source, nous n'avons évidemment pas témoignage direct puisque tous les projets que nous faisons sont basés sur les technologies Nuxeo. Mais plusieurs de nos camarades intégrateurs nous ont affirmé, sans souhaiter être cités pour l'instant, pouvoir chiffrer des charges de développement moins élevées avec Nuxeo qu'avec les autres plateformes qu'ils pratiquent.
Oui, mais ces boutiques-là devraient pouvoir sortir de leur logique pour voir ce qui se fait à côté.
Il serait illusoire pour nous de chercher à imposer notre technologie à tout le monde d'un seul coup, surtout lorsque cela représente un effort d'apprentissage important de nouvelles technologies. Notre cible principale est les développeurs Java et nous pensons que sur ce point nos efforts pour rendre le framework Nuxeo accessible ont déjà payé, ce qui ne nous empêche pas de travailler (notamment sur les outils) pour le rendre encore plus accessible.
Concernant les développeurs de type "LAMP" (PHP/RoR/Django/...), le nouveau framework web léger que nous allons annoncer prochainement (je ne manquerai pas de poster une annonce sur linuxfr) devrait répondre à leurs attentes.
[ Répondre ]
Re: Coût d'une telle solution
Salut et merci pour ton commentaires.
Quelques éléments de réponse:
1. Effectivement, la gamme actuelle de logiciels Nuxeo ne s'adresse pas aux boutiques (DSI ou intégrateurs) exclusivement PHP ou .NET.
2. Distinguons bien Nuxeo EP, qui est le fondement de notre offre, de Nuxeo RCP qui est une "cerise sur le gâteau", un moyen de développer des applications métiers dont le coût de développement est justifié par le gain de productivité des personnes qui vont utiliser l'application, par rapport à une approche client léger (qui a elle même son coût de développement, d'ailleurs, et qui n'est pas forcément moins élevé).
3. On se place donc bien dans la situation où les développeurs auxquels on s'adressent connaissent bien Java. En général, ils connaissent bien Ant, et le plus souvent (c'est en tout cas ce que nous avons constaté dans 100% des cas chez nos clients et partenaires), ils utilisent Eclipse comme IDE. Ils ont l'expérience d'un ou plusieurs serveurs d'applications, et dans la plupart des cas cela inclut JBoss. Maven était moins bien connu il y a deux ans quand on a commencé le projet Nuxeo 5, mais on a constaté depuis que de nombreux projets Java libres étaient passés à Maven et que ça connaissance se répandait dans l'industrie des services. De toute façon, les connaissances Maven nécessaires pour démarrer, builder et déployer un projet Nuxeo tiennent en deux pages de texte (il y a trois ou quatre options différents de la commande "mvn" à connaître), et par ailleurs des plugins Maven sont en train de mûrir pour Eclipse (et Netbeans).
4. Pour en revenir à la philosophie générale, et à la prospective, nous avons effectivement choisi de nous appuyer sur les approches les plus standards du monde Java, mais en même temps en tirant partie du dynamisme insufflé depuis la sortie de Java 5 et Java EE 5, de façon à faciliter la vie des développeurs qui travaillent sur notre plateforme.
Parmi les points sur lesquels nous comptons travailler dans les mois qui viennent (entre autres) et sur lesquels bien sûr nous accueillons à bras ouverts toute contribution (-> http://www.nuxeo.org/sections/community/ ), qu'elle soit sous forme de code, de plugins ou simplement d'idées:
- La réalisation d'un IDE (en fait, un profil pour Eclipse, avec une selection des plugins qui vont bien + quelques plugins spécifiques) dédié au développement d'applications sur la plateforme Nuxeo.
- Le déploiement de Nuxeo EP dans d'autres serveurs d'applications que JBoss.
- Une version de Nuxeo dédiée au développement d'application web légères, qui pourra être customisée par des développeurs qui ne connaissent pas Java.
S.
[ Répondre ]
Re: Autres soutiens de la lettre
Evidemment qu'on ne s'est pas tappé tout le rapport Attali, seulement la proposition 58 qui nous concerne directement! (soit à peu près une page).
Je n'ai aucune compétence, un intérêt modéré, et absolument pas le temps, pour étudier le reste du rapport.
S.
[ Répondre ]
Re: Peu clair
Le texte est à présent également signé par atReal ( http://www.atreal.net ) "éditeur de logiciels GED et espaces collaboratifs et de logiciels libres métiers pour les collectivités locales. atReal a été créé en janvier 2003 et bénéficie du soutien d'Oséo/Anvar pour son effort de R&D, auquel elle consacre plus de 20% de son CA.".
Et soutenu par l'APRIL ( http://www.april.org/ ) et l'association Libertis ( http://www.libertis.org/ ).
[ Répondre ]
Re: Peu clair
Accessoirement, il est aussi sur le site de l'AFUL qui soutient également l'initiative:
http://www.aful.org/presse/rapport-attali-editeurs-logiciels(...)
et avec quelques signatures supplémentaires depuis la publication par LinuxFR.
[ Répondre ]
Re: Peu clair
"Et d'abord, il est où ce texte des défenseurs du logiciel libre ?"
-> sous tes yeux ;)
[ Répondre ]
Re: Autres soutiens de la lettre
Les signataires de la lettre font tous de la R&D de manière très substancielle, ce qui contredit de manière factuelle et indéniables les allégations de l'AFDEL.
[ Répondre ]
Autres soutiens de la lettre
A noter que notre initiative est également soutenue officiellement par plusieurs poids lourds du logiciel libres: Red Hat, Ingres, l'AFUL et le consortium OW2 (anciennement ObjectWeb).
[ Répondre ]
Re: Java vraiment GPL?
http://nb-openjdk.netbeans.org/get-and-build.html
S.
[ Répondre ]
Re: Comparaison Nuxeo 5.1 avec un portail
Salut,
Nuxeo EP n'est pas un portail, donc il n'y a pas vraiment lieu de comparer Nuxeo et Liferay, JBoss Portal, Jahia, etc.
Notre idée générale est de ne jamais réinventer la roue, mais de nous appuyer sur des logiciels existants, autant que possible.
Comme il existe une offre déjà assez riche de portails Java (basés sur la JSR-168, autrement dit l'API de portlet), nous avons choisi de nous appuyer, lorsque c'est utile, sur ces portails.
L'intégration JSR 168 est actuellement disponible dans des plugins d'extension dans la "forge" Nuxeo (nuxeo-portlet-* dans [http://svn.nuxeo.org/trac/nuxeo/browser/sandbox]).
Nous sommes ouverts à des collaborations avec les gens qui font des portails, ou dont le métier est de faire de l'intégration autour de ces portails, pour enrichir cette intégration.
S.
[ Répondre ]
Oubli: Restlet
Parmi les projets utilisés par la plateforme, j'ai oublié de mentionner Restlet (http://www.restlet.org/) qui est utilisé (et c'est une des nouveautés des la 5.1) pour implémenter les web services RESTful dans Nuxeo.
S.
[ Répondre ]


Re: Business Loto
Le PDF pour les slides roadmap est aussi dispo ;)
http://www.nuxeo.org/static/doc/nuxeo-roadmap-200806.pdf
Merci en tout cas pour tes remarques sympa.
Stefane Fermigier, CEO, Nuxeo
ECM et GED open source
www.nuxeo.com | www.nuxeo.org
[ Répondre ]