J’y pense depuis longtemps. Et c’est décidé. Je me lance dans une série de billets sur Struts !
Cette série s’intitule Les bonnes pratiques avec Struts
. Je vais partager avec vous toutes les astuces et les bonnes pratiques que je peux utiliser lorsque je travaille avec Struts.
L’objectif est double :
- réaliser un aide mémoire sur l’utilisation de Struts
- partager et confronter les expériences de chacun sur ce framework MVC
Liste des billets :
En attendant strutsez-vous bien. 
Avec la récente actualité, il fallait s’y attendre : Shale devient un projet à part entière de la fondation Apache.
La présence de Shale au sein du projet Struts a longtemps prêté à confusion. L’annonce du nouveau projet Apache Shale va permettre de clarifier la position de chacun.
Dans un même temps, l’équipe de Struts fait le ménage. Ainsi, Struts Action 1 redevient Struts 1 et Struts Action 2 devient Struts 2[1].
Tout ce ménage devrait permettre à chacun de se remettre au travail sérieusement. De plus, on peut s’attendre à une certaine concurrence entre les deux projets[2].
Bonne chance à la nouvelle équipe de Shale, qui va devoir survivre s’affirmer dans la jungle des frameworks de conception d’applications web comme Struts mais aussi les nouveaux frameworks tels que JBoss Seam.
La dernière fois, c’était il y a un an. Le projet Eclipse continue son bonhomme de chemin et annonce la sortie de la version 3.2. La liste des nouvelles fonctionnalités décrit l’ensemble des avancées de cet IDE. Des efforts importants ont été réalisé pour optimiser le chargement d’Eclipse. Le debugger est été très largement amélioré. Je vous laisse découvrir la suite….
Chris Laffra a également écrit une présentation sur les nouveautés Eclipse 3.2.
Pour finir, notez que le projet Eclipse a tenu son pari et a également annoncé la première version officielle de Callisto. Pourtant, je peux vous assurer que le pari était loin d’être gagné. Callisto est un projet qui a pour but de packager dix projets Eclipse. Cette initiative semble vouloir contrer la récente percée de NetBeans[1].
Ceci est un petit rappel pour les retardataires qui souhaitent utiliser un classloader commun pour plusieurs webapp[1].
Tout d’abord, il faut savoir que la gestion du classloader dépend énormément du serveur d’applications. Par exemple, JBoss possède un seul et unique classloader utilise une hiérarchie de classloaders, mais par défaut c’est un référentiel de classes commun[2][3] pour tout le serveur qui est utilisé. Alors que JOnAS utilise une hiérarchie[4] de classloaders (serveur, application d’entreprise, application web, …).
Donc, en fonction du serveur d’application utilisé, cette question ne se pose pas toujours. Néanmoins, si vous rencontrez ce problème, il est possible de définir des JAR dans le classloader de votre EAR. Et donc d’avoir accès au classloader commun pour plusieurs WAR.
Vous êtes toujours en quête d’amélioration de la qualité de vos développements ? Et si vous entreprenez une petite traque aux bugs ?
Trois catégories de bugs peuvent identifiées :
- bug fonctionnel
- bug de conception
- bug lié au langage
Il existe un outil qui permet d’analyser le code source d’une application Java et de détecter les bugs de conception ou liés au langage. Cet outil se nomme FindBugs et est distribué sous la LGPL.
Comment fait-il ? Il analyse le code source, détecte des erreurs de codage, puis lève des warnings. Même si ces warnings ne sont pas fiables à 100%, le résultat obtenu est très efficace.
Et comme une bonne nouvelle n’arrive jamais seule, un plugin pour Eclipse existe. Le rapport de FindBugs apparaît alors au même endroit et de la même façon que le rapport de compilation Java.
La prochaine étape sera le lancement d’une campagne de Bounty hunters.
Lorsqu’un projet a une taille conséquente, il est nécessaire de répartir les tâches de développement entre les développeurs. Avec le développement multi-couche, cette répartition peut se faire de deux façon différentes :
- L’approche horizontale
- L’approche verticale
Selon Mastering EJB 3rd Edition[1], l’approche horizontale permet d’avoir des personnes ultra-spécialisées dans un domaine technologique correspondant à la couche sur laquelle ils ont l’habitude de travailler. Alors que l’approche verticale permet aux personnes d’obtenir une excellente maîtrise du fonctionnel lié au métier.
La première approche donne naissance à des experts dans des domaines spécifiques. Et avec le second point de vue les intervenants sont des généralistes et progressent dans tous les domaines technologiques.
Par expérience :
- L’approche horizontale :
- rallonge les temps de développements (à cause des problèmes d’intégrations)[2]
- réduit les retours lors de la recette (grâce aux contrôles des n développeurs travaillant sur le même use case et qui confrontent leur avis)
- le planning est plus difficile à organiser et maintenir à cause des dépendances (avec la pyramide des composants, il faut être capable d’ordonnancer correctement les développements) à moins de faire de l’IoC (par exemple avec Spring)
- risque d’ennui des développeurs s’ils sont toujours sur la même couche logicielle
- L’approche verticale :
- optimise les temps de développements
- les développeurs ont une vue d’ensemble du service
- la planification est beaucoup plus simple (grâce au découpage par use case)
- les développeurs progressent dans plusieurs domaines technologiques simultanément[3]
Aucune des deux approches ne semble surpasser l’autre. Personnellement[4], je préfère la répartition horizontale car elle permet d’obtenir une meilleure qualité des développements (d’un point de vue fonctionnel).
Et vous, comment faites-vous ? Quelle approche préférez-vous ?
