D'une part je cautionne pas mal le choix d'OpenERP comme base: avec la V6 (Medical vient d'être porté à cette v6), ça fait quand même une archi bien modulaire de plus en plus utilisée dans le monde (même si le manque de rigueur du framework ferait sourir des architectes J2EE; mais le monde n'est pas parfait...). Le choix d'architecture permet souvent de gagner plusieurs ordres de magnitudes sur la vitesse (ou le coûts) des développements. Typiquement sur de l'ERP on a des couts de dev 10 fois moindre en travaillant sur OpenERP plutôt que les technos ERP qui ont 15 ans d'âge ou plus (la norme dans les ERP).
D'autre part, je vois ici http://medintux.org/medintux/index.html
un projet franco français avec l'une des ces malheureuses pages d'accueil en Français. A qui faut-il jetter la pierre?
En france, sous prétexte qu'on est resté longtemps sur le devant de la scène international depuis l'ère de la colonisation (plus dur sera la chute), on a bien trop souvent fait ce choix absolument stupide de commencer des projets open sources en Français. Ben voilà le résultat: ça sert à rien, l'open source c'est international et la langue principal ça doit être l'anglais, il faut que nos petits français se mettent bien ça dans le crâne.
Enfin, une note d'optimise: vu la productivité d'OpenERP/Python, ça devrait pas être trop dur de repomper les bonnes idées de Medintux dans Medical, avis aux contributeurs.
venant de Java puis Ruby/Python, y'a pas longtemps je m'étais posé la question de me lancer sur Scala pour avoir du code rapide mais concis justement.
Mais j'avais conclu que l'effort d'apprentissage était important. Au contraire, connaissant Ruby et Python, j'avais alors vu que le leader de JRuby, Charles Headius Nutter http://blog.headius.com/ avait lancé un "dérivé" de JRuby, avec aussi la syntax de Ruby mais statique et aussi rapide que Java, tout comme Scala.
Récemment, ce langage à été renommé Mirah, je ne saurai que trop de recommander, des tronches de chez Google sont aussi sur le coup pour développer des applis sur AppEngine... Certes récent, mais léger et bati sur du solide, avec des leaders qui ont fait leurs preuves et promis à un brillant avenir: http://www.mirah.org/
Pourtant je peux vous dire que Lula a toute la presse brésilienne contre lui et que c'est diffamation sur diffamation (donc c'est vous dire le phénomène pour que le gars soit à 80% d'opinions favorables élu 2 fois). Au Brésil, il est très probable qu'aucune presse ne titre sur ce fait par exemple. Pour rappel, l'essentiel de la presse brésilienne (Globo, Folha, Estadao) é été fondée pendant et grâce à la dictature et ce sont toujours les même gens qui la dirigent (ça n'est pas rien quand on sait que Globo est bien plus gros que TF1 par exemple). Et autant le dire, ils n'aiment pas trop Lula (ni Dilma Roussef, l'ex guerrillero indiquée pour la présidentielle) qui a remis quelques privilèges en cause et ne fait pas partie de leur élite 100% blanche et riche. En France, des gens comme le Monde doivent pas avoir de correspondant valable au Brésil et se contentent de hélas repasser les infos biaisées de cette presse asservies à certains partis.
J'en sais quelque chose, j'ai fondé Akretion.com, SSLL spécialisée sur l'intégration de logiciel libre à Rio (intégration OpenERP surtout).
Bref ça fait plaisir de voir ce genre de news n'est pas étouffée et puisse avoir un peu d'echo ici, continuez les gars.
Le logiciel libre au Brésil a encore plus de sens que dans les pays riches (quoi que les gars, vous allez voir le Brésil va passer devant la France dans pas trop longtemps, peut-être 5 ans), mais j'ai toujours été choqué de voir qu'en contre partie il y avait les problèmes suivants:
- il est bien plus facile d'y faire du lobbying ou carrément de corrompre les décideurs pour qu'ils achètent certaines licences plutôt que d'investir dans le libre. J'ai été pour le moins surpris de voir autant de Windows dans certaines facs, quand on sait qu'une licence y coûtait un SMIC (avec quelques SMIC on met un technicien capable de gérér toute l'infra Linux de façon durable).
- le Brésil a des problème bien plus important à résoudre que le piratage et globalement aucun pirate n'est jamais pris au Brésil (c'est un paradis pour les téléchargeurs par exemple). Donc énormément de gens utilisent simplement des versions pirates de logiciels propriétaires ce qui malheureusement ne permet pas toujours au libre d'émerger comme l'alternative ayant le meilleur coût/bénéfice. Il est cependant prévisible qu'en devenant un marché significatif, les éditeurs proprios essaient de mettre un terme à cette hémoragie... ...ce qui ne manquera pas de donner toutes ses justifications économiques à l'open source.
Bah, je trouve leur descriptif assez honnête en fait, ils disent quand même:
"Il vise donc une cible différente, que sont les PME/TPE, indépendants, professions libérales, micro-entreprises ou associations, là où la sophistication des autres produits les rend plus adaptés aux plus grosses structures."
Donc à part pour ce qui est du passage sous silence de la modularité (équivalente ou meilleure) sur OpenERP ou de la future prétentendue modularité sur Openbravo v2.5.
je fini par penser que Dolibarr pourrait néanmoins avoir une niche (et assez grande): faut avouer que bcp plus de gens on un bagage PHP et pas Python. Donc ça parraît plus facile qu'une TPE qui ne peut pas payer d'intégration utilise d'éventuelles compétences internes pour s'en sortir avec un Dolibarr. Il y aussi une facilité d'installation (au moins de première installation), encore une fois du fait de l'usage de PHP et de MySQL qui est plus connu.
Et qui dit facilité, dit potentiellement grosse communauté. Un peu comme pour un CMS Drupal, qui sans valoir forcément ce que d'autres CMS ont a offrir a eu une croissance fulgurante. Installer toute la pile OpenERP jusqu'au eTiny en prod en HTTPS par exemple demande à côté des compétences plus rares ou plus pointues.
D'autre part, OpenERP oblige à faire le choses bien, dans les règles de l'art, ce qui est louable en soit. Mais je vois une foule de TPE qui n'ont pas les moyens de ces objectifs et pour lesquels écrire un hack qui marche à la porcasse histoire d'arriver à satisfaire un besoin pourrait faire l'affaire. Ici, avec un bon vieux PHP4, on peux imaginer que les gens arrive à hacker une page en PHP sans aller sa poser la moindre question sur le framework comme avec OpenERP. Pour résumer: OpenERP semble imposer des abstraction bcp plus puissantes, ce qui est bien pour les gens qui en ont les moyens, les petits joueurs qui sont hélas souvent condamnés à rester des prolétaires du code bas niveau pourraient en revanche être content de trouver un code hackable et plus facile d'accès.
Après, sur la modulartité en soit, je suis d'accord, je pense qu'OpenERP fait aussi bien et je parirai même mieux (sur l'exension des vues par exemple), mais j'avoue que c'est ici une pure supputation tant j'ai été impressionné par le pouvoir des modules sur OpenERP sans connaître assez Dolibarr.
Bref on verra bien. Nous on en intègre pas (encore) Dolibarr car justement la cible est trop petite pour intéresser un intégrateur qui ne soit pas un freelance (me semble t-il). Et on a 2 clients qui vont passer en prod sur OpenERP v5 sous peu qui n'auraient pas pu avoir Dolibarr (entre autre), ne serait-ce que par les moins grandes aptitudes en terme de gestion multi-entrepôts et traçabilité avec gestion de lot. Ou peut être encore en ce qui concerne la comptabilité analytique multiaxe ou OpenERP s'est révélé adaptée. Mais on a aussi vu pleins de gens qui ne pouvaient s'offrir une intégration OpenERP et dont certains sans doute pourraient arriver à qqch avec un Dolibarr s'il est aussi bien qu'ils le disent.
Après je pense qu'OpenERP saura aussi capter une partie de cette clientèle avec sa future offre Saas.
A plus et bonne chance pour votre v5. De tte façon, c'est tout le marché qui est en train de réaliser la maturité des ERP oss et donc il est presque souhaitable qu'une multitude d'acteurs oss percent, ce qui semble arriver.
Perso je pense que l'idée du MDA est une faillite intellectuelle, c'était valide à l'époque reine des EJB et autres bloatwares où il s'agissait avant tout de pisser du code tant le langage ou les frameworks étaient abérrants. A partir du moment ou tu as des langages+frameworks type Rails qui te permettent d'exprimer bien plus en quelques mots de prog déclarative sans avoir à aller connecter des flêches en se demandant combien coutera l'outil qui dessine les flêches demain (Neogia s'est bien planté avec PoseidonUML qui est devenu payant, ils n'ont même pas encore fini de payer leur migration sur l'UML fait dans Netbeans, jusqu'au prochain abus du fabricant d'outils...
Je considère qu'OpenERP est à peu près aussi bien conçu que Rails en terme d'API (disons que c'est ce qui s'en rapproche le plus en terme d'ERP) et je ne vois pas tellement comment on peut exprimer de façon plus canonique un besoin fonctionnel que le minimum d'instructions de code mis en jeux, c'est cela qui me donne une très grande confiance.
Après oui, c'est vrai OpenERP pourrait s'essayer à un peut plus de vitesse. Mais ils ont quand même 2 niveaux de cache dans leur ORM, comme sur Hibernate et pas comme sur Compiere ni Openbravo qui ont d'ailleurs sans doute un base plus faible de testeurs capables. Et au pire, sur les points chauds avérés tu peux toujours bourriner du PL/SQL à papa pour accélérer à la même vitesse d'un Openbravo ou un Compiere (mais la différence avec eux c'est que le PL/SQL reste l'ultime option et qu'on est pas obligé d'en arriver là d'office). Concédons que ces derniers peuvent tourner sur Oracle contrairement à OpenERP. Reste que depuis que ma dernière version du livre blanc en Mai, eTiny est devenu 3 fois plus rapide environ et nombre de partenaires ont fait état de déploiements avec des milliers de mouvements de stock ou comptables par mois. J'avoue que je suis en passe de ne plus me faire de souci de ce côté-ci, je corrige d'ailleurs notre livre blanc en ce sens.
Au fait, en creusant encore: oui décidemment Dolibarr semble avoir beaucoup progressé et sera sans doute un bon choix pour les très petites structures qui ne peuvent pas investir sur quelque chose de plus gros. Il s'agît en effet d'une niche qui était mal remplie par les les offres concurrentes.
c'est mon point de vue et pas forcément celui de la société qui m'emploie et qui a financé le livre blanc, mais sache que j'aurais vraiment beaucoup de mal à recommander Openbravo sur OpenERP. A la rigueur OpenbravoPOS pour les points de ventes qui est une solution lourde mais techniquement valide.
Sinon ça serait vraiment ma deuxième propositions pour les gens exclusivement paranoïaques au Python (pourtant plus facile à apprendre que Java), mais ecore une fois je pense qu'il n'y a pas photo sur le fonctionnel, la conception et la dynamique réelle. J'avoue qu'il m'a fallu 2 mois pour changer d'avis après avoir par erreur écarté OpenERP pensant qu'il s'agissait d'un client lourd simpliste (j'avais regardé le code et en avais vu tellement peu que j'étais loin d'imaginer que la couverture fonctionnelle était triple). Mais ensuite je n'ai jamais changé d'avis.
Faut voir aussi qu'Openbravo, si avec leurs 18 millions de dollars levés au total il n'arrivent pas à faire, dans quelques mois/années, quelque chose qui chatouille un peu ce qu'a fait un étudiant en école (OpenERP), alors ça seraient vraiment des manches (m'enfin ça se voit aussi les millions engloutis en mauvaises solutions, on dira d'ailleurs bien ça de SAP un jour). Personnellement je sais déjà où j'aurais mis mes billes mais ne faisons pas ici de procès d'intention.
OpenERP4.4 va sortir d'ici environ un mois et je pense que questions améliorations d'ergonomie tu seras servi (petite entrevue ici pour la gestion de projet, sur le client GTK: http://fptiny.blogspot.com/2008/09/reviewed-project-manageme(...) ). OpenERP ne donne certes pas la liberté d'une page HTML faite à la mano, mais on peut quand même pas mal customizer l'engin.
merci, post très éclairant. En effet, j'ai vu qu'il y avait encore beacoup de français uniquement dans votre doc et code, mais savoir que vous avez concience d'allez vers l'international est déjà une très bonne nouvelle.
Je n'étais pas non plus au courant du système de trigger PHP et workflows.
L'approche type Pareto: ne pas essayer de tout faire mais rester simple me paraît très valide.
Si le PHP4 que vous utilisez est objet, c'est plutôt rassurant. Hélas je n'avais pas pu m'en assurer dans le temps imparti.
Au fait, OpenERP ne fait pas de alter table ou de suppression de donnée sauvage à l'installation d'un module: il dit juste attention il faudra faire quelque chose. Ceci afin d'éviter les pertes de données accidentelles. En revanche, la gestion des dependances entre modules et les mécanismes d'héritage des objets métiers et de vues est extrèmement puissant. Je n'ai vue aucun autre ERP mature qui faisait ça (peut être ERP5 mais nous avions du mal à croire à la base Zope en général pour les PME en dehors d'une optique SaaS).
Bref, oui, nous allons surveiller ça. D'autant qu'il semble que Dolibar dispose d'une commaunauté contente, ce qui est un énorme plus et c'est très différents de certaines solutions J2EE dont les rares clients (pas les notres) n'ont de cesse de se plaindre.
Je crois aussi que Dolibarr répond bien aux attentes des TPE ou il y aurait un connaiseur de PHP, alors que d'autres ERP comme OpenERP, Openbravo ou Compiere visent des boîtes plus grosses et nécessitent en contreparitie un investissement supérieur (l'investissement sera surtout supérieur pour Compiere ou Openbravo ici).
Nous allons faire une mise à jour de notre livre blanc d'ici quelques jours. Hélas pas le temps de remettre Dolibarr sur le tapis pour l'instant. On le mentionnera un peu plus dans un paragraphe c'est promis. On va surtout mettre à jour les progrès indéniables de Compiere 3.1 (bien qu'on le répète pas très ouvert), les progrès (énormes) d'OpenERP 4.4 et son changenment de de nom consommé, le mode appliance d'Openbravo ou encore la difficile traversée du désert de Neogia qui ne donne pas trop signe de vie cette année.
Salut, je suis toujours à l'affût des évols des ERP libres. Concernant Dolibarr, quelqu'un a des infos sur les références les plus visibles d'entreprises l'ayant implémenté?
Perso, c'est OpenERP qui m'a le plus impressionné des tous ceux que j'ai pu tester pendant les 9 mois d'étude pour le livre blanc Smile, j'ai jamais rien trouvé à redire sur sa conception bluffante et à mon humble avis y'a des éditeurs qui vont plus trop rigoler dans quelques années.
En ce qui concerne Dolibarr, l'usage de PHP4 (pas très objet; me paraissait hasardeux tant un ERP est complexe: comment masquer et maîtriser la complexité à long terme sans abstraction objet?) et la caractère peu international du projet m'ont fait douté lorsque je l'ai passé en revue il y a presque un an. En effet, les projets open source qui percent sont rarement des projets non anglophones sans concession, fût-ils développés par des français car ils possèdent alors un base d'utilisateurs/contributeurs d'autant pus large.
L'impression que me laisse encore Dolibarr, c'est que la modularité applicative y est presque nulle: c'est à prendre ou à laisser; si ça ne vous convient pas, il faut hacker le code là oui l'est ou le détourner très en amont sans réutiliser rien du tout. Bref bonjour l'évolutivité et pas de phénomène de catalyse ou chacun peut réinjecter aisément le travail d'autres tierces parties (je ne parle pas de la simple addition de fonctionnalité assurés par le système actuel de modules, mais bien de l'altération des fonctions existantes). Quand je vois par exemple la maturité d'un openERP qui adapte tout seul la structure de la base quand on injecte des plugins qui viennent tuner exactement là ou on le voulait avec la précision d'un bon code objet, ou que je vois l'effervescence des modules tierces contribués qui exploitent ce système pleinement, je me dis que c'est juste autre chose.
Le problème du manque de modularité d'un ERP libre, à mon sens, c'est que si l'ERP ne permet pas de faire des choses très spécifiques avec des coûts de dev maitrisés, alors hélas les produits propriétaires de grande consommation tendent à être souvent plus compétitifs. Bref je n'imagine pas d'autre issue que la faculté de personnalisation à outrance compétitive, à moins qu'un jour ces logiciels atteignent la maturité d'un Firefox ou d'un OpenOffice mais j'en doute, ne serait-ce que par la complexité des métiers et des lois associées qui divisent les communautés déjà maigres en autant d'entités qu'il y a des pays/législations.
Reste que la barrière d'entrée semble plus basse sur Dolibarr que sur la majorité des autres ERP, le côté francophone, s'il est sans doute un handicap à long terme, hisse sans doute néanmoins Dolibarr au dessus de certains concurrent pour un usage hexagonal. Bref, pourquoi pas si Dolibarr semble répondre d'office à 90% des besoin, sinon mieux vaut accepter une barrière d'entrée plus haute mais des abstractions ensuite plus pérennes.
Au fait, je vois que Dolibarr est intégré avec OSCommerce apparemment. Puisque Magento est souvent désigné comme le successeur d'OSCommerce, Je signale donc au passage qu'à Smile on a bossé sur un connecteur (open source) OpenERP / Magento.
"l semble très simple à customiser"
Sans vouloir envenimer le débat et en espérant simplement suciter votre curiosité pour OpenERP, je pense que vous dite cela parce que vous n'avez pas vu:
* le view designer en Ajax d'OpenERP qui permet de construire les vues par simple glisser-déposer et de traduire les champs à l'envie (marche sur le SVN, preview non effective possible sur les démo en ligne; bouton 'customize view')
* l'éditeur de workflow en Ajax aussi qui permet une vétitable gestion BPM des process. ça n'est pas Intalio non plus mais franchement ça va très loin avec une simplicité maximale (cf SVN).
* l'extension des structures de données par héritage et éventuellement dans l'interface graphique. La modularité est très grande et le code résultant toujours propre, lisible et maintenable.
Ceci vaut aussi pour les controllers et méthodes métiers qui respectent la programmation objet et offrent ainsi différent niveaux de lisibilité et contrôle, c'est très différent du code procédural en pl/SQL de Compiere ou d'Openbravo... (le pl/SQL c'est bien, mais je préfère quand c'est utilisé sur des optims parcimonieuses plutôt qu'un recours systématique). C'est quand même aussi bien pratique de mettre ses breakpoints dans Pydev pour introspecter/modifier le code plutôt que de savoir comment avoir une license SQLDevelopper d'Oracle...
C'est vrai que Compiere et Openbravo rendent assez triviale l'extension des structures de données et de leurs vues associées (comme OpenERP donc), mais je pense que sur les process métiers, que ce soit au niveau de la modélisation BPM de haut niveau (genre l'état monitorable sur un graphe de workflow de tes lignes de commande dans OpenERP) ou le code objet vs pl/SQL, il y a une vraie différence de productivité.
J'ajoute que j'ai au moins 5 ans d'expérience de dev Java et j'avais seulement 3 jours de Python quand j'avais découvert OpenERP. Pourtant, tout comme les autres ressources de ma boîte, on préfère DE LOIN apprendre les rudiement de Python (en une semaine on fai beaucoup) plutôt que de faire des centaines/milliers de lignes de pl/SQL dans un ERP qui se prétendrai codé en Java (juste parce qu'il y a du Java entre le bout de HTML et l'appel de la proc stock quand on clique sur un bouton). En plus Python ça ressemble à Ruby et Ruby ça dépôte.
oui, la gestion de production est comprise dans OpenERP au même titre que sur les autres meilleurs ERP libres. Mais attention, il ne s'agit pas d'une gestion de production à capacité finie mature tels qu'on les trouve sur les ERP haut de gamme dédiés type Lawson. Il ne s'agit pour l'instant que de MRP1, c'est à dire du calcul des besoins en approvisionnement et en ordres de fabrications. La fabrication des produit est modélisée à l'aide des concepts fondamentaux classiques de gammes, de nomenclatures et de postes de travail, un peu comme sur ERP5, Neogia et Openbravo; je le résume dans le livre blanc de Smile. Ensuite sur chaque poste de travail, tu peux connaître et prévoir la charge et ainsi (re)planifier manuellement les runs de production à l'optimum physique en tenant compte de ces indicateurs de charge. On peut aussi brancher un planificateur externe.
Une bon aperçu est dispo ici: http://demo.openerp.com:8080/login?user=admin&passwd=adm(...)
Par ailleurs, la gestion de production des sociétés de services est aussi très bien déservie: assignation des tâches, plannings, tableaux d'évaluation de la rentabilité des projets, facturation du travail en régie, à la tâche ou au forfait...
Un autre aperçu ici: http://demo.openerp.com:8080/login?user=admin&passwd=adm(...)
NB: il semble qu'à l'heure précise ou j'écrive les serveurs soient en maintenance et soient down, essayez plus tard en cas de pépin.
J'ajoute, que la société dans laquelle je travaille, Smile.fr, m'a mandaté pour comparer les ERP open source sur plus de 6 mois (une trentaine de produits passés au crible). A l'issu, je dois dire que le constat est assez net: il est assez incontestable qu'OpenERP se classe en tête des ERP matures pour le marché français, sur l'ensemble des critères: couverture fonctionnelle, technologie (des années d'avances sur certains rivaux: BPM intégrée, ORM puissant...) et dynamique communautaire.
Ce livre blanc de 120 pages dont je suis l'auteur est téléchargeable gratuitement ici: http://www.smile.fr/publications/livres-blancs/erp-open-sour(...)
Franchement l'outil est impressionnant. les développeurs en herbes sauront monter eux-même leur système en achetant le bouquin paru chez Eyrolles, en écumant les forums très fréquentés d'OpenERP et la doc technique déjà très correcte pour un projet de cette envergure (la gestion de prod industrielle nécessitera quand même de la formation). Mais OpenERP saura aussi intéresser les plus grandes PME qui n'auront alors pas de difficulté à trouver un intégrateur compétitif.
Enfin je confirme, contrairement à nombre d'autres, OpenERP joue à fond la carte de l'open source: le code est GPL, le SVN est accessible, y compris pour de nombreux modules. De pus, comme le logiciel est bien conçu, les besoins de l'éditeur sont très modérés et sa stratégie marketing est en retour très douce. Mais surtout il y a une vraie gouvernance open source là où d'autres ERP open source n'ont aucune activité communautaire. Enfin, contrairement encore à d'autres ERP open source, par exemple codés à coup de pl/SQL à papa, le code d'OpenERP est largement lisible et maitrisable, ce qui en fait un vrai logiciel open source qu'on peut effectivement personnaliser à sa guise si on dispose plutôt de compétence et de motivation que de budget.
Grails est sans doute déjà un progrès par rapport à du Struts 1 et des JSP, mais personnellement je crois que JRuby on Rails a plus de sens. En effet, ça fait tourner le vrai Rails inchangé avec vraiment presque tous ces plugins (sauf de rares ayant des dépendances natives pas encore portées en Java), Rails 2.0 et ses nested resources URL si restful...
On peut bien y utiliser une persistence Hibernate (avec ActiveHibernate par exemple ou directement) si vraiment on ne trouve pas son bonheur avec ActiveRecord sur les drivers JDBC. On peut aussi facilement appeler tout beans Spring pour y intégrer du J2EE à papa. On peut aussi bien sur appeler n'importe quel javabeans directement depuis le code JRuby et échanger avec, disons que Spring c'est just pour mieux gérer l'IOC legacy, en Ruby on peut faire plus simple et plus élégant.
Grails c'est aussi la language Groovy dont les rumeurs sur les performances ne sont pas très bonnes; je crois que JRuby head fume bien Groovy. Sans compter que la génération de bytecode de Groovy est lente. Par ailleurs je ne crois pas que Groovy ait de compilation Just In Time comme JRuby dont c'est la force principale...
Un des rares avantages transitoire de Groovy est qu'on peut appeler depuis Java des classes implémenter en Groovy et qu'elles sont de vraies classes Java. Mais un compilateur extra de JRuby vers Java va aussi se rapprocher de ceci très rapidemment. En gros il va aussi permettre de type (optionnellement) des objets Ruby pour le cas ou on les utilise depuis Java...
Bref JRuby on Rails vaut le coup d'oeil, on se rapproche d'une maturité suffisante pour de la prod. Venez trainer sur #jruby si vous voulez en savoir plus, ça foisonne d'idées et de talents...
Il y a bel et bien un léger problème (temporaire) d'ergonomie avec OpenID selon moi:
les utilisateur sont habitués à donner un couple login/mot de passe. C'est devenu très intuitif pour eux.
Or, avec OpenID, hormis dans le cas où le site est fournisseur d'OpenID (c'est pas le but que chaque site soit son fournisseur sinon zéro fédération des identités), l'utilisateur doit d'abord entrer son OpenID qui prend généralement la forme d'une URL.
Cette première étape est déconcertante pour l'utilisateur moyen: il ne voit pas pourquoi d'un coup on ne lui demande plus deux mais une seule information et pourquoi celle-ci est généralement plus compliquée qu'un login.
Une fois que l'utilisateur est sur la page du fournisseur d'OpenID, c'est bon, il s'y retrouve.
Bref il y a bien une période pendant laquelle on va devoir éduquer les utilisateurs et convaincre les décideurs que cette différence fonctionnelle n'est pas insurmontable.
[^] # Re: et Medintux ?
Posté par rvalyi . En réponse à la dépêche Medical, un système d'information sur la santé et le milieu hospitalier. Évalué à 2.
D'autre part, je vois ici http://medintux.org/medintux/index.html
un projet franco français avec l'une des ces malheureuses pages d'accueil en Français. A qui faut-il jetter la pierre?
En france, sous prétexte qu'on est resté longtemps sur le devant de la scène international depuis l'ère de la colonisation (plus dur sera la chute), on a bien trop souvent fait ce choix absolument stupide de commencer des projets open sources en Français. Ben voilà le résultat: ça sert à rien, l'open source c'est international et la langue principal ça doit être l'anglais, il faut que nos petits français se mettent bien ça dans le crâne.
Enfin, une note d'optimise: vu la productivité d'OpenERP/Python, ça devrait pas être trop dur de repomper les bonnes idées de Medintux dans Medical, avis aux contributeurs.
# ceux qui connaissent le Ruby devraient plutôt regarder Mirah
Posté par rvalyi . En réponse à la dépêche Sortie de Scala 2.8 !. Évalué à 3.
venant de Java puis Ruby/Python, y'a pas longtemps je m'étais posé la question de me lancer sur Scala pour avoir du code rapide mais concis justement.
Mais j'avais conclu que l'effort d'apprentissage était important. Au contraire, connaissant Ruby et Python, j'avais alors vu que le leader de JRuby, Charles Headius Nutter http://blog.headius.com/ avait lancé un "dérivé" de JRuby, avec aussi la syntax de Ruby mais statique et aussi rapide que Java, tout comme Scala.
Récemment, ce langage à été renommé Mirah, je ne saurai que trop de recommander, des tronches de chez Google sont aussi sur le coup pour développer des applis sur AppEngine... Certes récent, mais léger et bati sur du solide, avec des leaders qui ont fait leurs preuves et promis à un brillant avenir:
http://www.mirah.org/
A bon entendeur...
Raphaël Valyi
Founder and ERP Consultant
http://www.akretion.com
# et pourtant le chemin de l'open source au Brésil est semé d'embuches..
Posté par rvalyi . En réponse à la dépêche Le discours très libre du président brésilien Lula. Évalué à 10.
Pourtant je peux vous dire que Lula a toute la presse brésilienne contre lui et que c'est diffamation sur diffamation (donc c'est vous dire le phénomène pour que le gars soit à 80% d'opinions favorables élu 2 fois). Au Brésil, il est très probable qu'aucune presse ne titre sur ce fait par exemple. Pour rappel, l'essentiel de la presse brésilienne (Globo, Folha, Estadao) é été fondée pendant et grâce à la dictature et ce sont toujours les même gens qui la dirigent (ça n'est pas rien quand on sait que Globo est bien plus gros que TF1 par exemple). Et autant le dire, ils n'aiment pas trop Lula (ni Dilma Roussef, l'ex guerrillero indiquée pour la présidentielle) qui a remis quelques privilèges en cause et ne fait pas partie de leur élite 100% blanche et riche. En France, des gens comme le Monde doivent pas avoir de correspondant valable au Brésil et se contentent de hélas repasser les infos biaisées de cette presse asservies à certains partis.
J'en sais quelque chose, j'ai fondé Akretion.com, SSLL spécialisée sur l'intégration de logiciel libre à Rio (intégration OpenERP surtout).
Bref ça fait plaisir de voir ce genre de news n'est pas étouffée et puisse avoir un peu d'echo ici, continuez les gars.
Le logiciel libre au Brésil a encore plus de sens que dans les pays riches (quoi que les gars, vous allez voir le Brésil va passer devant la France dans pas trop longtemps, peut-être 5 ans), mais j'ai toujours été choqué de voir qu'en contre partie il y avait les problèmes suivants:
- il est bien plus facile d'y faire du lobbying ou carrément de corrompre les décideurs pour qu'ils achètent certaines licences plutôt que d'investir dans le libre. J'ai été pour le moins surpris de voir autant de Windows dans certaines facs, quand on sait qu'une licence y coûtait un SMIC (avec quelques SMIC on met un technicien capable de gérér toute l'infra Linux de façon durable).
- le Brésil a des problème bien plus important à résoudre que le piratage et globalement aucun pirate n'est jamais pris au Brésil (c'est un paradis pour les téléchargeurs par exemple). Donc énormément de gens utilisent simplement des versions pirates de logiciels propriétaires ce qui malheureusement ne permet pas toujours au libre d'émerger comme l'alternative ayant le meilleur coût/bénéfice. Il est cependant prévisible qu'en devenant un marché significatif, les éditeurs proprios essaient de mettre un terme à cette hémoragie... ...ce qui ne manquera pas de donner toutes ses justifications économiques à l'open source.
[^] # Re: Argumentaire complètement erroné
Posté par rvalyi . En réponse à la dépêche Dolibarr 2.5 disponible. Évalué à 5.
Bah, je trouve leur descriptif assez honnête en fait, ils disent quand même:
"Il vise donc une cible différente, que sont les PME/TPE, indépendants, professions libérales, micro-entreprises ou associations, là où la sophistication des autres produits les rend plus adaptés aux plus grosses structures."
Donc à part pour ce qui est du passage sous silence de la modularité (équivalente ou meilleure) sur OpenERP ou de la future prétentendue modularité sur Openbravo v2.5.
je fini par penser que Dolibarr pourrait néanmoins avoir une niche (et assez grande): faut avouer que bcp plus de gens on un bagage PHP et pas Python. Donc ça parraît plus facile qu'une TPE qui ne peut pas payer d'intégration utilise d'éventuelles compétences internes pour s'en sortir avec un Dolibarr. Il y aussi une facilité d'installation (au moins de première installation), encore une fois du fait de l'usage de PHP et de MySQL qui est plus connu.
Et qui dit facilité, dit potentiellement grosse communauté. Un peu comme pour un CMS Drupal, qui sans valoir forcément ce que d'autres CMS ont a offrir a eu une croissance fulgurante. Installer toute la pile OpenERP jusqu'au eTiny en prod en HTTPS par exemple demande à côté des compétences plus rares ou plus pointues.
D'autre part, OpenERP oblige à faire le choses bien, dans les règles de l'art, ce qui est louable en soit. Mais je vois une foule de TPE qui n'ont pas les moyens de ces objectifs et pour lesquels écrire un hack qui marche à la porcasse histoire d'arriver à satisfaire un besoin pourrait faire l'affaire. Ici, avec un bon vieux PHP4, on peux imaginer que les gens arrive à hacker une page en PHP sans aller sa poser la moindre question sur le framework comme avec OpenERP. Pour résumer: OpenERP semble imposer des abstraction bcp plus puissantes, ce qui est bien pour les gens qui en ont les moyens, les petits joueurs qui sont hélas souvent condamnés à rester des prolétaires du code bas niveau pourraient en revanche être content de trouver un code hackable et plus facile d'accès.
Après, sur la modulartité en soit, je suis d'accord, je pense qu'OpenERP fait aussi bien et je parirai même mieux (sur l'exension des vues par exemple), mais j'avoue que c'est ici une pure supputation tant j'ai été impressionné par le pouvoir des modules sur OpenERP sans connaître assez Dolibarr.
Bref on verra bien. Nous on en intègre pas (encore) Dolibarr car justement la cible est trop petite pour intéresser un intégrateur qui ne soit pas un freelance (me semble t-il). Et on a 2 clients qui vont passer en prod sur OpenERP v5 sous peu qui n'auraient pas pu avoir Dolibarr (entre autre), ne serait-ce que par les moins grandes aptitudes en terme de gestion multi-entrepôts et traçabilité avec gestion de lot. Ou peut être encore en ce qui concerne la comptabilité analytique multiaxe ou OpenERP s'est révélé adaptée. Mais on a aussi vu pleins de gens qui ne pouvaient s'offrir une intégration OpenERP et dont certains sans doute pourraient arriver à qqch avec un Dolibarr s'il est aussi bien qu'ils le disent.
Après je pense qu'OpenERP saura aussi capter une partie de cette clientèle avec sa future offre Saas.
A plus et bonne chance pour votre v5. De tte façon, c'est tout le marché qui est en train de réaliser la maturité des ERP oss et donc il est presque souhaitable qu'une multitude d'acteurs oss percent, ce qui semble arriver.
Raphaël Valyi.
[^] # Re: quid des références?
Posté par rvalyi . En réponse à la dépêche Dolibarr ERP/CRM 2.4 stable est disponible. Évalué à 1.
question MDA: y'en a déjà un moyen pour OpenERP:
http://www.openobject.com/index.php?option=com_content&t(...)
cliques sur la deuxième démo 'generate the objects'.
Perso je pense que l'idée du MDA est une faillite intellectuelle, c'était valide à l'époque reine des EJB et autres bloatwares où il s'agissait avant tout de pisser du code tant le langage ou les frameworks étaient abérrants. A partir du moment ou tu as des langages+frameworks type Rails qui te permettent d'exprimer bien plus en quelques mots de prog déclarative sans avoir à aller connecter des flêches en se demandant combien coutera l'outil qui dessine les flêches demain (Neogia s'est bien planté avec PoseidonUML qui est devenu payant, ils n'ont même pas encore fini de payer leur migration sur l'UML fait dans Netbeans, jusqu'au prochain abus du fabricant d'outils...
Je considère qu'OpenERP est à peu près aussi bien conçu que Rails en terme d'API (disons que c'est ce qui s'en rapproche le plus en terme d'ERP) et je ne vois pas tellement comment on peut exprimer de façon plus canonique un besoin fonctionnel que le minimum d'instructions de code mis en jeux, c'est cela qui me donne une très grande confiance.
Après oui, c'est vrai OpenERP pourrait s'essayer à un peut plus de vitesse. Mais ils ont quand même 2 niveaux de cache dans leur ORM, comme sur Hibernate et pas comme sur Compiere ni Openbravo qui ont d'ailleurs sans doute un base plus faible de testeurs capables. Et au pire, sur les points chauds avérés tu peux toujours bourriner du PL/SQL à papa pour accélérer à la même vitesse d'un Openbravo ou un Compiere (mais la différence avec eux c'est que le PL/SQL reste l'ultime option et qu'on est pas obligé d'en arriver là d'office). Concédons que ces derniers peuvent tourner sur Oracle contrairement à OpenERP. Reste que depuis que ma dernière version du livre blanc en Mai, eTiny est devenu 3 fois plus rapide environ et nombre de partenaires ont fait état de déploiements avec des milliers de mouvements de stock ou comptables par mois. J'avoue que je suis en passe de ne plus me faire de souci de ce côté-ci, je corrige d'ailleurs notre livre blanc en ce sens.
Au fait, en creusant encore: oui décidemment Dolibarr semble avoir beaucoup progressé et sera sans doute un bon choix pour les très petites structures qui ne peuvent pas investir sur quelque chose de plus gros. Il s'agît en effet d'une niche qui était mal remplie par les les offres concurrentes.
Cordialement,
Raphaël Valyi.
[^] # Re: quid des références?
Posté par rvalyi . En réponse à la dépêche Dolibarr ERP/CRM 2.4 stable est disponible. Évalué à 1.
c'est mon point de vue et pas forcément celui de la société qui m'emploie et qui a financé le livre blanc, mais sache que j'aurais vraiment beaucoup de mal à recommander Openbravo sur OpenERP. A la rigueur OpenbravoPOS pour les points de ventes qui est une solution lourde mais techniquement valide.
Sinon ça serait vraiment ma deuxième propositions pour les gens exclusivement paranoïaques au Python (pourtant plus facile à apprendre que Java), mais ecore une fois je pense qu'il n'y a pas photo sur le fonctionnel, la conception et la dynamique réelle. J'avoue qu'il m'a fallu 2 mois pour changer d'avis après avoir par erreur écarté OpenERP pensant qu'il s'agissait d'un client lourd simpliste (j'avais regardé le code et en avais vu tellement peu que j'étais loin d'imaginer que la couverture fonctionnelle était triple). Mais ensuite je n'ai jamais changé d'avis.
Faut voir aussi qu'Openbravo, si avec leurs 18 millions de dollars levés au total il n'arrivent pas à faire, dans quelques mois/années, quelque chose qui chatouille un peu ce qu'a fait un étudiant en école (OpenERP), alors ça seraient vraiment des manches (m'enfin ça se voit aussi les millions engloutis en mauvaises solutions, on dira d'ailleurs bien ça de SAP un jour). Personnellement je sais déjà où j'aurais mis mes billes mais ne faisons pas ici de procès d'intention.
OpenERP4.4 va sortir d'ici environ un mois et je pense que questions améliorations d'ergonomie tu seras servi (petite entrevue ici pour la gestion de projet, sur le client GTK: http://fptiny.blogspot.com/2008/09/reviewed-project-manageme(...) ). OpenERP ne donne certes pas la liberté d'une page HTML faite à la mano, mais on peut quand même pas mal customizer l'engin.
Bonne chance,
Raphaël Valyi.
[^] # Re: quid des références?
Posté par rvalyi . En réponse à la dépêche Dolibarr ERP/CRM 2.4 stable est disponible. Évalué à 3.
merci, post très éclairant. En effet, j'ai vu qu'il y avait encore beacoup de français uniquement dans votre doc et code, mais savoir que vous avez concience d'allez vers l'international est déjà une très bonne nouvelle.
Je n'étais pas non plus au courant du système de trigger PHP et workflows.
L'approche type Pareto: ne pas essayer de tout faire mais rester simple me paraît très valide.
Si le PHP4 que vous utilisez est objet, c'est plutôt rassurant. Hélas je n'avais pas pu m'en assurer dans le temps imparti.
Au fait, OpenERP ne fait pas de alter table ou de suppression de donnée sauvage à l'installation d'un module: il dit juste attention il faudra faire quelque chose. Ceci afin d'éviter les pertes de données accidentelles. En revanche, la gestion des dependances entre modules et les mécanismes d'héritage des objets métiers et de vues est extrèmement puissant. Je n'ai vue aucun autre ERP mature qui faisait ça (peut être ERP5 mais nous avions du mal à croire à la base Zope en général pour les PME en dehors d'une optique SaaS).
Bref, oui, nous allons surveiller ça. D'autant qu'il semble que Dolibar dispose d'une commaunauté contente, ce qui est un énorme plus et c'est très différents de certaines solutions J2EE dont les rares clients (pas les notres) n'ont de cesse de se plaindre.
Je crois aussi que Dolibarr répond bien aux attentes des TPE ou il y aurait un connaiseur de PHP, alors que d'autres ERP comme OpenERP, Openbravo ou Compiere visent des boîtes plus grosses et nécessitent en contreparitie un investissement supérieur (l'investissement sera surtout supérieur pour Compiere ou Openbravo ici).
Nous allons faire une mise à jour de notre livre blanc d'ici quelques jours. Hélas pas le temps de remettre Dolibarr sur le tapis pour l'instant. On le mentionnera un peu plus dans un paragraphe c'est promis. On va surtout mettre à jour les progrès indéniables de Compiere 3.1 (bien qu'on le répète pas très ouvert), les progrès (énormes) d'OpenERP 4.4 et son changenment de de nom consommé, le mode appliance d'Openbravo ou encore la difficile traversée du désert de Neogia qui ne donne pas trop signe de vie cette année.
Cordialement,
Raphaël Valyi.
# quid des références?
Posté par rvalyi . En réponse à la dépêche Dolibarr ERP/CRM 2.4 stable est disponible. Évalué à 6.
Perso, c'est OpenERP qui m'a le plus impressionné des tous ceux que j'ai pu tester pendant les 9 mois d'étude pour le livre blanc Smile, j'ai jamais rien trouvé à redire sur sa conception bluffante et à mon humble avis y'a des éditeurs qui vont plus trop rigoler dans quelques années.
En ce qui concerne Dolibarr, l'usage de PHP4 (pas très objet; me paraissait hasardeux tant un ERP est complexe: comment masquer et maîtriser la complexité à long terme sans abstraction objet?) et la caractère peu international du projet m'ont fait douté lorsque je l'ai passé en revue il y a presque un an. En effet, les projets open source qui percent sont rarement des projets non anglophones sans concession, fût-ils développés par des français car ils possèdent alors un base d'utilisateurs/contributeurs d'autant pus large.
L'impression que me laisse encore Dolibarr, c'est que la modularité applicative y est presque nulle: c'est à prendre ou à laisser; si ça ne vous convient pas, il faut hacker le code là oui l'est ou le détourner très en amont sans réutiliser rien du tout. Bref bonjour l'évolutivité et pas de phénomène de catalyse ou chacun peut réinjecter aisément le travail d'autres tierces parties (je ne parle pas de la simple addition de fonctionnalité assurés par le système actuel de modules, mais bien de l'altération des fonctions existantes). Quand je vois par exemple la maturité d'un openERP qui adapte tout seul la structure de la base quand on injecte des plugins qui viennent tuner exactement là ou on le voulait avec la précision d'un bon code objet, ou que je vois l'effervescence des modules tierces contribués qui exploitent ce système pleinement, je me dis que c'est juste autre chose.
Le problème du manque de modularité d'un ERP libre, à mon sens, c'est que si l'ERP ne permet pas de faire des choses très spécifiques avec des coûts de dev maitrisés, alors hélas les produits propriétaires de grande consommation tendent à être souvent plus compétitifs. Bref je n'imagine pas d'autre issue que la faculté de personnalisation à outrance compétitive, à moins qu'un jour ces logiciels atteignent la maturité d'un Firefox ou d'un OpenOffice mais j'en doute, ne serait-ce que par la complexité des métiers et des lois associées qui divisent les communautés déjà maigres en autant d'entités qu'il y a des pays/législations.
Reste que la barrière d'entrée semble plus basse sur Dolibarr que sur la majorité des autres ERP, le côté francophone, s'il est sans doute un handicap à long terme, hisse sans doute néanmoins Dolibarr au dessus de certains concurrent pour un usage hexagonal. Bref, pourquoi pas si Dolibarr semble répondre d'office à 90% des besoin, sinon mieux vaut accepter une barrière d'entrée plus haute mais des abstractions ensuite plus pérennes.
Au fait, je vois que Dolibarr est intégré avec OSCommerce apparemment. Puisque Magento est souvent désigné comme le successeur d'OSCommerce, Je signale donc au passage qu'à Smile on a bossé sur un connecteur (open source) OpenERP / Magento.
mes 0,02$
Raphaël Valyi.
[^] # Re: GPAO
Posté par rvalyi . En réponse à la dépêche OpenERP : la gestion d'entreprise libre. Évalué à 3.
Sans vouloir envenimer le débat et en espérant simplement suciter votre curiosité pour OpenERP, je pense que vous dite cela parce que vous n'avez pas vu:
* le view designer en Ajax d'OpenERP qui permet de construire les vues par simple glisser-déposer et de traduire les champs à l'envie (marche sur le SVN, preview non effective possible sur les démo en ligne; bouton 'customize view')
* l'éditeur de workflow en Ajax aussi qui permet une vétitable gestion BPM des process. ça n'est pas Intalio non plus mais franchement ça va très loin avec une simplicité maximale (cf SVN).
* l'extension des structures de données par héritage et éventuellement dans l'interface graphique. La modularité est très grande et le code résultant toujours propre, lisible et maintenable.
Ceci vaut aussi pour les controllers et méthodes métiers qui respectent la programmation objet et offrent ainsi différent niveaux de lisibilité et contrôle, c'est très différent du code procédural en pl/SQL de Compiere ou d'Openbravo... (le pl/SQL c'est bien, mais je préfère quand c'est utilisé sur des optims parcimonieuses plutôt qu'un recours systématique). C'est quand même aussi bien pratique de mettre ses breakpoints dans Pydev pour introspecter/modifier le code plutôt que de savoir comment avoir une license SQLDevelopper d'Oracle...
C'est vrai que Compiere et Openbravo rendent assez triviale l'extension des structures de données et de leurs vues associées (comme OpenERP donc), mais je pense que sur les process métiers, que ce soit au niveau de la modélisation BPM de haut niveau (genre l'état monitorable sur un graphe de workflow de tes lignes de commande dans OpenERP) ou le code objet vs pl/SQL, il y a une vraie différence de productivité.
J'ajoute que j'ai au moins 5 ans d'expérience de dev Java et j'avais seulement 3 jours de Python quand j'avais découvert OpenERP. Pourtant, tout comme les autres ressources de ma boîte, on préfère DE LOIN apprendre les rudiement de Python (en une semaine on fai beaucoup) plutôt que de faire des centaines/milliers de lignes de pl/SQL dans un ERP qui se prétendrai codé en Java (juste parce qu'il y a du Java entre le bout de HTML et l'appel de la proc stock quand on clique sur un bouton). En plus Python ça ressemble à Ruby et Ruby ça dépôte.
A bon entendeur... Bien cordialement,
Raphaël Valyi.
[^] # Re: GPAO
Posté par rvalyi . En réponse à la dépêche OpenERP : la gestion d'entreprise libre. Évalué à 4.
oui, la gestion de production est comprise dans OpenERP au même titre que sur les autres meilleurs ERP libres. Mais attention, il ne s'agit pas d'une gestion de production à capacité finie mature tels qu'on les trouve sur les ERP haut de gamme dédiés type Lawson. Il ne s'agit pour l'instant que de MRP1, c'est à dire du calcul des besoins en approvisionnement et en ordres de fabrications. La fabrication des produit est modélisée à l'aide des concepts fondamentaux classiques de gammes, de nomenclatures et de postes de travail, un peu comme sur ERP5, Neogia et Openbravo; je le résume dans le livre blanc de Smile. Ensuite sur chaque poste de travail, tu peux connaître et prévoir la charge et ainsi (re)planifier manuellement les runs de production à l'optimum physique en tenant compte de ces indicateurs de charge. On peut aussi brancher un planificateur externe.
Une bon aperçu est dispo ici: http://demo.openerp.com:8080/login?user=admin&passwd=adm(...)
Par ailleurs, la gestion de production des sociétés de services est aussi très bien déservie: assignation des tâches, plannings, tableaux d'évaluation de la rentabilité des projets, facturation du travail en régie, à la tâche ou au forfait...
Un autre aperçu ici:
http://demo.openerp.com:8080/login?user=admin&passwd=adm(...)
NB: il semble qu'à l'heure précise ou j'écrive les serveurs soient en maintenance et soient down, essayez plus tard en cas de pépin.
Hope this helps,
Raphaël Valyi.
# Selon notre analyse de 6 mois, OpenERP est le meilleur ERP libre...
Posté par rvalyi . En réponse à la dépêche OpenERP : la gestion d'entreprise libre. Évalué à 9.
J'ajoute, que la société dans laquelle je travaille, Smile.fr, m'a mandaté pour comparer les ERP open source sur plus de 6 mois (une trentaine de produits passés au crible). A l'issu, je dois dire que le constat est assez net: il est assez incontestable qu'OpenERP se classe en tête des ERP matures pour le marché français, sur l'ensemble des critères: couverture fonctionnelle, technologie (des années d'avances sur certains rivaux: BPM intégrée, ORM puissant...) et dynamique communautaire.
Ce livre blanc de 120 pages dont je suis l'auteur est téléchargeable gratuitement ici:
http://www.smile.fr/publications/livres-blancs/erp-open-sour(...)
Franchement l'outil est impressionnant. les développeurs en herbes sauront monter eux-même leur système en achetant le bouquin paru chez Eyrolles, en écumant les forums très fréquentés d'OpenERP et la doc technique déjà très correcte pour un projet de cette envergure (la gestion de prod industrielle nécessitera quand même de la formation). Mais OpenERP saura aussi intéresser les plus grandes PME qui n'auront alors pas de difficulté à trouver un intégrateur compétitif.
Enfin je confirme, contrairement à nombre d'autres, OpenERP joue à fond la carte de l'open source: le code est GPL, le SVN est accessible, y compris pour de nombreux modules. De pus, comme le logiciel est bien conçu, les besoins de l'éditeur sont très modérés et sa stratégie marketing est en retour très douce. Mais surtout il y a une vraie gouvernance open source là où d'autres ERP open source n'ont aucune activité communautaire. Enfin, contrairement encore à d'autres ERP open source, par exemple codés à coup de pl/SQL à papa, le code d'OpenERP est largement lisible et maitrisable, ce qui en fait un vrai logiciel open source qu'on peut effectivement personnaliser à sa guise si on dispose plutôt de compétence et de motivation que de budget.
Cordialement,
Raphaël Valyi.
# Oui mais Grails c'est aussi Groovy...
Posté par rvalyi . En réponse à la dépêche Sortie de Grails 1.0. Évalué à 5.
Grails est sans doute déjà un progrès par rapport à du Struts 1 et des JSP, mais personnellement je crois que JRuby on Rails a plus de sens. En effet, ça fait tourner le vrai Rails inchangé avec vraiment presque tous ces plugins (sauf de rares ayant des dépendances natives pas encore portées en Java), Rails 2.0 et ses nested resources URL si restful...
On peut bien y utiliser une persistence Hibernate (avec ActiveHibernate par exemple ou directement) si vraiment on ne trouve pas son bonheur avec ActiveRecord sur les drivers JDBC. On peut aussi facilement appeler tout beans Spring pour y intégrer du J2EE à papa. On peut aussi bien sur appeler n'importe quel javabeans directement depuis le code JRuby et échanger avec, disons que Spring c'est just pour mieux gérer l'IOC legacy, en Ruby on peut faire plus simple et plus élégant.
Grails c'est aussi la language Groovy dont les rumeurs sur les performances ne sont pas très bonnes; je crois que JRuby head fume bien Groovy. Sans compter que la génération de bytecode de Groovy est lente. Par ailleurs je ne crois pas que Groovy ait de compilation Just In Time comme JRuby dont c'est la force principale...
Un des rares avantages transitoire de Groovy est qu'on peut appeler depuis Java des classes implémenter en Groovy et qu'elles sont de vraies classes Java. Mais un compilateur extra de JRuby vers Java va aussi se rapprocher de ceci très rapidemment. En gros il va aussi permettre de type (optionnellement) des objets Ruby pour le cas ou on les utilise depuis Java...
Bref JRuby on Rails vaut le coup d'oeil, on se rapproche d'une maturité suffisante pour de la prod. Venez trainer sur #jruby si vous voulez en savoir plus, ça foisonne d'idées et de talents...
Raphaël Valyi.
[^] # Re: Complexe par rapport à quoi ?
Posté par rvalyi . En réponse à la dépêche OpenID 2.0 est arrivé. Évalué à 3.
les utilisateur sont habitués à donner un couple login/mot de passe. C'est devenu très intuitif pour eux.
Or, avec OpenID, hormis dans le cas où le site est fournisseur d'OpenID (c'est pas le but que chaque site soit son fournisseur sinon zéro fédération des identités), l'utilisateur doit d'abord entrer son OpenID qui prend généralement la forme d'une URL.
Cette première étape est déconcertante pour l'utilisateur moyen: il ne voit pas pourquoi d'un coup on ne lui demande plus deux mais une seule information et pourquoi celle-ci est généralement plus compliquée qu'un login.
Une fois que l'utilisateur est sur la page du fournisseur d'OpenID, c'est bon, il s'y retrouve.
Bref il y a bien une période pendant laquelle on va devoir éduquer les utilisateurs et convaincre les décideurs que cette différence fonctionnelle n'est pas insurmontable.
Raphaël Valyi.