Java est-il un choix coûteux pour les entreprises ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

20/03/2011, 14h15
ego

Citation:

Envoyé par damien.charpentier

la JSR 303 defini un standard pour une application en Java (de la couche presentation jusqu'au DAO). Ce n'est pas de la responsabilite de cette specification de gerer des technologies completement differentes (comme une base de donnees). Il faudrait se tourner vers des editeurs qui fournissent ce genre de support. JSF 2 supporte la Bean Validation pour verifier la bonne saisie des champs.

Tu vois damien, c'est un peu ça le problème de l'informatique. J'ai simplement donné un exemple pour illustrer mon propos et toi (mais tu n'es pas le seul) tu me parles de détails et du fait que ce n'est pas le rôle de l'un mais de l'autre.
Il est justement là le problème, c'est à dire l'approche globale.

Encore une fois, prenons un exemple avec les WebServices. On, je veux dire la communauté informatique, c'est empressé de développer cet aspect alors que l'on avait déjà des trucs comme les EJBs. Pourquoi avoir dépensé beaucoup d'énergie à inventer encore une technique de communication au lieu de tenter de résoudre des problèmes plus globaux comme le lien IHM-Métier-BDD ? Encore une fois, la profusion de technos est peut être un point intéressant mais au lieu de développer 50 solutions pour résoudre la même problématique, on pourrait essayer de consolider 2 ou 3 solutions et surtout aborder des problématiques que personne ne veut aborder.

Et vous savez que c'est là que réside la force de Microsoft = ils proposent une solution globale, outillée. Avec eux, on ne se fait pas de noeuds au cerveau et la formation des développeurs est "plus simple" car on sait ce qu'ils vont devoir utiliser.
Pour information, je suis du monde Java et ne connait pas les technos Microsoft. Cependant, je me rend compte que la profusion nuit forcément à la clareté.
20/03/2011, 16h07
thelvin

Citation:

Envoyé par ego

Encore une fois, prenons un exemple avec les WebServices. On, je veux dire la communauté informatique, c'est empressé de développer cet aspect alors que l'on avait déjà des trucs comme les EJBs. Pourquoi avoir dépensé beaucoup d'énergie à inventer encore une technique de communication au lieu de tenter de résoudre des problèmes plus globaux comme le lien IHM-Métier-BDD ?

Parce que les EJBs manquaient de souplesse pour les échanges PHP-Ruby ?

Citation:

Et vous savez que c'est là que réside la force de Microsoft = ils proposent une solution globale, outillée.

C'est sûr que quand on peut se permettre de ne se parler qu'à soi-même, même machine, mêmes programmes, de manière générale mêmes fournisseurs, on peut faire des trucs de ce genre.
Mais à ce niveau-là, il suffit de choisir un seul framework Java, dire merde aux autres, et prendre une solution intégrée clé-en-main qui se base sur ce framework : on obtient la même chose.
Forcément, il ne sera pas apte à communiquer avec autre chose sans sortir de l'intégration prémâchée.
20/03/2011, 16h51
ego

Citation:

Envoyé par thelvin

Parce que les EJBs manquaient de souplesse pour les échanges PHP-Ruby ?

C'est sûr que quand on peut se permettre de ne se parler qu'à soi-même, même machine, mêmes programmes, de manière générale mêmes fournisseurs, on peut faire des trucs de ce genre.
Mais à ce niveau-là, il suffit de choisir un seul framework Java, dire merde aux autres, et prendre une solution intégrée clé-en-main qui se base sur ce framework : on obtient la même chose.
Forcément, il ne sera pas apte à communiquer avec autre chose sans sortir de l'intégration prémâchée.

Ruby, je sais pourquoi on a investigué autre chose que les EJB, c'est simplement pour dire qu'il y a bien d'autres problèmes à résoudre que des problèmes techniques.
Est-ce que Microsoft propose autant de frameworks pour faire des IHM que ce que l'on a dans le monde Java ?
Ce que je pointe du doigt n'est pas la légitimité ou non de telle techno mais le fait que quand la communauté traite un problème elle n'en traite pas un autre. Et comme par hasard, on traite bien trop souvent des problématiques techniques, je ne sais pas trop pourquoi, peut être parce que c'est plus "noble" ? plus "cool" ?.
Et même en traitant certains problèmes un peu moins techniques comme la Validation des beans, on rigole du résultat obtenu. Car valider un objet c'est :
1- valider chaque attribut
2- puis valider l'objet lui-même (règles inter-attributs)
3- puis valider l'objet vis-à-vis de son environnement (règles inter-objets)
4- bien entendu quand on récupère une grappe d'objets (DTO) on valide d'abord les données unitairement (le 1) puis les objets individuels (le 2) et le 3 ensuite.
5- les règles doivent être déclenchées bien entendu uniquement si les données sur lesquelles la règle porte sont modifiées (comment le détecter ? SDO en parle, on peut fabriquer sa propre solution)
6- certaines règles ne sont déclenchables qu'à un moment du cycle de vie de l'objet (création, modification, suppression)

On en parle où de tout ça dans la JSR ?

Même remarque sur le nombre astronomique de langages, et là Java n'y est pour rien. C'est plus "rigolo" de créer un langage que de traiter des problèmes de fond. Des têtes bien faites dépensent de l'énergie à inventer une nouvelle syntaxe alors qu'elles pourraient travailler sur autre chose.
20/03/2011, 22h48
thelvin

Citation:

Envoyé par ego

Ruby, je sais pourquoi on a investigué autre chose que les EJB, c'est simplement pour dire qu'il y a bien d'autres problèmes à résoudre que des problèmes techniques.

Ça suffit. Ton exemple ne marche pas.
Les EJBs sont un système de communication interne à Java (et tous les langages en ont au moins un fourni avec, un "canonique", et plein fourni par des tiers.) Les webservices sont interlangages et n'ont pas d'affinité particulière avec Java. C'est tout.

Pour le reste, il y a du vrai, et en effet quand je commençais dans le métier je n'arrivais pas à choisir seul dans tout ce bazar, j'avais besoin que mes aînés décident et m'expliquent pourquoi.
Apparemment tu prétends que sur d'autres plate-formes, c'est moins le cas. Moais. Je connais d'autres (vieux) langages, autres que Java, et ils étaient exactement pareil, bien qu'avec moins de choses pleines de hype fournies par des tiers. Après, il est vrai qu'entre-temps, les approches webservices ont explosé, et que maintenant on parle du cloud.
20/03/2011, 23h40
B.AF

Le Web Service, ce n'est que de la sérialisation XML (Ou autre si on considére REST, JSON...). L'EJB n'est pas incompatible avec ça.
La seule différence est que par nature un web service est stateless.

Le Web service, ça reste quand même l'escroquerie architecturale de la décennie d'un point de vue architecture. C'est une vision marketing du paquet TCP. Sauf que pour beaucoup de gens; avec du XML, un XSD et les WS-i, le W3C, et du http, c'est très bien. Pire on en est même arrivé au Rest, qui est la vraie régression (dire qu'un service get ou post sur htpp; on ne peut pas dire que c'est une révolution).

Et aujourd'hui, les architectures multi techno, je fais plus. C'est trop de temps perdu en plomberie.

Mais c'est certain le web service hello world n'a aucune affinité avec le langage. Comme toute les technos : tant que l'exemple est trivial, la techno semble magique.
21/03/2011, 09h51
OButterlin

Citation:

Envoyé par B.AF

Le Web service, ça reste quand même l'escroquerie architecturale de la décennie d'un point de vue architecture. C'est une vision marketing du paquet TCP. Sauf que pour beaucoup de gens; avec du XML, un XSD et les WS-i, le W3C, et du http, c'est très bien. Pire on en est même arrivé au Rest, qui est la vraie régression (dire qu'un service get ou post sur htpp; on ne peut pas dire que c'est une révolution).

C'est brut de fonderie comme affirmation 8O

Le web service n'est pas une escroquerie, loin s'en faut lorsqu'on veut utiliser la même logique métier pour des clients utilisant d'autres langages que java.
Là où je suis partiellement d'accord, c'est quand on utilise un web service écrit à partir d'un EJB dans une application java...
21/03/2011, 10h44
thelvin

Citation:

Envoyé par B.AF

Le Web Service, ce n'est que de la sérialisation XML (Ou autre si on considére REST, JSON...). L'EJB n'est pas incompatible avec ça.

Discutable... Dans ton sens. C'est-à-dire que ce que tu dis est vaguement défendable.
Mais à la base, les EJBs sont 100% couplés à Java, alors que les webservices sont faiblement couplés au web, et à rien d'autre. La différence de généricité et de pluralité cause de nombreux points de mésentente entre les deux.

Pour le reste, mais oui, mais oui. Pourquoi on est pas tous restés sur le binaire, c'était très bien. D'ailleurs, on aurait parfaitement réussi à mettre toutes les technos d'accord sur une seule vue binaire des choses, et à la base c'est de cette question-là qu'on parle.
21/03/2011, 11h18
B.AF

C'est brutal mais ça reste vrai.

Si tu regardes bien, TCP est une techno simple, éprouvée, qui a aussi ses défauts de sécurité (en même temps comparée à Http et au marché du certificats...); qui permet un transport simple, uniforme, multi technologie, des messages standardisés. En plus Http n'est qu'un subside de TCP.

Donc avant tu avais une technologie qui te permet d'avoir un serveur dans n'importe quelle technologie qui échange un message avec un client dans n'importe quelle techno (synchrone ou non), avec des options de sécurité et surtout un message normalisé et une gestion d'état (qui permet in fine de faire un dialogue fonctionnel).

Aujourd'hui tu as une technologie qui te permet d'utiliser une autre technologie qui échange un message avec un client dans éventuellement une autre technologie à condition que les proxy puissent être partagés (et autant dire qu'il faut que ça reste simple) et sans étant, avec une sécurité assez complexe à gérer et pas si portable, le tout sans état. D'ailleurs maintenant, il y a le SML qui permet de définir le modéle. Finalement n'étant pas si pratique et interopérable, on tombe...
Dans JSON pour finalement consommer du Web Service dans le navigateur depuis Jscript (...); voir faire du "RestFul" et lire...Un fichier text, ce qui nous raméne au point du TCP, puisque c'est de header Http. (Donc finalement....)

Rien à dire, le web service, c'est un vrai progrés...:ccool:
:mouarf: (Je reconnnais, c'est sarcastique)
21/03/2011, 11h21
B.AF

Citation:

Envoyé par thelvin

Discutable... Dans ton sens. C'est-à-dire que ce que tu dis est vaguement défendable.
Mais à la base, les EJBs sont 100% couplés à Java, alors que les webservices sont faiblement couplés au web, et à rien d'autre. La différence de généricité et de pluralité cause de nombreux points de mésentente entre les deux.

Ce que je voulais dire c'est que faire des EJB et du Web Service n'a pas de rapport logique. Un EJB reste un objet java, et le web service reste juste un transport. Qu'il soit EJB ou autre, le but du jeu reste de transporter une image d'un objet.
21/03/2011, 20h10
ego

Vous voyez messieurs, c'est reparti, on essaye de prendre de la hauteur et en fait on retombe dans des débats stériles pour technophobes.

Encore une fois, ce n'était qu'un exemple pour essayer de vous montrer que l'on aborde trop les problèmes de plomberie et pas assez les problèmes réels de conception applicative de manière globale de A à Z.
21/03/2011, 22h43
B.AF

Je crois qu'à trop chercher tes formules, tu en as oublié la conception globale de a à z de ton post :mrgreen::mrgreen:

En même temps les débats stériles de technoPHOBES sur un site qui se nomme développez.com, c'est une tautologie.

Et quand tu parles de problèmes de conception globale, c'est justement qu'il faudrait arrêter de faire de la conception avec des choix uniquement techniques réputés ouverts pour éviter de choisir et faire "comme tout le monde".

De la même façon je trouve insupportable ceux qui ne résonnent qu'en relationnel ou en SQL.

Il y a deux chose dangereuses en architecture logicielle :
- Les dogmes, comme le couplage faible, les couches, les services
- Les modes, comme les web services
22/03/2011, 09h29
batataw

Citation:

Envoyé par ego

Vous voyez messieurs, c'est reparti, on essaye de prendre de la hauteur et en fait on retombe dans des débats stériles pour technophobes.

Encore une fois, ce n'était qu'un exemple pour essayer de vous montrer que l'on aborde trop les problèmes de plomberie et pas assez les problèmes réels de conception applicative de manière globale de A à Z.

Je partage ton avis, c'est reparti encore une fois sur des débats hyper techniques qui s'éloignent du sujet principale. Ca n'intéresse guère que les plombiers.

Je pense que tu voulais dire technophile.
22/03/2011, 09h36
batataw

Citation:

Envoyé par B.AF

En même temps les débats stériles de technoPHOBES sur un site qui se nomme développez.com, c'est une tautologie.

Pour le coup s'en est pas une :P
22/03/2011, 10h21
thelvin

C'est bien gentil de vouloir prendre de la hauteur, mais il ne faut pas trop se croire bon dans l'art d'y amener les gens. En réalité des exemples très concrets ont été abordés dans cette tentative, et ils vont dans le sens de "Java coûte cher machin" ou dans l'autre sens. C'est tout.

Ceci pour une raison très simple, c'est la même que pour obtenir la paix, la sécurité et le bonheur de tous les êtres.
Résoudre à la fois tous les problèmes des technologies de développement, c'est probablement impossible, et au mieux c'est tellement difficile qu'on n'arrive pas vraiment à l'aborder. Ça nécessite encore beaucoup de temps d'évolution. À moins que la longévité soit significativement augmentée au cours de notre vie, nous ne verrons jamais une chose pareille.
Ça ne signifie pas qu'on doit renoncer à essayer, seulement c'est extrêmement compliqué et ce n'est pas avec des raccourcis qu'on va décrire ses idées. D'ailleurs il y a deux questions qui sont distinctes mais interdépendantes :
- Quel genre de technologie résoudrait les problèmes actuellement observés et prédits ?
- Comment les faire adopter par le monde ?

Et pour l'amour du ciel qu'on vienne pas me dire "mais moi je prétends pas que j'ai la solution, je dis juste que ça et ça c'est un problème." Les problèmes ont toujours des origines, c'est un prêté pour un rendu, tout le temps. On peut tant qu'on veut trouver qu'il aurait mieux valu pas avoir le prêté vu le rendu qu'on se paie, mais ça ça dépend des besoins. Des besoins il y en a autant que d'idées de réalisations, ils sont adressés de différentes manières, plus ou moins dans le détail, qui colleront plus ou moins avec l'idéal. Mais nier la multitude des besoins c'est chercher à stagner et le monde ne le fera pas pour vous. Personnellement je pense qu'il a bien raison.

Ça vous va, ça, comme hauteur prise ?
22/03/2011, 10h55
B.AF

Citation:

Envoyé par batataw

Je partage ton avis, c'est reparti encore une fois sur des débats hyper techniques qui s'éloignent du sujet principale. Ca n'intéresse guère que les plombiers.

Je pense que tu voulais dire technophile.

C'est quand même dingue de lire autant de condescendance. :no:
Quant à des débats hyper techniques, excuses moi mais on parle de sujet quand même très généraux et pas très complexes.:ave:
Je pourrais te dire que si tu trouves ça hyper technique, il serait utile de ré-évaluer ta notion d'hyper:aie:

Un débat stérile pour technophobes sur un site de développement, dire qu'il n'a pas sa place, c'est bien un tautologie.
Enfin je concéde que le technophobe ici n'a pas vraiment sa place.

Ou avec la plèbe plombiére ????:mouarf:
22/03/2011, 11h51
batataw

Java est-il un choix coûteux pour les entreprises ?

Citation:

Envoyé par thelvin

C'est bien gentil de vouloir prendre de la hauteur, mais il ne faut pas trop se croire bon dans l'art d'y amener les gens. En réalité des exemples très concrets ont été abordés dans cette tentative, et ils vont dans le sens de "Java coûte cher machin" ou dans l'autre sens. C'est tout.

Webservice vs EJB. Je n'ai rien contre des exemples mais franchement on s'éloigne du sujet. D'autant plus que les Webservices ne sont pas propres à Java.

Je pensais qu'on parlerait d'architecture globale, des frameworks, d'agilité, des cycles de développement, des coûts, la verbosité...
- Pourquoi les boites choisissent Java ?
- Les courbes d'apprentissage des différents Framework ?
- Les performances globales.
- Coût d'un Dev Java vs Dev .NET vs C++ vs PHP
- Pourquoi Scala cartonne
- Les défauts de Java

Citation:

Envoyé par B.AF

C'est quand même dingue de lire autant de condescendance. :no:
Quant à des débats hyper techniques, excuses moi mais on parle de sujet quand même très généraux et pas très complexes.:ave:
Je pourrais te dire que si tu trouves ça hyper technique, il serait utile de ré-évaluer ta notion d'hyper:aie:

"Très généraux", non ils sont spécifiques. Je n'ai pas parlé de complexité mais contrairement à toi je pense qu'on s'éloigne du sujet avec cette histoire d'EJB.S
22/03/2011, 12h55
B.AF

EJB ? Annotation ? Tests ? Couches ? Multiplication des frameworks ?
Je suis ravi pour toi si tu peux aujourd'hui créer des bus de service sans overhead.:aie:

Citation:

Envoyé par batataw

Webservice vs EJB. Je n'ai rien contre des exemples mais franchement on s'éloigne du sujet. D'autant plus que les Webservices ne sont pas propres à Java.

Justement, quel est le point architectural de privilégier une exposition spécifique ou universelle ? Quels sont les risques ? Est-ce que le WS est la réponse ? Est-ce que l'EJB est un élément technique ou un élement structurant dans une architecture Java distribuée? Quelles sont les raisons qui devraient mener à choisir des Web services ?

Citation:

Envoyé par batataw

- Pourquoi les boites choisissent Java ?

Et quelles solutions si elles n'ont pas choisi QUE java ? Ce qui reste le cas majoritaire.

Citation:

Envoyé par batataw

- Les courbes d'apprentissage des différents Framework ?
- Les performances globales.

Et ça n'a rien à voir avec la multiplication des frameworks dans l'architecture et l'approche technologique ?
Apprendre la persistence, c'est différent pour un guru SQL et un noob en développement, l'approche MVC est différente entre un architecte qui se penche sur le pattern et le développeur qui en utilise une implémentatio dans un framework. Pire que ça, il y a les design fondamentaux : API, Services, composants, programmation par convention, para / multithread...
Il y a aussi les contaminations entre les frameworks :
- Dépendances logicielles
- Multiplication des équivalences (n versions du même framework, ou de fraemwork équivalent mais liés à d'autres framework)
- Fermeture technologique (faut-il un framework qui fasse tout - spring - ou un framework dont les responsabilités sont définies - guice)
- Fermeture intellectuelle : faut-il n'utiliser qu'un ORM ou faut-il moduler l'approche en fonction des cas ?
....

Concernant les performances, sur quelle base ??? C'est le doux rêve du benchmark universel.
La seule performance valable est celle d'usage. Je ne connais pas un seul vrai architecte qui sacrifiera la perf de l'appli au profit de modes architecturales douteuses. (Comme la prolifération des interfaces ou des aspects)

Citation:

Envoyé par batataw

- Coût d'un Dev Java vs Dev .NET vs C++ vs PHP

Question stupide. Coût du choix de l'architecture. Le coût du développement en Java lui même est économiquement non intéressant.
La vraie question de ce sujet est de dire : quel est le coût réel d'une architecture ouverte basée sur des frameworks hétérogénes et une architecture fermée basée sur un développement local. Quelle que soit la technologie. On ne fera pas du Web en C++, ni du calcul intensif en PHP, on ne fera pas de la progfonctionnelle en Java, on ne fera pas un client lourd en php....Sauf à considérer qu'il n'existe qu'une seule architecture viable qui existe pour ces 3 technos, voir pour toutes les technos, c'est juste une question polémique.

Quels avantages dans cette configuration offre la plateforme java ?
- Uniformité entre applications Java --> EJB
- Interopérabilité --> Web Services

Citation:

Envoyé par batataw

- Pourquoi Scala cartonne

C'est vrai que choisir Scala sur la JVM n'est pas technique et que de savoir qu'il y a une mode autour de ce langage est un point de très haut niveau dans une conception logicielle....:aie:

Citation:

Envoyé par batataw

- Les défauts de Java

Non, le sujet, c'est au dessus de Java, c'est le coût réel des architectures objet basées sur des technologies libres / ouvertes.
Là où le sujet tombe à l'eau, c'est qu'aucun framework ne peut :
- Créer de la logique métier
- Anticiper un comportement métier
- Créer de la valeur fonctionnelle immédiate
Java n'a pas de défauts. Comme toutes les techno, il a son sweet spot et sa zone d'inutilité ou d'improductivité et ses manques. Java est et reste une technologie majeure, riche et fiable. Sauf que sa richesse devient son talon d'Achille dans le temps car c'est une richesse éparpillé car communautaire.

Avant de prendre de la hauteur, il faut savoir prendre du recul:ccool:
22/03/2011, 19h00
ego

Citation:

Envoyé par B.AF

Je crois qu'à trop chercher tes formules, tu en as oublié la conception globale de a à z de ton post :mrgreen::mrgreen:

En même temps les débats stériles de technoPHOBES sur un site qui se nomme développez.com, c'est une tautologie.

Et quand tu parles de problèmes de conception globale, c'est justement qu'il faudrait arrêter de faire de la conception avec des choix uniquement techniques réputés ouverts pour éviter de choisir et faire "comme tout le monde".

De la même façon je trouve insupportable ceux qui ne résonnent qu'en relationnel ou en SQL.

Il y a deux chose dangereuses en architecture logicielle :
- Les dogmes, comme le couplage faible, les couches, les services
- Les modes, comme les web services

je suis tout à fait d'accord avec toi
22/03/2011, 19h06
ego

Citation:

Envoyé par thelvin

C'est bien gentil de vouloir prendre de la hauteur, mais il ne faut pas trop se croire bon dans l'art d'y amener les gens. En réalité des exemples très concrets ont été abordés dans cette tentative, et ils vont dans le sens de "Java coûte cher machin" ou dans l'autre sens. C'est tout.

Ceci pour une raison très simple, c'est la même que pour obtenir la paix, la sécurité et le bonheur de tous les êtres.
Résoudre à la fois tous les problèmes des technologies de développement, c'est probablement impossible, et au mieux c'est tellement difficile qu'on n'arrive pas vraiment à l'aborder. Ça nécessite encore beaucoup de temps d'évolution. À moins que la longévité soit significativement augmentée au cours de notre vie, nous ne verrons jamais une chose pareille.
Ça ne signifie pas qu'on doit renoncer à essayer, seulement c'est extrêmement compliqué et ce n'est pas avec des raccourcis qu'on va décrire ses idées. D'ailleurs il y a deux questions qui sont distinctes mais interdépendantes :
- Quel genre de technologie résoudrait les problèmes actuellement observés et prédits ?
- Comment les faire adopter par le monde ?

Et pour l'amour du ciel qu'on vienne pas me dire "mais moi je prétends pas que j'ai la solution, je dis juste que ça et ça c'est un problème." Les problèmes ont toujours des origines, c'est un prêté pour un rendu, tout le temps. On peut tant qu'on veut trouver qu'il aurait mieux valu pas avoir le prêté vu le rendu qu'on se paie, mais ça ça dépend des besoins. Des besoins il y en a autant que d'idées de réalisations, ils sont adressés de différentes manières, plus ou moins dans le détail, qui colleront plus ou moins avec l'idéal. Mais nier la multitude des besoins c'est chercher à stagner et le monde ne le fera pas pour vous. Personnellement je pense qu'il a bien raison.

Ça vous va, ça, comme hauteur prise ?

Ben disons que bof bof
Je ne nie pas la multitude des besoins mais je constate simplement que l'on a très peu, voir pas du tout de solutions tout intégrées comme on a pû avoir à l'époque des L4G. Et sans vouloir refaire des L4G, je trouve qu'il y a encore une marge entre les frameworks unitaires que l'on peut trouver et un semblant de liant entre tout ça.
22/03/2011, 21h59
lequebecois79

Ce mec ne sort pas grand chose de nouveau....

Java a permis de faire de grosses économies de temps en terme de développement, après si aucun suivi n'est fait au niveau de la qualité, c'est à se demander ce que fait le DSI, chargé de projet et architecte...

Qu'une entreprise décide de faire son propre framework, ça prendra beaucoup de temps quel que soit le langage.

La très grande diversité de Java démontre qu'il n'y a pas une seul réponse à un problème.
Lorsqu'un choix est fait au niveau d'un IDE, librairie ou framework, il faut un minimum se renseigner, voir ses possibilités et non les prendre car ils sont à la mode.... Faut voir si on a intérêt à les employer...

Je crois que cette étape est très souvent négligée.... après il y a blâme... faut que les DSI commencent à assumer leurs responsabilités.
23/03/2011, 10h27
batataw

Citation:

Envoyé par B.AF

EJB ? Annotation ? Tests ? Couches ? Multiplication des frameworks ?
Je suis ravi pour toi si tu peux aujourd'hui créer des bus de service sans overhead.:aie:

Là je n'ai pas compris mais c'est pas grave, çà dois être trop savant pour moi. Premièrement les questions que j'ai posées n'étaient pas là forcément pour que tu te jettes dessus. C'était plus pour ré-orienter le débat qui devenait trop technique par rapport au sujet initial.

Citation:

Envoyé par B.AF

Justement, quel est le point architectural de privilégier une exposition spécifique ou universelle ? Quels sont les risques ? Est-ce que le WS est la réponse ? Est-ce que l'EJB est un élément technique ou un élement structurant dans une architecture Java distribuée? Quelles sont les raisons qui devraient mener à choisir des Web services ?

Excuse moi mais si tu t'arrêtes sur chaque composant de Java, c'est sans fin. XML, REST, Couche TCP, SQL...voici ce qui a été abordés dans les posts précédentes. Franchement on s'éloigne du sujet. Après on peut toujours ouvrir une autre file pour en discuter.

Citation:

Envoyé par B.AF

Et quelles solutions si elles n'ont pas choisi QUE java ? Ce qui reste le cas majoritaire.

Ca mérite d'être approfondi, comment ce fait le choix d'une techno dans un S.I. CQFD le choix de Java dans notre cas.

Citation:

Envoyé par B.AF

Et ça n'a rien à voir avec la multiplication des frameworks dans l'architecture et l'approche technologique ?
Apprendre la persistence, c'est différent pour un guru SQL et un noob en développement, l'approche MVC est différente entre un architecte qui se penche sur le pattern et le développeur qui en utilise une implémentatio dans un framework. Pire que ça, il y a les design fondamentaux : API, Services, composants, programmation par convention, para / multithread...
Il y a aussi les contaminations entre les frameworks :
- Dépendances logicielles
- Multiplication des équivalences (n versions du même framework, ou de fraemwork équivalent mais liés à d'autres framework)
- Fermeture technologique (faut-il un framework qui fasse tout - spring - ou un framework dont les responsabilités sont définies - guice)
- Fermeture intellectuelle : faut-il n'utiliser qu'un ORM ou faut-il moduler l'approche en fonction des cas ?
....

Là on est dans le vif du sujet dommage que tu n'appronfondis pas :(

Citation:

Envoyé par B.AF

Concernant les performances, sur quelle base ??? C'est le doux rêve du benchmark universel.
La seule performance valable est celle d'usage. Je ne connais pas un seul vrai architecte qui sacrifiera la perf de l'appli au profit de modes architecturales douteuses. (Comme la prolifération des interfaces ou des aspects)

Sans aller jusqu'au Benchmark universel, on sait dire aujourd'hui chiffre à l'appuie si une solution est couteuse ou non. L'usage je veux bien mais il faut avoir quelques certitudes avant de se lancer sinon tes usagers vont s'étrangler devant leur clavier.

Citation:

Envoyé par B.AF

Question stupide. Coût du choix de l'architecture. Le coût du développement en Java lui même est économiquement non intéressant.
La vraie question de ce sujet est de dire : quel est le coût réel d'une architecture ouverte basée sur des frameworks hétérogénes et une architecture fermée basée sur un développement local. Quelle que soit la technologie. On ne fera pas du Web en C++, ni du calcul intensif en PHP, on ne fera pas de la progfonctionnelle en Java, on ne fera pas un client lourd en php....Sauf à considérer qu'il n'existe qu'une seule architecture viable qui existe pour ces 3 technos, voir pour toutes les technos, c'est juste une question polémique.

Quels avantages dans cette configuration offre la plateforme java ?
- Uniformité entre applications Java --> EJB
- Interopérabilité --> Web Services

Arf, c'est forcément à projet équivalent, ça va de soit non?
Ca valait le coût de comparer 2 projets équivalents et de voir les plus et les moins de chaque technos. J'ai eu des retours terrains parfois des gens qui ont regrettés d'avoir choisi tel ou tel technos.

Citation:

Envoyé par B.AF

C'est vrai que choisir Scala sur la JVM n'est pas technique et que de savoir qu'il y a une mode autour de ce langage est un point de très haut niveau dans une conception logicielle....:aie:

Oui cette question est plutôt technique mais t'es pas obliger de pondre du code tout de suite. On peut discuter de pourquoi ce langage existe, Java serait-il trop compliqué, trop verbeux ou inaccessible pour certains...

Citation:

Envoyé par B.AF

Non, le sujet, c'est au dessus de Java, c'est le coût réel des architectures objet basées sur des technologies libres / ouvertes.
Là où le sujet tombe à l'eau, c'est qu'aucun framework ne peut :
- Créer de la logique métier
- Anticiper un comportement métier
- Créer de la valeur fonctionnelle immédiate
Java n'a pas de défauts. Comme toutes les techno, il a son sweet spot et sa zone d'inutilité ou d'improductivité et ses manques. Java est et reste une technologie majeure, riche et fiable. Sauf que sa richesse devient son talon d'Achille dans le temps car c'est une richesse éparpillé car communautaire.

Java n'a pas de défauts, t'as tout dit là...le mec pond un article pour expliquer le contraire.

Citation:

Envoyé par B.AF

Avant de prendre de la hauteur, il faut savoir prendre du recul:ccool:

Jolie formule, certains sont beaucoup trop près de leur clavier.
23/03/2011, 14h17
B.AF

Pour moi, il n'y a pas de gens trop proches ou trop loins du clavier.

Il y a ceux qui savent que pour faire une architecture optimale; il faut deux éléments :
- Le premier c'est la connaissance fonctionnelle nécessaire pour lever l'ambiguité de la modélisation métier
- La seconde c'est la connaissance technique nécessaire à orchestrer la modélisation métier dans un contexte d'utilisation.

Une plateforme n'a pas UNE architecture mais une somme d'architectures. Ce qui est important ce n'est pas que l'on puisse combiner les architectures, c'est que la conception soit centralisée.

Quand je dis que Java n'a pas de défaut, je le pense, je pense que le défaut c'est plutôt ceux qui s'en servent sans maitriser. C'est comme si on devait dire la langue Française a des défauts; alors que c'est dans l'usage qu'il y a des problèmes.

Quand tu parles Français, tu as le choix de parler verlan par exemple, mais ce n'est pas la bonne solution pour trouver un emploi et faire une bonne impression dans la société, en revanche, c'est possible, et les problèmes liés à l'usage du "Framework Verlan" ne sont pas dus à la langue française, mais à son contexte d'usage.
23/03/2011, 14h31
B.AF

Citation:

Envoyé par batataw

Excuse moi mais si tu t'arrêtes sur chaque composant de Java, c'est sans fin. XML, REST, Couche TCP, SQL...voici ce qui a été abordés dans les posts précédentes. Franchement on s'éloigne du sujet. Après on peut toujours ouvrir une autre file pour en discuter.

Oui parce que c'est là qu'est le loup. Quand on aura un jour compris que Java ce n'est pas Spring, ce n'est pas Hibernate, ce n'est pas JBoss, ce n'est pas Tomcat, ce n'est pas Strut; ce sera une GRANDE avancée.

Java, c'est une technologie. Et tous les jours on méprend son usage (faire du java) avec son emploi (faire du java avec des frameworks tiers).

Utiliser Spring, ce n'est pas faire du Java. C'est faire du Spring. C'est une API particuliére, avec une fonction particuliére, ses bugs, ses fonctionnalités, sa sédimentation et surtout UNE vision de Java. Pas LA vision de Java.

Ce que je dis est très simple : aujourd'hui faire des Web services ou des EJB, ce n'est pas faire du java, c'est faire un choix technique d'usage en employant des API existantes. Si ces api sont incompatibles, ca n'invalide pas Java. Ca invalide juste le processus qui améne le choix.

Pour utiliser Java j'ai besoin de :
- Un éditeur de texte
- Le compilo

Pour le reste, je prends le parti de prendre le résultat du travail d'autrui (payé ou non) et de faire l'ingenierie par assemblage.

Le choix de l'IDE, du gestionnaire de source, du faire du JSF, du JPA, du JDO, du Seams, du Guice, du Clojure, du drools, du tarabiscotta; c'est mon choix de productivité Java.

Si avec le choix de la techno et des outils que j'assume je ne produis pas le bon résultat, c'est que le problème vient de moi en tant qu'architecte.
Soit je n'ai pas cerné le sujet, soit j'ai utilisé des composants que je ne maitrise pas, soit même j'ai choisi la mauvaise techno.

Mais au milieu de ça, je ne peux pas reprocher à Java d'avoir des défauts car ça voudrait dire que j'ai utilisé un techno fondamentale pour faire une architecture sans en comprendre les risques.

Et typiquement; ça veut souvent dire que le paradigme objet n'est pas correctement mis en oeuvre. Ce qui signifie aussi qu'avec un autre langage, le résultat serait strictement identique.

Et c'est aussi le défaut des vendeurs de techno : ils vendent la derniére techno comme étant la meilleure, tout le monde s'engouffre et les platres ne peuvent pas toujours s'essuyer.
23/03/2011, 16h07
OButterlin

Citation:

Envoyé par B.AF

Oui parce que c'est là qu'est le loup. Quand on aura un jour compris que Java ce n'est pas Spring, ce n'est pas Hibernate, ce n'est pas JBoss, ce n'est pas Tomcat, ce n'est pas Strut; ce sera une GRANDE avancée.

Java, c'est une technologie. Et tous les jours on méprend son usage (faire du java) avec son emploi (faire du java avec des frameworks tiers).

Utiliser Spring, ce n'est pas faire du Java. C'est faire du Spring. C'est une API particuliére, avec une fonction particuliére, ses bugs, ses fonctionnalités, sa sédimentation et surtout UNE vision de Java. Pas LA vision de Java.

Ce que je dis est très simple : aujourd'hui faire des Web services ou des EJB, ce n'est pas faire du java, c'est faire un choix technique d'usage en employant des API existantes. Si ces api sont incompatibles, ca n'invalide pas Java. Ca invalide juste le processus qui améne le choix.

Pour utiliser Java j'ai besoin de :
- Un éditeur de texte
- Le compilo

Pour le reste, je prends le parti de prendre le résultat du travail d'autrui (payé ou non) et de faire l'ingenierie par assemblage.

Le choix de l'IDE, du gestionnaire de source, du faire du JSF, du JPA, du JDO, du Seams, du Guice, du Clojure, du drools, du tarabiscotta; c'est mon choix de productivité Java.

Si avec le choix de la techno et des outils que j'assume je ne produis pas le bon résultat, c'est que le problème vient de moi en tant qu'architecte.
Soit je n'ai pas cerné le sujet, soit j'ai utilisé des composants que je ne maitrise pas, soit même j'ai choisi la mauvaise techno.

Mais au milieu de ça, je ne peux pas reprocher à Java d'avoir des défauts car ça voudrait dire que j'ai utilisé un techno fondamentale pour faire une architecture sans en comprendre les risques.

Et typiquement; ça veut souvent dire que le paradigme objet n'est pas correctement mis en oeuvre. Ce qui signifie aussi qu'avec un autre langage, le résultat serait strictement identique.

Et c'est aussi le défaut des vendeurs de techno : ils vendent la derniére techno comme étant la meilleure, tout le monde s'engouffre et les platres ne peuvent pas toujours s'essuyer.

Je suis d'accord sur le fond, il y a un problème d'assimilation du langage java avec les apis (EE/SE).

Je pense que java (langage) n'a pas de gros défaut, il a ses contraintes, comme d'autres langages ont les leurs.

Ce n'est pas java qui manque de productivité, le choix des outils par contre :aie:
23/03/2011, 16h32
B.AF

Citation:

Envoyé par OButterlin

Je pense que java (langage) n'a pas de gros défaut, il a ses contraintes, comme d'autres langages ont les leurs.

En langage pur, non il n'a pas de gros défauts. Une grosse contrainte plus que défaut pour moi est la gestion des accesseurs et mutateurs. En revanche, sur le langage pur, les annotations et les enumérations sont super agréables à utiliser.
La gestion des exception est bonne aussi et permet de se poser des bonnes question plutôt que de trapper et de debugger constamment.
J'avoue que j'ai envie de voir les closures arriver car là Java prendra un tournant d'usage fabuleux.

Je pense que la vision d'un éditeur (qui pensera aussi au côté "bankable" de sa techno) devrait apporter du mieux sur les points de productivité.
23/03/2011, 17h11
OButterlin

Citation:

Envoyé par B.AF

Une grosse contrainte plus que défaut pour moi est la gestion des accesseurs et mutateurs.

Tu voudrais éviter de coder les accesseurs/mutateurs par défaut ou tu vois autre chose ?
23/03/2011, 18h02
thelvin

Citation:

Envoyé par ego

Ben disons que bof bof
Je ne nie pas la multitude des besoins mais je constate simplement que l'on a très peu, voir pas du tout de solutions tout intégrées comme on a pû avoir à l'époque des L4G. Et sans vouloir refaire des L4G, je trouve qu'il y a encore une marge entre les frameworks unitaires que l'on peut trouver et un semblant de liant entre tout ça.

J'adore. J'avais terminé en disant et qu'on vienne pas me dire "moi je dis juste que" et évidemment ça n'a pas raté.

Un prêté pour un rendu, voilà tout. Si ces solutions sont moins à la mode il y a des raisons. Certaines sont logiquement débiles (ou en tout cas fort de café du point de vue des concepteurs,) et d'autres répondent simplement à un besoin bien réél.
Quelque chose qui est bien intégré à lui-même est moins bien intégré au reste. Et l'absence réelle de besoin de s'intégrer au reste, ça n'existe que pour de petites applets. Le monde informatique n'est pas, actuellement, constitué de petites applets. Elles ne sont presque que des jouets sans autre rôle que divertir.

Citation:

Envoyé par OButterlin

Tu voudrais éviter de coder les accesseurs/mutateurs par défaut ou tu vois autre chose ?

Au niveau du langage oui; j'aime bien la notion de propriétés en .Net; je trouve ça plus élégant.

Après c'est vraiment dans l'implémentation dans les api que ça fera la différence (notamment en liaison de données). Typiquement en .Net, les propriétés sont un bon concept, mais l'implémentation d'INotify est vraiment lourde et enléve du charme. Un peu comme changeListener.

Typiquement j'aimerai (dans les deux cas)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public interface IBeanBehavior { @AfterSet(Mamethode) @BeforeSet(Mamethode2) @BeforeGet(Mamethode3) @AfterGet(Mamethode4) @NotifyChange double maProp{get;set;} } public class MonBean implements IBeanBehavior { public double maProp {private get;set} }
A cela, j'aime bien le code de Google sur la programmation par contrat.
Mais ça permet de garder les pojo/poco les plus objets possible; et de déléguer les manipulations à un contrat de service; et si c'est de l'implémentation d'interface de pouvoir généraliser des comportements dans tout le design.
Bref, si quelqu'un veut la liste des drogue que je prends....:mouarf::mouarf:

23/03/2011, 19h42
professeur shadoko

j'ai pas eu le temps de tout lire ... désolé.
Mais le document initial me navre ...
j'ai un point de vue très particulier:
- je suis formateur professionnel
- je suis suffisament agé (age de la retraite dépassé) pour avoir entendu ça sur à peu près n'importe quel langage ("de mon temps on faisait du solide on ne perdait pas de temps avec des abstractions d'intellectuels :calim2:")

de mon point de vue égoïste ce qui me navre c'est que quand on propose à un DSI de former ses équipes, d'avoir une politique de formation et de bien payer les bons programmeurs on est pris pour un martien!
curieusement ceux qui comprennent le message nous disent après qu'ils voient d'un autre oeil les aspects "couts global" du développement.
J'espère certes qu'un jour on aura encore mieux que Java mais les arguments avancés dans ce papier relèvent de jugements péremptoires un peu courts (j'emploie de doux euphémismes car je sens là un client potentiel :mouarf:!)
24/03/2011, 08h54
OButterlin

Citation:

Envoyé par B.AF

Bref, si quelqu'un veut la liste des drogue que je prends....:mouarf::mouarf:

Ouaip, c'est d'la bonne ! :mouarf:

Tant qu'on y est, j'aimerais avoir accès "automatiquement" au fait qu'une propriété est été changée, voir à la valeur précédente si possible...
quitte à ce que seules les propriétés implémentant Comparable soient prises en compte.

Un autre truc, plus spécifique, ce serait bien que lorsqu'un Entity étend une classe abstraite, les annotations de la classe abstraite soient traitées.
On vient de se rendre compte que ce n'était pas le cas (@PreUpdate @PrePersist...) mais là, on n'est moins dans le langage... enfin, je suppose...
24/03/2011, 10h50
B.AF

Dans le principe moi ce que j'aimerai c'est que l'on puisse faire des objets simples sans plomberie, et de pouvoir les décorer par des contrats de service.

En gros, considérer que la propriété est un service rendu par l'objet.
24/03/2011, 11h37
batataw

Citation:

Envoyé par B.AF

Pour moi, il n'y a pas de gens trop proches ou trop loins du clavier.

Il y a ceux qui savent que pour faire une architecture optimale; il faut deux éléments :
- Le premier c'est la connaissance fonctionnelle nécessaire pour lever l'ambiguité de la modélisation métier
- La seconde c'est la connaissance technique nécessaire à orchestrer la modélisation métier dans un contexte d'utilisation.

Une plateforme n'a pas UNE architecture mais une somme d'architectures. Ce qui est important ce n'est pas que l'on puisse combiner les architectures, c'est que la conception soit centralisée.

Quand je dis que Java n'a pas de défaut, je le pense, je pense que le défaut c'est plutôt ceux qui s'en servent sans maitriser. C'est comme si on devait dire la langue Française a des défauts; alors que c'est dans l'usage qu'il y a des problèmes.

Quand tu parles Français, tu as le choix de parler verlan par exemple, mais ce n'est pas la bonne solution pour trouver un emploi et faire une bonne impression dans la société, en revanche, c'est possible, et les problèmes liés à l'usage du "Framework Verlan" ne sont pas dus à la langue française, mais à son contexte d'usage.

Je vois ce que tu veux dire, j'ai deux remarques :

- La première c'est bien de Java et de son éco-système dont il est question dans l'article. C'est impossible de les dissocier. Personne n'utilise le notepad pour développer on est obligé de parler d'Eclispe ou de Netbeans. C'est aussi vrai pour les Frameworks, API, les conteneurs...

- Pour le langage je suis pas tout à fait d'accord, Java a des défauts dans le sens où on pourrait modifier des choses pour qu'il se bonifie. Pour preuve, Java au fil de ses versions apporte ces améliorations. Certaines améliorations sont bien syntaxiques. Et puis je l'ai déjà dit mais l'existence même de Scala au sein de projets professionnels est un signe fort à méditer.
26/03/2011, 10h20
thiphoenix

Bonjour à tous,

Je suis nouveau sur ce site, mais pas dans la profession, j'ai des années d'expérience dans le développement J2EE avec JBoss, Seam, Hibernate et Richfaces...

Il est vrai que la complexité du projet augmente avec le nombre de briques que l'on intègre. La difficulté d'intégration n'est pas non plus une moindre affaire. Il faut du temps, je dirais même beaucoup de temps avant d'utiliser correctement une brique qu'elle soit open source ou pas d'ailleurs.

Je pense quand même que Java/J2EE peut être un bon atout. Il ne faut tout de même pas négliger cependant les autres langages. J2EE permet vraiment de faire certaines choses très bien, mais il faut être réaliste, il reste limité dans les services "temps réel".
Pour ma part, il faut donc choisir le langage approprié au service que l'on veut rendre, on peut donc avoir plusieurs langages au sein d'un même projet que l'on relie en les interconnectant par le biais d'adaptateur.

Le développement d'un projet J2EE peut être très rapide mais peut être aussi très long.
Le nombre de compétence nécessaire est aussi très important. Il faut un spécialiste en base de donnée (même si hibernate le fait pas si mal que ça, mal configuré ou les beans mal écrit, c'est pas évident de toujours trouver l'erreur), un spécialiste en Java/J2EE et JSP/JSF, et un graphiste. Bien sûr, je parle de compétence, une seule personne peut les avoir toutes. De toute façon, cela a un coût qui n'est pas négligeable.
Je suis révolté à voir des programmeurs développer du code et toujours le même, alors qu'il suffit de développer ou d'utiliser des outils qui permettent d'ailleurs de rendre le code plus maintenable puisqu'il a été généré dynamiquement.

La maintenance d'aujourd'hui des projets Java représente un coût considérable, et je trouve cela complètement débile. Au jour d'aujourd'hui où les langages deviennent de plus en plus performant et de plus en plus complexe, on s'acharne à vouloir encore programmer à la main des algorithmes et des beans alors que l'on peut mettre en place des systèmes sémantiques permettant d'alléger la maintenance et le développement de tel projet.

J'ai justement créer une entreprise qui a pour but de développer ces systèmes.
Imaginer permettre à un graphiste de mettre en place le design directement sur la plateforme ou grâce à un kit. Imaginer qu'un ingénieur qui n'y connait rien en programmation puisse interconnecté 2 systèmes à priori incompatible sans écrire le moindre code.

Ah, ce beau jour, où les développeurs pourront se concentrer sur le développement de nouvelle application. Ils n'auront plus à réinventer la roue. Ce jour-là, le métier de développeur redeviendra un métier hautement respecté.
26/03/2011, 10h37
tchize_

Prenons de la hauteur donc. J'admet que java a pléthore d'outils pour faire plein de truc. J'admet aussi que mes connaissances en .net sont plus que limitées puisque je m'y met à peine. Mais c'est un fait dès qu'on entame le .net. Il y a aussi pléthore d'outils, tout n'est pas géré par la solution .net. Je ne suis pas à la moitié du tutorial de C#qu'on est déjà occupé de m'expliquer comment installer spring framework et Nunit, qu'on m'explique que si je veux un système de gestion automatique des dépendances j'ai besoin d'outils comme http://npanday.codeplex.com/, qui paradoxalement font tourner un maven en java :roll:. Que si je veux faire tourner mon application .net sous unix, je dois utiliser les ponts gtk.net ou qt.net plutot que l'api IHM fournie par windows, etc.

Java n'a pas l'apanage des outils annexes qui poussent partout. Ce qui compte c'est d'utiliser l'outil dont vous avez besoin et quand vous en avez besoin. Ce devraient être les besoins des développeur et uniquement eux qui détermine quel outils on fait rentrer dans l'application, car ce sont eux les bénéficiaires exclusifs de cet outil. Le client il s'en contre fiche de ce qu'ils ont mis comme plomberie. Ce qui lui importe c'est que la plomberie mise en place lui permet d'obtenir ce qu'il a demandé dans des délais raisonnables.

Et quand tu respecte ces règles simples, il n'y a pas de raisons que java coute plus cher que .net.
26/03/2011, 10h43
tchize_

Citation:

Envoyé par thiphoenix

mais il faut être réaliste, il reste limité dans les services "temps réel".

Il existe bien des JVM temps réel! Et celles-ci sont encadrées par une spécification précise. http://java.sun.com/javase/technolog...time/index.jsp ;)
27/03/2011, 00h30
B.AF

Heu c'est plutôt Nuget que tu cherches en fait...
:ccool:
03/04/2011, 18h19
dolby

Opinion basée sur la pratique et non pas sur l'analyse de java

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 !
04/04/2011, 09h22
B.AF

Citation:

Envoyé par 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.

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.
04/04/2011, 10h38
OButterlin

Citation:

Envoyé par B.AF

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.
04/04/2011, 10h51
B.AF

J'espére bien qu'en bossant dans l'informatique j'ai un raisonnement de développeur :mrgreen::mrgreen::mrgreen: (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.

Voir 40 message(s) de cette discussion en une page