Le weblogue de SeB

Les appareils mobiles poussent partout. Les accès réseaux sont de plus en plus disponibles. Dans l’environnement réduit de la mobilité, les Web Services semblent opportuns.

Avec la multiplication des appareils mobiles (PDAs, téléphones, …) et des accès Internet omniprésents, il n’est pas étonnant de voir arriver les Web Services pour l’environnement J2ME.

Wendong présente la première version de Apache Mirae. Ce projet est l’implémentation de la JSR-172. Apache Mirae permet d’accéder à des services web distants simplement en implémentant toute la couche analyse XML et la gestion du protocole SOAP.

Les Web Services et les navigateurs sont deux prochains acteurs majeurs des plates-formes mobiles. Ce projet est donc à surveiller de très près.

Non, ce n’est pas le dernier animal virtuel japonais ! Bien que cette petite île ne soit pas étrangère à cette annonce.

Depuis la version 0.2.2 de MySaifu JVM, il est possible d’exploiter les capacités d’enregistrement et de lecture audio en Java sur la plate-forme Pocket PC. En m’inspirant du code source d’exemple fourni par l’auteur japonais^[1], j’ai écrit Parrot. Ce programme, piloté avec une interface graphique en AWT permet d’enregistrer une séquence sonore comme avec un dictaphone puis de rejouer cette séquence à volonté.

Cet outil a été écrit dans l’unique but de valider les fonctionnalités proposées par cette JVM qui continue de progresser.

L’écriture des méthodes toString() est une tâche répétitive et peu gratifiante. Pourtant cette méthode est très pratique pour les traces applicatives. C’est pourquoi, il est recommandé de l’automatiser.

Dans sa version sans extension, Eclipse ne permet pas de générer les méthodes toString() des JavaBeans. Heureusement, il existe de nombreux plugins qui permettent de le faire. Six projets sont présentés ci-dessous :

• ToString Generator génère les méthodes toString() JavaBean par JavaBean. Il est possible de choisir le séparateur et champ et si la méthode existe déjà il demande la confirmation avant de l’écraser. La fonction n’est pas accessible dans la perspective Ressource, mais seulement dans la perspective Java et J2EE (WTP).

• CodeSugar propose la génération des méthodes hashCode(), equals(), clone() et toString(). Il est possible d’écraser systématiquement l’ancienne méthode. L’outil permet également d’autres manipulations sur les JavaBeans. Il est regrettable qu’il ne soit pas possible de paramétrer le séparateur de champ.

• Commons4E génère du code en se basant sur la bibliothèque Jakarta Commons Lang pour implémenter les méthodes hashCode(), equals(), compareTo() et toString(). Il supporte l’héritage et propose différents modèles de représentation pour les JavaBeans. Dommage qu’il soit nécessaire de sélectionner à chaque fois le modèle à utiliser et que le séparateur de champ ne soit pas paramétrable.

• Commonclipse reprend le même principe que le précédent plugin. Il a l’avantage d’enregistrer les paramètres pour la génération des méthodes et surtout il permet de générer les méthodes pour une liste de fichiers sources ! En revanche il n’est pas possible de choisir les champs à utiliser pour la méthode toString().

• CodeRelief permet de générer le code source à utiliser pour les méthodes hashCode(), equals() et toString(). Il se révèle très peu pratique car il faut créer soit-même la méthode puis faire un copier/coller du code généré.

• JUtils ToString Generator autorise la création d’un constructeur par copie ainsi que de la méthode toString(). Le code source généré est totalement paramétrable de façon simple et supporte l’héritage. Il est possible d’obtenir quelque chose de propre en modifiant le modèle de la méthode toString() fourni par défaut. La génération de code n’est accessible que dans la perspective Java par contre elle peut se faire pour plusieurs fichiers en même temps.

Le point positif est que la plupart de ces outils utilisent un StringBuffer pour le code généré. Commons4E retient l’attention, mais la dépendance du code généré avec Jakarta Commons Lang est fortement regrettable. ToString Generator ne propose que la génération de la méthode toString() et le fait très bien. Néanmoins JUtils ToString Generator reste l’outil le plus souple, même s’il ne supporte pas les champs de type Array ou Collection. Mais cela doit être réalisable avec le paramétrage du modèle.

Pour finir, voici un modèle personnalisé plus pratique que celui fourni par défaut :

public String toString() {
 StringBuffer sb = new StringBuffer("");
 sb.append("${class_name}(").
 append(super.toString()).
 append(",").
 append("${attribute}=").
 append(this.${attribute}).
 append(")");

 return sb.toString();
}

Encore jeune, WTP ne propose pas une intégration assistée des taglibs. Même s’il les supporte.

Le sujet de cette note n’est pas de démontrer l’utilité des taglibs. Mais seulement de montrer comment intégrer simplement les taglibs dans un projet Web avec WTP.

Une fois le projet de type Dynamic Web Project créé, il faut sélectionner le répertoire WebContent/WEB-INF/lib^[1] et choisir dans le menu File la fonction Import…. Il faut ensuite choisir l’importation d’un système de fichiers, puis sélectionner le répertoire où ont été décompressé les jars des taglibs^[2].

L’intégration est terminée ! Il est possible de vérifier dans la section Web App Libraries la présence des jars pour les taglibs. Il faut également penser à ajouter la déclaration de ces dernières dans le descripteur de déploiement de la WebApp en insérant par exemple les lignes suivantes dans le fichier web.xml :

<jsp-config>
 <taglib>
 <taglib-uri>http://java.sun.com/jstl/core</taglib-uri>
 <taglib-location>/WEB-INF/lib/jstl.jar</taglib-location>
 </taglib>
 <taglib>
 <taglib-uri>http://java.sun.com/jstl/fmt</taglib-uri>
 <taglib-location>/WEB-INF/lib/standard.jar</taglib-location>
 </taglib>
</jsp-config>

De plus, il ne faut pas oublier de déclarer les taglibs dans les JSP ainsi :

<jsp:root
 version="2.0"
 xmlns:jsp="http://java.sun.com/JSP/Page"
 xmlns:c="http://java.sun.com/jsp/jstl/core"
 xmlns:fmt="http://java.sun.com/jsp/jstl/fmt"
 xmlns="http://www.w3.org/1999/xhtml">
 <!-- 	... -->
</jsp:root>

A partir de ce moment, l’utilisation des taglibs devient nettement plus facile dans WTP. La syntaxe est validée et l’auto-complétion fonctionne à la fois pour les noms des tags mais aussi pour les attributs^[3].

Ce type de manipulation montre que WTP n’est pas encore mature^[4]. En revanche la qualité des fonctions proposées demeure très bonne^[5].

Qu’est-ce que Struts Shale permet de faire ?

Ce prometteur projet de la fondation Apache, fait son chemin. Tout le monde attend une première version stable afin de pouvoir l’utiliser en production. Néanmoins la version de développement est utilisable pour réaliser des prototypes ou pour apprendre à manipuler ce framework.

Pour toutes les personnes qui n’ont pas encore compris ce que permet de faire Struts Shale, Nicolas Martignole présente très bien le positionnement de Struts Shale. De plus, il décrit tous les modules qui sont fournis avec ce projet.

Une très bonne lecture d’introduction pour appréhender le projet.

Toutes les bonnes adresses pour vivre dans le cercle du Web 2.0.

Non, ce n’est pas le bottin des fondateurs d’entreprises qui font du Web 2.0 !

Le bottin du Web 2.0 représente une liste de plus de 900 sites dit Web 2.0 qui sont classés dans plus de 50 catégories tags^[1]. Cette liste est très pratique pour comparer les offres existantes ou pour trouver une alternative à un service. De plus elle permet à chacun d’explorer ce qui se fait déjà avant de se lancer dans l’aventure de la création d’un nouveau service.

Si la matrice du Web 2.0 n’avait pas suffit aux plus assoiffés de connaissance. Cette nouvelle source d’information devrait occuper les passionnés pendant un certain temps…

De plus en plus présent. Mais cet outil est-il utilisé correctement ?

JUnit est un framework de tests unitaires. Son utilité n’est plus à prouver. Beaucoup de personnes l’utilisent, mais pas toujours de la bonne façon.

Ady nous fait découvrir deux articles sur les exemples à ne pas suivre lors de l’implémentation de tests unitaires. L’article de Joe Schmetzer intitulé JUnit Anti-pattern est très bien écrit et met en évidence les pièges à éviter. Selon l’auteur, il faut éviter d’écrire des tests :

• sans assertions
• avec plusieurs assertions
• avec des assertions superflues
• avec des assertions non-adaptées
• avec des try/catch
• …

Dans ces exemples, ce que l’on peut souvent rencontrer ce sont les try/catch. Beaucoup de développeurs ont pris l’habitude de gérer les exceptions dès qu’il est possible d’en rencontrer une^[1]. Cependant lors de l’écriture de test unitaire, il est rarement nécessaire de gérer les l’exceptions^[2]. Laissez l’exception remonter jusqu’au framework JUnit !

En revanche, J. Schmetzer explique qu’il ne faut pas mettre plusieurs assertions dans un même test. Il n’a pas tord puisque la première assertion en échec masque les suivantes. Pourtant dans la réalité, l’application de cette bonne pratique peut vite devenir un vrai calvaire. En effet, un simple test avec cinq ou six assertions doit être remplacé par cinq ou six fois le même test avec pour chaque test une assertion différente. Le nombre de tests à écrit est alors considérable.

Il ne faut pas négliger la qualité de l’écriture des tests unitaire. Gardez les précédentes recommandations en mémoire.

Faut-il ou non documenter le code source privé en Java ?

Cédric Beust s’interroge sur l’intérêt de documenter le code Java dont l’accès est privé. Car dans la majorité des cas, JavaDoc ignore ces commentaires. C. Beust documente ces champs ou ces méthodes qui ont un accès privé en autre parce qu’un IDE tel que Eclipse affiche une info-bulle avec le commentaire associé même si l’élément est privé.

Même si les personnes qui utilisent une API n’ont besoin de connaître que le fonctionnement public. Il faut avoir en tête que le code source de cette API sera sûrement modifié par différentes personnes. C’est à ce moment que la documentation des sections privées prend tout son sens.

Je ne me suis jamais posé de question sur l’utilité de la documentation du code privé^[1]. Alors pensez aux personnes qui reliront votre code source.

Un outil existe pour générer des domain hacks.

Certains sites ont pour nom de domaine ce qui est appelé dans la langue de Shakespeare des domain hacks. Par exemple del.icio.us, script.aculo.us, dontclick.it, … L’idée est d’utiliser l’extension du nom de domaine pour former le nom du site. Certains vont jusqu’à utiliser le chemin dans l’URL qui suit le nom de domaine.

Ne cherchez pas à vous torturer l’esprit afin de trouver le prochain domain hack qui fera fureur. Le site Xona propose un générateur de ”domain hack” à partir de mots clé.

Il ne reste plus qu’à trouver un nom de domaine encore libre…

Voici une très bonne interprétation des principales règles du marketing de Google.

Jean-François Ruiz propose son interprétation des 7 principes du marketing de Google.

Sa vision est très bonne. En voici un résumé agrémenté de quelques pistes supplémentaires :

• Results must be trackable : afin de maximiser la productivité de Google, il est nécessaire de connaître au mieux les utilisateurs. Ceci passe à la fois par les outils tels que Urchin et MesureMap mais aussi par la mise en place du compte unique pour tous les services proposés par Google.
• Data. Not Hypes : il ne faut pas céder à l’engouement général. Les données pré-valent sur la popularité et sur l’effet de mode.
• Let others speak for you : il ne faut pas perdre son temps à promouvoir un service. Des tierces personnes le feront très bien et seront jugées plus impartiales. La culture du secret est également génératrice de marketing viral…
• You’re smart and your time matters : il faut aller vite, très vite ! La course à la conquête du web qui se déroule actuellement dans la bataille du Web 2.0 oblige chacun à se concentrer sur la valeur ajoutée. C’est pourquoi la présentation des services de Google reste sobre en général. Bien qu’avec des interfaces telles que celles de Gmail ou Google Reader, un important travail a été fourni sur l’utilisabilité.
• Big ideas move us : il ne faut pas empêcher la naissance d’une idée aussi farfelue qu’elle puisse paraître. La société affiche vouloir laisser ses employés libres de mettre à exécution leur propres idées. Ceci dans le but de favoriser la créativité des collaborateurs.
• We’re serious. Except when we’re not : être sérieux sans l’être. C’est l’image que souhaite donner Google. A savoir que les entreprises peuvent faire confiance à la qualité du service rendu. Mais l’entreprise est jeune, dynamique; en un mot : fun^[1] !
• Promote trial : il faut proposer des services non abouti^[2]. Dans la course que la société mène avec ses concurrents, il est impératif de proposer mieux ou avant. En général il est plus facile de proposer avant que mieux. Cela rejoint l’idée sur l’invasion des versions beta.

En ajoutant à ces principes les récentes fuites sur la stratégie de Google, force est de constater que la société s’est fortement engagée dans la bataille du Web 2.0.