Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Tu ne fais pas du JSF 2 pour un simple CRUD (a part pour un prototype), le but est bien d'ameliorer la productivite sur le long terme. Je ne vois pas pourquoi tu opposes qualite et productivite, pour moi ces deux concepts sont lies.Envoyé par B.AF
Ensuite si les applications qui consistent en un simple empilement de frameworks ne marchent pas, c'est peut etre a cause du developpeur, pas de l'outil.
Dans un cadre d'efforts d'industrialisation constants par les DSI, le choix de Java est remis en question. Oui, .NET limite délibérement le nombre de frameworks. Mais quelle suite applicative ! Excusez le troll mais je ne comprends pas qu'on passe encore autant de temps à parler d'Eclipse alors que j'ai l'impresson de perdre le mien à chasser à travers tous ses projets de plugins, à gérer des dépendances hasardeuses parfois et une prise en main toute relative par les équipes. Je demande un bon outil de modélisation uml ou merise et je ne trouve rien dans le catalogue cet IDE qui soit probant. Je me tourne alors vers un outil tiers... sans interop ! super... Eclipse open source, certes mais où est le ROI ? je suis entièrement d'accord avec Duquenne sur les autres points.
Michaël Mary
Consultant PLM dans une société de conseil toulousaine
Auditeur CNAM-IPST depuis septembre 2008
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
John F. Woods
mon cv et mon domaine et mon blog
Aucune question technique par MP, svp
L'avantage de dotnet, c'est qu'il y a les briques de microsoft et ça suffit,
DAL => entity, couche de communication => WCF, validation => dataannoration, presentation => xaml/asp/mvc, analyse => reporting services, repository => TFS.
Et c'est tout, du coup n'importe quel archi utilise les même outil ce qui n'est pas vrai pour java.
Et dotnet n'est au final pas plus cher, maintenance plus facile, dev moins cher cf prix du marché.
Les couts d'infrastructure son identique, aucune grossr entreprise prends une distribution linux gratuite, trop de risque.
Les couts d'infra de windows ou de ibm, sun, red hat, sont relativement identique.
Au final un projet dotnet coutera moins cher qu'il soit de 1500/10000/100000 jour/homme.
En dessous les entreprises prennent php.
C'est pareil sur la trinité S/H/S en Java, il y a beaucoup d'idées reçues là dedans.
EF ne permet pas aujourd'hui de tout faire, WCF demandent de la plomberie plus qu'on ne le croit (notamment en conjonction avec un ORM, la sérialisation, la sécurité, la performance), pour la présentation chaque techno a ses spécificités et ses contraintes (ah le thread ui en winforms), TFS est excellent soit, mais est très long à faire fonctionner correctement, ou du moins autrement qu'en dépot de source. Si tu prends la gestion du messaging, .Net est beaucoup moins outillé que Java.
Et n'importe quelle archi .Net n'utilise pas les mêmes outils. Il suffit de compter le nombre de projet Codeplex.
La seule partie sur laquelle .Net a pour moi un avantage non discutable de productivité c'est la partie client lourd (Forms vs Swing).
Ca fait un bail que la communaité demande à sun (et maintenant oracle) de nous pondre un swing2 ou autre chose n'assurant pas la compatibilité, histoire d'avoir quelque chose de propre, léger et facile à gérer
Certains disent que les développements java sont lourds, en partie oui, mais il faut comparer des choses comparables.
S'il s'agit de faire une application autonome (client lourd), la différence se fera plutôt dans la connaissance de Swing ou d'un Delphi/C++ Builder (ou équivalent). En pratique, c'est presque équivalent.
S'il s'agit d'un développement web, c'est une autre histoire.
La question est plutôt : qu'est ce qui fait que ces applications sont plus difficiles à réaliser.
Les différentes couches y sont pour beaucoup. Et la couche présentation tout particulièrement.
Là, on peut gagner en productivité en choisissant un framework plutôt qu'un autre (par exemple JSF+RichFaces vs Struts+Struts-Layout).
Avec ces architectures distribuées sont venues des problématiques nouvelles, l'interopérabilité devient un besoin (chose qu'on ne faisait pas trop il y a 10 ans) etc...
Le problème est peut-être dans le choix des framework. Ça bouge tout le temps, une solution arrive à peine à maturité qu'elle est remplacée par autre chose... Trouver des vrais experts devient de + en + difficile et ça peut être un frein quand il s'agit de décider.
Une fois le choix établi, encore faut-il former des équipes correctement.
Hibernate (ou les ORM plus généralement) est un outil intéressant, mais tout faire à coup d'entité peut se révéler désastreux en terme de performance (surtout si elles sont mal pensées).
Bref, les discours à l'emporte pièce ne servent pas à grand chose et ne font rien avancer... dire que java n'est pas un bon langage me semble franchement déplacé et pour moi, le problème n'est pas là.
Cela semble être le cas avec JavaFX 2.0Ca fait un bail que la communaité demande à sun (et maintenant oracle) de nous pondre un swing2 ou autre chose n'assurant pas la compatibilité, histoire d'avoir quelque chose de propre, léger et facile à gérer
a++
Franchement, Swing en tant que technologie, c'est très bien. Ca permet de tout faire et c'est performant, de nos jours.Ca fait un bail que la communaité demande à sun (et maintenant oracle) de nous pondre un swing2 ou autre chose n'assurant pas la compatibilité, histoire d'avoir quelque chose de propre, léger et facile à gérer
Le problème de Swing, c'est la complexité de mise en oeuvre. C'est compliqué à comprendre, et donc la courbe d'apprentissage est raide.
Donc, ce qu'il faudrait, ce n'est pas un nouveau système incompatible avec Swing, mais une couche qui prenne en charge tout ce qui est compliqué et qu'un programmeur n'a pas besoin de connaitre. Un peu ce qu'Adobe a fait avec AIR, en gros. J'ai l'impression que c'est ce que Sun voulait faire avec JavaFX, mais pour l'instant, c'est plutôt raté...
swing est bien, en tout cas a plein de bon truc. Le problème c'est toute la tartine AWT derrière qui n'a pas vraiment de raison d'être, puisqu'on ne peux pas mélanger du swing et de l'AWT. Et pour s'en défaire, faudrait arriver à quelque chose d'incompatible.
C'est également ce qu'Oracle semble vouloir faire avec JavaFX 2.0, qui devrait se débarrasser de son langage de script pour devenir une API pure Java...
a++
En quoi un projet .NET utilisant spring.NET, Nunit, NHibernate serait moin cher qu'un projet Java utilisant Spring, Junit et hibernate ?
Tout dépend des frameworks que tu utilises, et pour avoir fait du .NET et du Java, les trucs bien que je peux faire en .NET, je peux aussi les faire (avec le même niveau de productivité et de qualité) en Java, mais l'inverse n'est hélas pas toujours vrai. Par exemple, je cherche encore des frameworks IHM en .NET qui me permettent la même productivité que GWT... Je cherche encore des équivalent à Maven en .NET (réelement utilisés...)... etc..
ta des statistiques ou donnée contrète sur le sujet ? ou bien c'est comme les propos de bush sur les armes de destruction massive en irak?
Enfin en 10 ans d'expérience sur la conception et le développement de projets Java, c'est la première fois que j'entends quelqu'un avouer ce qui est peu avouable, les projets Java coûtent très très chers aux clients mais aussi aux prestataires.
Et ce n'est pas au moment du développement du projet que cela coute mais bien après ! C'est à dire lorsque l'application va vivre sa vie, va devoir être maintenue et donc subir des opérations de maintenance mais aussi des évolutions voir des refontes radicales.
Pourtant j'adore ce langage et j'apprécie toute la "Java Sphere" qui l'entoure sa grande force par rapport à d'autres langages plus pauvres et plus fermés de ce point de vue là. Mais je dois dire que même après 10 ans passé dans ce monde captivant on n'en fini toujours pas de réinventer la roue et cette pratique est très pénalisante pour les projets. On aboutie inévitablement à du code plus où moins fiable, plus ou moins performant et surtout plus où moins lisible et évolutif surtout lorsqu'il est implémenté dans 95% des cas par de jeunes ingénieurs fraîchement sorti de l'école et qui ont appris le langage sur le tas au moment de la réalisation du projet !
Dans les 10 euros du coût d'un projet Java, 50 centimes sont généreusement investi dans le développement initial et 9.50 euros seront encore investi pour tenter d'assurer sa maintenance tant bien que mal jusqu'au moment où 6 mois après une nouvelle direction décide de faire table rase pour arrêter la surchauffe des coûts et tout recommencer ... et ce dans les mêmes conditions.
Merci panda31 pour cette citation très à propos:
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
John F. Woods
Source: http://groups.google.com/group/comp....b64e464aed84a0
En gros l'article se résume à : "Y a plein de gens qui codent en Java comme des gros porcs, donc c'est le bordel de maintenir une appli Java."
En quoi cela serait différent avec .NET ou python ou autre ?On aboutie inévitablement à du code plus où moins fiable, plus ou moins performant et surtout plus où moins lisible et évolutif surtout lorsqu'il est implémenté dans 95% des cas par de jeunes ingénieurs fraîchement sorti de l'école et qui ont appris le langage sur le tas au moment de la réalisation du projet !
Les briques standards Java suffisent aussi : JSF + EJB + JPA.L'avantage de dotnet, c'est qu'il y a les briques de microsoft et ça suffit,
+1.avoir des frameworks techniques n'a jamais amélioré le SI.
Je ne suis pas tout à fait d'accord. Cela demande une certaine maitrise des bons outils pour être productif, mais on arrive à être productif avec Java. Par contre je suis d'accord sur le fait que ça ne coule pas de source.Java est de fait non productif.
Là encore, je pense qu'il ne faut pas confondre "valeur d'un outil" et "compétence pour l'utiliser".on passe encore autant de temps à parler d'Eclipse alors que j'ai l'impresson de perdre le mien à chasser à travers tous ses projets de plugins, à gérer des dépendances hasardeuses parfois et une prise en main toute relative par les équipes. Je demande un bon outil de modélisation uml ou merise et je ne trouve rien dans le catalogue cet IDE qui soit probant
Une bonne architecture est maintenable quel que soit le langage utilisé. Dire que le coût est supérieur car on utilise Java / C# / (langage de votre choix ici) et tel ou tel framework est une ineptie ; le problème n'est pas tant de mettre en place une solution technique que de la comprendre et surtout la maitriser : utiliser Struts / Spring / Hibernate sans savoir pourquoi, c'est ça qui coûte cher !
Je suis très d'accord avec le fait que le problème ne soit pas Java ou un autres langage mais son usage.
C'est un problème de gestion globale : techno open source = gratuit, développeurs juniors = bas prix.
A tout gérer par le coût direct le plus petit, faut pas s'étonner des défauts. Mais ça n'a rien à voir avec l'open source ou le Java. Ca peut arriver avec du C++ et du closed source.
Le problème de fonds, c'est qu'à force d'enseigner n'importe quoi, n'importe qui fait n'importe quoi n'importe où.
Entièrement d'accord B.AF.
Pour ma part, la plateforme JAVA a souffert de tatonnements de la part de certains concepteurs et du foisonnement de technologies ce qui amène ce constat cruël mais très réaliste.
Paradoxalement, c'est maintenant je trouve la plateforme mature: les EJB 3 sont simples à utiliser et pour tout ce qui internet, les framework EXT/GWT/VAADIN sont en bonne voie ( il leur faut cependant encore améliorer pas mal de choses), il existe des solutions simples à mettre en place pour les caches distribués (allez faire un tour du côté d'Hazelcast).
J'utilise toutes ces technos en ce moment et je dois dire que je suis assez statisfait de la rapidité de mise en oeuvre. Au niveau langage, il reste pas mal de petites choses à améliorer pour être à la hauteur de C#. Mais je ne me fais guèere de soucis, car très vite, ce dernier va devenir trop riche pour être facilement maintenable ;-).
J'ai vu tant de choses. Même des langages complètement inconnus qui peuvent faire des miracles.
Un langage n'a aucun coût (hormis une licence pour certains). Le plus grand coût viens clairement des ingénieurs et techniciens qui réalisent les différents projets. Si un langage particulier deviens "cher", c'est un problème de ressources humaines et non de technologie.
Faire simple
B.AF a en gros raison.
(Notamment , le développement en client lourd avec Visual C# est incroyablement productif.)
Ceci dit, Le problème général de l'informatique, et du développement, c'est qu'il faudrait faire simple, alors que l'on fait compliqué...
Il faudrait avoir une architecture, des composants, un code, facile à maintenir, alors que c'est plutôt le contraire...
Certes, Le problème n'est pas que pour le monde Java.
Néanmoins, mon expérience est que l'utilisation des frameworks J2EE : Hibernate, Struts, Spring, et surtout leur intégration, peut devenir très lourde.
Par exemple, pour Spring, il faut vraiment s'interroger sur son utilité, de manière générale pour tout framework, il faut regarder sa véritable plus-value
Les développeurs doivent vraiment maitriser ces frameworks, et maitriser leur intégration, et doivent avoir des règles strictes à suivre (lorsque l'on implémente une nouvelle classe, une nouvelle table, etc...).
Il devrait y avoir des commentaires dans le code, pour dire ce que l'on fait, et une documentation sur l'architecture et l'utilisation des classes.
En pratique, je constate que la maintenance devient de plus en plus
compliquée suivant l'age du logiciel, une fois que les créateurs du logiciels, et/ou les architectes sont partis, ils ne transmettent pas l'intégralité de la connaissance, et après plusieurs générations de développeurs sur un logiciel, cela peut devenir l'enfer. En fait, on devrait écrire du code comme on aimerait le trouver si on débarquait sur un nouveau logiciel !!! Mais très peu de personnes le font, et notamment très peu de jeunes...
Répondre avec citation
Partager