Version imprimable
On parle beaucoup de Spring et malheureusement je remarque qu'il est toujours associé à JSF ou Struts, alors qu'il propose déjà une couche web : SpringMVC.
Je conseille a tout le monde de regarder la présentation/démo de SpringMVC 3 par Keith Donald.
(C'est une combo spring-mvc / jquery).
En ce qui me concerne je trouve le programming model excellent ... proche du web http, alors que d'autres frameworks essaient de le masquer, à tord selon moi.
Ce n'est pas un problème de langage, c'est un problème écosystème. Je ne parlerais que du Web. Le tout XML, les trop nombreuses couches, les conteneurs Web à configurer. Les pseudos langages qui en théorie simplifient le développement mais qu'il faut apprendre. Les déploiements fastidieux. C'est long et lourd à mettre en place. Vous allez me dire c'est propre et robuste mais à quel prix. D'autant plus qu'un Dev Java coûte plus cher que les autres développeurs à expérience équivalente (Encore une fois, je parle du Web).
Je me suis réconcilié avec le développement Java Web en découvrant le Framework Java Play. Je me régale avec.
L'article met en avant l'agilité, c'est vraiment ce qui manque à Java.
C'est bête mais rien qu'installer son environnement de travail demande un temps fou. J'ai passé 1/2 journée sur Tomcat.
étonnant pour une application qu'il suffit de dezipper n'importe ou :/Citation:
Envoyé par batataw
C'est bien là le problème, une fois dézippé c'est pas fini, t'as toute la configuration qui suit. Déclarer son site Web, régler les permissions, télécharger les librairies, redémarrer X fois ton service car j'ai oublié un truc. Modifier le port..., l'interface Web de Tomcat étant limité, j'ai du me taper tous les fichiers XML. Bon ça a marché à la fin mais c'est vraiment trop lourd. J'oubliais les messages d'erreurs sont illisibles (piles Java).Citation:
Envoyé par tchize_
Le Framework Play est ce que j'attendais depuis longtemps pour le développement WEB. Parce qu'à côté de ça la syntaxe me plaît beaucoup.
Y a deux trucs que je trouve assez vrais quand même...
Certes, c'est pas spécifique à Java, mais c'est quand même en Java que c'est le plus flagrant... quand il y a 10 couches d'abstractions les unes sur les autres avec des factory, des facades et autres adapters qui viennent se glisser là dedans, il faut commencer à se poser des questions :aie:. Les designs patterns, c'est bien, mais ça a parfois tendance à prendre trop d'ampleur et à "obfusquer" ce que fait vraiment le code...Citation:
des « architectes apprentis sorciers »
Encore une fois, l'overengineering n'est pas une spécificité de Java, mais je l'ai observé dans la plupart des gros projets Java que j'ai pu voir (certes pas très nombreux vu que je bosse surtout sur .NET)
Ca fait longtemps que j'ai remarqué ça, et c'est un des trucs que j'aime pas trop dans le monde Java... Dans un sens, c'est bien d'avoir du choix, mais là c'est vraiment la jungle. Il y a tellement de frameworks en tout genre disponibles que ça devient difficile de choisir le bon... En .NET, il y a aussi pas mal de choix (certes pas autant), mais il y a des libs "standard" clairement identifiées pour la plupart des besoins courants, souvent intégrées dans le .NET Framework proprement dit, si bien qu'il n'y a pas besoin de trop se creuser la tête pour savoir laquelle utiliser. Même si évidemment ça ne fait jamais de mal de regarder ce qui existe à côté, on a parfois de bonnes surprises...Citation:
un « écosystème technologique étourdissant ».
Pour ma part je n'ai encore jamais rencontré un besoin que je n'ai pas su satisfaire grâce a la galaxie de produits microsoft ou grâce aux librairies/outils/frameworks disponibles sur CodePlex et cie.Citation:
Ainsi en Java (pour faire la comparaison avec .NET, mais on pourrait le faire avec d'autres plateformes) , j'ai plus de choix en terme de serveurs, d'orm, de framework IHM, de framework d'IOC etc.... Java est peut être un choix coûteux pour les entreprises, mais ses alternatives le sont bien plus encore, et bien souvent elles laissent moins de latitudes aux dévelopeurs pour leurs propres choix techniques. Cette latitude permet aux développeurs d'avoir plus de chance de coller aux attentes du client en terme de coûts, de sécurité et de qualité.
En plus dotNet en entreprise est très intéressant de par son intégration aux environnements, aussi bien serveur que client, windows. (Dev pour l'AD en dotnet se fait les doigts dans le nez par exemple, ai tenté en java... boarf...)
Pourtant dotnet ne propose pas autant de libr/fm et cie que Java, mais se centre plus (a mon humble avis) sur les vrai besoins du dev ou de l'utilisateur en évitant un peu la masturbation intellectuelle (ce qui est assez présent en java je trouve)
Maintenant les problèmes évoqués par Duquenne sont tout sauf neuf et ne sont pas forcément spécifique à Java. Toutes les technos type Java/Dotnet du marché souffre des mêmes problèmes (avec des proportions différentes).
Hum... c'est moi ou il tente de nous réinventer la librairie/framework ?Citation:
Capitaliser sur des briques open-source proposant des réponses aux problématiques les plus courantes dans le développement d'applications.
Il est très optimiste sur ce point. Le dev "strass" est très a la mode et faire joujoux avec le dernier truc sorti peut aussi être un moyen de dire "regardez, nous sommes à la pointe". (Vu et entendu) Au péril de la stabilité et la robustesse.Citation:
Le deuxième challenge serait de maintenir ce socle pour les 5, 10 ou 15 prochaines années au milieu d'un écosystème Java en constante évolution.
D’où le fait qu'ils soient de bons archis.Citation:
Les bons architectes sont souvent difficiles à retenir dans la durée, car ils puisent leurs motivations dans la résolution de nouveaux challenges techniques leur permettant d’améliorer leur expertise.
(pour moi c'est un peu comme demander 10ans d’expérience, moins de 30ans et pour 1200€/mois...)
Ce qui est censé se faire dans toute boite qui se respecte ^^Citation:
Duquenne recommande des solutions qui peuvent évacuer la complexité du Java et de son environnement comme le cadrage structurant les méthodes de développement, l’utilisation de Frameworks, l'intégration continue ou encore le recours aux approches agiles de gestion de projet favorisant les échanges d'informations et limitant la dépendance aux personnes clefs du projet.
Je trouve qu'a la fin il identifie non pas les problèmes lié a java mais les problèmes lié a tout développement logiciel.
Reste cependant intéressant comme piqure de rappel.
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...
Java est Open Source, non ? À 95 %, il me semble.Citation:
Envoyé par Idelways
Et même maintenant !Citation:
Envoyé par gagaches
+1Citation:
Envoyé par gagaches
Troll velu détecté !!!!:mouarf:Citation:
Envoyé par ner0lph
Si tu achétes Microsoft Access pour 190€, pour 10 personnes, soit 2000€ qu'en quatre jours à 500 € par jour tu réalises le développement nécessaire pour ces 10 personnes (10 tables, 4 formulaires; 2 rapports). Tu reprends les données d'un tableur Excel. (1 journée)
On peut donc dire :
2000 € de "techno" (troll velu)
2500 € de ressource humaine
Soit 4500 € de prix pour livrer une appli utile à 10 personnes.
[:ccool:Je précise pour éviter de faire fanboy microsoft que le fait d'utiliser les équivalents .NET ne ferait pas mieux à architecture équivalente:ccool:]
Tu prends Eclipse, le JDK, Hibernate, Spring, et strut et PostGre / MySql / Firebird. C'est gratuit. Tu l'installes en local. Tu résouds les dépendances. Tu cherche tes plugins, tu fais tes tests. Ca fait 1 petite journée
Tu achétes un serveur d'application linux. 3000 €; linux est "gratuit".
Tu payes une license pour virtualiser (serveur de prod; serveur de test). 500 €
Tu achétes un serveur Linux pour mettre un SVN. 1500 €.
Ca fait 1 semaine pour la commande; 3 jours pour l'installation.
Tu installes Tomcat. Avec la sécurité et toukivabien et tu te donnes du temps pour tester la sécurité. 2 jours
Tu commences à développer ton dal avec hibernate. Ca fonctionne. Mais tu veux des tests. Tu implémentes tes test depuis les règles du tableur Excel. Au passage, tu fais la reprise Excel vers le SGBD et un script SQL. Tu fais un dev pour reprendre les données proprement avec POI (2 jours); et tu mets en place Quartz pour mettre à jour tes données tous les soirs (1/2 jour) et une réplication prod --> test (1/2 jour). Tu décides d'utiliser Jenkins pour faire l'intégration continue. 2 jours.
Tu commences alors à développer des écrans. Tu fais du strut. 4 jours.
Tu te demandes comment faire les rapports ? Tu prends Jasper. Gratuit. Tu le fais fonctionner avec Eclipse et ton modéle hibernate. 2 jours. Tu fais tes rapports (2 jours). Tu fais l'inclusion Web de tes rapports et du lancement. (2 jours).
tu mets en prod (2 jours).
Mis bout à bout, ton application deux, utilisant des technologies exclusivement gratuite voir libres, te coûte ...28 jours; et 5000 € de matériel et
14 000 € de développement.
Soit 400 % plus chére à produire et quasiment 4 fois plus longue.
Mon exemple est exagéré, je pense que le vrai ratio serait dans les 3, mais l'erreur, c'est celui qui choisi la techno. :ccool:
ce que je trouve amusant dans l'histoire ce que tu compare la création en access d'une application desktop pour 10 personnes à la création en java d'une application web pour 500 utilisateurs 8O Donc j'aurais tendance à dire, 4 fois plus chere pour 50 fois plus d'utilisateur, donc 12 fois moins cher / poste.
Tu prends Eclipse, le JDK, Hibernate, Spring, et strut et PostGre / MySql / Firebird. totalement inutile et déplacé pour une si petite application.
Tu résouds les dépendances. Tu cherche tes plugins -> plus besoin cf ci-dessus
Si t'es rodé, tu prend 5 minutes pour installer un plugin maven. Voilà, t'es paré à travailler en 20 minutes. Pour la db, si t'as besoin d'un db pour ça, un H2 embedded et ça roule.
Tu achétes un serveur d'application linux. 3000 €; linux est "gratuit". Si t'achète un serveur linux, la comparaison aurait voulue que tu acheter un serveur windows de l'autre coté. Donc pas de serveur, c'est une application desktop, c'est gratuit
Tu payes une license pour virtualiser (serveur de prod; serveur de test). 500 € Pas de serveur, pas de virtualisation, toutjours 0€
Tu achètes un serveur Linux pour mettre un SVN. 1500 €.Quand bien même tu en aurais eu besoin -> c'est un investissement unique pour toute ta SISI pendant des années, ca nécessite peu de matos, et de toutes façons, tu ne l'a pas mis plus haut, donc retiré de la comparaison, 0€
Ca fait 1 semaine pour la commande; 3 jours pour l'installation. Rien à commander, rien de compliqué à installer, on est à 30 minutes de temps de dev pour le moment
Tu installes Tomcat. Avec la sécurité et toukivabien et tu te donnes du temps pour tester la sécurité. 2 jours N'existe pas-> 0 minutes.(Et un tomcat s'installe en 20 minutes, (juste à dézipper et c'est prêt), seule ton application devra éventuellement être sécurisée)
Mais tu veux des tests. .... 2 jours ->T'as pas mis de test automatisé dans ta version access. Si tu peux travailler comme un cochon, moi aussi-> 0 jours.
Tu commences alors à développer des écrans. Tu fais du strut. 4 jours. Tu fais une appli destkop, 4 formulaires. Si le client est pas chipoteur sur la position des champs, un formulaire se dessine en 2 heures avec matisse + 2 heure pour faire les requetes JDBC derrière. -> 2 jours (et pour info, des formulaires JSF sur des EJB3, c'est pas plus long quand tu connais)
Tu te demandes comment faire les rapports ? Je prend jodreport, je prend le template que m'a envoyé le client en .doc, et j'y met les instructions d'insertion. 1 jour par rapport parce que je suis spépieu. Au passage je rend les odt au client, comme ça, si il veux, il peux les changer n'importe quand sans avoir besoin de moi.
Maintenant, si nous reprenons l'exemple access: tu peux facilement me compter 3 à 4 jours par formulaire personnellement. Et le même pour les rapport. Non Obstant l'utilisation de technos inutile dans ton exemple, je suppose que les temps que tu donne sont fonction des tes connaissance en java. Les formulaire et la config hibernate / test / JSF et autres, ca va beaucoup plus vite quand tu l'a déjà fait quelque fois. Et struts / JSF c'est pas comparable, tu va facilement 2 à 4 fois plus vite avec JSF ;)
Bref, si on dois comparer, comparons des choses comparables à compétence équivalentes. T'es surement capable de réaliser ça en 4 à 5 jours sous access, je suis tout à fait capable de tenir les même délais en java
J'aime bien ca :lol:Citation:
Envoyé par tchize_
Dans le meme esprit que BAF, je dirais que c'est plus productif de faire de la conception sur papier que sur ordinateur.
Demonstration : Je cherche à fabriquer une arme.
Sur papier :
Je dessine un lance pierre => 2 mins.
Je cherche un bon elastique => 2h
Je vais dehors chercher des pierres => 1h
En 1/2 journée c'est fait.
Sur ordinateur, je cherche à fabriquer une bombe atomique :
Je cherche du personnel competent => 6 mois
Je fais bosser tout ce beau monde => des années.
Moralité : c'est infiniment plus productif de concevoir sur papier que sur ordinateur.
Je finirais parMais bon, les plus observateurs d'entre vous auront remarqué que les 2 exemples ne sont pas tres comparables (meme dans mon exemple) ;)Citation:
Mon exemple est exagéré
Ça commençait bien pourtant:
/popcornCitation:
Envoyé par B.AF
Bonjour,
Si la difficulté est chez Java comme ailleurs de réfléchir plus que de coder, je voudrais juste faire part d'une petite incompréhension (frustration ?) que j'observe dans les présentations de Java aux étudiants et jeunes programmeurs.
On ne fait que très peu référence à l'influence du bytecode. En fait, je trouve que dire que Java dérive de C++ n'est pas vrai, par rapport à la question de l'analyse du projet informatique. La syntaxe est juste familière, d'un point de vue cosmétique.
Pour moi, la vraie filliation que l'on devrait enseigner pour Java est celle de Forth. Il suffit de désassembler un programme pour la JVM : c'est frappant.
Je ne fais pas dans la nostalgie de Forth ; l'organisation autour d'objets impose un passage à une syntaxe à la Java/C++. Ce serait trop fastidieux et hasardeux de demander à un programmeur d'invoquer explicitement un calcul pour trouver la bonne méthode par rapport à l'objet qu'il manipule.
Par contre, les questionnements sur l'analyse que Forth permettait devraient être expliqués aux programmeurs, car ils existent en Java à cause de la JVM, sont utiles et peuvent coûter très cher à un projet quand ils sont négligés.
C++ comme toujours autorise cette forme de pensée, mais ne l'impose pas, contrairement à Java, où la POO est "pure". Alors quand on rajoute la "verbosité" du langage...
:?
ref, par exemple :
http://netcologne.dl.sourceforge.net...orth-color.pdf
(je sais, ça date...)
A ce stade ce n'est plus de l'exagération mais de la diffamation.Citation:
Envoyé par B.AF
Dommage tu sabordes ta démonstration, serait pu être instructif.
Arrêtez de lire sous le prisme de votre techno favorite.
Ce que je veux dire, c'est qu'on peut prendre du gratuit, se louper en architecture en pensant bien faire et finir avec un prix extrème; dépassant celui d'une "non-solution" propriétaire, en l'occurence access.
Ce serait sympa de lire plutôt que de faire du fanboyisme de base.
Quand tchise me dit que j'ai pondu un truc pour 500 users, je dis non. J'ai déjà vu ça proposé sur des ordres de 5 à 15 users.
Quel utilisateur final moyen a quelque chose à faire de la technologie du produit qu'il utilise ?
Est-ce que l'utilisateur d'office se soucie des langages derrière office ?
Non. Est-ce qu'il fait la différence entre la base access faite par un gars qui est parti mais qui marche bien et un progiciel en J2EE qui marchera ? Non.
Le défaut de ce forum (et pan!) c'est que rien n'est abordé du côté user ou client.
L'exemple que je donne, il est réel, je l'ai rencontré. Une dizaine de développeurs Java et .Net qui se battent contre des bases access utilisées en front-end de SQL Server.
Le second, avec tous ses défauts techno, de tests, était bien pour les utilisateurs, simplement parce que réactif et léger.
Le premier, il faisait la course avec le second et les utilisateurs n'en voulaient pas. Oh bien sur, il y avait toujours le composant technique qui allait, et il suffisait de...Mais du haut de leurs certitudes sur le développement et la performance, tous les jours ils ont perdu la guerre contre Access.
C'était assez laid ("on fera joli plus tard, c'est de l'ihm"), lent ("on fera l'optim plus tard, c'est pas un problème"), ne faisait pas grand chose ("c'est de l'objet, on peut faire ce qu'on veut"), quand les utilisateurs disaient "c'est pas souple" la réponse c'était "Ah oui mais c'est du testable et du développement en couche et on peu ajouter un moteur de règle", pour faire un nouvel état, "une réplication et un Business Object et ça marche" et ça a couté une demie boule. Pour rien. Tu demandes ce que ça fait, on t'envoie sur des tags de classe qui "serviront plus tard à faire de la doc".
Et un jour, le patron de la boite a dit : stop; il a foutu tout le monde à la porte et depuis, ils utilisent encore access.
Pour dire aussi que du prisme d'un décideur, peu de développeurs savent expliquer leurs choix. Alors lui il choisi ce qu'il pense fonctionner.
C'est une histoire vraie. Comme quoi. Ca vous fait peut être pas rire, mais si je vous envoie le tableau du contrôle de gestion du projet que j'évoque, beaucoup de fanboy Java et .Net risquent les larmes. C'est pas un troll, c'est un retour d'expérience. Surtout que je l'ai mal vécu.
Aimer une techno ne doit pas empêcher de prendre du recul.
Mais j'aime les passionnés aussi.
J'ai fait la liaison avec les postulats tenus depuis le début du post.Citation:
Envoyé par tchize_
Point barre.
Je suis content de lire que toi aussi tu trouves ça absurde.:ccool:
C'est pas la cas de tout le monde.
Ca c'est un tuto génial mais où vois-tu qu'on dise aux gamins aujourd'hui : faites vos choix en fonction de l'usage ? :calim2:
Mais je reconnais devant l'éternel que je suis fan de ton vitriol :ccool::mrgreen
@+
Chez moi, j'ai eu ce genre de formation oui. Mais comme partout, j'ai eu des bonnes et des mauvaise formations, j'ai eu un prof d'UML qui nous disait que de toutes façons, uml ca servait à rien :aie:. J'ai eu un prof d'intelligence artificiel qui nous a dit "bon maintenant pour le projet d'examen, vous trouvez un bon optimum pour le problème suivant avec l'algorithme de fourmis. Je veux une proposition de solution d'une page et une annexe de 15 pages qui regroupe les résultats optimums, les plus mauvais, les courbes d'apprentissage, etc. Vous emmerdez pas à écrire les annexe, faites un petit programme de 10 lignes en perl vite fait qui les remplis à la fin de la simulation, si j'en vois un qui a écrit l'annexe lui même il a 0, on est pas là pour perdre du temps en paperasse. Pour les graphes, vous avez gnuplot"Citation:
Envoyé par B.AF
Bref, un/des frameworks, c'est une boite à outils, quand un plombier viens chez moi, je m'en fou de savoir qu'il va utiliser un pince suédoise ou une clé anglaise. Ce que je veux, c'est que mon radiateur soit monté ;) Et si il essaie de visser son tuyau avec son super canif 54 fonction qu'il viens d'acheter..... Je vais regarder bizzare.
Citation:
Envoyé par trimok
Parfois je fais de petite appli et j'utilise quand même un ApplicationContext spring pour la porter. Je ne trouve pas ça lourd, au contraire, ca va tellement vite à faire ! Et ca structure le code : on s'habitue à écrire des services sous forme de pojo configurable et à penser l'application comme un réseau de beans.
Un autre exemple au hasard : Si je ne devais pas utiliser Spring dans mes applications, je recoderais un mini JdbcTemplate, en utilisant le même pattern avec les Callbacks. On peut en faire un en 10 min si on veut et en 30 lignes. Je le ferai tout simplement parce que je serais débarrassé une fois pour toute des dataSource.getConnection() et connection.close(), et que le pattern avec les callbacks permet de n'écrire qu'une fois la gestion des exceptions.
Il n'y a pas meilleure solution que ce pattern en ce qui concerne JDBC. Donc pourquoi s'en passer ?
Il faudrait pouvoir juger sur des exemples de code concret écrit en utilisant différents frameworks. Je suis aussi curieux de voir les patterns qui sont utilisés dans .NET, car cela peut inspirer et être reproduit dans le monde Java.
J'ajouterai pour terminer que j'ai été témoins de projets utilisant Spring et qui étaient écrit en plat de spaghetti (tout en méthode static ... et un seul <bean>). Mais on comprend très vite la cause : des responsables qui pensent que l'on peut faire une appli niquel avec des stagiaires sans aucune formation et un bon framework. Tant qu'il y aura les même causes, il y aura les même conséquences.
Oh que c'est vrai.Citation:
Envoyé par bugsan
D'une manière générale, la tendance à avoir un architecte qui pond sur le papier un design très joli, mais sans rien implémenter (il coûte trop cher), et ensuite on confie ça à des débutants complets ... :aie:
Et là aussi je parle de vécu, et pas sur des petits projets (>3000jh).
Alors qu'il suffirait de choper un Expert Technique qui entame les dévs pour faire une base puis encadre les débutants. Surcoût initial léger, énorme gain à l'arrivée, que ça soit en respect des délais, en productivité ou en évolutivité ...
Le problème ne vient ni de Java, ni de l'architecte qui peut avoir parfaitement raison sur le choix des frameworks (encore que certains soient souvent agités devant le client pour faire genre, ça je le reconnais volontiers). Il vient surtout des managers / commerciaux qui veulent un gain immédiat et refusent de dépenser un peu plus au début pour structurer.
Je suppose qu'on peut aussi voir ça comme une confiance aveugle dans l'architecte et dans les débutants ...
.Le probleme, c'est que ton postulat de base, c'est :Citation:
Envoyé par B.AF
- Developper Java = aime perdre du temps dans des architectures inutiles, compliquées et onereuses.
- Developper Access = va a l'essentiel
Franchement, je ne vois pas le lien entre la techno utilisée et la non productivité. J'ai connu des gens qui ont monté en C des moteurs à architecture proche de l'objet (grace aux pointeurs de fontion). C'etait complexe et pourtant pas sur Java.
A l'inverse, on peut faire un projet Java sans utiliser toutes les technos disponibles pour afficher un combo avec 1 requete SQL.
Maintenant, c'est vrai qu'il y a beaucoup de developpeurs qui veulent trop bien faire (ca m'arrive aussi, je pense que c'est naturel quand on veut faire du bon boulot) et il faut savoir s'arreter. Mais je ne pense pas que Java soit le seul nid ou on les retrouve...