Julien Carnelos Blog – Archives

Les projets de maintenance sur de l’existant ou le « legacy code » sont fréquents.

Le « legacy code » possède une définition simple : « C’est du code si vieux/mal fait qu’on a peur d’y toucher« . Malheureusement, il faut tout de même y toucher à un moment pour le maintenir ou ajouter des évolutions (et combattre le statu-quo!). C’est à ce moment là que quelques bonnes pratiques peuvent sauver le développeur de la démence…

Je vous recommande la lecture d’un excellent article de Jeremy Miller, Removing the « Legacy » from your Code qui décrit sa stratégie générale.

Les points essentiels que j’ai retenu et déjà appliqué :

1. Gérer ses ressources : Inutile de partir bille en tête dans une refonte totale du projet. Cela sera sûrement une perte de temps. On ne touche aux morceaux de l’appli que lorsque l’on veut ajouter une valeur métier. A ce moment là, il faudra en profiter pour améliorer le design de l’application.

2. Automatiser le build : C’est souvent un point critique sur les anciennes applications. Une procédure de compilation / déploiement en 15 étapes à la main est source d’erreur et de problèmes de configuration. C’est ici que les outils de build comme ANT/NANT (Maven, Rake,…) peuvent être utilisés à bon escient.

3.  Avoir une vision globale de où l’on souhaite aller : On peut mettre en place au sein de l’équipe une vision du projet à long terme. Par exemple, se fixer comme objectif de remplacer l’ancienne couche DAO par le framework ORM Hibernate/NHibernate. Un wiki collaboratif interne conviendra très bien à ce genre d’informations.

4. Visible du management : Dans l’idéal, il faut que l’idée de cette amélioration du projet par à coups et en douceur soit acceptée par la direction. Avec son support, les modifications majeures seront plus faciles à porter. Par expérience, malheureusement ça sera rarement le cas. Dans ce cas il suffit d’adopter la technique du sous-marin : J’intègre dans mon chiffrage le temps d’effectuer les mises à jour techniques nécessaires. Attention, cette technique doit avoir l’aval de l’équipe technique sous peine de se retrouver isolé…

5. Interdiction d’abîmer le code : Le code source du projet est déjà suffisament ancien, toute modification de celui-ci doit respecter la qualité attendue. Aucune verrue supplémentaire ne doit être tolérée.

Depuis le temps que c’est réclamé par une partie du monde des développeurs c’est officiel, Java passe Open Source.

Alors est-ce une bonne nouvelle ?

Sans même entrer dans les débats sur la relative perte de contrôle des sources, je crois que cela ne changera absolument rien.

Depuis des années, les entreprises font confiance à la machine virtuelle de Sun et Sun a toujours montré un soutien fort et multi plateforme de son offre.

Après, l’opensource est tellement à la mode que Java ne pourra que profiter de cette annonce et du buzz l’accompagnant…

C’est pour bientôt !

Une excellente initiative de Sun est le démarrage d’un effort de traduction de la Javadoc. Un peu comme Microsoft fait depuis des années.

En effet, il n’est pas rare d’entendre des débutants sur le langage râler du manque de ressources françaises. Cet effort est donc le bienvenue. En revanche, pour le moment c’est du ultra-béta et c’est prévu uniquement pour les nouvelles version Java 6 et Java EE 5 (et non pas J2EE).

Donc il faudra être patient mais tout vient à point à qui sait attendre 😉

Etant donné la popularité du framework Struts encore aujourd’hui, je pense qu’il est vraiment bon pour le CV de se former et d’être prêt pour la sortie de la version 2 du framework.

En effet, je ne serais pas étonné de voir le buzz monter lors de la sortie de struts2 et de voir aussi les décideurs et chefs informatiques (ceux qui lisent le 01 😉 ) se dirent :

Tiens la version 2 de notre framework préféré, chouette. On migre !

(un DSI dit souvent chouette, c’est connu 😉 )

Tout ça pour conclure, prenez de l’avance : Converting to Struts2 – Part I

Eclipse Callisto est une initiative de la fondation Eclipse visant à sortir simultanément 10 projets le 30 juin. L’intérêt est de montrer aux DSI qu’Eclipse est un produit prévisible puisqu’il est prévu d’avoir des sorties régulières (1 par an).

Cela augmente la confiance dans la pérénnité du projet. Effectivement, c’est une chose qui manque souvent sur les projets OpenSource…

Liste des projets :

   *  Business Intelligence and Reporting Tools (BIRT) Project    * C/C++ IDE    * Data Tools Platform    *    * GEF - Graphical Editor Framework (3 inclus)    *    * Eclipse Project    * Eclipse Test and Performance Tools Platform Project    * Eclipse Web Tools Platform Project    * VE - Visual Editor

La page du projet montrait un compteur qui en était à moins d’1H au moment de ce post mais il a disparu et se retrouve remplacé par un laconique « Coming Soon ».

J’espère juste qu’ils ne vont pas se louper la date de sortie. Quand on voit l’emballement qui suit cette sortie simultanée Eclipse « Callisto » an Agile Success Story (vu sur infoQ.com), il serait dommage de voir retomber le soufflé 😉 .

Avec la sortie de Eclipse 3.2, il est intéressant de voir quelles sont les nouveautés proposées par cet IDE.

On retrouve sur le site d’eclipse un document de 91 pages ! présentant toutes ces nouveautés écrit par Chris Laffra. Très intéressant à lire car beaucoup de captures d’écran.

• Présentation au format PDF
• Présentation au format PPT

Histoire de mettre le nez dans ces nouveautés, je vous engage à aller télécharger la dernière version mise à la disposition sur le site de eclipse (page de download).

Il s’agit actuellement de la 3.2 M6 (sortie le 31 mars 06) qui est relativement stable et ne plante pas plus qu’un 3.1. De plus cette version est « feature complete ». C’est à dire que lorsque la version finale sortira, elle sera identique au point de vue fonctionnalités.

C’est donc un bon moyen de prendre de l’avance sur la prise en main de l’outil.

La sortie définitive d’eclipse 3.2 est prévue pour fin juin.

La société Megere vient de mettre à disposition un livre électronique gratuitement sur Maven 2.0 . Le manque flagrant de documentation était un des principaux reproches que l’on pouvait faire à Maven (et surtout sur sa v2).

Esperons que le livre comblera ce manque. Et surtout qu’il sortira des tutoriaux classiques pour nous donner des solutions pragmatiques que l’on rencontre tous les jours à l’utilisation de maven…

Le livre a été écrit entre autre par :

• Jason Van Zyl, Chief Architect and founder of Maven
• Vincent Massol, author of « Maven: a Developers Notebook »

Donc pas des débutants 🙂

Lien pour le téléchargement : http://www.mergere.com/m2book_download.jsp

Dans toutes les équipes de développement J2EE avec lesquelles j’ai eu l’occasion de travailler on retrouve l’omni-présence de Tomcat comme serveur web de développement pour les JSP.

Souvent la principale raison d’utilisation est la simplicité. Vis à vis d’un serveur de production sous Weblogic ou Websphere, il n’y a pas photo on s’y retrouve. De plus, avec la maturité des outils, le lancement d’un Tomcat sous Eclipse avec débogage et hot-deploy est grandement simplifiée.

Petit apparté, les outils incountournable à ce sujet sont :

• Le plugin Sysdeo Tomcat launcher pour les environnements déjà existants
• Le projet Eclipse Web Tool Plateform pour les nouveaux projets

Ainsi, la suprématie de Tomcat est compréhensible et point critiquable.

Pourtant, (il y a un pourtant sinon cet article n’aurait aucun intérêt), au fur et à mesure des nouvelles versions, Tomcat devient plus complet et plus robuste mais au détriment d’une certaine vitesse. Evidemment, pour l’utiliser en serveur d’intégration ou de production, il vaut mieux que Tomcat soit costaud et correctement sécurisé, mais en développement, cela rend Tomcat moins attrayant qu’auparavant.

J’ai ainsi découvert récemment le serveur Jetty.

Jetty est un moteur de JSP écrit entièrement en Java et qui tient dans un JAR de 300 ko. Intégrant la norme Servlet 2.4, il implémente la norme J2EE sur le tiers web. Cela signifie pas d’EJB, mais aujourd’hui avec Spring qui utilise encore les EJB 😉 …

Comme sous Tomcat, on peut modifier en dynamique les JSP qui seront recompilés, on peut faire du débogage et même du hot-deploy.

Sur un projet existant, passer par Jetty se résume à installer Jetty, le plugin Jetty pour eclipse et faire un « Run As… » Jetty server, configurer 3 options et c’est parti !

Depuis peu est disponible de façon officielle la suite de l’outil de design DbDesigner4. En effet, ce projet opensource est passé sous le giron de MySQL qui propose désormais le MySQL Workbench.

Sûrement plus stable et à terme plus fonctionnel, ce logiciel a pourtant perdu un attrait fort : la compatibilité affirmée avec d’autres SGBD comme Oracle.

Il possède encore l’option de se connecter à d’autres bases de données mais quand j’essaye sur l’écran de configuration, je tombe toujours sur une erreur :

Driver not attached

Et ce même en associant correctement le driver jar d’oracle…

A re-essayer dans quelques temps donc, ou prévenez-moi si ça marche chez vous ! 🙂

Passons maintenant à ce qui nous intéresse le plus, les Framework AJAX pour Java :

• DWR – 1.1 RC1
• AjaxTags – 1.2
• AJAX Toolkit Framework (ATF) Project

DWR (Direct Web Remoting) est donc un framework Ajax spécialisé pour J2EE. Son utilisation coté serveur est donc simplifiée et se traduit par une « installation facile » :

0. Ajouter le dwr.jar dans le projet web dans WEB-INF/lib.

1. Ajouter DWR comme servlet au projet dans le web.xml :

<servlet>    <servlet-name>dwr-invoker</servlet-name>    <display-name>DWR Servlet</display-name>    <description>Direct Web Remoter Servlet</description>    <servlet-class>uk.ltd.getahead.dwr.DWRServlet</servlet-class>    <init-param>      <param-name>debug</param-name>      <param-value>true</param-value>    </init-param>    <init-param>      <param-name>scriptCompressed</param-name>      <param-value>false</param-value>    </init-param>    <load-on-startup>1</load-on-startup>  </servlet>  <servlet-mapping>    <servlet-name>dwr-invoker</servlet-name>    <url-pattern>/dwr/*</url-pattern>  </servlet-mapping>

2. On déclare nos objets Java dans le dwr.xml (qui se situe à coté du web.xml) On peut marquer ces objets avec des propriétés comme par exemple des droits limités d’accès sur les méthodes ou d’autorisation.

Par exemple ici, je déclare un objet JDate qui est une instance de java.util.date :

  <create creator="new" javascript="JDate">      <param name="class" value="java.util.Date"/>      <exclude method="getHours"/>      <auth method="getMinutes" role="admin"/>    </create>

Pour cet objet, j’exclus l’appel à la méthode getHours() et je demande une autorisation pour le getMinutes() .

3. On ajoute dwr sur nos pages web.

 <script src='dwr/engine.js'></script>  <script type='text/javascript' src='/dwr/dwr/interface/JDate.js'></script>

Et c’est tout !

DWR va alors générer dynamiquement du code javascript en fonction de son parametrage et créer des objets javacript reprenant les objets et méthodes Java déclarés. On appele alors de manière transparente un objet distant Java dans notre code Javascript…

De plus, on peut également consulter directement un objet « partagé » sur le client par une url http du style : http://localhost:8080/dwr/dwr/test/JDate

exemple de résultat :

Ce qui est très agréable avec DWR, c’est qu’on écrit pas de javascript supplémentaire technique pour accéder à nos objets. Tout le cablage est réalisé de façon transparente par le framework.

AjaxTags

Il s’agit d’une ancienne librairie qui ne fonctionnait que sous Struts mais qui fonctionne maintenant avec tout container JSP.

L’installation est également aisée :

0. Installation du ajaxtags-1.2.jar et dépendances dans WEB-INF/lib

1. Mise en place du TLD des tags dans le web.xml si la version des JSP est inférieure à 2.0

2. C’est parti ! Par exemple, pour coder un auto-completer, dans notre jsp on va utiliser le tag autocomplete :

<ajax:autocomplete  source="model"  target="make"  baseUrl="${contextPath}/autocomplete.view"  className="autocomplete"  indicator="indicator"  minimumCharacters="1"  parser="new ResponseXmlToHtmlListParser()" />

En paramètre, les champs les plus importants sont le champ source d’auto complétion et l’url / classe Java de la servlet qui pourra être remplacé par une action struts si on souhaite.

Le résultat est une auto complétion qui fonctionne sans soucis 😉

ATF (AJAX Toolkit Framework)

Projet incubateur sur eclipse.org, il possède l’appui d’éditeurs majeurs comme BEA, IBM, Oracle… Ce framework vise à standardiser la syntaxe Ajax et à réaliser un toolkit Ajax sous Eclipse. Projet donc très intéressant. Pour le moment ce projet est disponible sur le site d’IBM. Je le testerai quand il sera téléchargeable sur eclipse.org.

Bilan

Si le besoin est d’ajouter quelques effets graphiques sur un site, Rico ou scriptaculous sont à peu près équivalent et restent simple d’utilisation.

Pour Dojo, je le vois plutôt comme un composant de haut niveau. C’est à dire qu’il soit directement intégré par un framework web et que le développeur l’utilise par ce framework. Cela permettra de simplifier le travail du développeur pour les cas déjà implémentés par le framework tout en lui fournissant une librairie complète si besoin.

Concernant un développement Java, DWR est tout indiqué dans le cas ou il s’agit d’appeler des composants métier directement depuis le navigateur et AjaxTags permet d’accélerer l’intégration de composants prêt à l’emploi. Les deux approches ne sont pas concurrentes mais gare au mélange de trop de frameworks Ajax, donc bien choisir en fonction du besoin…

Pour ATF, je ne me prononce pas, ne l’ayant pas encore testé.