Discussion :

[hwoarang]

T'as pas mis de test automatisé dans ta version access. Si tu peux travailler comme un cochon, moi aussi-> 0 jours.

J'aime bien ca


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 par

Mon exemple est exagéré

Mais bon, les plus observateurs d'entre vous auront remarqué que les 2 exemples ne sont pas tres comparables (meme dans mon exemple)

[B.AF]

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 Donc j'aurais tendance à dire, 4 fois plus chere pour 50 fois plus d'utilisateur, donc 12 fois moins cher / poste.

J'ai fait la liaison avec les postulats tenus depuis le début du post.
Point barre.

Je suis content de lire que toi aussi tu trouves ça absurde.
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 ?

Mais je reconnais devant l'éternel que je suis fan de ton vitriol :mrgreen
@+

[batataw]

Troll velu détecté !!!!
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.

A ce stade ce n'est plus de l'exagération mais de la diffamation.
Dommage tu sabordes ta démonstration, serait pu être instructif.

[B.AF]

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.

[framework]

Si on parle des vieux langages utilisés en entreprise, moi je pense plutôt à ceux orientés gestion, c'est à dire le RPG ou le Cobol.

Et là, peut-être qu'effectivement, ils sont plus efficace que Java car ultra spécialisés dans leur domaine (la gestion) !

Sinon pour le web, il y a aussi PHP...

[william44290]

Parce que je partage la même conviction que l'auteur de l'article, j'ai développé mon propre Framework. Le mouvement "agile" dans le développement devrait aussi s'appliquer au framework que l'on utilise.





______________________________________________________________________________________________________________
[Mode PUBLI-REDACTIONNEL on]
Les constats :

• 1 les composants Swing de java sont primaires (Incomplet à l'usage ou trop complexe)
• 2 les outils disponibles sont trop nombreux (C'est une jungle technologique)
• 3 les interfaces graphiques sont délicates à maitriser (Multi entrée et Nombreux comportements à gérer)
• Les logiciels de gestion sont simples et répétitifs basés sur le template CRUD

Les objectifs de Abc-wtools sont :

• de faire gagner du temps lors du développement
• d'offrir un cadre de développement simplifié et robuste
• de limiter l'intervention du développeur aux problématiques métier
• d'apporter une solution Lite pour la mise en oeuvre de projet "Client Lourd"

Les services de Abc-wtools :

• Une architecture standard complète, à charge pour le Dev de réaliser la partie métier
• Des entités fonctionnelles nommées Fichier c'est la base de développement des objects métiers
• Des composants graphique unaire, des templates applicatif, des conteneurs pour construire des UI métier
• Des classes de service afin de synthétiser le codage, traitements des chaines, gestion des layout, des dates
• Un DAO SQL multi-SGDB pour la persistance des données métier

Le Développeur se concentre sur trois aspects fondamentaux du développement qui sont :

• le Modele Conceptuel de Données métier : définir les tables, les relations et les identifiants
• le Modele Conceptuel de Traitement métier : définir les transitions et les traitements de données
• les Interfaces Utilisateur : définir l'arborescence des menus et concevoir les écrans

La philosophie du framework Abc-wtools :

• Un framework de production finale (pas une sur-couche qui offre un nouveau potentiel)
• La gestion des packages doit-être une image de l'application métier (faciliter l'extension et le support)
• Un package égale une entité graphique fonctionnelle (Gagner en lisibilité)
• Des objets concrets (Garantir une utilisation intuitive)
• Le développeur manipule directement ses composants graphiques et ses données (Garder la maitrise)
• Ne coder que ce qui est nécessaire (Gagner en productivité)
• Rester Lite (Assurance de performance et de robustesse)
• Rester dans son domaine de définition (Faire peu, mais le faire bien)

Ce que n'est pas Abc-wtools :

• Une vitrine technologique
• Un environnement de travail standard
• L'outils magique

[Mode PUBLI-REDACTIONNEL off]

[dolby]

Si on veut comme souvent aller très vite dans la production avec des développeurs qui ne voudront pas prendre un peu de temps pour se former, effectivement Java est le mauvais choix. Mais dans une optique ou l'on veut améliorer de plus en plus la qualité du code que l'on génère au prix d'un apprentissage peut-être un petit peu plus long alors Java est un bon choix.
Toute le question est veut ton construire dans le temps ou veut t'on juste aller vite et vendre vite ! Je crois qu'il n'y a pas que sur le choix des langages que l'on peut avoir le même raisonnement !

[B.AF]

Si on veut comme souvent aller très vite dans la production avec des développeurs qui ne voudront pas prendre un peu de temps pour se former, effectivement Java est le mauvais choix. Mais dans une optique ou l'on veut améliorer de plus en plus la qualité du code que l'on génère au prix d'un apprentissage peut-être un petit peu plus long alors Java est un bon choix.

Ca n'est pas propre à Java. Tout langage est substituable.
C'est de faire de la qualité qui est le bon choix dans le temps.

[OButterlin]

C'est de faire de la qualité qui est le bon choix dans le temps.

Raisonnement de développeur...
Une société de service (la plupart) se fout royalement de faire de la qualité, elle veut vendre vite et à moindre coût.
L'intérêt de java et de sa plate-forme EE est de miser sur une technologie portable et durable, certainement pas pour sa facilité d'apprentissage... à moins bien sûr qu'on ne parle de langage qui lui est plutôt facile à appréhender.

[B.AF]

J'espére bien qu'en bossant dans l'informatique j'ai un raisonnement de développeur (et j'en suis fier).

Et ce n'est pas vraiment en développeur, mais en entrepreneur :
Faire de la qualité dans le temps ne fait qu'être moins orienté avant vente.

On peut encore vendre, à un prix cohérent et faire des choses correctes. Au contraire, tant qu'il y aura des SSII pour bosser comme ça dans mon secteur, je sais que j'aurai toujours du chiffre. Non seulement je suis sollicité sur des sujets plus "funky", mais en outre, j'ai une tarification qui est en moyenne 35% plus élevée minimum que les SSII.

Je ne vois toujours pas en quoi faire de la qualité coute plus ?
Disons plutôt la réalité :
La plupart des décideurs sont frileux et préférent payer peu longtemps, qu'investir (c'est à dire une mise de départ et un résultat rapide).
Effectivement dans le premier cas, on peut mettre 1 an avant de voir arriver l'échec.

Je trouve que ta remarque prouve bien que le culte du résultat est encore bien en retrait par rapport à celui du process.

Quand on veut réussir, il faut savoir prendre des risques, et cela inclue le risque économique.Et la compétence n'est pas liée exclusivement à la techno.

[tchize_]

Raisonnement de développeur...
Une société de service (la plupart) se fout royalement de faire de la qualité, elle veut vendre vite et à moindre coût.

Ca me rapelle une boite qui voulait nous proposer une solution de gestion documentaire. On leur a demandé comment si ils pouvaient nous garantir que leur solution serait toujours utilisable dans 50 ans, soit la durée légale où nous devons préserver certains documents. La réponse a été cinglante "la pluspart de nos clients sont des PME qui sont content si ils sont encore vivant dans 3 ans, alors on s'est jamais posé la question"

[OButterlin]

Ca me rapelle une boite qui voulait nous proposer une solution de gestion documentaire. On leur a demandé comment si ils pouvaient nous garantir que leur solution serait toujours utilisable dans 50 ans, soit la durée légale où nous devons préserver certains documents. La réponse a été cinglante "la pluspart de nos clients sont des PME qui sont content si ils sont encore vivant dans 3 ans, alors on s'est jamais posé la question"

Je pense que les SSII justifient leurs procédés derrière ce genre de remarques. Le problème vient plutôt qu'elles ne veulent pas payer la compétence, il suffit de regarder les annonces : on demande des capacités d'informaticiens avec 5 ans minimum d'expérience pour un salaire de débutant... SYNTAXE ERROR !
Pour avoir bossé il n'y a pas si longtemps avec une très grosse SSII sur un projet en commun, j'ai vu et écouté les personnes, toutes très jeunes et étonnées par certaines remarques, pourtant assez basiques... ils n'y avaient pas pensé...
Ils reproduisent des mécanismes que d'autres ont mis au point (très compétents ceux-là) sans se poser la question de savoir si c'est judicieux, adapté, etc... au cas présent.

Enfin bref, les SSII sont plus des vendeurs de barbaque qu'autre chose, et d'un autre côté, si les clients achetaient un peu moins un prix qu'un produit, on n'en serait pas là, à "out-sourcer" les développements vers des pays à bas coûts.

Pour B.AF, ne te méprends pas sur mes propos, quand je dis "raisonnement de développeur" ce n'est pas pour le dénigrer, je pense la même chose, mais la réalité de notre monde est toute autre.

[Franck Z]

En fait, quand je lis votre retour d'expérience sur l'utilisation de Java et de son écosystème, j'ai l'impression que le mouvement "open source" pourrait s'attaquer aujourd'hui à une deuxième aliénation du monde informatique.

Historiquement, la première aliénation, ça a été lorsque tout est devenu propriétaire et que pour accéder aux outils de programmation, il fallait faire un investissement réservé aux entreprises à but lucratif.

Aujourd'hui, c'est quand même mieux. Même Microsoft permet d'utiliser ses outils de développement sans avoir à les acheter tant qu'on ne les utilise pas à but lucratif. Le monde libre, est assez proche de cette logique pour peu qu'on respecte la clause "morale" de faire une contribution volontaire au projets open source si on réalise un bénéfice avec ce que ces projets vous ont permis de faire.

Il y a donc aujourd'hui une deuxième aliénation (publicitaire, commerciale, versatilité des frameworks...) à briser, qui fait que le développement des compétences des acteurs en informatique, et donc de la qualité des réalisations, est empêché par tous les mécanismes dont vous parlez.

[larry57]

Bonjour,

Je concède que les applications web java ou autres sont jolies, mais quelle lenteur.... Rien ne vaut les vieilles technologies (mainframe ou system i) à partir du moment oû l'on souhaite faire du volume et ou les coûts de maintenance sont bien inférieur.

Larry57

[Logan Mauzaize]

Je concède que les applications web java ou autres sont jolies, mais quelle lenteur.... Rien ne vaut les vieilles technologies (mainframe ou system i) à partir du moment oû l'on souhaite faire du volume et ou les coûts de maintenance sont bien inférieur.

Concernant le volume, il coûte moins cher d'acheter une équipe de bras cassé qui se dit faire du Java et de s'acheter une ferme de serveur PC qu'une seule machine de test IBM ^^ Sans compter les compétences spécifiques pour l'installation/administration/maintenance de la partie système.
Ensuite je n'ai jamais vu de comparaison entre une même application batch sous IBM et sous un PC. Quand je travaillais dans le mainframe, on traitait des millions de lignes de données mais on en avait pour la semaine pour certains traitements.

Concernant le coût, d'un côté tu as des compétences rares, recherchées et qui tendent à disparaître pour gros système et de l'autre une pléthore de débutants Java auto-formés. Ensuite d'un côté tu as des logiciels relativement simples (si a je fais ça, si b je fais autre chose) et vieux (pas d'évolution et d'autres plus complexes et immatures.
Donc je vois pas trop le côté "moins cher" du gros système.
Si tu devais faire la même chose sur des gros systèmes, la complexité serait exponentielle.

[tchize_]

Je rajoute qu'en ce qui me concerne, en Général, je n'ai pas le choix sur l'architecture, je n'ai de choix que sur mes language. Quand on a pas de mainframe, on fait sans mainframe
Je crois que beaucoup de sociétés sont comme ça. L'architecture est existante, le besoin lui est nouveau. Au codeur de lier les deux.

[larry57]

Concernant le volume, il coûte moins cher d'acheter une équipe de bras cassé qui se dit faire du Java et de s'acheter une ferme de serveur PC qu'une seule machine de test IBM

Effectivement, je concède que les tarifs d'IBM sont excéssifs. Mais tu as les mêmes problèmes si tu utilises WAS où le coût de la licence est prohibitif.
Pour ce qui est de la programmation java, il y a autant de méthode de programmer que de développeur. Et cela, je l'ai souvent constaté.

Si tu devais faire la même chose sur des gros systèmes, la complexité serait exponentielle.

Pas d'accord, prenons l'exemple du system i, les dernières versions de l'os permettent de faire du java, de l'xml... La partie logiciel évolue encore.

Larry57

[Logan Mauzaize]

Effectivement, je concède que les tarifs d'IBM sont excéssifs. Mais tu as les mêmes problèmes si tu utilises WAS où le coût de la licence est prohibitif.

Normal c'est IBM :p

Pour ce qui est de la programmation java, il y a autant de méthode de programmer que de développeur. Et cela, je l'ai souvent constaté.

C'est le problème des débutant et/ou auto-formés. Tout bon développeur devrait s'adapter à l'environnement dans lequel il travaille.

Pas d'accord, prenons l'exemple du system i, les dernières versions de l'os permettent de faire du java, de l'xml... La partie logiciel évolue encore.

Bien vu ! Tous les gros systèmes que j'avais vu fonctionnait sous C/COBOL, je pensais qu'ils en étaient restés là.

[OButterlin]

il y a aussi RPG sur les gros systèmes IBM, extrêmement robuste, fiable, performant... le seul problème est de trouver les compétences sur ces vieux langages...
Pour bien connaître les 2 mondes, force est de constater que c'est beaucoup plus fiable de faire tourner un programme RPG que l'équivalent java au travers des couches EJB/JPA/JTA etc...
mais bon, d'un point de vue coût...