Discussion :

[Logan Mauzaize]

La formation à 10k€ pour un besoin qui peut-être minimes, voir intégré de manière incrémentale, n'est pour quasi aucune entreprise un choix pertinent.

De mon expérience, les frameworks sont :

• soit intégré par des connaisseurs qui propagent généreusement leurs savoirs aux équipes ;
• soit au strict minimum par un ingénieur qui apprend sur le tas. Et l'intégration d'autres éléments du framework se fera de la même manière

Les SSII n'ont généralement pas une vision à long termes qui n'est pas de leur seul choix mais aussi des habitudes commerciales des clients.
Par exemple, mon client fait des contrats de 1 à 3 ans renouvelables.

Ensuite il y a le fait que nous sommes ingénieurs et relativement capable d'assimiler de nouvelles technos. Je ne dis pas que nous sommes capables de les utiliser convenablement, mais suffisamment pour qu'une entreprise gagne son pain avec. Et au pire ca génère du CA en support/maintenance.



Concernant les frameworks/outils et les politiques de formation, d'abord je ne pense pas qu'elles cherchent à faire des choses obscures mais plutôt des choses très avancées (pour se démarquer de la concurrence) et qu'elles mettent leur priorité sur le code plutôt que la documentation. Il vaut mieux un truc qu'il le fasse bien, plutôt qu'il le dise bien !
J'ai pour bon exemple en ce moment de l'intégration de RichFaces 4.1 !

Autrement, c'est à mon avis le meilleur choix commerciale (surtout pour l'Open Source):

• D'un côté la philosophie Apple qui fait payer un peu (90€ ) les petits, en l'occurence des consommateurs (re ), qui sont nombreux.
• De l'autre côté Google qui fait payer gros (voir très gros) les grands, les constructeurs de téléphone, qui sont moins nombreux mais qui ont une grande mannes de clients.

Dans notre cas, il s'agit de fournir un produit gratuitement afin qu'il soit assimilé par une tonnes de petits ingénieurs geeks, car ce sont eux et surtout eux qui iront vendre l'intégration de leurs solutions chez un client. Et ensuite le client (ou le prestataire qui assure le suivi du service) qui paiera les formations/supports pour externaliser quelques menus dépenses.
S'ils faisaient payer leurs produits, ils seraient moins populaires, à part sur un marché fermé ou une niche, je vois pas comment vendre une solution que tout le monde distribue gratuitement et qui offrent au pire des formations/supports/migrations pour pas beaucoup plus cher que le prix du produit que tu vends quasi-nus.

[hwoarang]

C'est le gagne pain de beaucoup de boite qui sorte des logiciels en open source. Il faut bien qu'ils aient un retour sur investissement, donc cette approche est même pour moi nécessaire et viable.

Et surtout, ca permet de mettre à disposition de tout le monde (y compris ceux qui developpent des petits programmes pour eux) des outils fiables, testés et avec au moins un peu de doc.

La formation à 10k€ pour un besoin qui peut-être minimes, voir intégré de manière incrémentale, n'est pour quasi aucune entreprise un choix pertinent.

J'ajouterais qu'il est difficile de se rendre compte de la pertinence de la formation avant de l'avoir faite. Parce que faire la formation à 10k€ pour se rendre compte que le produit/framework ne correspond pas à ce qu'on veut faire, ca fait perdre du temps et de l'argent. A mes yeux, c'est d'ailleurs le gros point noir. Je me suis auto-formé au developpement Java web et franchement, en essayant de regarder de tres haut pour m'orienter vers une techno pratique, c'est pas evident. Par exemple, je n'ai toujours pas compris l'interet de Sping et des frameworks associés. Bien sur, je pourrais faire des tutos et passer par la pratique mais j'aurais préféré un petit document qui synthetise les interets de la techno et qui definisse les cas ou elle est utile et ceux ou elle ne l'est pas. A contrario, la documentation de Vaadin donc m'a parlé tchize (que je remercie au passage) est bien faite à ce niveau et les premieres pages suffisent à se rendre compte s'il est pertinent d'utiliser l'outil ou non.

Ensuite il y a le fait que nous sommes ingénieurs et relativement capable d'assimiler de nouvelles technos. Je ne dis pas que nous sommes capables de les utiliser convenablement, mais suffisamment pour qu'une entreprise gagne son pain avec.

Comme tu le dis, le probleme, c'est qu'il n'est pas evident de se rendre compte si le tuto qu'on a suivi (et qui fonctionne) est correct du point de vue de la philosophie de l'outil. Et encore moins quand on il y a un minimum d'aspect sécurité.

Et au pire ca génère du CA en support/maintenance.

Ah bah c'est du joli ca ! Faire des bugs pour que le client soit obligé de revenir... Bah c'est le principe de l'informatique, en fait

Dans notre cas, il s'agit de fournir un produit gratuitement afin qu'il soit assimilé par une tonnes de petits ingénieurs geeks, car ce sont eux et surtout eux qui iront vendre l'intégration de leurs solutions chez un client. Et ensuite le client (ou le prestataire qui assure le suivi du service) qui paiera les formations/supports pour externaliser quelques menus dépenses.
S'ils faisaient payer leurs produits, ils seraient moins populaires, à part sur un marché fermé ou une niche, je vois pas comment vendre une solution que tout le monde distribue gratuitement et qui offrent au pire des formations/supports/migrations pour pas beaucoup plus cher que le prix du produit que tu vends quasi-nus.

La dessus, je suis d'accord

[deathness]

J'aurai du un peu plus varier mon propos.
Ce n'est pas seulement proposer des formations qui fait rentrer de l'argent, mais c'est surtout proposer par la suite d'envoyer un prestataire/consultant chez les clients pour les aider à intégrer/utiliser l'application (open-source ou non d'ailleurs).

Mais je pense que de plus en plus d'entreprise se mettent/vont se mettre à la philosophie que ce n'est pas le produit lui-même qui est la valeur mais les compétences qu'on peut proposer/vendre avec. Et que donc il n'est parfois pas judicieux de faire payer le produit.

Je pense notamment au développement de BonitaSoft qui est un modèle du genre.

[Logan Mauzaize]

Dans le même modèle économique, tu as OBM.
Avec en plus, une option pour les clients souhaitant des développements spécifiques de payer pour ; et ca devient disponible pour tout le monde.


Je vois un gros intérêt, dans mon contexte, à Spring même si ca représente peu de choses de ce qui est proposé : externaliser (par rapport au code/fichiers de configuration obscure) et centraliser (plutôt qu'éparpiller dans d'énième fichiers) la configuration spécifique à l'utilisateur.
Car dans la multitude des fichiers de configuration, il y a la partie technique qui nous sert à découpler le code, améliorer la maintenabilité ou la testabilité, etc. et la partie adaptation à l'environnement.
Cependant ca ne représente qu'un morceau : Bean, XML et Configuration.

La seconde force de Spring (et sûrement d'autres framework) c'est d'être assez complet pour industrialiser des méthodes de développement en Java. Quelqu'un qui connait Spring s'y retrouve très rapidement dans tous les projets Spring et retrouve tous ces paradigmes/patterns rapidement sans chercher s'il existe bien une classe qui gère tel paradigme/pattern et comment elle est rangée/appelée/organisée/pensée.
D'ailleurs quand tu passes d'un projet à un autre les classes utilitaires n'assurent que les fonctions dont les développeurs ont besoin (et plus nécessairement celles dont ils ont eu besoin !!! Le code mort c'est mal) et il faut toujours ajouter du code pour ajouter la petite fonction sympas qui fait un petit peu plus. Pour peu que ce soit une autre équipe interne, voir qu'elle soit externe, c'est la croix et la bannière (c'est du vécu )
Il faut également ajouter à cela le lot de bugs/limitations que se trainent ces classes/packages/bibliothèques/framework maisons.

EDIT: Un grand merci à tout les helpers Spring.
Que Dieu et les développeurs qui prendront ma relève aient pitié de moi pour l'affreuse API que j'ai écrite pour gérer les transactions Hibernate sur un projet sans Spring

[_skip]

Perso je n'utilise pas Spring car lors de mes essais, je ne supportais pas ce que j'estimais être une perte de maîtrise sur mon application. Enfin il faut dire que je suis réfractaire à tout ce qui fait de la magie en java, donc lorsque c'est possible je vais au plus simple et je ne m'impose aucune carcan architectural.

Je sais juste que si mon applic reste maintenable et raisonnablement modifiable, je bosse pas trop mal. On peut utiliser des gros outils, oui mais seulement si on les comprend et seulement si les besoins les justifient.
En java, je pense qu'on tombe très vite dans le piège du surarchitecturé, on ajoute vite des frameworks pleins d'annotations magiques pour obtenir des fonctionnalités à priori alléchantes sans forcément garder une maîtrise suffisante de ce qui se passe sous le capot.

[Logan Mauzaize]

Je plussoie complétement ! Tu parles de surarchitecture mais il y a également la surconception !
Je suis complétement partisan du refactoring : tu abstraits et rajoutes des couches que quand c'est nécessaire : factorisation/découplage ; histoire de gagner en maintenabilité (Le code dupliqué c'est mal).

[OButterlin]

Perso je n'utilise pas Spring car lors de mes essais, je ne supportais pas ce que j'estimais être une perte de maîtrise sur mon application. Enfin il faut dire que je suis réfractaire à tout ce qui fait de la magie en java, donc lorsque c'est possible je vais au plus simple et je ne m'impose aucune carcan architectural.

Il faut bien comprendre qu'il y a une grosse différence entre développer une application pour 1 société et en développer une pour N sociétés.
Là, l'injection de dépendance (pour ne citer qu'elle) prend tout son sens.

Après, Spring ou EJB, c'est une question de préférence

[_skip]

Il faut bien comprendre qu'il y a une grosse différence entre développer une application pour 1 société et en développer une pour N sociétés.
Là, l'injection de dépendance (pour ne citer qu'elle) prend tout son sens.

Après, Spring ou EJB, c'est une question de préférence

A condition qu'il soit possible d'encapsuler les différences entre les implémentations spécifiques de chaque client derrière une interface commune. Pas forcément toujours faisable sans nécessiter des adaptations fréquentes de l'interface et des zones pluggables dans le coeur.

Enfin c'est du cas par cas. Mais j'admets tout à fait qu'il y ait des domaines où le gros framework est très souhaitable. Je pense juste que dans bien des applications, on ferait beaucoup mieux de chercher plus simple.

[Logan Mauzaize]

Il faut bien comprendre qu'il y a une grosse différence entre développer une application pour 1 société et en développer une pour N sociétés.
Là, l'injection de dépendance (pour ne citer qu'elle) prend tout son sens.

Après, Spring ou EJB, c'est une question de préférence

Ca concerne que les éditeurs de logiciels et je pense que la plupart des développeurs bossent dans le service et non dans l'édition.

[Rei Ichido]

A condition qu'il soit possible d'encapsuler les différences entre les implémentations spécifiques de chaque client derrière une interface commune. Pas forcément toujours faisable sans nécessiter des adaptations fréquentes de l'interface et des zones pluggables dans le coeur.

Il faut voir aussi que ça peut être une demande du client, s'il a beaucoup d'applications à gérer ; car le côté "facilité de passer d'une appli à une autre" se retrouve aussi pour lui - il peut facilement faire migrer des ressources d'un projet à un autre, que ça soit des internes ou des prestataires.

[OButterlin]

Ca concerne que les éditeurs de logiciels et je pense que la plupart des développeurs bossent dans le service et non dans l'édition.

Et alors ? ça remet en cause la remarque ?

[Logan Mauzaize]

Il faut voir aussi que ça peut être une demande du client, s'il a beaucoup d'applications à gérer ; car le côté "facilité de passer d'une appli à une autre" se retrouve aussi pour lui - il peut facilement faire migrer des ressources d'un projet à un autre, que ça soit des internes ou des prestataires.

Je reste persuadé que ces initiatives viennent rarement du client mais plus des techos qui veulent satisfaire un égo.
De plus il y a de moins en moins d'AT et de plus en plus de forfait, donc le client n'a dans les faits pas son mot à dire et n'en a généralement rien à carrer. Pour lui, le produit se limitant généralement à l'IHM.

Et alors ? ça remet en cause la remarque ?

Dans la mesure où tu citais _skip qui évoquait des projets (service) et non des produits (édition), oui !

Cependant en y réfléchissant, ca peut s'appliquer au service si comme le souligne Rei Ichido, il y a des contraintes d'uniformisations qu'elle soit côté MOA ou MOE.
Un client peut imposer un produit générique pour gérer un portefeuille de projet qu'il veut standardiser/industrialiser/etc.
De la même manière, un fournisseur de service peut avoir un produit générique interne pour fournir des réponses plus rapides, plus propres, plus standard, etc.
Donc je serai tenté de répondre non à ta question si l'on considère ma réponse.

Mais je modérai tout de même le fait qu'on voit BEAUCOUP trop de surarchitecture/surconception que ce qui est nécessaire et c'est ce que voulait dire _skip : pas que ce soit inutile/futile mais que dans la majorité des cas, cela n'a pas lieu d'être.
Donc je dirai "oui" par rapport au message original de _skip !

[_skip]

En dehors de tout ça, pour répondre à la question java, choix coûteux ou non. Je dirai que oui, c'est coûteux voire très coûteux par rapport à d'autres technos.
Principalement je dirai à cause des learning curve de la plupart de ces frameworks, y compris (voir surtout) le standard.

J'ai fait pour la première fois du java orienté web en 2007, et j'ai salement galéré avec mon JSF de l'époque. Déjà parce que quasiment tout sur cette techno était mal pensé, stupide et inutilement complexe (je peux développer avant que vous fassiez pleuvoir les -1), mais aussi parce que j'ai du apprendre ce que c'était qu'un serveur d'application, comment ça se configurait, ce que c'était que des servlets et tout ce XML.

Lorsque je cherchais de la doc, ça ne semblait jamais correspondre à ma situation, ou alors c'était des frameworks différents, des versions différentes.... Bref, faire du java c'est pas seulement savoir coder du java, mais aussi connaître un peu l'écosystème et les stacks applicatives sur lesquels les applications s'appuient. Et là il y a beaucoup à savoir.

Si je prends son concurrent, à savoir .Net, on arrive bien plus facilement à un résultat car ça se disperse moins dans tous les sens, il y a un IDE de référence, un serveur de référence et on trouve plus facilement de l'aide car ce monde est plus homogène. Essayez pour voir de faire un webservice en .Net sous visual studio, ça se fait en 3 clics et demi et on se pose pas la question de savoir si on va utiliser Axis, Jax machin ou autre et on est sûr d'avoir fait juste du premier coup même si on connaît rien à IIS, WSDL et tout ça...

En comparaison, je pense pouvoir dire en toute sincérité et sans troll que c'est beaucoup plus dur de débuter le monde serveur/web en java que sur quasiment tous les autres langages que je connais. Que ce soit Php, python ou .net.
Le monde du serveur en java permet de faire des choses très poussées, mais c'est clairement pas à mon sens le choix idéal pour construire un site traditionnel de contenu ou quoi que ce soit d'assez léger.

En gros, java c'est un certaine complexité qui met quand même du temps à s'apprivoiser. Il faut faire des choix (framework de présentation, conteneur, ORM) qui sont implicites sur d'autres technos et qui demandent du temps et du travail pour être compris et utilisés à leur plein potentiel. La doc a beau être abondante sur le net, on ne peut pas toujours s'en contenter et elle ne correspond pas toujours à la stack qu'on utilise.
Cependant il est vrai qu'une fois qu'on est plus à l'aise, qu'on sépare mieux les choses dans sa tête et qu'on a compris le gros du fonctionnement de la machine, on peut faire des choses très poussées.

Donc je résume, la boîte qui passe à java, ça va lui coûter cher surtout si comme 3/4 des entreprises elle renonce à mettre à disposition des moyens de formation au profit des "ptits tutos sur le web". Elle devrait être sûr que c'est nécessaire et que ça lui apporte quelque chose par rapport à du plus simple.
Quelque chose ça peut être le multiplateforme qui peut être stratégique, les performances qui restent quand même très honorables, la possibilité d'être stateful avec des objets de scope server, caches, indexs en mémoire ou autres (ce qui par exemple pourrait être éliminatoire en PHP), la sécurité du code compilé et la richesse de l'écosystème.

[OButterlin]

C'est le contre-coût de la richesse de choix...
Maintenant, le développement proprement dit ne me parait pas plus compliqué que sur d'autres technos, c'est moins drag and drop, et encore, surtout pour les développements web mais ça reste abordable.
Le seul problème que je vois est lié au choix, comment faire le bon, là est la question

[_skip]

C'est le contre-coût de la richesse de choix...
Maintenant, le développement proprement dit ne me parait pas plus compliqué que sur d'autres technos, c'est moins drag and drop, et encore, surtout pour les développements web mais ça reste abordable.
Le seul problème que je vois est lié au choix, comment faire le bon, là est la question

Oui tu as raison car si on creuse, on trouve des trucs très sympas et raisonnablement faciles à mettre en oeuvre. Je dis toujours que mon erreur en démarrant dans le serveur a été de me fier aux choix de standardisation de SUN.

Je ne veux pas avoir l'air d'un troll et je sais que tout le monde ne sera pas d'accord, mais je trouve qu'ils sont tout de même venus avec certaines technos pourries, d'une complexité sans nom, avec des lacunes évidentes qui avaient pour seul argument d'avoir un le joli sceau "it's a standard!!".
Déjà parce qu'elles étaient moins abouties que ce qu'on trouvait déjà à ce moment là dans le non standard. (Comparez un JPA de l'époque à Hibernate du même moment).

Quant à savoir si ces technos "standards" étaient réellement si portables qu'elles étaient censée l'être entre les serveurs d'application, gros point d'interrogation car j'entends des gens dire qu'un Struts + Spring + Hibernate était plus portable que la stack standard de SUN.

Maintenant que tout ce petit monde dépend d'oracle, je suis curieux de voir comment java va évoluer et ce qu'ils vont standardiser.

Enfin ça c'est pour le web / serveur, côté desktop si on regarde les choix, un swing vieillissant (avec de bonnes initiatives comme swingLabs qui sont aujourd'hui au grenier), javaFx qui se moque du monde, il y aurait aussi pas mal à dire.

Donc j'aime java, mais je ne m'impose pas (plus) ses technos et frameworks "standards".

[OButterlin]

C'est vrai que du côté client lourd, swing est un peu lourd au début... et javaFX, ça me dépasse...
Java semble surtout se concentrer sur les applications web

[_skip]

C'est vrai que du côté client lourd, swing est un peu lourd au début... et javaFX, ça me dépasse...
Java semble surtout se concentrer sur les applications web

Et c'est assez dommage je trouve car avec java web start, ils avaient proposé une solution qui aurait pu se montrer extrêmement intéressante en entreprise. (malgré quelques "loups" sur l'aspect configuration comme d'hab ).

Pour ce qui tourne autour des besoins conventionnels d'une application de gestion, les Api d'impressions de swing sont d'une complexité totalement ridicule par rapport à tout ce que j'ai vu d'autre et leur bon fonctionnement sous linux est plus que douteux sitôt que les fonctions et le format papier dépassent le stade de la page A4 recto.
A ce titre là il me semble que même openoffice utilise un autre système. En tout cas sa boîte de dialogue d'impression est native sous linux (et donc elle récupère correctement les formats et fonctions supportées de CUPS) contrairement à celle en standard en swing.

Je pourrai en dire un paquet mais java pour desktop, c'est pas super super. Ca avait pourtant un sacré potentiel mais comme tu le dis, c'est passé en priorité 4.

[Logan Mauzaize]

Il y a une demande beaucoup plus fortes pour les applications web que pour les clients lourds. Et pour de bonnes raisons :

• Gestion des versions
• Déploiement
• Configuration
• Migration
• Support technique
• Gestion des droits pour installer une nouvelle application
• Contrôle d'accès/diffusion
• ...

Java Web Start c'est bien mais pour le versionnement de l'application et des bibliothèques, mises à jour des données, gestion du proxy et des portails/SSO etc. On repassera.


Pour ce qui est de l'impression, dans mon souvenir, il me semble qu'il est possible d'afficher la boîte de dialogue système. Cependant l'API pour gérer le contenu (Java 2D) et l'organisation est à chier ! Le meilleur truc à faire c'est de générer une image et de l'envoyer à l'impression.

[_skip]

Il y a une demande beaucoup plus fortes pour les applications web que pour les clients lourds. Et pour de bonnes raisons :

Java Web Start c'est bien mais pour le versionnement de l'application et des bibliothèques, mises à jour des données, gestion du proxy et des portails/SSO etc. On repassera.

Juste mais il y a plusieurs raisons qui peuvent obliger à passer par du client lourd, l'accès au système (les disques, tout ce qui est rs232, encore très courant dans l'industrie électronique, lecteurs RFID, lecteurs de carte à puce, appareils de mesure, balances industrielles, pilotage de machine etc...) en bref tout ce qui doit sortir du navigateur web.

Pour ce qui est de l'impression, dans mon souvenir, il me semble qu'il est possible d'afficher la boîte de dialogue système. Cependant l'API pour gérer le contenu (Java 2D) et l'organisation est à chier ! Le meilleur truc à faire c'est de générer une image et de l'envoyer à l'impression.

Bien vu pour la fonction permettant d'utiliser la boîte de dialogue du système, mais elle ne fonctionne pas sous linux, seulement sur windows, testé récemment et certifié.
Ta meilleure solution je pense c'est d'utiliser birt si tu veux des documents sans trop de contraintes de formatage ou jasperreports si tu as besoin d'être "pixel perfect", travailler avec ces commandes bas-niveau préhistoriques n'est pas une bonne idée. Ou alors comme tu dis tu fabriques une image 2D.

[OButterlin]

Personnellement, je préfère une solution jasperreport, de préférence développée sous linux parce qu'il est plus facile de passer de linux à windows que l'inverse.
Après, il est vrai qu'on a également eu des problèmes avec les imprimantes Linux, c'est vraiment over chiant par moment... surtout pour trouver les drivers qui vont bien...
Autre truc qu'on a découvert à nos dépend, le java linux (openjdk) ne fonctionnait pas là où la version sun fonctionnait, bonjour la "portabilité"

Après, client lourd ou client web, c'est un autre débat, tout dépend de l'application qu'on développe. Je ne me vois pas faire une application de synoptiques en web