Archiblog

Commentaires

1. Le mercredi, 15 juin 2005, 11:42 par alexismp

je suis plus inquiet par le tout "client lèger" (vs. client riche) que par le tout Struts/JSF...

2. Le jeudi, 16 juin 2005, 00:32 par Laurent Simon

Je suis assez d'accord avec toi sur le fond mais il s'agit là d'un autre axe de comparaison.

Quand on compare Struts à JSF, on compare deux moyens différents pour atteindre un même but. Quand on compare le client léger à du client riche, on compare deux objectifs différents.

Il est effectivement aujourd'hui totalement illusoire de rendre la même palette de services avec du client léger qu'avec du client riche. Ceci dit il y a certains usages où le client léger est plus approprié que le client riche (publication d'information, besoins d'interactivité simples, etc.). La tendance actuelle à vouloir utiliser le client léger comme une solution universelle est par contre un véritable désastre en entreprise. Cet effet de mode suivi aveuglément, aboutit souvent à la mise à disposition d'outils qui sont plus une régression qu'un progrés pour l'utilisateur final.

3. Le mardi, 26 juillet 2005, 12:25 par doj

Choisir Tapestry après la lecture de cet article relève t il d'un acte "mouton" ?

On pourrait argumenter que l'histoire bégaie, que les arguments pro-Tapestry de 2005 sont un curieux écho aux arguments pro-Struts de 2000... Je pense que les gens étaient sincérement intéressés par l'architecture de Struts à l'époque, comme on peut l'être aujourd'hui par Tapestry.

Il est certain que si les projets étaients plus itératifs, permettaient plus de "spike", les modèles seraient critiqués plus vite encore, les frameworks évalués et remplacés plus facilement encore.

Mais relativisons la vision négative : ça va déjà très très vite...

4. Le lundi, 27 mars 2006, 10:20 par Altifun

Monsieur,

Je viens de prendre une grande claque en lisant votre article. Il est vrai que je vis, vous l'avez clairement exprimé, le poid de la presse et de la "mode". Je ne suis pas encore sure d'être encore tout à fait d'accord avec vous, mais vos propos ne m'ont pas laissé insensible. Ils résument malherureusement très bien la situation. L'aspect commercial d'une offre ne doit toutefois pas être négligé. Ma question, comment être sûre de faire les bons choix lorsque nous ne sommes pas chercheur et malgré nos sérieuses bibliographies comment pouvons nous, nous fier à tel ou tel article. Si nous ne pouvons nous fier à la presse, ne croyez vous pas que le rôle des enseignants et des universités est essentiel à notre bonne perception du marché ? A propos de biblio, je suis un "vieux débutant :)", puisque je développe depuis environ 20 ans et que je suis aujourd'hui élève Ingénieur CNAM. Je n'ai pas trouvé votre CV pour vous siter. Le lien a propos de l'auteur ne fonctionne pas. Cordialement

5. Le mardi, 28 mars 2006, 11:32 par Laurent Simon

Tout à fait, l’aspect commercial d’une offre (ainsi que sa pérennité) ne peut pas être négligé que l’on soit fournisseur ou client.

• D’un côté, une société de service se doit de proposer des solutions crédibles et reconnues si elle veut vendre.
• De l’autre, le client doit s’assurer qu’il trouvera facilement les compétences nécessaires pour maintenir son système. Une bonne technologie devient inefficace si elle n’est pas entourée des compétences nécessaires à sa mise en oeuvre.

Sur cet aspect, il est certain que le buzz médiatique joue bien son rôle car tout le monde converge rapidement vers des choix identiques. Le problème vient du fait que de part son effet boule de neige, la médiatisation devient trop souvent le critère essentiel. Ce qui finit par aboutir à l’absence de choix réellement réfléchi. Chacun fait comme le voisin non pas parce qu’il a constaté que le choix du voisin était réellement adapté à sa situation et efficace mais uniquement parce que tout le monde en parle et donc tout le monde fait ça.

Ceci ne veut pas pour autant dire que le critère technique soit meilleur. Techniquement, Struts est vraiment très bien par exemple. Que ce soit les concepts ou bien la façon dont il est implémenté, il n’y a pas grand-chose à redire. Quand je m’en prends à Struts ce n’est pas le framework que je critique. Ce sont ceux qui l’ont choisi et se retrouvent avec des usines à gaz car le contrôle leur en a échappé. Tous simplement parce que ce n’était pas un choix adapté à leur contexte.

Le plus gros problème du choix des outils c’est de vérifier leur adéquation à la population qui va les utiliser. On ne peut pas faire choisir des outils par une élite puis demander ensuite à toute une équipe d’utiliser ces mêmes outils. C’est pourtant ce qui s’est passé avec l’utilisation de Struts par le biais de la médiatisation ambiante. Sous la bannière du MVC à tout prix on s’est retrouvé avec des bataillons de développeurs qui l’utilisaient à toutes les sauces, en appliquant scrupuleusement toutes les best-practices qu’ils avaient pu glaner, mais sans réellement en comprendre les tenants et les aboutissants. Le résultat de cet empilement ne s’est pas fait attendre, on trouve aujourd’hui partout dans les entreprises des applications malades, in maintenables qui sont incapables de monter en charge car elles ont des architectures aussi délirantes qu’inefficaces. Ce n’est pas la faute du modèle MVC mais celle de ceux qui influencés par le buzz ambiant ont fait ces choix sans s’assurer que les résultats obtenus étaient reproductibles à grande échelle (sur des appliquettes, il n’y a jamais de soucis).

Quand je dis utilisez Tapestry plutôt que Struts, ce n’est pas parce qu’il est meilleur en soit. C’est parce qu’il amène le minimum de structuration qui est nécessaire pour pouvoir jouer dans la cours des grands. Avec Struts le système fonctionne avec les tripes à l’air. La qualité du résultat dépend donc exclusivement de la qualité des développeurs qui vont l’utiliser. En pratique, il y en a peu qui savent réellement bien l’utiliser. Au contraire, avec Tapestry, on peut envisager une utilisation à grande échelle avec un minimum de qualité garantie dès le départ sans craindre de laisser une bonne partie des développeurs largués sur le bord de la route ou de découvrir des cadavres dans les placards plus tard. En résumé, avec un outil structurant comme Tapestry, il faut vraiment beaucoup de bonne volonté pour se planter tandis qu’avec Struts, il faut être vraiment compétent pour réussir.

Comment choisir une techno ? Là est bien tout le problème. La presse se contente d’agiter la mousse ambiante mais ne gratte jamais la croûte et s’arrête aux concepts. Elle sert éventuellement une activité de veille mais ne permet pas de comparer ni de choisir objectivement. Elle serait réellement utile si plutôt que de mettre en avant des témoignages d’autosatisfaction, elle faisait des reportages sur les ratages (qui souvent sont les mêmes, mais vus sous un autre angle).

L’enseignement ne peut pas tenir ce rôle. Ces technologies évoluent beaucoup trop vite. Il se trouve déconnecté du terrain. La durée des cursus est trop proche de celle de la durée de vie de telles technos. Choisir aujourd’hui d’enseigner une techno plutôt qu’une autre devient extrêmement périlleux. L’enseignement se contente donc à juste titre d’enseigner les bases en s’appuyant sur des standards reconnus du moment mais ne peut pas aller au-delà. Dans ce contexte, choisir Struts comme outil pédagogique pour enseigner le principe du MVC n’est pas un mauvais choix. C’est même un choix logique. Cet outil est le plus utilisé. Il fonctionne « à poil » et permet donc de bien percevoir toutes les facettes et les subtilités techniques de l’environnement dans lequel il est mis en oeuvre.

La seule référence valable en termes de choix, c’est l’expérience. Il faut expérimenter dans un contexte précis qui intègre la dimension humaine. Au travers de l’expérimentation, il ne faut pas chercher un résultat technique en premier lieu. Il faut surtout chercher ce qui fonctionne et que l’on maîtrise le mieux au sein d’une équipe. Les autres critères viennent tous en second plan. Il est en effet inutile de choisir le meilleur ou le plus réputé (notions très subjectives) si on ne peut pas en rationaliser l’usage de façon industrielle (critère facilement mesurable et seul vrai facteur de succès sur le plan technique).

La constitution d’un cadre de travail industriel est en fait le véritable défi. Certains choix vont se révéler plus judicieux que d’autres dans un tel contexte. On peut très bien construire un cadre industriel basé sur Struts. Seulement pour inscrire ce dernier dans un cadre utilisable pas une population Lambda, il reste énormément de travail à effectuer à côté (plus que de raison à mon avis) tandis qu’avec Tapestry, l’essentiel du cadre est déjà là.

Pour le lien qui ne fonctionne pas, c'est normal ça fait partie de toutes les petites choses que je n'ai pas le temps de faire. En attendant, ce CV devrait vous fournir toutes les informations utiles.

6. Le lundi, 3 avril 2006, 06:46 par altifun

Merci pour votre réponse. Je vous promets d'être vigilant lors de mes prochains choix. Je vais par ailleurs étudier Tapestry, car comme vous le dîte il faut se faire son expérience. Si vous avez des tutoriaux je suis prenneur. Merci pour votre CV. Cordialement

7. Le jeudi, 24 août 2006, 23:48 par user_xman

bonjour a tous,

je veux savoir comment recuperer la valeur d'un bean dans une page jsp poiu l'utiliser enfin dans l'action associé a cette page.

Recherche

• Accueil -
• Archives