Blog Xebia France » développement

Xebia à la conférence Software Craftsmanship

Jean-Laurent de Morlhon — Fri, 20 May 2011 14:12:52 +0000

La conférence Européene de référence sur le Software Craftsmanship se tiendra cette année à Milton Keynes, en Grande Bretagne, non loin de Londres, ce Jeudi 26 mai. Aprés un conférence 2010 réussie, réunissant les pionniers du mouvement Craftsmanship, cette année s’annonce tout aussi prometteuse.
Ordinateur portable avec IDE obligatoire pour cette journée qui s’organisera autour de
4 tracks en paralléles, essentiellement des sessions hands-on. On va voir du code.

Voici quelques sessions issues du programme :

Is TDD Slower In The Short Term?
Enhancing Legacy Test Suites
How Object Oriented Are You Feeling Today?

Plus de détails sur les sessions se trouvent sur le site de jotform

Nous serons 3 sur places et vous retrouverez sur notre blog nos retours sur cette conférence différente et vous pourrez suivre en live sur le compte Twitter de @morlhon.

NoThunes, MediaPlayer et moteur de recherche

Aurélien Maury — Fri, 22 Oct 2010 09:39:22 +0000

Pour le quatrième volet de notre projet de plateforme de musique libre, NoThunes, nous allons ajouter les dernières fonctionnalités du backlog original :

En tant qu’internaute, je dois pouvoir écouter un morceau
En tant qu’internaute, je dois pouvoir rechercher des morceaux par mots-clés

Pour cela, nous passerons par l’utilisation de 2 plugins très pratiques :

Sound Manager, qui offre des tags GSP pour ajouter facilement des fonctions de media player dans les vues
Searchable, qui apporte des fonctionnalités de recherche basées sur Compass (et donc indirectement sur le moteur Lucene)

Suivez le guide …

En tant qu’internaute, je dois pouvoir écouter un morceau

Pour rappel, dans les épisodes précédents, nous avons offerts :

aux utilisateurs membres : la possibilité d’uploader des morceaux de musique.
aux internautes : la possibilité de naviguer dans les morceaux disponibles en filtrant par Band et Album, et de les télécharger.

Aujourd’hui nous allons leur permettre d’écouter les morceaux avant de les télécharger. Précisons tout d’abord cette User Story un peu vague. Il s’agit ici de fournir une fonctionnalité très minimaliste, permettant de jouer un morceaux directement dans l’interface de navigation, pour « goûter » avant de télécharger.

Le périmètre de notre besoin est très restreint et il se trouve qu’un plugin Grails le comble parfaitement : sound-manager. Ce plugin permet de transformer n’importe quel lien pointant vers un fichier mp3 dans la page en un mini lecteur audio flash.

Commençons donc par installer le plugin :

grails install-plugin sound-manager

Si vous avez une bonne mémoire, vous vous rappelez de notre GSP grails-app/views/navigation/_trackList.gsp qui sert à afficher la liste des Tracks recherchés. Il nous suffit d’ajouter en tête de ce fichier :

Ce tag va, à chaque chargement de la page, rechercher les liens pointant vers des fichiers mp3 et les « entourer » avec un peu de sound-manager pour obtenir un mini flash-player dédié au lien.

Comme nous avons mis une image dans le lien vers le mp3, il reste possible de télécharger le morceaux en cliquant sur l’icône plutôt que sur le bouton Play.

And voilà ! 100% de notre petit besoin est rempli, et l’opération a dû prendre 20 minutes en comptant :

la recherche du plugin sur le portail Grails.
la lecture de la documentation.
l’installation.
la mise en œuvre.

C’est presque allé trop vite pour en goûter toute la saveur.

Pour ceux qui veulent aller plus loin, sachez que ce plugin est basé sur la librairie du même nom, et qu’il est donc également possible d’utiliser l’intégralité de l’API, qui est très complète, pour obtenir un lecteur plus riche, éventuellement en HTML5.

En tant qu’internaute, je dois pouvoir rechercher des morceaux par mots-clés

Passons maintenant au moteur de recherche de notre navigation. Le but est ici d’ajouter un formulaire de recherche sur la page de navigation et de lancer la recherche sur les noms des Bands, Albums et Tracks existant en base. Là il y a un peu plus à faire. Tout d’abord, installons le plugin Searchable :

grails install-plugin searchable

Ce plugin est basé sur Compass, qui est lui même basé sur Apache Lucene, le moteur de recherche full-text Java Open Source le plus utilisé (notamment par Twitter depuis peu). Le première étape est de déterminer sur quelles données nous souhaitons baser nos recherches. Dans notre cas, nous avons choisi les champs name des classes de domaines Band, Album et Track.

Pour renseigner l’index du moteur Lucene, il suffit de rajouter cette ligne dans nos classes :

static searchable = [only: ['name']]

Si vous souhaitez faire des mappings plus complexes, il existe de nombreuses possibilités : regardez du coté de la section Mappings de la documentation.

Notre index est maintenant renseigné. Il nous faut une nouvelle méthode de contrôleur pour l’interroger. Pour plus de simplicité, nous la plaçons dans le NavigationController. Fait notable : la recherche par l’index Lucene remonte des entités incomplètes. Seuls les champs indexés sont renseignés. Par conséquent, pour l’affichage final, il faut interroger la base pour avoir tous les champs. Il faut également penser à modifier la chaîne de recherche pour la rendre compréhensible par Lucene. Nous utilisons ici une technique très basique, mais les query Lucene peuvent être autrement plus puissantes. Pour plus de détails, voir la documentation du moteur.

grails-app/controllers/fr/xebia/nothunes/domain/NavigationController.groovy

  /**
    * Methode d'instrumentation pour transformer la chaine de recherche du formulaire en query Lucene-compliant
    * @param query Chaine de recherche
    */
   def instrument(String query) {
      return query+"*"
   }
   /**
    * Methode de recherche full-text
    */
   def search = {
      String searchQuery = instrument(params.searchQuery)
      log.debug "search query is ${searchQuery}"
      def result = searchableService.search(searchQuery)
      // Les *.searchEvery remontent des entités incomplètes, il faudra les récupérer en base pour avoir tous les champs
      def albumResult = Album.searchEvery(searchQuery)
      def bandResult = Band.searchEvery(searchQuery)
      def trackResult = Track.searchEvery(searchQuery)
      def trackList = [] as Set
      def bandList = [] as Set
      def albumList = [] as Set
      // filtrage des tracks pour n'afficher que ceux qui ont un fichier audio
      trackResult.each {
         def fullTrack = Track.get(it.id)
         if (fullTrack.audioPath) {
            trackList.add(fullTrack)
            albumList.add(fullTrack.album)
            bandList.add(fullTrack.album.band)
         }
      }
      // filtrage des albums pour afficher uniquement ceux qui ont au moins un track avec un fichier audio
      albumResult.each {
         def hasOneCompleteTrack = false
         def fullAlbum = Album.get(it.id)
         fullAlbum.tracks.each { aTrack ->
            if (aTrack.audioPath) {
               trackList.add(aTrack)
               hasOneCompleteTrack = true
            }
         }
         if (hasOneCompleteTrack)  {
            albumList.add(fullAlbum)
            bandList.add(fullAlbum.band)
         }
      }
      bandResult.each {
         def fullBand = Band.get(it.id)
         fullBand.albums.each {anAlbum ->
            def hasOneCompleteTrack = false
            anAlbum.tracks.each { aTrack ->
               if (aTrack.audioPath) {
                  trackList.add(aTrack)
                  hasOneCompleteTrack = true
               }
            }
            if (hasOneCompleteTrack)  {
               bandList.add(fullBand)
               albumList.add(anAlbum)
            }
         }
      }
      // Rendu de la vue
      render (view:'list', model: [bandList: bandList, albumList: albumList, trackList: trackList, searchQuery: params.searchQuery])
   }

Dernière chose à ajouter : le formulaire de recherche dans la vue :

grails-app/views/navigation/list.gsp

La chaine est maintenant complète et nous pouvons lancer des requêtes pour interroger notre base.

Conclusion

L’ajout de ces deux fonctionnalités a été assez rapide. Si l’on possède les bons points d’entrée et que l’on prend la peine de fouiller le repository de plugins de Grails, il y a de fortes chances de trouver son bonheur rapidement. Il va de soit que les exemples donnés ici sont des usages basique. Les librairies tirées par les plugins sont plus complètes et permettent d’aller beaucoup plus loin.

Je me permet ici personnel, mais l’utilisation de Grails me remplit de joie . C’est rapide, c’est concis, et si j’en veux plus, je peux. Le chemin vers le code qui fonctionne est bien tracé par les documentations.

Dans le prochain épisode, nous verrons comment tester notre code et contrôler sa qualité.

Ressources

NoThunes, AJAX-ification sauce Grails

Aurélien Maury — Thu, 07 Oct 2010 07:53:51 +0000

Retour sur notre plateforme de musique en ligne préférée. Comme promis, dans ce chapitre, nous allons ajouter une pincée de 2.0 à notre application. Nous allons donc nous pencher sur la mise en oeuvre d’AJAX à la mode de Grails.

Listes déroulantes dynamiques avec JSON
Mise à jour de fragments de page avec modèles GSP

Vous allez pouvoir découvrir l’intégration d’AJAX dans Grails, et à quel point la vie du développeur est facilitée. Les exemples d’utilisation sont simples mais déclinables à l’infini.

Sprint Backlog détaillé

En tant que …	je dois pouvoir …	détail …
membre	Créer/modifier/supprimer des `Tracks` liés à mes albums, en uploadant un fichier mp3	CRUD standard avec upload de fichier.
internaute	naviguer dans la hiérarchie de groupes/albums/morceaux existante	Dans une même page, on offre la sélection par groupe, album et morceaux. Si un groupe est sélectionné, on filtre les albums et les morceaux. Si un album est sélectionné, on filtre les morceaux.
internaute	télécharger un morceau	Dans la navigation offerte aux internautes, on doit disposer d’un lien pour télécharger le fichier mp3 associé à un Track.

Gestion des Tracks

Nous sautons tout ce qui concerne la mise en place du CRUD et de la gestion de l’upload de fichier mp3. La méthode employée est foncièrement identique au travail déjà fait pour les classes Band et Album. Comme d’habitude le détail est dans le GitHub.

Attardons nous, par contre, sur un point particulier du formulaire de création de Track : l’attribution à un Album. Chaque Track appartient à un Album (par un lien belongsTo). Pour une meilleure ergonomie, nous avons choisi de proposer à l’utilisateur de sélectionner d’abord un Band dans un . Enfin un peu d’AJAX dans notre projet !

Pour ceux qui n’ont pas fait de veille techologique depuis plusieurs années, voici un petit rappel sur AJAX.

Nous commençons par outiller nos pages avec ce qu’il faut de Javascript :

grails-app/views/layouts/main.gsp

Ces tags ajoutent dans toutes les pages l’import de la librairie Prototype, fournie par défaut avec Grails, et du fichier web-app/js/application.js. Ce dernier est destiné à recevoir le code Javascript spécifique à notre appli. Ensuite nous créons une méthode dans notre BandController pour renvoyer, au format JSON, la liste des albums appartenant au groupe dont l’id est passé en paramètre :

grails-app/controllers/fr/xebia/nothunes/domain/BandController

...
// Pensez bien à faire cet import
import grails.converters.*
...
def ajaxGetAlbums = {
   render Band.get(params.id).albums as JSON
}

Comme on peut le voir le package grails.converters nous offre une méthode plus que simple pour la conversion d’objets en JSON. A noter que, dans la même famille il est possible d’utiliser as XML.

Maintenant il faut que nous lancions un appel AJAX vers cette méthode, lors de la sélection d’un groupe. Grails a prévu pour nous la méthode remoteFunction qui va générer le Javascript nécessaire.

grails-app/views/tracks/create.gsp

Les paramètres de remoteFunction sont assez explicites :

controller, action : le contrôleur et l’action ciblée
params : les paramètres de la requête
onComplete : la méthode javascript callback de l’appel AJAX

Il ne reste plus qu’à rédiger la méthode Javascript pour mettre à jour le select des Albums :

web-app/js/application.js

function updateSelectAlbumWithJSON(e, albumListId) {
   var rselect = $(albumListId)
   // Vidage du select
   var l = rselect.length
   while (l > 0) {
      l--
      rselect.remove(l)
   }
   // Evaluation du JSON retourné par le serveur
   var albums = eval("(" + e.responseText + ")")
   if (albums) {
   // Remplissage du select avec les nouvelles options
      addOption(rselect, '---Choose an album---', '')
      for (var i=0; i < albums.length; i++) {
         addOption (rselect, albums[i].name, albums[i].id)
      }
   }
}
function addOption(selectId, text, value) {
   var opt = new Element('option');
   opt.text = text
   opt.value = value
   try {
      selectId.add(opt,null) // Standard, ne fonctionne pas avec IE
   }
   catch(ex) {
      selectId.add(opt) // seulement pour IE
   }
}

En mode développement, c’est certainement superflu, mais au cas où le listing des albums deviendrait un peu long, il est possible d’ajouter un gif d’attente. Cette image est gracieusement fournie par Grails. Ça n’a l’air de rien, d’ailleurs ce n’est rien, mais ça fait plaisir quand même !
Juste à coté du tag des Albums on peut ajouter un petit :

grails-app/views/tracks/create.gsp

Et dans le javascript, ajouter du $('waitingGif').show() et $('waitingGif').hide(). Ca fait toujours plus joli après tout.

Ça y est, pas besoin de plus ! Pour la page d’édition d’une instance existante, la méthode est pratiquement la même. il faut juste ajouter dans le trackcontroller le chargement de la liste des albums pour que les 2 select soient remplis au chargement. les gentils membres ont maintenant toutes les fonctionnalités pour alimenter notre plateforme de musique en contenu dûment étiquetté.

Navigation pour les internautes

Il faut maintenant penser aux internautes moyens, avides de pouvoir accéder au contenu des membres. Nous allons donc attaquer la navigation publique. Pour éviter de surcharger les contrôleurs existant, nous créons un NavigationController, qui sera dédié à la page de navigation destinée aux internautes lambdas, ainsi qu’une page GSP associée à l’action list (donc dans le fichier grails-app/views/navigation/list.gsp).

La sélection d’un Band doit déclencher le filtrage de la liste des Albums et des Tracks, et la sélection d’un Album doit déclencher le filtrage de la liste des Tracks uniquement. Le filtrage des Albums est identique au cas précédent, puisque c’est un select. Le tableau des Tracks, un peu plus riche, mérite qu’on s’y attarde un peu.

Le principe est globalement le même, à ceci près qu’on va utiliser un modèle GSP pour créer le fragment HTML qui servira à remplacer dynamiquement la liste des Tracks. Zoomons un peu sur la mécanique de notre page list.gsp :


   
      
      
         // Fonction de filtrage du select des Albums et de la liste des Track, à partir d'un id de Band
         function filterByBand() {
            var bandId = $F('bandSelect');
            
            
         }
         // Fonction de filtrage de la liste des Track, à partir d'un id d'Album
         function filterByAlbum() {
            var albumId = $F('albumSelect');
            
         }
         // Fonction de mise à jour de la liste des Track avec la réponse (au format HTML) de la requête AJAX.
         function updateTrackList(e) {
            $('navTrack').innerHTML = e.responseText;
         }
         // Fonction de mise à jour du select des Albums avec la réponse (au format JSON) de la requête AJAX.
         function updateAlbums(e) {
            // Le code est identique à l'exemple donné pour la
            // mise à jour de select du paragraphe précédent
         }
      
   
   
      
         Navigation

Dans le tag en fin de l’exemple, on voit qu’on fait appel au modèle GSP qui contient la liste formatée des Tracks. Passons à sa rédaction. Il faut penser à nommer le fragment qui servira de modèle en commençant par un caractère ‘_’, c’est la convention. Notez que dans la colonne Download on réutilise le DlController créé à l’épisode 2.

grails-app/views/navigation/_trackList.gsp


         
   
      
         ${message(code: 'track.name.label', default: 'Name')}  
         ${message(code: 'band.name.label', default: 'Band')}   
         ${message(code: 'album.name.label', default: 'Album')} 
         Download      
      
   
   
      
            
            ${fieldValue(bean: trackInstance, field: "name")}
            
            
               ${fieldValue(bean: trackInstance, field: "album.band.name")}
            
            
            ${fieldValue(bean: trackInstance, field: "album.name")}

${message(code: 'track.name.label', default: 'Name')}	${message(code: 'band.name.label', default: 'Band')}	${message(code: 'album.name.label', default: 'Album')}	Download
${fieldValue(bean: trackInstance, field: "name")}	${fieldValue(bean: trackInstance, field: "album.band.name")}	${fieldValue(bean: trackInstance, field: "album.name")}

Enfin, dans notre méthode du contrôleur on pourra faire usage de render comme ceci :

grails-app/controllers/fr/xebia/nothunes/domain/NavigationController.groovy

...
   def ajaxFilterTrackByAlbum = {
      def trackList = Track.withCriteria {
         ne('audioPath', 'empty')
         if (params.id) {
            album {
               eq('id', new Long(params.id))
               if (params.band) {
                  band {
                     eq('id', new Long(params.band))
                  }
               }
            }
         }
      }
      render (view:'_trackList', model: [trackList: trackList])
   }
...

Ça y est nos internautes peuvent naviguer dans les morceaux uploadés par nos gentils membres, et les télécharger à leur guise.

Sprint Review

Nous avons pu voir dans cet épisode que la mise en place de méthodes AJAX est relativement intuitive et rapide. Les 2 cas décrits ici sont déclinables à l’infini pour répondre à beaucoup de besoins. L’API Grails est correctement documentée, et la librairie Prototype embarquée par défaut offre des outils plus que suffisant pour manipuler le DOM de la page. Pour ceux qui préférent, il existe les plugins JQuery et JQuery-UI pour installer en une commande tous les fichiers au bon endroit.

Le programme du prochain épisode :

En tant que …	je pourrai …
internaute	écouter un morceau
internaute	rechercher des morceaux par mots-clés

Stay (no)tuned …

Ressources

NoThunes, l’espace VIP

Aurélien Maury — Thu, 23 Sep 2010 13:52:40 +0000

Continuons le montage de notre projet OpenSource propulsé par Grails. Au dernier épisode, nous avions démarré le projet, façonné les styles CSS, mis en place la sécurité, mais aussi et surtout, rédigé les classes du modèle de données. Aujourd’hui nous allons leur donner vie en ajoutant des fonctionnalités aux utilisateurs membres.

Nous nous attarderons sur :

la gestion du profil utilisateur
la génération des écrans CRUD de nos données
leur adaptation à nos ‘règles métier’
la gestion des upload et download

Ces étapes peuvent paraître triviales à ceux qui ont déjà une expérience de Grails. Cependant, j’ai choisi de les traiter malgré tout. J’ai moi-même perdu trop de temps à chercher des exemples concrets et simples sur la toile pour oser faire l’impasse dessus. Donc, toi qui débute sur Grails, sois le bienvenu.

Sprint backlog détaillé

En tant que …	je dois pouvoir …	détail …
membre	voir et mettre à jour mon profil utilisateur	Un membre authentifié doit pouvoir modifier son profil, sauf son login et ses rôles.
membre	créer/modifier/supprimer des groupes de musiques	Un membre authentifié doit pouvoir créer des groupes de musique et lister/modifier/supprimer les groupes qu’il a créés.
membre	créer/modifier/supprimer des albums liés à mes groupes	Si un membre a créé un groupe de musique, il peut créer un album pour ce groupe.

Gestion du profil utilisateur

Confirmation des modifications de mot de passe

Lorsque nos membres pourront mettre à jour leur profil, ils pourront également modifier leur mot de passe. Pour commencer, il faut donc que nous fassions des adaptations pour ajouter la confirmation du mot de passe dans la gestion des comptes utilisateurs. En deux coups de cuillère à pot, cela donne :

Ajout d’un champ confirmPasswd dans la classe de domaine User, et d’un validateur associé :

grails-app/domain/fr/xebia/nothunes/security/User.groovy

class User {
   ...
   static transients = ['confirmPasswd']
   ...
   String confirmPasswd
   static constraints = {
      ...
      confirmPasswd(validator :{val, obj ->
         if (obj.properties['passwd'] != val) {
            return 'default.invalid.confirmPasswd.message'
         }
      })
   }
}

Le champ nouvellement créé est passé en transient pour éviter que sa valeur ne soit persistée en base. Notez que la valeur retournée par le validateur est un String correspondant au message d’erreur à afficher. Par conséquent, il faut ajouter ce message dans les fichiers messages.properties pour avoir l’affichage de l’erreur dans les GSP :

grails-app/i18n/messages.properties

default.invalid.confirmPasswd.message=Bad password confirmation

Modification du UserController :

Pour que le champ confirmPasswd soit correctement renseigné avant la validation, il faut aller modifier la classe UserController. Dans les méthodes save() et update(), le champ passwd est chiffré avant sauvegarde en base. Il faut appliquer le même traitement au champ confirmPasswd. De cette façon le validateur fait la comparaison entre les deux champs chiffrés. Si les versions chiffrées sont identiques alors la confirmation du mot de passe est valide, CQFD.

grails-app/controllers/UserController.groovy

...
// à chaque occurence du chiffrage du champ 'passwd' ...
person.passwd = authenticateService.encodePassword(params.passwd)
// on ajoute le chiffrage du champ 'confirmPasswd'
person.confirmPasswd = authenticateService.encodePassword(params.confirmPasswd)
...

Modification des formulaires de création et d’édition d’un User :

Pour l’instant les formulaires de création et d’édition des User ne contiennent pas de champ pour confirmPasswd donc le validateur renvoie toujours une erreur. Il suffit d’ajouter un champ texte, initialisé avec la valeur du mot de passe.

grails-app/views/user/create.gsp ET grails-app/views/user/edit.gsp

...

   Password:
   
      
   



   Confirm password:
   
      
   

...

Création d’un contrôleur dédié à l’affichage et la mise à jour du profil

Maintenant que nous disposons d’une validation correcte pour la mise à jour des mots de passe, nous pouvons attaquer le cœur du sujet. Pour cela, on crée un nouveau contrôleur grâce à la commande :

grails create-controller fr.xebia.nothunes.profile.Profile

Cela génère une coquille vide nommée ProfileController. Le but de ce contrôleur est de permettre d’afficher le profil de l’utilisateur courant et de le mettre à jour. Par conséquent il faut créer les méthodes :

index : qu’on redirigera vers show. Dans le cas où le contrôleur est appelé sans méthode particulière, c’est index() qui sera lancé.
show : pour récupérer le compte de l’utilisateur courant en base et l’afficher.
edit : pour récupérer le compte de l’utilisateur courant en base et afficher le formulaire d’édition.
update : pour persister en base un envoi de formulaire d’édition. Si la sauvegarde se passe bien, à la fin on redirige vers show() avec un message de succès ; sinon on redirige vers edit() avec un message d’erreur.

Conjointement, il nous faut 2 vues :

profile/show.gsp : pour afficher le profil. Elle contient un bouton pour passer en édition.
profile/edit.gsp : pour éditer le profil. Elle contient un formulaire qui pointe sur la méthode update du contrôleur.

Afin de ne pas trop alourdir ce billet, je vous renvoie au GitHub pour le détail des vues et du contrôleur. Le code est très fortement inspiré de ce qui existe déjà dans le UserController et ses vues.

Pour être sûr que l’utilisateur est authentifié quand il accède au contrôleur, on ajoute dans les règles de sécurité la protection de /profile/* directement dans le bootstrap de l’application :

grails-app/conf/BootStrap.groovy

class BootStrap {
   def init = { servletContext ->
      ...
      def protectUserProfileManaging = new RequestMap(url: '/profile/*', configAttribute: 'ROLE_ADMIN,ROLE_USER').save()
   }
   ...
}

Une fois tout ceci fait, il suffit de rajouter le lien vers l’affichage du profil dans la GSP qui contient le menu pour les membres :

grails-app/views/menu/_user.gsp

...
   Member manages ...
   
      your profile
   
...

On redémarre notre application et le tour est joué !

Gestion des CRUD métiers : les classes Band et Album

Attaquons maintenant la gestion des CRUD de nos objets métiers. Premier de la liste : Band. Pour rappel, cette classe représente un groupe de musique géré par un utilisateur membre. Un membre doit pouvoir créer des groupes et modifier uniquement ceux qu’il a créé. Pour avoir un petit rappel sur le contenu de la classe Band, voir sur le GitHub. Grails nous offre un démarrage rapide en générant les vues et le contrôleur à partir de la classe de domaine avec la commande :

grails generate-all fr.xebia.nothunes.domain.Band

Le contrôleur et les vues générés sont génériques et doivent être adaptés pour nos besoins particuliers. Ces fonctionnalités doivent être réservées aux membres, donc on ajoute dans le bootstrap les règles de sécurité pour protéger le contrôleur :

grails-app/conf/BootStrap.groovy

class BootStrap {
   def init = { servletContext ->
      ...
      def protectUserProfileManaging = new RequestMap(url: '/band/*', configAttribute: 'ROLE_ADMIN,ROLE_USER').save()
   }
   ...
}

Ensuite il faut rajouter des contrôles métier pour permettre aux membres de ne lister, visualiser et modifier que les Band qu’ils ont créés. Pour cela, on va s’appuyer sur l’appartenance de la classe Band à un User (lien belongsTo). Pour commencer, la méthode list ne doit afficher que les groupes dont l’utilisateur est propriétaire :

grails-app/controllers/fr/xebia/nothunes/domain/BandController.groovy

...
def list = {
   params.max = Math.min(params.max ? params.int('max') : 10, 100)
   def owner = User.get(authenticateService.userDomain().id)
   [bandInstanceList: Band.findAllByOwner(owner, params), bandInstanceTotal: Band.count()]
}
...

Ensuite, lors d’une sauvegarde, on doit définir le propriétaire du Band avant la sauvegarde

grails-app/controllers/fr/xebia/nothunes/domain/BandController.groovy

...
def save = {
   def bandInstance = new Band(params)
   // on définit le propriétaire du Band
   bandInstance.owner = User.get(authenticateService.userDomain().id)
   ...
}
...

Enfin, à l’entrée des méthodes show, edit et update du BandController on teste la légitimité de l’utilisateur courant à agir sur le Band demandé de la façon suivante :

grails-app/controllers/fr/xebia/nothunes/domain/BandController.groovy

...
def show = {
   def bandInstance = Band.get(params.id)
   // on recupere le user courant
   def currentUser = User.get(authenticateService.userDomain().id)
   // s'il existe et qu'il est propriétaire du Band demandé, on autorise la suite
   if (bandInstance && currentUser && bandInstance.owner == currentUser) {
      [bandInstance: bandInstance]
   } else {
   // sinon on affiche un message et on le renvoie sur la liste de ses propres groupes
      flash.message = "${message(code: 'default.not.found.message', args: [message(code: 'band.label', default: 'Band'), params.id])}"
      redirect(action: "list")
   }
}
...

Et, touche finale, on ajoute le lien vers la gestion des Band dans le menu utilisateur :

grails-app/views/menu/_user.gsp

...
   Member manages ...
   
      your profile
      your bands
   
...

La technique est la même pour les Albums :

génération des vues et du contrôleur
protection par les règles de sécurité
ajout de contrôles métier pour filtrer les actions utilisateurs

Pour le détail du code tournant autour des Albums, faites un tour par le GitHub.

Upload d’une image logo pour les `Band`

Pour rendre notre gestion de Band un peu plus sexy, on y ajoute l’upload d’une image qui servira de logo. Rien de plus facile. Nous commençons par ajouter dans la configuration de l’application un chemin vers un répertoire de stockage :

grails-app/conf/Config.groovy

...
storage.image.directory='/tmp/nothunes_images/'
...

Pour pouvoir réutiliser la méthode d’upload de fichier, on crée un service grails dédié :

grails create-service fr.xebia.nothunes.upload.Upload

Puis on crée une méthode saveImage, qui s’occupe de vérifier le type mime du fichier soumis, et de le stocker dans le répertoire défini dans la Config de l’application.

class UploadService {
   def authorizedImageContentType = [ 'image/jpeg' :'jpg', 'image/gif' :'gif', 'image/png' :'png']
   def grailsApplication
   def saveImageFile(anImageFile, name) {
      if (!anImageFile.empty) {
         FileNameMap fileNameMap = URLConnection.getFileNameMap();
         def contentType = fileNameMap.getContentTypeFor(anImageFile.originalFilename)
         if ( authorizedImageContentType.keySet().contains(contentType) ) {
            File storageDir = new File(grailsApplication.config.storage.image.directory)
            if (!storageDir.exists()) {
               if (!storageDir.mkdir()) {
                  log.error 'Directory does not exist and cannot be created '+grailsApplication.config.storage.image.directory
                  return false
               }
            }
            // Pour un minimum de standardisation, on génère le nom du fichier à enregistré à partir du paramètre
            // 'name' et du type mime
            def targetFilename = name + '_logo.' + authorizedImageContentType[contentType]
            // sauvegarde du fichier
            anImageFile.transferTo( new File(grailsApplication.config.storage.image.directory + targetFilename) )
            return targetFilename
         } else {
            log.debug 'Someone tried to upload a non-image file : '+contentType
            return false
         }
      } else {
         return false
      }
   }
}

Ensuite on modifie nos GSP de création et d’édition pour ajouter un champ de type file et faire des formulaires multipart :

grails-app/views/band/create.gsp ET grails-app/views/band/edit.gsp

A la soumission du formulaire, on peut désormais récupérer le fichier et le passer à notre service de sauvegarde en appelant :

uploadService.saveImageFile(request.getFile('logoFile'), bandInstance.name)

Le paramètre passé à la méthode request.getFile() correspond à l’attribut name du champ input de notre formulaire. Encore une fois pour le code complet, voir le GitHub. Il va de soi que ce code n’est pas en l’état complet, et qu’il faut lui ajouter des fonctionnalités techniques. Par exemple, pour supprimer les fichiers lors d’un changement d’image, ou dans d’autres cas tordus. La plupart de ces cas sont traités dans le code du projet. Je vous laisse lire le détail de l’implémentation directement dans le code, cet article étant déjà assez (trop ?) verbeux.

Contrôleur de téléchargement

Nos images sont maintenant dans le répertoire dédié au stockage, mais on ne peut pas les afficher en faisant un lien directement dans nos pages, puisqu’elles sont en dehors de l’arborescence du site. Pour pallier ce problème, on crée un nouveau contrôleur, dédié au téléchargement des images. Le but est de pouvoir insérer dans nos GSP des tag avec un attribut src="..." pointant sur notre contrôleur. Encore une fois la méthode est assez directe :

création d’un DlController :

grails create-controller fr.xebia.nothunes.Dl

création d’une méthode images pour servir l’image en fonction des paramètres de requête :

class DlController {
   def images = {
      String filename = params.id
      log.debug "dl image file : ${filename}"
      def file = new File(grailsApplication.config.storage.image.directory + filename)
      if (file.exists()) {
         response.setContentType("application/octet-stream")
         response.setHeader("Content-Disposition", "attachment; filename=${filename}")
         response.setContentLength(file.readBytes().size())
         response.getOutputStream() << file.readBytes()
      }
      response.flush()
   }
}

Nous pouvons maintenant afficher l’image en créant un lien vers ce contrôleur :

grails-app/views/band/show.gsp

...

...

Sprint review

Comme je l’avais annoncé dans l’intro, ce billet est certainement plus intéressant pour ceux qui débutent avec Grails. Nous avons pu voir une méthode de création d’un contrôleur de bout en bout, et une façon simple de stocker et servir des fichiers à l’extérieur de l’arborescence du site. Retenez que les vues et contrôleurs générés par Grails sont très ouverts, il faut donc bien se souvenir de systématiquement :

les protéger en rajoutant de filtres URL dans le bootstrap
ajouter les contrôles métiers si besoin dans le code du contrôleur
nettoyer les vues des informations techniques, superflues pour les utilisateurs

Mission accomplie : le sprint backlog est bouclé et notre projet est livrable à la fin du sprint, ce qui reste un point crucial. Au prochain épisode, on va s’occuper des classes Tracks et de la navigation pour les internautes, le tout en utilisant massivement AJAX.

Ressources

NoThunes, naissance d’un projet Grails

Aurélien Maury — Thu, 09 Sep 2010 06:19:24 +0000

Les exemples de prise en main du framework Grails ne manquent pas sur la toile. Nous allons tenter de dépasser les Getting started en déroulant la réalisation d’une application web de bout en bout :

Conception
Réalisation
Mise en production
Evolutions et maintenance

Parce qu’il est toujours plus agréable de travailler sur du concret, nous allons réaliser pas à pas une plateforme de musique libre en ligne, que nous baptisons : Projet NoThunes, en clin d’oeil à une autre célèbre plateforme de musique payante. Tout le code du projet est disponible sur GitHub. Ce projet est donc Open Source mais aussi « Open méthode » puisque je vous ferai partager toutes les étapes de conception/réalisation au travers d’une série d’article. Chaque article sera associé à un tag du dépôt GitHub, pour que tout le monde puisse savoir à quelle version on se réfère.

Bien évidemment il y a plus d’une bonne façon de faire. Ce projet est mené dans une optique d’amélioration personnelle et de partage donc n’hésitez pas à discuter les choix techniques et à fournir des solutions alternatives en commentaire.

Dans ce premier billet, nous allons :

définir le product backlog du projet
présenter les classes du modèle
démarrer notre projet
mettre en place la sécurité et les classes du modèle
créer un menu dynamique, différencié par rôle utilisateur

Note technique

Le projet est réalisé avec Grails v1.3.3.

Product Backlog

On distingue 3 rôles utilisateurs :

les administrateurs : par définition omnipotents sur le site pour gérer les comptes utilisateurs, les règles de sécurité, etc.
les internautes : les visiteurs lambda de notre site.
les membres : des internautes qui se seront enregistrés pour accéder à plus de fonctionnalités.

En sachant qu’un membre, s’il est authentifié, doit conserver l’accès à toutes les fonctionnalités des internautes, et qu’un administrateur doit aussi avoir accès aux fonctionnalités des membres.

Le product backlog est trié par business value décroissante. Je vous épargne le chiffrage agile et les fioritures de Scrum.

En tant que …	je dois pouvoir …
administrateur	créer des comptes utilisateurs (administrateurs et membres)
internaute	m’enregistrer pour obtenir un compte membre
membre	voir et mettre à jour mon profil utilisateur
membre	créer des groupes de musique
membre	modifier/supprimer les groupes de musique que j’ai créé
membre	créer/modifier/supprimer des albums liés à mes groupes
membre	créer/modifier/supprimer des morceaux liés à mes albums, en uploadant un fichier mp3
internaute	naviguer dans la hiérarchie de groupes/albums/morceaux
internaute	télécharger un morceau
internaute	écouter un morceau
internaute	rechercher des morceaux par mots-clés

Présentation du modèle de données

Il s’agit d’un cas d’école donc nous simplifions à l’extrême le modèle de données à gérer. Le but n’est pas (encore ) de concurrencer les plateformes en place. On considère donc les objets :

Entité	représente …
Role	les rôles utilisateurs
User	les comptes utilisateurs administrateurs et membres
Band	un groupe de musique, créé par un membre
Album	un album enregistré par un groupe
Track	un morceau, une piste d’un Album

Les attributs de chacun de ces objets sont volontairement simplistes. Cela nous donne le modèle suivant :

Démarrage du projet

Comme tous ceux qui ont déjà survolé Grails le savent, un nouveau projet démarre toujours par le lancement de la commande :

grails create-app nothunes

qui va générer l’arborescence initiale du projet. Comme c’est toujours plus confortable, l’étape suivante sera d’importer ce projet dans votre IDE favori. Pour travailler avec Grails le choix est limité et le support inégal : NetBeans, SpringSource Tool Suite ou IntelliJ IDEA. Au pire un bon vieux vim suffira.

Mise en place de la sécurité

Le plugin de sécurité officiel du projet Grails est depuis peu le Spring Security Core Plugin, couplé au plugin Spring Security UI pour la génération des écrans de CRUD concernant les rôles et utilisateurs. Malgré cela, je lui préfère encore pour quelques temps son prédécesseur : Acegi Plugin, dont le développement a été stoppé, mais qui est plus complet et plus simple à mettre en place. D’autre part, le côté stable du plugin Acegi, comparé au développement hyperactif des plugins Spring Security est assez confortable pour notre projet.

Je vous renvoie donc au précédent article que j’ai écrit sur le sujet. Le package de base à utiliser est : fr.xebia.nothunes.

Création des classes du modèle

Maintenant que nous avons les classes utiles pour la gestion des utilisateurs et de la sécurité, ajoutons un peu de métier dans tout ça. Pour cela on utilise la commande grails create-domain-class pour chacune des entités qu’on souhaite obtenir, puis on passe en édition dessus pour ajouter les attributs. Je trouve dommage de n’avoir pas plus poussé la ressemblance avec Ruby on Rails en autorisant l’ajout des attributs directement en paramètre de la ligne de commande.

Parmi les attributs que l’on donne à chaque classe, il y en a 2 qui sont partout et bien utiles : lastUpdated et dateCreated. Ces 2 attributs indiquent à GORM qu’il faut gérer le timestamping automatique des objets qui les possèdent.

Dynamisons le menu

La documentation du plugin Acegi n’en parle pas mais si vous téléchargez les sources du plugin et que vous allez voir le fichier grails-app/taglib/org/grails/plugins/springsecurity/taglib/AuthorizeTagLib.groovy vous tombez alors sur une taglib tout à fait disponible dès que vous faites usage de ce plugin dans votre projet, et qui offre les tags suivants :

ifAllGranted
ifNotGranted
ifAnyGranted
loggedInUserInfo
isLoggedIn
isNotLoggedIn
loggedInUsername

Nous allons baser la différenciation des menus sur ces tags qui permettent de tester, directement dans les GSP si l’utilisateur courant possède un rôle donné ou non.

La première étape est de séparer le contenu du menu dans un fichier GSP à part. Pour l’instant notre application est telle que générée par grails. Dans le fichier grails-app/views/index.gsp se trouve la page d’accueil par défaut. Elle contient une balise

qui encapsule le menu de gauche de la page d’accueil de l’application.

Pour ajouter plus de flexibilité, on sort cette div dans un nouveau fichier qu’on va placer dans grails-app/views/menu/_nav.gsp (après avoir créé le répertoire menu bien sûr), puis on remplace dans index.gsp la présence de cette div par un tag

Si vous lancez un grails run-app et que vous allez voir la page d’accueil vous remarquerez que rien n’a changé. Le paramètre passé au tag render indique d’inclure le code du fichier GSP situé dans le répertoire menu/ et nommé _nav.gsp (le caractère est indispensable en début de nom).

Ce découpage, allié aux tags du plugin Acegi, nous conduit à un joli découpage propre :

grails-app/views/menu/_nav.gsp



	Welcome,
	Logout
	Login
	No account ? : Register

grails-app/views/menu/_admin.gsp

Admin manages ...

	roles
	users
	requestMaps

grails-app/views/menu/_user.gsp

Member manages ...

	...

grails-app/views/menu/_all.gsp

Menu

	Home

Maintenant il suffira d’utiliser le tag directement dans le layout global pour appliquer le menu sur toute notre application, et on a maintenant un fichier GSP par section de menu avec juste ce qu’il faut de tag de sécurité pour gérer l’affichage contextuel.

Après ce découpage, j’ai travaillé un peu le layout et la css afin d’avoir toutes les pages aux couleurs du projet, c’est toujours plus agréable pour travailler. Pour éviter de surcharger cet article, si vous voulez voir le détail complet du travail de mise en forme, reportez vous au GitHub du projet.

Debriefing

Voilà un bon démarrage pour notre plateforme de musique. Le projet est lancé et nous pouvons travailler dans de bonnes conditions pour la suite. L’état du product backlog :

En tant que …	je peux déjà …
administrateur	créer des comptes utilisateurs (administrateurs et membres)
internaute	m’enregistrer pour obtenir un compte membre

Notre projet est déjà livrable en production avec ces fonctionnalités.

A bientôt pour le prochain épisode :

En tant que …	je pourrai …
membre	voir et mettre à jour mon profil utilisateur
membre	créer des groupes de musique
membre	modifier/supprimer les groupes de musique que j’ai créé
membre	créer/modifier/supprimer des albums liés à mes groupes

Ressources

Refactorisation de bases de données avec Liquibase

Emmanuel Servent — Wed, 03 Dec 2008 15:55:59 +0000

Gérer les modifications d’une base de données est toujours une affaire délicate, que ce soit lors du développement d’une application, pendant le déroulement des tests unitaires et même lors du déploiement en production.
On observe un grand nombre de difficultés, en particulier dans les projets Agile, où les changements sur le modèle de données sont fréquents.
A l’heure actuelle, peu d’outils sont disponibles sur le marché et on pense rarement à les mettre en place sur nos projets. On passe par des solutions « maisons » avec toutes les difficultés que cela peut engendrer.

Tout d’abord, nous ferons un point sur les problèmes posés par la gestion des bases de données, puis nous verrons comment Liquibase, outils de refactorisation, peut nous aider à les surmonter.
Nous continuerons par la description de ses caractéristiques et fonctionnalités principales et par les différents moyens de l’exécuter.
Un petit exercice pour se familiariser avec cet outil viendra conclure ce billet.

Problèmes posés par la gestion des bases de données

Lorsqu’un projet démarre, on se demande souvent si l’on doit installer une base de données par développeur ou une base commune pour tous.
Sur des projets de taille réduite, une base peut suffire et une personne est désignée pour centraliser les changements et éviter ainsi des problèmes de redondance, d’incohérence, etc. Mais dans ce cas-là, dès qu’un changement est effectué, tout le monde doit impérativement mettre à jour le modèle objet sinon il court le risque de ne plus pouvoir lancer l’application. Par ailleurs, les jeux de tests de chaque développeur peuvent « se télescoper » ce qui peut faire perdre beaucoup de temps.
Sur des projets plus importants, il est préférable d’avoir une base par développeur, ce qui cause d’autres difficultés, telles que les répercutions des changements d’un développeur à l’autre ou encore une intégration plus laborieuse.
Se pose aussi la question suivante : comment va-t-on tracer les changements successifs ? Le plus courant reste d’écrire un fichier d’update SQL mais ce n’est pas fait systématiquement pendant les développements et ça manque de structure (au sens XML) et ça pas de signification propre. Par exemple, rien ne permet rapidement de différencier dans un script, le code qui applique les changements de celui qui les rollback (à part les commentaires !); ou les actions comme « Renommer » se traduisent par un DROP COLUMN / ADD COLUMN, ce qui fait perdre le sens de l’action.
Cette dernière question amène à s’en poser d’autres :

comment versionner les changements effectués sur une base de données ?
comment appliquer les changements ? Entre développeurs, mais aussi lorsqu’on passe en intégration, puis en recette, etc. Pour le moment, cette étape prend du temps, que ce soit en amont si on décide de packager correctement les changements, ou en aval lorsqu’il s’agit de dérouler les scripts.

Voilà en quelques phrases les multiples difficultés rencontrées lorsqu’on souhaite refactoriser une base de données.
Regardons à présent ce qu’un outil comme Liquibase peut faire pour nous accompagner dans ce travail délicat.

Refactorisation de bases de données avec Liquibase

Liquibase est un outil qui peut s’intégrer dans un projet (Ant, Maven, etc.) ou se lancer en mode standalone directement en ligne de commande (jar).
Son objectif est de faciliter les modifications apportées à une base de données. Il est particulièrement pratique dans des projets ayant adoptés une méthodologie Agile, car les changements sont nombreux, fréquents et importants.
Le développeur enregistre dans un fichier XML (changelogs.xml), les différentes refactorisations qu’il souhaite effectuer (création d’une nouvelle table, renommage d’un champ, insertion de données, etc.). Ensuite, il suffit de lancer Liquibase en lui donnant les paramètres de connexion à la base de données et le fichier changelogs.xml. Liquibase applique ces modifications et les trace dans une table.
Les fichiers changelogs.xml sont versionnés dans le gestionnaire de sources, et sont considérés comme n’importe quelle autre ressource du projet. La base de données est alors complètement intégrée au cycle de développement.

Après cette brève présentation de Liquibase, intéressons-nous aux caractéristiques principales de cet outil.

Caractéristiques et fonctionnalités principales

Liquibase est Open Source diffusé sous licence LGPL. Ce projet Open Source est actif, la dernière version (1.8.1) est sortie en octobre 2008 et sa road map montre qu’il veut aller encore plus loin. Il supporte un grand nombre de bases de données (> 10) et propose plus de 30 refactorisations possibles. Et pour certaines, il sait même faire un roll back (Ex: renommer une colonne).
Les changements peuvent être regroupés dans un changeset, ce qui permet de conserver un sens et une cohérence aux modifications.
On peut également n’exécuter des changements que sous certaines conditions, ou selon un certain profil d’exécution (utile pour les jeux de tests par exemple).

On peut noter également que Liquibase n’est pas juste « braqué » vers la refactorisation de la base de données, il offre d’autres fonctionnalit

Ce que vous avez peut-être raté au troisième trimestre 2008

Xebia France — Wed, 01 Oct 2008 06:51:57 +0000

Voici la liste des billets les plus lus sur ce blog en juillet, août et septembre :

Les 10 commandements des logs applicatives

Tout au long du cycle de vie d’une application J2EE, il est nécessaire de posséder des traces de qualité :

durant le développement, afin de suivre l’exécution pas à pas et de détecter d’éventuelles anomalies.
durant la recette, afin de corréler anomalies fonctionnelles et exécution du programme.
durant l’exploitation, afin de surveiller la « bonne santé » de l’application.

Mais obtenir des traces de qualité n’est pas un exercice trivial. C’est pourquoi nous vous proposons nos 10 commandements des logs.

Lire cet article »

Simplifiez votre configuration Spring 2.5 avec les annotations

Spring 2.5 est sorti depuis le 19 novembre 2007 comme nous l’annoncions, il y a quelques temps, dans notre revue de presse. Vous avez comme moi sagement mis à jour vos poms Maven2 vers la dernière release de Spring (normalement et la plupart du temps compatible avec les versions 2.0.x).

Mais avez-vous vraiment profité des nouveautés de cette version en terme de configuration ?

Lire cet article »

Programmation concurrente : notions fondamentales

Jouer avec les Threads n’est pas trivial. En informatique de gestion, cette difficulté est heureusement masquée par les serveurs d’application et les API spécifiques. La plupart du temps, ils permettent aux développeurs de s’abstraire de ces contraintes et de se concentrer sur le code métier, moins technique. Il arrive pourtant qu’il faille se relever les manches. Certains besoins vous ont certainement déjà poussé à faire communiquer 2 Threads.
Si le développement n’est pas facile, le debug peut devenir une calamité ! La programmation concurrente ne soulève pourtant que 3 types majeurs de problèmes. Faites le sondage autour de vous, les développeurs associent trop rapidement le mot clé synchronize au multithreading sans en comprendre véritablement le fonctionnement. Demandez-leur ensuite de vous décrire l’utilité du mot clé volatile …

Cet article revient sur les grands principes de la programmation concurrente.

Lire cet article »

Les 10 commandements des logs applicatives

Pablo Lopez — Fri, 11 Jul 2008 08:34:40 +0000

Tout au long du cycle de vie d’une application J2EE, il est nécessaire de posséder des traces de qualité :

durant le développement, afin de suivre l’exécution pas à pas et de détecter d’éventuelles anomalies.
durant la recette, afin de corréler anomalies fonctionnelles et exécution du programme.
durant l’exploitation, afin de surveiller la « bonne santé » de l’application.

Mais obtenir des traces de qualité n’est pas un exercice trivial. C’est pourquoi nous vous proposons nos 10 commandements des logs.

Une application J2EE possède de nombreux types de logs :

Des logs purement techniques, ponctuelles, générées automatiquement ou à la demande comme les dumps (ThreadDump, MemoryDump…).
Des logs provenant de l’environnement d’exécution : logs Système (journaux d’évènements serveur…), logs du serveur applicatif et logs générées par les librairies tierces utilisées par l’application.
Les logs générées par le code développé pour l’application, que nous désignerons comme logs applicatives, sur lesquelles l’équipe projet a la main.

Nous traiterons quasi exclusivement de ces dernières dans cet article.

Les 10 commandements

Les logs sont un outil collaboratif issu d’un processus itératif.
Les logs sont une brique applicative intégrée à l’environnement d’exécution de l’application.
Les logs sont paramétrées en fonction des besoins.
Les logs doivent avoir un impact minimal sur les performances globales de l’application.
Les logs ne doivent pas occasionner de perte d’information.
Une utilisation correcte du logger est la première source d’information.
L’utilisation du framework de logs doit être simplifiée.
Une log efficace doit remplacer le debugger.
Le framework mis en place doit servir exclusivement à produire des logs applicatives.
Les logs permettent de décrire le comportement aux frontières de l’application.

Entrons dans le détail

1 – Les logs sont un outil collaboratif issu d’un processus itératif

Les messages de logs sont destinés à tous les acteurs du projet.
Il est essentiel de garder à l’esprit, lors de de tout développement, qu’une application est vouée à être développée, puis testée, puis exploitée (et éventuellement corrigée). Les logs doivent prendre en compte ces 3 phases de la vie du projet, et permettre à tous les acteurs intervenant lors de ces différentes phases de pouvoir interagir efficacement.
C’est pourquoi chaque méthode devrait au minimum contenir des traces de niveau INFO, WARN et ERROR, chaque niveau ciblant un des acteurs intervenant sur l’application.
De plus, il est difficile de réaliser une ‘bonne’ log du premier coup. La pertinence de celle-ci sera renforcée par des échanges constants entre exploitation et développement (ciblage spécifique d’un problème de performance, anomalie non remontée initialement…).
Chaque correction d’anomalie devrait entrainer l’ajout de traces de niveau DEBUG, qui permettront un diagnostic plus fin en cas de nouvelle occurrence.

2 – Les logs sont une brique applicative intégrée à l’environnement d’exécution de l’application

C’est pourquoi il est essentiel de choisir un framework de logs bien intégré dans le middleware utilisé en production.
Ce framework doit pouvoir être utilisé et paramétré aisément pour obtenir des traces de l’ensemble des composants du système, que ce soit de la part de librairies embarquées tierces comme des systèmes ‘contenants’ (serveur d’application par exemple).
Par exemple, Jakarta Commons Logging est délicat à utiliser avec Websphere.

3 – Les logs sont paramétrées en fonction des besoins

L’écriture d’une log a un coût qu’il ne faut pas négliger. Les performances d’une application en production ne doivent pas être plombées par la génération de lignes de log inutiles. Et il est inenvisageable de demander à chaque développeur d’effacer systématiquement les logs qu’il ajoute (si ces logs ont été utiles à un moment de la vie du projet, il y a de grandes chances qu’elles puissent resservir plus tard).
Il est donc impératif de choisir un framework de logs facilement administrable autant en développement qu’en production :

Pour le développement :

Une configuration de logs par défaut quand on fait un checkout du code (typiquement un fichier log4j.properties dans le classpath configuré au niveau WARN qui redirige vers System.out).
La possibilité de modifier à chaud la configuration des logs lors de l’éxécution de l’application dans l’IDE (typiquement un configureAndWatch sur classpath:log4j.properties).

Pour l’exploitation :

Une configuration par fichiers, séparée du WAR, ce qui permet de livrer / modifier l’application indépendamment de sa configuration (et vice et versa).
Des mécanismes de reconfiguration à chaud par modification de fichier et/ou par API (JMX).

On se doit d’exploiter au maximum les différents Appenders.
Le système d’Appender fourni avec les principaux framework de log permet de gérer finement la persistence de la trace : elle peut être éphémère, par exemple dans une sortie Console, ou bien être archivée périodiquement, en utilisant un système de DailyRollingFileAppender.
Une bonne connaissance des Appenders est essentielle dans la gestion à long terme de la log, aussi bien en terme de performance (utilisation des Loggers asynchrones en utilisant JMS) qu’en terme d’espace disque (configurer correctement les FileAppenders afin que les fichiers restent exploitables).

4 – Les logs doivent avoir un impact minimal sur les performances globales de l’application

La majorité des frameworks de log disposent de méthodes conditionnelles de type log.isEnabled(). Conditionner l’écriture de la log par ces méthodes permet d’économiser des ressources précieuses lors du runtime (construction d’une aggrégation de chaînes de caractères par exemple). La méthode log.(String) effectue bien entendu le même test, mais après la résolution des paramètres.

Evitez :

log.debug("Entrée dans la méthode doIt(), avec param1[" + param1 + "], param2 [" + param2 + "]");

Préférez :

if(log.isDebugEnabled() {
   log.debug("Entrée dans la méthode doIt(), avec param1[" + param1 + "], param2 [" + param2 + "]");
}

5 – Les logs ne doivent pas occasionner de perte d’information

Ce commandement s’applique plus particulièrement aux logs des exceptions.
Il est primordial de qualifier le plus finement possible les exceptions tracées.
C’est pourquoi on privilégiera systématiquement les méthodes Logger#error(java.lang.Object message, java.lang.Throwable t) à Logger#error(java.lang.Object message) , afin de ne pas perdre les informations exposées par la stackTrace.
De plus, on explicitera au maximum le contexte d’exécution dans le message.

Evitez :

...
} catch (UnknownUserException exception) {
   log.error("Une exception s'est produite :" + exception);
   ...
}
...

Préférez :

...
catch (UnknownUserException exception) {
   log.error("L'utilisateur [" + user :"] n'a pas été trouvé dans l'annuaire ["+ myLdap + "]", exception);
...
}
...

NB : le traitement des exceptions fera l’objet d’un prochain article.

6 – Une utilisation correcte du logger est la première source d’information

Chaque niveau de log a ses spécificités. Bien définir l’utilisation de chacun de ces niveaux permet de s’affranchir du risque de logger trop, ou trop peu, aux différentes étapes du cycle de vie de l’application. Utiliser des niveaux de log cohérents et pertinents donne donc un premier niveau d’information essentiel.
Voici les niveaux existants dans les différents frameworks, et leur utilisation communément admise (Log4J/Apache Commons Logging – java.util.logging) :

TRACE / FINE : niveau d’information ultrafin.
DEBUG / CONFIG : information détaillée pour le suivi d’exécution du programme (identification et résolution d’éventuelles anomalies).
INFO : information essentielle sur le programme, suivi de l’exécution d’un point de vue global.
WARN / WARNING : situation d’exécution non idéale (utilisation d’API dépréciées, ressource non critique absente…).
ERROR / : situation d’erreur ou inattendue, qui n’entraine pas forcément une situation de blocage (accès à un service externe non critique et dont l’accès est re-testé périodiquement).
FATAL / SEVERE : situation d’erreur critique, qui entraîne un blocage voire un arrêt du système (problème de connexion à la DB par exemple).

7 – L’utilisation du framework de logs doit être simplifiée

L’ajout de log doit être le moins contraignant possible pour les développeurs. De plus, dans le cadre d’une équipe de développement, il n’est pas toujours facile pour un développeur de savoir quelles sont les informations pertinentes à tracer, s’il n’est pas l’auteur de la classe suivie. Il faut donc faciliter la création de logs de qualité…

… en rendant ses classes explicites.
En surchargeant la méthode Object#toString(), afin qu’elle renvoie les informations principales d’une classe, on peut facilement tracer les informations en entrée ou sortie de méthode, et expliciter le contexte applicatif de l’exécution. Attention, les méthodes toString() ne doivent jamais lancer d’exception.

Evitez :

public String toString(){
   StringBuilder sb = new StringBuilder();
   sb.append(getClass().getName())
   // Ici, on peut avoir une NullPointerException
   sb.append(" myfield=[").append(this.myfield.toString()).append("]");
   return sb.toString();
}

Préférez :

public String toString(){
   return new ToStringBuilder(this).append("myfield", this.myfield).toString();
}

… en définissant, documentant et partageant la hiérarchie de logger
L’utilisation la plus répandue de la hiérarchie de Logger consitste à déclarer un logger par classe.

private final static Logger LOGGER = Logger.getLogger(MyClass.class);

Cependant, il est souvent interessant de réfléchir à une hiérarchie plus poussée, par domaines technico-fonctionnels par exemple.
Il est parfois même utile de déclarer plusieurs Loggers par classe (un logger pour le suivi de l’exécution générale, un logger particulier pour surveiller une fonction critique)
Afin d’avoir des logs cohérentes, il est nécessaire de définir et de documenter la hiérarchie des Loggers au plus tôt de la vie du projet, et de la communiquer à l’ensemble des équipes, afin d’unifier les méthodes de logging.

8 – Une log efficace doit remplacer le debugger

Il existe un grand nombre de circonstances qui rendent impossible l’utilisation d’un debugger, dont la plus évidente, la nécessité de debugger un système en production. Mais on pourrait aussi citer les traitements multi-threadés, etc
Dans ces cas particuliers, l’utilisation de la log doit se substituer au débuggeur, et répondre aux mêmes besoins : « exécution » pas à pas des algorithmes, inspection des valeurs d’entrée et de sortie des points de passage clefs, parcours des différentes couches de l’application, surveillance des entrées / sorties du système.
La mise à disposition d’un tel outil est vitale pour les développeurs, car trop souvent, les équipes de développements sont dans l’obligation d’attendre plusieurs occurrences d’un même bug en production avant d’être aptes à déterminer ses conditions précises d’occurrence.

9 – Le framework mis en place doit servir exclusivement à produire des logs applicatives

Les logs sont et doivent être un outil technique. Utiliser le framework de log pour générer des traces ‘fonctionnelles’ (audit, génération de traces métier, constitution de fichiers métier) présente un risque majeur de perte de données. En effet, le risque d’effacement des logs est réel : la configuration des différents Appenders provoquent souvent un effacement périodique des logs, le comportement global des logs peut être totalement modifié dans le cadre d’une intervention de type ‘troubleshooting’ (limitation des traces à un sous-ensemble de classes très restreint)…
En revanche, il est possible d’utiliser les fonctionnalités offertes par le framework de logs (RollingFileAppender, etc) mais il faut que cette utilisation soit dissociée du fonctionnement et de la configuration des logs applicatives.

10 – Les logs permettent de décrire le comportement aux frontières de l’application

L’un des enjeux majeurs des Systèmes d’Information actuels est l’intégration des différentes composantes de ce SI.
Il est très souvent ardu de suivre intégralement la chorégraphie entre les différents composants, aboutissant à la réponse ‘finale’ du système.
D’où la nécessité de tracer le plus finement chaque appel entrant ou sortant du système, en utilisant :

l’heure de cet appel
le système appelant / appelé (par HTTP, JMS, SOAP…)
une description concise de l’interaction sollicitée
éventuellement, au niveau le plus fin (TRACE), le message émis / reçu

Certaines librairies Open Source, comme commons-http-client (HTTP) et CXF (SOAP) offrent ces fonctionnalités de manière native.

En conclusion

L’application de ces 10 commandements nous pousse de manière assez naturelle à l’utilisation de Log4J, qui répond à l’ensemble des besoins listés ci dessus.
Le choix de Commons Logging ou de java.util.logging, si il est loin d’être proscrit, demande une plus grande vigilance (voir les articles ‘Critiques’ cités en références).

Quoi qu’il en soit, il est primordial d’avoir en tête ces bonnes pratiques dès le démarrage d’un projet. En effet, au même titre que les tests unitaires ou que la documentation interne du code, les logs ne peuvent être repoussées à ‘plus tard’ : plus le temps passe, plus la complexité et le volume de code à ‘tracer’ augmentent.
Ceux qui ont expérimenté « l’intervention pompier » sur une application peu ou mal loggée savent qu’il est quasiment impossible d’otenir des logs globales et/ou pertinentes a posteriori (d’autant qu’il est difficile de ‘budgeter’ une telle opération, dont la valeur métier est nulle).

Références

Les frameworks de logs les plus connus

Simple Logging Facade for Java (SLF4J) : A simple facade for various logging APIs allowing to the end-user to plug in the desired implementation at deployment time.
Log4J : Site officiel du framework Log4J
Java Commons Logging : Site officiel du framework Commons Logging
java.util.logging : API de java.util.logging

Critiques

Rod Waldhoff’s Weblog – Commons Logging was my fault : une critique de Commons Logging par son auteur
Tomcat Docs – Logging : The default implemenatation of java.util.logging provided in the JDK is too limited to be useful. …

Ce que vous avez peut-être raté au second trimestre 2008

Xebia France — Tue, 01 Jul 2008 15:31:55 +0000

Voici la liste des billets les plus lus sur ce blog en avril, mai et juin :

Urbanisation pour les nuls

Le XKE (Xebia Knowledge Exchange) de mars a été l’occasion de présenter la démarche d’urbanisation. L’exemple présenté ne suivait pas le déroulement type : une démarche d’urbanisation est adaptée suivant les projets et organisations auxquels elle est appliquée.
Le but de ce billet est de dérouler cette démarche de manière simplifiée. Cela nous donnera l’occasion de définir le vocabulaire employé, et de faire un constat sur cette démarche.
Nous déroulerons l’exemple avec une approche TOP-DOWN, c’est-à-dire que l’analyse commence par la définition de la stratégie pour descendre ensuite au travers des différentes strates du SI. Pour l’exemple, nous prendrons le cas d’une agence de voyages qui achète et vend des voyages.

Lire cet article »

Les 10 commandements des tests unitaires

Les tests unitaires ne sont pas qu’une bonne pratique des méthodes agiles, ils sont un véritable pré-requis à la mise en place d’un développement itératif.
Le refactoring et la modification d’une base de code existante, bien que facilités par les environnements de développement actuels, comportent un évident risque de régression, en partie couvert par les tests unitaires.

Vous trouverez dans ce billet nos 10 commandements des tests unitaires.

Lire cet article »

SpringSource Application Platform : la brèche dans Java EE

L’annonce de SpringSource a des allures de schisme. Après des années à critiquer la complexité et le monolithisme de Java Enterprise Edition (Java EE), les équipes de Rod Johnson ont franchi le Rubicon et proposent un serveur d’applications Java qui ne reposera pas sur la monolithique spécification Java EE.
SpringSource Application Platform se limite à quelques fragments de cette spécification (principalement Servlet et JPA) assemblés dans un conteneur OSGI augmenté de quelques particularités Spring. Les applications web ne seront plus assemblées sous forme de WAR avec un fichier web.xml mais sous forme de plusieurs bundles OSGI avec des fichiers de configuration Spring.

Lire cet article »

Hands on Wicket – Partie 4

Manuel Eveno — Wed, 23 Apr 2008 07:31:13 +0000

Dans les précédents articles sur Wicket, nous avons exploré les bases du framework. Nous allons nous intéresser maintenant à quelques fonctionnalités avancées comme le templating ou l’internationalisation.

Les mécanismes de templating

Avec Wicket, même le templating est très simple. L’implémentation du templating dans Wicket est très proche de la façon de faire de SiteMesh (au moins pour la partie HTML). La mise en œuvre se fait par des mécanismes d’héritage : Wicket nomme ceci le Markup Inheritance. Prenons un exemple concret.

J’ai une page de template qui va définir le header et le footer commun de mon site. Ensuite le body va varier selon les pages. Je crée donc un fichier HTML et la classe Java associée. Dans le fichier HTML, j’ai juste besoin de préciser où va s’insérer le contenu des fils en positionnant la balise .

Ce qui donne dans le fichier HTML du parent :

La balise permettra plus tard d’ajouter des éléments (comme le titre de la page) dans le header de la page à partir des enfants. Cette zone est en quelque sorte une zone modifiable du template.

La classe Java (ParentPage.java) associée :

package test.view;
// import ...;
public abstract class ParentPage extends WebPage {
	private static final long serialVersionUID = 1L;
	public ParentPage() {
		super();
		createTemplateComponents();
	}
	protected void createTemplateComponents() {
		// Ajout des composants communs dans le header et le footer
	}
}

Pour les pages du fils, je vais, comme d’habitude en Wicket, définir le fichier HTML et la classe Java associée. La classe Java va hériter de la classe ParentPage (les composants ajoutés et gérés par la page parente seront donc ajoutés à ma page).

package test.view;
// import ...;
public class ChildPage extends ParentPage {
	private static final long serialVersionUID = 1L;
	public ChildPage() {
		super();
		createComponents();
	}
	protected void createComponents() {
		// Ajout des composants propres à cette page
	}
}

Pour ce qui est du fichier HTML, je dois encadrer le code HTML qui doit être inséré dans le code HTML du parent par la balise .



	Page fille !



	
	Hello dans le fils

Cette fois-ci, dans le header de la page et entre les balises , j’insère la balise . Ce titre sera inséré dans la page finale rendue à l’utilisateur. De même, je peux ajouter des imports CSS ou JavaScript propres à la page fille.</p><p>Et voilà, tout ce que j’ajouterai dans la page parent apparaitra aussi dans les pages filles !</p><h3><a title="Linternationalisation" name="Linternationalisation"></a>L’internationalisation</h3><p>L’internationalisation se fait de la façon habituelle, c’est à dire via l’utilisation de fichiers properties nommés en fonction de la langue supportée. Avec Wicket, il est possible d’adjoindre à chaque composant (page, formulaire, composant ‘maison’) un fichier properties portant le même nom et situé dans le même package que la classe associée.</p><p>Exemple : Le fichier properties contenant les traductions pour la page fr/xebia/wicket/demo/HomePage.java doit être fr/xebia/wicket/demo/HomePage.properties (<a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/resource/loader/ComponentStringResourceLoader.html" title="par défaut">par défaut</a> bien sûr).</p><p>L’accès aux traductions se fait de trois manières :</p><ul><li>Dans le code HTML, en ajoutant la balise <wicket:message key= »stringKey » /></li><li>Dans le code Java, en utilisant un type de modèle particulier : le <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/model/StringResourceModel.html" title="StringResourceModel">StringResourceModel</a>. Ce modèle peut être passé en paramètre de tous les composants Wicket (Label, TextField, etc)</li><li>Toujours dans le code Java, en appelant la méthode <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/Component.html#getLocalizer()" title="getLocalizer().getString()">getLocalizer().getString()</a> sur n’importe quel composant.</li></ul><p>Cependant, Wicket ne s’est pas arrêté là. Pour la classe StringResourceModel, la clé passée en paramètre peut être dynamique. Exemple : « product.${product.id} ». Le modèle passé en paramètre permet de résoudre la clé (dans ce cas, l’objet Product contient un champ id).</p><p>L’autre particularité, ici, réside dans le mécanisme de recherche de la traduction. Wicket va utiliser la hiérarchie de classes pour parcourir les fichiers properties.</p><p>Prenons en exemple la hiérarchie suivante :</p><pre class="brush: java; title: ; notranslate"> + fr/xebia/wicket/BasePage.java + fr/xebia/wicket/MyPage.java </pre><p>Si dans la classe MyPage (ou la page HTML correspondante), je recherche une traduction, Wicket va rechercher la valeur en parcourant dans cet ordre les fichiers properties :</p><ul><li>fr/xebia/wicket/MyPage.properties</li><li>fr/xebia/wicket/BasePage.properties</li><li>org/apache/wicket/markup/html/WebPage.properties</li><li>Et ainsi de suite, en remontant la hiérarchie de classe …</li></ul><p>Pour les cas où cette façon de faire implique trop de duplication de properties, il est aussi possible de charger arbitrairement des fichiers properties dans la classe principale de l’application) en configurant les <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/settings/IResourceSettings.html" title="IResourceSettings">IResourceSettings</a>.</p><h3><a title="Modifierdynamiquementlesattrib" name="Modifierdynamiquementlesattrib"></a>Modifier dynamiquement les attributs des balises HTML</h3><p>Le cas d’usage typique pour ce genre de besoin est la modification dynamique de l’attribut « class » d’un tag HTML pour modifier le rendu en jouant avec les CSS. Un autre type d’utilisation est d’écrire un appel JavaScript dynamique en définissant par exemple l’attribut « onClick » d’un bouton.</p><p>Différentes approches sont proposées dans <a href="http://cwiki.apache.org/WICKET/how-to-modify-an-attribute-on-a-html-tag.html" title="cette page">cette page</a> du Wiki mais nous n’en retiendrons ici qu’une seule. Il s’agit d’utiliser la classe <a href="http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wicket/AttributeModifier.html" title="AttributeModifier">AttributeModifier</a>. Cette classe est très simple dans son usage : on ajoute une instance de cette classe à n’importe quel élément Wicket héritant de Component comme suit :</p><pre class="brush: java; title: ; notranslate"> TextField textField = new TextField("myField", new Model()); textField.add(new AttributeModifier("class", true, new Model("formFields"))); </pre><p>Dans cet exemple, un attribut « class » sera ajouté même s’il n’est pas présent dans le HTML (signification du paramètre « true »). La valeur de l’attribut est donnée par le modèle passé en 3ème position.</p><p>Il est aussi possible de modifier le comportement par défaut en surchargeant la méthode getObject() :</p><pre class="brush: java; title: ; notranslate"> textField.add(new AttributeModifier("class", new Model() { public Object getObject(final Component component) { String cssClass; if ( test.getAlarmState() ) cssClass = "alarm"; } else { cssClass="noAlarm"; } return cssClass; } })); </pre><p>C’est tout pour cette fois. Vous en savez déjà assez pour commencer votre nouveau projet avec Wicket. D’autres aspects de Wicket sont à découvrir : avec Wicket, on peut aussi faire de l’<a href="http://cwiki.apache.org/WICKET/ajax.html" title="AJAX">AJAX</a>, des <a href="http://cwiki.apache.org/WICKET/testing-pages.html" title="tests d'IHM">tests d’IHM</a> et plein d’<a href="http://cwiki.apache.org/WICKET/reference-library.html" title="autres choses">autres choses</a>.</p><p>A l’occasion de ces articles, un projet de démonstration de wicket a été créé et est disponible (sous License Apache 2.0) sous le <a href="http://code.google.com/p/xebia-france">projet xebia-france</a> hébergé chez GoogleCode. Voici le <a href="http://code.google.com/p/xebia-france/source/checkout">lien direct</a> vers le repository Subversion.</p> </article> <article> <h1>Les 10 commandements des tests unitaires</h1> <p>Guillaume Carre — Fri, 11 Apr 2008 07:13:51 +0000</p> <div style="float: right;"> </div><p>Les tests unitaires ne sont pas qu’une bonne pratique des méthodes agiles, ils sont un véritable pré-requis à la mise en place d’un développement itératif.<br /> Le refactoring et la modification d’une base de code existante, bien que facilités par les environnements de développement actuels, comportent un évident risque de régression, en partie couvert par les tests unitaires.</p><p>Vous trouverez ci-dessous nos 10 commandements des tests unitaires.</p><div style="clear:both;"></div><ol><li>Un test unitaire doit être véritablement <strong>unitaire</strong>. La classe testée doit l’être en isolation complète, afin de ne tester qu’une classe (et une méthode) à la fois, le SUT (<a href="http://en.wikipedia.org/wiki/System_Under_Test" title="System Under Test" >System Under Test</a>).</li><li>Si une classe est difficile à tester, il est temps de <strong>faire du refactoring</strong>. Est-elle trop volumineuse ? Présente-t-elle trop de dépendances ? Profitez de l’occasion pour la découper et déplacer du code dans des classes annexes.</li><li>Un test unitaire doit <strong>s’exécuter le plus rapidement possible</strong> afin d’avoir un retour quasi immédiat. Il faut donc proscrire l’accès à des fichiers, des bases de données ou des services externes dans un test unitaire. Un test qui dialogue avec une base de données n’est pas un test unitaire, c’est un <strong>test d’intégration</strong>.</li><li>Le code d’un test unitaire fait partie du code applicatif. Il doit donc, à l’image du reste de l’application, respecter des conventions de code. <strong>Chouchoutez vos tests unitaires</strong>, faites du refactoring sur leur code, respectez les bonnes pratiques, présentez le code à vos collègues, codez les tests en <a href="http://en.wikipedia.org/wiki/Pair_Programming" title="pair programming" >pair programming</a>, sans quoi on trouvera certainement dans votre application des <a href="http://xunitpatterns.com/Test%20Smells.html" title="tests smells" >tests smells</a>, des <strong>tests unitaires peu lisibles et difficilement maintenables</strong>. De bons tests unitaires doivent permettre à leur lecture de comprendre le comportement du SUT.</li><li>Isolez les dépendances de la classe testée grâce à l’<a href="http://martinfowler.com/articles/injection.html" title="injection de dépendances" >injection de dépendances</a>.</li><li>Ne testez qu’un comportement à la fois. Soyez raisonnable et gardez le test simple, lisible et <strong>concentré sur ce comportement</strong>.</li><li>Pensez à utiliser un <a href="http://www.easymock.org" title="framework de mocks" >framework de mocks</a> pour <strong>injecter les dépendances sous forme de bouchons</strong>. Ces outils permettent de respecter le commandement n°1. Ne bannissez pas pour autant les bouchons codés à la main ; ils peuvent parfois rendre le test unitaire plus simple et plus lisible qu’avec un mock provenant d’un framework.</li><li>Identifiez précisément les étapes <strong>setup, exercise, verify, teardown</strong> dans votre code. On retrouve ces quatre étapes dans tout test unitaire.</li><li>Ne vous concentrez pas sur une <strong>couverture de code à 100%</strong>. Ce n’est qu’un indicateur technique, qui doit être examiné dans le contexte de l’application, et qui ne prouve en rien la qualité du code et des tests unitaires.</li><li>Ne développez pas vos tests unitaires <strong>« plus tard »</strong>. Si vous n’utilisez pas l’approche TDD, développez-les le plus tôt possible.</li></ol><p>Les deux premières règles sont incontournables.</p><p>Ne tester qu’une classe à la fois facilite la maintenance et la correction des tests unitaires, et permet de se concentrer sur le comportement de la classe à tester. Quand un test unitaire échoue, on sait exactement d’où provient l’erreur (elle est soit dans le test unitaire si le comportement du SUT a changé, soit une modification du SUT a cassé son comportement attendu).</p><p>Si vous développez votre code sans penser aux tests unitaires que vous ferez <strong>« plus tard »</strong>, il sera difficilement testable et vous perdrez un temps précieux pour corriger les erreurs de design. <strong>« Design for testability »</strong>, en particulier, utilisez au maximum l’injection de dépendances, qui est obligatoire pour l’injection des bouchons. Si vous utilisez Spring ou un autre framework d’injection de dépendances, cela ne devrait pas être trop compliqué …</p><p>Pour aller plus loin, nous vous recommandons vivement la bible <a href="http://www.amazon.fr/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054/ref=sr_1_1?ie=UTF8&s=english-books&qid=1207388575&sr=8-1" title="xUnit Test Patterns" >xUnit Test Patterns</a>, de Gerard Meszaros, dans laquelle vous retrouverez une présentation sur l’automatisation des tests, un catalogue de « test smells », et une liste complète de « test patterns », des meilleures pratiques de tests unitaires qui ont émergé ces dernières années.</p><p>Enfin, vous trouverez également sur les blogs suivants une liste de commandements:</p><ul><li><a href="http://monkeyisland.pl/2008/01/31/10rules/" title="10 rules of (unit) testing" >10 rules of (unit) testing</a> de Szczepan Faber, auteur du nouveau framework de Mocks qui monte, <a href="http://code.google.com/p/mockito/" title="Mockito">Mockito</a></li><li><a href="http://codeforfun.wordpress.com/2007/11/07/ten-tdd-commandments/" title="Ten T.D.D. Commandments" >Ten T.D.D. Commandments</a> de Cliff</li><li><a href="http://curious-attempt-bunny.blogspot.com/2007/11/ten-commandments-of-unit-testing.html" title="Ten commandments of unit testing" >Ten commandments of unit testing</a> de Merlyn Albery-Speyer</li><li><a href="http://docs.codehaus.org/display/ASH/Home" title="Ashcroft - Ten Commandments of Unit Tests" >Ashcroft – Ten Commandments of Unit Tests</a> de Aslak Hellesøy et Shane Duan, une des premières tentatives sur le sujet, hélas interrompue après le quatrième commandement.</li></ul> </article> <article> <h1>Ce que vous avez peut-être raté au premier trimestre 2008</h1> <p>Xebia France — Thu, 03 Apr 2008 16:12:35 +0000</p> <p>Voici la liste des billets les plus lus sur ce blog en janvier, février et mars :</p><h4><a href="http://blog.xebia.fr/2008/01/10/scrum-ou-xp-scrum-et-xp/">Scrum ou XP ? Scrum ET XP !</a></h4><p>Lors des <a href="http://www.rencontresagiles2007.com/">Rencontres Agiles</a>, que nous avons co-organisées en décembre dernier – et qui, soit dit en passant, ont rencontré un fort et encourageant succès -, plusieurs personnes m’ont demandé si, pour démarrer un projet agile, il était préférable de choisir eXtreme Programming (XP) ou Scrum. La réponse est simple : il faut adopter les deux !<br /> La complémentarité de Scrum et XP est communément admise. Scrum se positionne au niveau de la gestion et de l’organisation de projet là où XP se positionne au niveau des activités de développement. C’est la raison pour laquelle ces deux approches fonctionnent si bien ensemble : elles adressent des problématiques différentes et se complètent mutuellement.</p><p>Cet article propose une présentation sommaire de Scrum et de la façon dont elle (il? non, allez, c’est plutôt une fille) s’articule avec eXtreme Programming… Bonne lecture !</p><p><a href="http://blog.xebia.fr/2008/01/10/scrum-ou-xp-scrum-et-xp/">Lire cet article »</a></p><h4><a href="http://blog.xebia.fr/2008/02/07/lanalyse-de-couverture-de-code-en-java/">L’analyse de couverture de code en Java</a></h4><p>Il ne reste plus grand’monde pour soutenir que l’écriture de tests unitaires automatisés est une perte de temps sur un projet logiciel – la notion de dette technique entre dans les moeurs. Cette prise de conscience salutaire se heurte pourtant souvent à deux grandes catégories de difficultés :</p><ul><li>Le conservatisme – pour ne pas dire la stupidité – de certains chefs de projet, qui persistent à voir dans l’écriture des tests une activité contre-productive, qui servira de variable d’ajustement au moindre coup de grisou</li><li>L’existant : quand le projet n’a pas systématisé la pratique du test dès son origine et que la multiplication des anomalies tardives le pousse à la réintroduire. Par où commencer ?</li></ul><p>Pour le premier point, la solution passe par un effort pédagogique, ou, pour les cas désespérés, par une reconversion imposée ou un congé sabbatique.<br /> Pour le second, il faut un peu de bon sens, et un peu d’outillage.</p><p>C’est sur le deuxième aspect qu’interviennent les outils d’analyse de <strong>couverture de code</strong> (ou « <strong>code coverage</strong> » en anglais). Dans la suite, nous verrons que ces outils ne permettent pas d’évaluer les tests unitaires d’un point de vue qualitatif, mais qu’ils peuvent en revanche apporter au bon sens un précieux appui en répondant aux questions suivantes :</p><ul><li>Quels sont les tests unitaires déjà en place ?</li><li>Les tests sont-ils en phase (à jour) avec le code qu’ils testent ?</li><li>Les fonctions critiques de l’application sont-elles couvertes par les tests ?</li></ul><p><a href="http://blog.xebia.fr/2008/02/07/lanalyse-de-couverture-de-code-en-java/">Lire cet article »</a></p><h4><a href="http://blog.xebia.fr/2008/05/02/java-agent-instrumentez-vos-classes/">Un nouveau type d’architecte: l’Architecte Agile</a></h4><p>On observe ces derniers temps de multiples débats sur le fait de savoir si une équipe agile a besoin d’un architecte en son sein, et sur la valeur ajoutée de ce dernier sur un projet agile alors que l’architecture évolue à chaque itération.<br /> Les architectes « Tour d’Ivoire » se révèlent petit à petit être le maillon faible des projets agiles. Les responsabilités des architectes traditionnels sont distribuées ci et là au sein des équipes agiles, leur supprimant au passage des tâches qui leur étaient auparavant attribuées.<br /> Une nouveau genre est en train d’apparaître et de sortir du lot comme le prédit la théorie de l’évolution de Charles Darwin – question d’adaptation. Le rôle d’un Architecte Agile ne doit pas susciter de questions et tout membre d’une équipe agile vous le confirmera: ce sont des équipiers qui apportent l’une des plus grandes valeurs ajoutées.</p><p>Alors qui est cet Architecte Agile ? Comment savoir si l’architecte de votre équipe est un Architecte Agile ?</p><p><a href="http://blog.xebia.fr/2008/05/02/java-agent-instrumentez-vos-classes/">Lire cet article »</a></p> </article> <article> <h1>Hands on Hibernate Search : Recherche full-text</h1> <p>Christophe Heubès — Fri, 28 Mar 2008 07:29:48 +0000</p> <p>Comme nous l’avions vu dans notre précédent billet <em>(« <a href="http://blog.xebia.fr/2008/03/06/introduction-a-hibernate-search-googling-your-persistent-domain-model/">Introduction à Hibernate Search (Googling your Persistent Domain Model)</a>« )</em>, Hibernate Search vise à réconcilier la recherche full-text et les modèles de persistance relationnels.<br /> Pour ce faire, Hibernate Search se base sur <a href="http://lucene.apache.org">Apache Lucene</a>, un moteur d’indexation et de recherche full-text standalone très puissant et permet ainsi d’utiliser ses capacités dans le cadre d’une couche de mapping Hibernate.</p><p>Ce billet présente, au travers d’un exemple simple, les capacités de recherche full-text d’Hibernate Search.<br /> L’exemple proposé permet l’indexation et la recherche de documents auxquels sont attachés des auteurs.<br /> Vous retrouverez l’ensemble des sources présentées dans ce billet dans le repository <a href="http://code.google.com/p/xebia-france/source/browse/trunk/search/hibernate-search-demo/">SVN de Xebia France</a>.</p><h3>Structuration du projet et démarrage</h3><p>Le projet utilise maven. Une fois les sources récupérées depuis notre dépot SVN, vous pouvez donc générer une configuration Eclipse à l’aide de la commande :</p><pre class="brush: bash; title: ; notranslate"> mvn eclipse:eclipse </pre><p>Le projet déclare des dépendances vers :</p><ul><li>hibernate-search en version 3.0.0.ga.</li><li>hibernate-annotations en version 3.3.0.ga.</li><li>hibernate-entitymanager en version 3.3.1.ga.</li><li>lucene-analyzers en version 2.3.1.</li></ul><pre class="brush: xml; title: ; notranslate"> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-search</artifactId> <version>3.0.0.ga</version> </dependency> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-annotations</artifactId> <version>3.3.0.ga</version> </dependency> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-entitymanager</artifactId> <version>3.3.1.ga</version> </dependency> <dependency> <groupId>org.apache.lucene</groupId> <artifactId>lucene-analyzers</artifactId> <version>2.3.1</version> </dependency> </pre><p>Le projet est structuré sur l’arborescence classique maven :</p><ul><li><code>src\main\java</code> contient les sources du projet :<br /> - Le package <code>fr.xebia.demo.hibernate.search.model</code> contient les entités persistées qui seront mappées dans un index Lucene.<br /> - Le package <code>fr.xebia.demo.hibernate.search.analysis</code> contient un analyseur de langue anglaise.</li><li><code>src\main\test</code> contient les sources des tests. Les tests « unitaires » ont ici été détournés pour faire la démonstration des capacités d’indexation et de recherche full-text d’Hibernate Search.</li></ul><h3>Mapping des entités sur l’index</h3><p>Le mapping des entités dans un index Lucene se fait par annotation :</p><ul><li>L’annotation <strong><code>@Indexed</code></strong> déclare une classe comme indexable</li><li>L’annotation <strong><code>@Analyzer</code></strong> définit l’implémentation d’analyseur syntaxique à utiliser pour cette indexation :</li></ul><pre class="brush: java; title: ; notranslate"> @Entity @Indexed @Analyzer(impl = SimpleEnglishAnalyzer.class) @Table(name = DOCUMENT_TABLE_NAME) public class Document { </pre><ul><li>L’annotation <strong><code>@DocumentId</code></strong> indique l’attribut à utiliser en tant qu’identifiant. Cet identifiant est utilisé par Hibernate Search afin d’assurer l’unicité des entités dans l’index :</li></ul><pre class="brush: java; title: ; notranslate"> @Id @DocumentId @Column(name = "id", nullable = false) public Long getId() { return this.id; } </pre><ul><li>L’annotation <strong><code>@Field</code></strong> marque un attribut comme devant être indexé. La propriété <code>index = Index.TOKENIZED</code> indique que le texte va être « tokenisé » via l’analyseur définit au niveau de la classe. La propriété <code>store = Store.NO</code> indique que le texte de l’attribut ne sera pas stocké dans l’index.</li></ul><pre class="brush: java; title: ; notranslate"> @Column(name = "title") @Field(index = Index.TOKENIZED, store = Store.NO) public String getTitle() { return title; } @Column(name = "summary") @Field(index = Index.TOKENIZED, store = Store.NO) public String getSummary() { return summary; } </pre><ul><li>Dans le cadre d’une association, l’annotation <strong><code>@IndexedEmbedded</code></strong> indique que l’objet associé doit être indexé dans l’index de l’entité racine. Dans notre exemple, cette méthode permet d’effectuer une recherche full-text sur les entités de type <code>Document</code> basée sur les propriétés de son attribut <code>author</code> :</li></ul><pre class="brush: java; title: ; notranslate"> @ManyToOne(cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }, fetch = FetchType.EAGER) @JoinColumn(name = "author_id") @Fetch(FetchMode.JOIN) @ForeignKey(name = "fk_document_author_id") @IndexedEmbedded public Author getAuthor() { return author; } </pre><h4>Analyseur et tokeniseur</h4><p>La « tokenisation » consiste à découper un texte en mots. Ce découpage se fait en suivant les règles définies dans un analyseur. Hibernate Search propose par défaut l’utilisation de <code>org.apache.lucene.analysis.standard.StandardAnalyzer</code>.<br /> Il est possible de définir son propre analyseur en étendant la classe abstraite <code>Analyzer</code> dont il faut implémenter la méthode</p><pre class="brush: java; title: ; notranslate"> public abstract TokenStream tokenStream(String fieldName, Reader reader); </pre><p>C’est ce que propose la classe <code>SimpleEnglishAnalyzer</code> :</p><pre class="brush: java; title: ; notranslate"> @Override public final TokenStream tokenStream(String fieldName, Reader reader) { if (fieldName == null) throw new IllegalArgumentException("fieldName must not be null"); if (reader == null) throw new IllegalArgumentException("reader must not be null"); TokenStream result = new StandardTokenizer(reader); result = new StandardFilter(result); result = new LowerCaseFilter(result); result = new StopFilter(result, stopTable); result = new PorterStemFilter(result); return result; } </pre><p>Cette implémentation passe les mots en minuscule, supprime les mots courants, et utilise le <code>PorterStemFilter</code> pour supprimer les terminaisons morphologiques communes.</p><h3>Configuration Hibernate Search</h3><p>La configuration d’Hibernate Search est câblée sur le système d’écoute d’événements. Elle est donc transparente avec Hibernate Annotations.<br /> Dans le cadre de notre exemple, la configuration Hibernate est réalisée dans le set up de la classe <code>HibernateSearchDemoTestCase</code>. La seule propriété de configuration que nous spécifions pour Hibernate Search est le répertoire de stockage des index :</p><pre class="brush: java; title: ; notranslate"> @Override protected void setUp() throws Exception { AnnotationConfiguration cfg = new AnnotationConfiguration(); [...] cfg.setProperty("hibernate.search.default.indexBase", "target"); [...] } </pre><h3>Création et indexation des données de test</h3><p>La création des données de test se fait dans la méthode <code>populateDB</code> de la classe de test <i>(<code>HibernateSearchDemoTestCase</code>)</i>. L’indexation des données de test est faite de manière transparente au moment du commit de la transaction :</p><pre class="brush: java; title: ; notranslate"> Transaction tx = this.testSession.beginTransaction(); Author bTate = new Author( "Bruce", "Tate", "Bruce A. Tate is a [...]"); [...] Document beyondJava = new Document(); beyondJava.setTitle("Beyond Java"); beyondJava .setSummary("In Beyond Java, [...]"); beyondJava.setAuthor(bTate); this.testSession.persist(beyondJava); [...] tx.commit(); </pre><h3>Recherches full-text sur les entités</h3><p>La recherche full-text de documents dans l’index se fait au travers de la méthode <code>searchDocuments</code> de la classe de test <i>(<code>HibernateSearchDemoTestCase</code>)</i> :</p><pre class="brush: java; title: ; notranslate"> private List<Document> searchDocuments(String queryString) { FullTextSession searchSession = Search .createFullTextSession(this.testSession); Transaction tx = searchSession.beginTransaction(); MultiFieldQueryParser parser = new MultiFieldQueryParser(new String[] { "title", "summary", "author.lastName", "author.firstName", "author.resume" }, new SimpleEnglishAnalyzer()); FullTextQuery query; try { query = searchSession.createFullTextQuery( parser.parse(queryString), Document.class); } catch (ParseException pe) { logger.error("Error while parsing query.", pe); return new ArrayList<Document>(0); } List<Document> result = query.list(); tx.commit(); return result; } </pre><p>Pour effectuer une recherche full-text, il faut :</p><ul><li>Créer une <code>FullTextSession</code> à partir de la session Hibernate.</li><li>Créer un parseur (<code>MultiFieldQueryParser</code>) en lui indiquant les champs sur lesquels la recherche doit avoir lieu et l’analyseur à utiliser pour tokeniser les chaînes de recherche <i>(il est bien évidemment préférable d’utiliser le même que pour l’indexation des documents)</i>.</li><li>Créer une requête de recherche full-text à partir de la chaîne de recherche tokenisée.</li><li>Exécuter la méthode <code>list</code> sur la requête.</li></ul><p>Hibernate Search retourne alors une liste d’entités « managées ».</p><h4>Les cas de test</h4><p>La démonstration peut être lancée via maven avec la commande :</p><pre class="brush: bash; title: ; notranslate"> mvn test </pre><p>Les cas de test proposés sont :</p><ul><li>Recherches simples (<code>"java"</code>, <code>"father"</code>, <code>"JAVA"</code>):</li></ul><pre class="brush: bash; title: ; notranslate"> ===================================================== Simple Test (query == "java"): Results list: Document 1: Beyond Java: > Summary: In Beyond Java, Bruce Tate, author of the Jolt Award-winning Better, Faster, Lighter Java, chronicles the rise of the most ... > Author: Bruce Tate (1) > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ... Document 2: From Java to Ruby: > Summary: If you're trying to adopt Ruby in your organization and need some help, this is the book for you. Based on a decision tree ... > Author: Bruce Tate (1) > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ... Document 4: AspectJ Cookbook: > Summary: This hands-on book shows readers why and how common Java development problems can be solved by using new Aspect-oriented pr ... > Author: Russell Miles (3) > Resume: Russell Miles is a software engineer for General Dynamics UK where he works with Java and Distributed Systems, although his ... ===================================================== ===================================================== Simple Test (query == "father"): Results list: Document 1: Beyond Java: > Summary: In Beyond Java, Bruce Tate, author of the Jolt Award-winning Better, Faster, Lighter Java, chronicles the rise of the most ... > Author: Bruce Tate (1) > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ... Document 2: From Java to Ruby: > Summary: If you're trying to adopt Ruby in your organization and need some help, this is the book for you. Based on a decision tree ... > Author: Bruce Tate (1) > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ... ===================================================== ===================================================== Simple Case Test (query == "JAVA"): Results list: Document 1: Beyond Java: > Summary: In Beyond Java, Bruce Tate, author of the Jolt Award-winning Better, Faster, Lighter Java, chronicles the rise of the most ... > Author: Bruce Tate (1) > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ... Document 2: From Java to Ruby: > Summary: If you're trying to adopt Ruby in your organization and need some help, this is the book for you. Based on a decision tree ... > Author: Bruce Tate (1) > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ... Document 4: AspectJ Cookbook: > Summary: This hands-on book shows readers why and how common Java development problems can be solved by using new Aspect-oriented pr ... > Author: Russell Miles (3) > Resume: Russell Miles is a software engineer for General Dynamics UK where he works with Java and Distributed Systems, although his ... ===================================================== </pre><ul><li>Recherche par approximation (<code>"jav~"</code>):</li></ul><pre class="brush: bash; title: ; notranslate"> ===================================================== Approximation Test (query == "jav~"): Results list: Document 1: Beyond Java: > Summary: In Beyond Java, Bruce Tate, author of the Jolt Award-winning Better, Faster, Lighter Java, chronicles the rise of the most ... > Author: Bruce Tate (1) > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ... Document 2: From Java to Ruby: > Summary: If you're trying to adopt Ruby in your organization and need some help, this is the book for you. Based on a decision tree ... > Author: Bruce Tate (1) > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ... Document 4: AspectJ Cookbook: > Summary: This hands-on book shows readers why and how common Java development problems can be solved by using new Aspect-oriented pr ... > Author: Russell Miles (3) > Resume: Russell Miles is a software engineer for General Dynamics UK where he works with Java and Distributed Systems, although his ... ===================================================== </pre><ul><li>Recherche par proximité (<code>""engineer UK"~5"</code>):</li></ul><pre class="brush: bash; title: ; notranslate"> ===================================================== Proximity Test (query == ""engineer UK"~5"): Results list: Document 4: AspectJ Cookbook: > Summary: This hands-on book shows readers why and how common Java development problems can be solved by using new Aspect-oriented pr ... > Author: Russell Miles (3) > Resume: Russell Miles is a software engineer for General Dynamics UK where he works with Java and Distributed Systems, although his ... ===================================================== </pre> </article> <article> <h1>Hands on Wicket – Partie 3</h1> <p>Manuel Eveno — Fri, 07 Mar 2008 10:35:15 +0000</p> <p><a href="http://wicket.apache.org/">Wicket</a> est un framework plutôt en rupture avec les frameworks web actuels. Ici pas de fichier XML qui définit la navigation, pas de librairies de tag spécifiques, juste de la simplicité et du pragmatisme … tout pour nous plaire ! Wicket a choisi de ne pas mélanger les genres : les pages se font en plain html et le développement, à proprement parler, se fait en pur Java.</p><p>Enfonçons-nous un peu dans les mécanismes du framework. Cette semaine, étudions la gestion de la session, la validation de formulaires et l’intégration (toujours aussi simple) avec SpringFramework.</p><h3>La gestion de la session</h3><p>Le framework s’occupe déjà de mettre en session la page courante et les composants Wicket inclus dans celle-ci. Ce mécanisme permet notamment d’écrire les traitements de réponse aux événements à la Swing (onClick, onSubmit). Il est cependant très important de faire attention aux objets que l’on met en attribut des pages et composants pour éviter de voir grossir la taille de la session.</p><p>Mais Wicket ne met en session que la page courante. Or, dans bien des cas, il est nécessaire de pouvoir accéder et manipuler des données de la session afin de rendre certaines données accessibles au travers d’un enchainement de pages. Wicket nous permet bien sûr d’accéder à la session mais nous oblige à le faire proprement.</p><p>A partir de n’importe quel composant, il est possible d’obtenir la session en utilisant la méthode <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/Component.html#getSession()">getSession()</a> qui renvoit un objet <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/Session.html">Session</a>, wrapper Wicket de la véritable session HTTP. On s’empresse donc de regarder les méthodes de cette session et on s’aperçoit que les méthodes get/setAttribute() sont « protected » et donc inaccessibles. Comment faire donc ?</p><p>Wicket nous invite en réalité à hériter de la classe WebSession pour proposer des méthodes explicites pour manipuler la session. L’avantage de cette méthode est la lisibilité et la limitation des erreurs dues à la manipulation de la session via les méthodes génériques habituelles et des clés de type String. Voici donc un exemple de session personnalisée :</p><pre class="brush: java; title: ; notranslate"> public class ShoppingWebSession extends WebSession { private static final long serialVersionUID = 1L; private static final String CART_KEY = "cart"; public XkeWebSession(Request request) { super(request); } public void setCart(Cart cart) { setAttribute(CART_KEY, cart); } public Cart getCart() { Cart cart = (Cart) getAttribute(CART_KEY); return cart; } } </pre><p>Ensuite, il faut dire à Wicket d’utiliser cette classe de session à la place de celle par défaut. Souvenez-vous de la classe principale dont je vous ai parlé dans un <a href="http://blog.xebia.fr/2008/02/14/hands-on-wicket-partie-1/">précédent article</a>. C’est dans cette classe que nous allons redéfinir la classe qui représentera la session. Il suffit de redéfinir la méthode newSession(Request, Response) de la classe <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/Application.html#newSession(org.apache.wicket.Request,%20org.apache.wicket.Response)">Application</a> pour proposer notre classe de session.</p><pre class="brush: java; title: ; notranslate"> @Override public Session newSession(Request request, Response response) { return new ShoppingWebSession(request); } </pre><p>Et voila ! Wicket utilisera désormais votre classe pour gérer la session HTTP.</p><p>La bonne nouvelle, ce genre de ligne disparait de notre code :</p><pre class="brush: java; title: ; notranslate"> ((Cart) request.getSession().getAttribute("cart")); </pre><p>La mauvaise, lors de l’utilisation de notre session, il faut effectuer un « cast » :</p><pre class="brush: java; title: ; notranslate"> ((ShoppingSession) getSession()).getCart(); </pre><p>Malgré cela, l’accès à la session ne se fait plus via des String mais au travers de méthodes Java qui doivent compiler, ce qui évite bien des erreurs.</p><p>Il est aussi possible d’utiliser des Helpers ou de créer une base de composants fournissant des méthodes pour accéder sans « cast » à la session.</p><h3>La validation de formulaire</h3><p>En ce qui concerne les champs requis, la procédure est très simple : on les définit avec la méthode <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/markup/html/form/FormComponent.html#setRequired(boolean)">setRequired(boolean)</a> disponible sur la classe <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/markup/html/form/FormComponent.html">FormComponent</a> (dont héritent quasiment tous les champs de formulaire).</p><pre class="brush: java; title: ; notranslate"> TextField textField = new TextField("myRequiredField", new Model()); textField.setRequired(true); </pre><p>Pour la validation plus avancée de valeur, il faut utiliser les validators qui implémentent l’interface <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/validation/IValidator.html">IValidator</a>. On ajoute ensuite aux éléments du formulaire les validations nécessaires avec la méthode add(IValidator). Wicket fournit en standard quelques validators disponibles dans le package <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/validation/validator/package-frame.html">org.apache.wicket.validation.validator</a> (email, date, number, string, etc). Il est bien sûr possible de créer ses propres validateurs en implémentant soi-même l’interface IValidator.</p><p>Exemple :</p><pre class="brush: java; title: ; notranslate"> TextField textField = new TextField("myRequiredField", new Model()); textField.add(NumberValidator.range(10L, 99L)); // Valide un entier compris entre 10 et 99 </pre><p>Pour effectuer des validations entre les éléments du formulaire (par exemple, si tel champ vaut telle valeur alors tel autre champ doit ….), il faut se tourner cette fois-ci vers l’interface <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/markup/html/form/validation/IFormValidator.html">IFormValidator</a> ou la classe <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/markup/html/form/validation/AbstractFormValidator.html">AbstractFormValidator</a>. Quelques implémentations de base sont disponibles mais ce genre de validation reste très spécifique aux besoins de l’application.</p><p>Encore une fois, pas de fichier XML fastidieux à définir, juste du bon vieux Java :-) .</p><h3>Intégration avec SpringFramework</h3><p>Pour utiliser Spring avec Wicket, il faut ajouter l’extension wicket-spring et wicket-spring-annot à votre projet en ajoutant la dépendance dans votre pom.xml.</p><p>Du point de vue de la configuration Spring, il suffit de déclarer la classe principale de l’application en tant que bean avec un scope singleton.</p><pre class="brush: xml; title: ; notranslate"> <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" default-autowire="no" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> <bean id="wicketApplication" class="fr.xebia.view.WicketApplication" scope="singleton"/>  [.........] </beans> </pre><p>On modifie le Servlet Filter dans le web.xml, en spécifiant cette fois-ci, la propriété « applicationFactoryClassName ». Cette propriété pointe vers la factory Spring qui permet l »intégration des deux frameworks :</p><pre class="brush: xml; title: ; notranslate"> <filter> <filter-name>Application</filter-name> <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class> <init-param> <param-name>applicationFactoryClassName</param-name> <param-value>org.apache.wicket.spring.SpringWebApplicationFactory</param-value> </init-param> </filter> </pre><p>Puis dans la méthode init() de la classe principale de l’application (rappelez-vous celle qui hérite de WebApplication), il faut ajouter une ligne pour que l’injection de dépendance fonctionne pour les pages Wicket :</p><pre class="brush: java; title: ; notranslate"> addComponentInstantiationListener(new SpringComponentInjector(this)); </pre><p>Ce <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/spring/injection/annot/SpringComponentInjector.html">SpringComponentInjector</a> va utiliser la classe <a href="http://static.springframework.org/spring/docs/2.0.8/api/org/springframework/web/context/support/WebApplicationContextUtils.html">WebApplicationContextUtils</a> de Spring pour retrouver le contexte Spring (ceci sous-entend que vous ayez configuré un <a href="http://static.springframework.org/spring/docs/2.0.8/api/org/springframework/web/context/ContextLoaderListener.html">ContextLoaderListener</a> Spring dans le web.xml par exemple pour charger la déclaration des beans gérés par Spring). Si vous voulez charger le contexte Spring vous-même, il est aussi possible de passer le contexte Spring en paramètre du constructeur de SpringComponentInjector.</p><p>Enfin dans le code Java, il nous suffit d’ajouter l’annotation <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/spring/injection/annot/SpringBean.html">@SpringBean</a> devant les attributs des composants (Page, Form, etc.) pour lesquels il faut injecter des beans gérés par Spring.</p><pre class="brush: java; title: ; notranslate"> @SpringBean(name="mySpringService") private MyService myService; </pre><p>Et voila, rien de plus !</p><p>La prochaine fois, nous verrons la mise en œuvre des mécanismes de templating, l’internationalisation ainsi que la façon d’écrire des tests unitaires (ce qui tient à cœur aux équipes de Xebia) !</p> </article> <article> <h1>Introduction à Hibernate Search (Googling your Persistent Domain Model)</h1> <p>Christophe Heubès — Thu, 06 Mar 2008 07:00:42 +0000</p> <p>J’ai eu l’occasion courant décembre de rencontrer <a href="http://blog.emmanuelbernard.com/">Emmanuel Bernard</a> [1] pour, entre autres, une présentation d’Hibernate Search.</p><p>La vulgarisation et la généralisation de l’utilisation des moteurs de recherche ont définitivement changé les habitudes et les exigences des utilisateurs. Pourquoi la fonctionnalité de recherche d’une application de gestion ne serait-elle pas aussi simple et performante que Google ?<br /> Difficile d’expliquer à son responsable que cela est dû à une divergence de paradigme entre l’indexation documentaire et SQL.<br /> <a href="http://search.hibernate.org/">Hibernate Search</a> vise à répondre à cette question, à moindre coût, en s’appuyant sur <a href="http://lucene.apache.org">Apache Lucene</a> afin d’offrir au travers du modèle de persistance d’Hibernate des capacités de recherche full-text.</p><h3>Réconcilier la recherche full-text et les modèles de persistance relationnels</h3><p>Par nature, SQL nous limite à l’écriture de requête de recherche par mot <em>(par terme)</em> avec l’aide éventuelle de wildcard (‘%’, ‘?’).<br /> La recherche SQL sur un modèle relationnel n’offre pas <em>(ou en tout cas pas sans de très gros efforts)</em> un ensemble de capacités dignes d’un moteur de recherche moderne :</p><ul><li>L’<strong>approximation</strong> qui permet de s’affranchir des fautes de frappe (Ex : « xebi » -> « xebia »).</li><li>La <strong>recherche par synonyme</strong> qui permet de remonter des résultats pertinents mais ne contenant pas le terme recherché (En SQL, « JEE » est différent de « J2EE »).</li><li>La <strong><a href="http://en.wikipedia.org/wiki/Proximity_search_%28text%29">recherche par proximité</a></strong> (Ex : « persistance java » -> « Hibernate »).</li><li>Le <strong>classement des résultats</strong> par pertinence <em>(result scoring)</em>.</li><li>La recherche <strong>multi-colonnes</strong>.</li></ul><p>Ces fonctionnalités sont traditionnellement offertes par les solutions de recherche full-text qui s’appuient sur l’utilisation <a href="http://en.wikipedia.org/wiki/Inverted_index">d’index inversés</a>. Malheureusement, de telles solutions se marient souvent mal avec les systèmes de bases de données relationnelles en raison de décalages entre les deux paradigmes :</p><ul><li>Un <strong>déséquilibre structurel</strong> tout d’abord : Les index full-text ne sont que du texte. Ils ne reflètent pas une quelconque structuration des données. De plus, ils ne permettent pas de gérer des relations entre les documents.</li><li>De plus, le mariage des deux systèmes pose des problèmes de <strong>synchronisation</strong> : comment s’assurer que le contenu de la base de données et l’index documentaire sont à jour et cohérents l’un vis-à-vis de l’autre ?</li><li>Enfin, les <strong>résultats</strong> de recherches full-text sont des documents. En effet, les index ne stockent pas d’objets. Encore moins des objets <em>« managés »</em>.</li></ul><p>A cela s’ajoute des problèmes de portabilité et de flexibilité dus au fait que la plupart des implémentations ne sont que des surcouches propriétaires au dessus du SQL.</p><p>L’objet d’Hibernate Search est de résoudre ces décalages et de réconcilier la recherche full-text et les modèles de persistance relationnels. Pour ce faire, Hibernate Search se base sur <a href="http://lucene.apache.org">Apache Lucene</a>, un moteur d’indexation et de recherche full-text standalone très puissant, mais plutôt bas niveau <em>(et donc facile à mal utiliser)</em>.<br /> Hibernate Search permet ainsi d’utiliser les capacités d’Apache Lucene dans le cadre d’une couche de mapping Hibernate.</p><h3>Architecture</h3><p>Hibernate Search est donc un moteur d’indexation et de recherche full-text reposant sur Apache Lucene. Il prend ainsi en charge la gestion d’un index Lucene et sa synchronisation avec une structure objet persistée en base de données.</p><p>La mise à jour de l’index est déclenchée au travers de la capture d’événements JPA : quand une entité est insérée, mise à jour ou supprimée en base de données, Hibernate Search récupère l’événement et programme une mise à jour de l’index. Cette mise à jour est effectuée de façon transparente par Hibernate Search et ne nécessite pas l’utilisation directe des API Lucene.<br /> Par souci d’efficacité, les opérations d’écritures dans l’index Lucene sont traitées par lots. Le traitement de ces lots s’inscrit dans la transaction courante. De cette façon, la mise à jour de l’index n’est déclenchée que si celle-ci est « commitée », permettant ainsi de garantir l’<a href="http://fr.wikipedia.org/wiki/Propri%C3%A9t%C3%A9s_ACID">ACID</a>-ité du système.</p><p>La recherche dans l’index se fait au travers des APIs <tt>}}<a href="http://www.hibernate.org/hib_docs/v3/api/org/hibernate/Query.html">org.hibernate.Query</a> ou <a href="http://java.sun.com/javaee/5/docs/api/javax/persistence/Query.html">javax.persistence.Query</a>{{</tt> de la même façon que l’on écrirait des requêtes natives, HQL ou JPA-QL. Une requête de recherche Hibernate Search retourne une liste d’entités « managées » sans que le développeur ait à se soucier du fastidieux travail de mapping Objet <-> Document Lucene.</p><p>Le traitement des opérations de mise à jour de l’index peut être traité par différents backend en fonction de l’architecture et des scénarii mis en place. Hibernate Search propose deux « backend sur étagère » : Un backend Lucene <em>(synchrone)</em> et un backend JMS <em>(asynchrone)</em>.</p><h4>Backend synchrone</h4><p>Ce mode est le plus simple : toutes les opérations de mise à jour de l’index sont traitées par le nœud (la JVM) à l’origine de l’événement déclencheur. Le traitement des mises à jour est effectué de façon synchrone <em>(au commit de la transaction)</em>.<br /> Ce backend adresse des environnements standalones <em>(non clusterisés)</em> ou en clusters symétriques <em>(tous les nœuds partagent la même instance d’index Lucene)</em>. C’est alors Lucene qui est en charge de la gestion de la stratégie de locking.</p><div align="center"></div><p>Les avantages de ce mode sont sa simplicité de mise en œuvre et la visibilité immédiate des mises à jour de l’index puisqu’elles sont traitées en synchrone.<br /> Par contre, cette approche synchrone peut dégrader les performances de l’application front.</p><h4>Backend asynchrone</h4><p>Ce backend met en jeu le pattern maître / esclaves : Les opérations de mise à jour de l’index sont effectuées sur un index maître tandis que les opérations de lecture <em>(recherche)</em> sont effectuées sur des index esclaves. A intervalles réguliers, l’index maître est répliqué sur les esclaves <em>(copies du maître)</em>.</p><p>Ce backend adresse des environnements clusterisés répondant à des besoins de haute performance de l’application front. Dans ce mode, chaque nœud utilise un index esclave en local. Ces indexes sont exclusivement utilisés en lecture. Lorsqu’un événement nécessite une opération de mise à jour de l’index, l’ordre de mise à jour est envoyé sur une queue JMS <em>(tous les nœuds utilisant la même queue)</em>. Cette queue est dépilée par un consommateur unique en charge du traitement <em>(asynchrone)</em> des opérations de mise à jour qu’il effectue sur l’index maître.</p><div align="center"></div><p>Le principal avantage de ce mode est de ne pas surcharger l’application front avec les traitements de mise à jour de l’index.<br /> Il entraîne par contre un délai de mise à jour des index de recherche <em>(Traitement asynchrone des mises à jour + délai de réplication)</em>.</p><h3>Pour bien commencer</h3><ul><li>Le site du projet <a href="http://search.hibernate.org">Hibernate Search</a>.</li><li>La <a href="http://www.hibernate.org/hib_docs/search/reference/en/html_single/">documentation Hibernate Search</a>.</li><li>La documentation de la <a href="http://lucene.apache.org/java/2_3_1/queryparsersyntax.html">syntaxe de requêtes</a>.</li></ul><p>Et rendez-vous fin mars sur notre blog pour <a href="http://blog.xebia.fr/2008/03/28/hands-on-hibernate-search-recherche-full-text/">un premier sample</a>.</p><hr /> [1] <a href="http://blog.emmanuelbernard.com/">Emmanuel Bernard</a> est membre de l’équipe Hibernate, Core developer à JBoss, lead developer sur les projets Hibernate Annotations, Hibernate EntityManager et Hibernate Search ainsi que membre des groupes d’expert EJB 3.0 et JSR-303.</p> </article> <article> <h1>Hands on Wicket – Partie 2</h1> <p>Manuel Eveno — Fri, 22 Feb 2008 09:43:04 +0000</p> <p><a href="http://wicket.apache.org">Wicket</a> est un framework plutôt en rupture avec les frameworks web actuels. Ici pas de fichier XML qui définit la navigation, pas de librairies de tag spécifiques, juste de la simplicité et du pragmatisme … tout pour nous plaire ! Wicket a choisi de ne pas mélanger les genres : les pages se font en plain html et le développement, à proprement parler, se fait en pur Java.</p><p>Dans le <a href="http://blog.xebia.fr/2008/02/14/hands-on-wicket-partie-1/">précédent</a> billet, nous nous étions arrêtés à la mise en place d’un projet Wicket. Aujourd’hui, regardons de plus près la construction des pages et la façon d’implémenter la logique de navigation avec les formulaires et les liens.</p><h3>Construction des pages</h3><p>La construction des pages se fait en deux étapes :</p><ul><li>Création du fichier HTML</li><li>Création de la classe Java correspondante</li></ul><p>Par défaut, Wicket suppose que le fichier HTML et la classe Java doivent être dans le même package et porter le même nom (sauf l’extension bien sûr) . Il est cependant possible de <a href="http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html">modifier</a> ce comportement.</p><p>Le fichier HTML utilise exclusivement la syntaxe HTML sur laquelle on vient positionner des attributs "wicket:id" pour les éléments qui sont associés aux traitements métiers des pages. Les balises auxquelles on ajoute cet attribut représentent le contenu dynamique (que l’on veut traiter en Java). C’est par cet attribut que Wicket fera la correspondance entre les tags HTML et les composants créés en Java. Le code HTML ne contient rien d’autre que de la mise en page et mise en forme (classique HTML + CSS), la logique métier étant complètement implémentée en Java. Un bel exemple de "<a href="http://en.wikipedia.org/wiki/Separation_of_concerns">Separation of concerns</a>".</p><p>Etudions un exemple pour bien comprendre ce mécanisme.</p><p>Imaginons le fichier HTML suivant avec un message que l’on veut dynamique, un champ texte et un bouton :</p><pre class="brush: xml; title: ; notranslate"> <html> <body> <p>Dynamic Message goes here</p> <form> <input type="text" /> <input type="submit" value="update"/> </form> </body> </html> </pre><p>Le passage à Wicket donnera :</p><pre class="brush: xml; title: ; notranslate"> <html> <body> <p wicket:id="message">Message goes here</p> <form wicket:id="messageInputForm"> <input type="text" wicket:id="messageInput"/> <input type="submit" value="update"/> </form> </body> </html> </pre><p>On ajoute l’attribut wicket:id auquel on donne une valeur unique qui nous servira dans le code Java. Cet attribut "wicket:id" persiste par défaut dans le HTML même après traitement par Wicket. Il est cependant possible de demander à Wicket de supprimer ces attributs (voir <a href="http://cwiki.apache.org/WICKET/how-to-remove-wicket-markup-from-output.html">ici</a>) en production pour obtenir des pages HTML conformes au <a href="http://validator.w3.org">standard du W3C</a>.</p><p>Il nous reste plus qu’à écrire la classe Java correspondante qui doit hériter de la classe <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/markup/html/WebPage.html">WebPage</a> :</p><pre class="brush: java; title: ; notranslate"> public class HelloWorld extends WebPage { public HelloWorld() { IModel messageModel = new Model("Hello World!"); add(new Label("message", messageModel)); add(new MessageForm("messageInputForm", messageModel)); } private static final class MessageForm extends Form { public MessageForm(String id, IModel model) { super(id); add(new TextField("messageInput", model)); } protected void onSubmit() { // Rien à faire ici, le modèle sera automatiquement mis à jour } } } </pre><p>On remarque que le code Java réutilise les ids qui apparaissent dans le code HTML. C’est via ces ids que le pont entre le Java et le HTML est fait.</p><p>Ensuite, la seconde chose que l’on note est l’imbrication des composants. Cette imbrication doit respecter celle qui existe dans le HTML. Ainsi puisque le formulaire contient le champ texte, dans le code Java, on doit retrouver cette contenance.</p><p>L’autre particularité à remarquer est l’utilisation de l’objet Model. Tous les composants Wicket ont un model qui permet de définir leur contenu : même un simple label utilise un Model pour afficher son body. Chacun des modèles doit implémenter l’interface <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/model/IModel.html">IModel</a> (voir paragraphe suivant).</p><p>Dans notre cas, le champ texte et le label partagent le même modèle. Ainsi, le contenu du label aura le même contenu que le champ texte. De plus, par défaut, la soumission d’un formulaire entraîne la mise à jour automatique du modèle avec les données du formulaire. La classe Form appelle simplement la méthode setObject(…) du modèle avec la donnée correspondante du formulaire. La mise à jour du champ causera donc la mise à jour du label après soumission du formulaire. Il est bien sûr possible d’ajouter des traitements dans la méthode onSubmit() du formulaire.</p><p>Je vous invite à faire un tour dans les <a href="http://www.wicketstuff.org/wicket13/">exemples</a>, la <a href="http://people.apache.org/~tobrien/wicket/apidocs/index.html">Javadoc</a> et le <a href="http://cwiki.apache.org/WICKET/">wiki</a> pour éplucher les différents composants et leur modèle respectif.</p><h3>La notion de Model</h3><p>Les composants Wicket reposent tous sur un modèle. Les composants accèdent aux données qu’ils doivent prendre en charge via le modèle qui leur est attaché. Ces modèles implémentent tous l’interface <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/model/IModel.html">IModel</a>. Ceci permet de garder le contrôle sur l’accès aux données par les composants. Il est à noter que les objets qui implémentent cette interface seront systématiquement stockés dans la session. Il faut donc faire attention à la façon dont nous implémentons les modèles pour éviter de surcharger la session.</p><p>Plusieurs modèles sont disponibles et fournis par Wicket :</p><ul><li> <b>Basic Models</b> – Pour implémenter un modèle basique qui sera intégralement stocké dans la session. Pour implémenter ce modèle, vous pouvez utiliser simplement la classe <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/model/Model.html">Model</a>.</li><li> <b>Detachable Models</b> – Ces modèles implémentent l’interface <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/model/IDetachable.html">IDetachable</a> et offrent la méthode detach(), qui permet d’être notifié quand Wicket n’a plus besoin du modèle, ainsi les données peuvent être libérées de la mémoire au plus tôt.</li><li> <b>Nested Models</b> – Les modèles peuvent aussi être imbriqués pour représenter une hiérarchie d’objets. Pour ce faire, il suffit d’implémenter la méthode getNestedModel() de l’interface IModel qui renvoie le modèle sous-jacent.</li><li> <b>Property Models</b> – La classe <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/model/AbstractPropertyModel.html">AbstractPropertyModel</a> fournit un comportement par défaut pour les modèles basés sur des propriétés. La classe <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/model/PropertyModel.html">PropertyModel</a> permet d’encapsuler un POJO et de donner accès aux propriétés de cet objet. C’est cette classe qu’on utilise pour associer l’attribut d’un objet à un champ de formulaire.</li><li> <b>Compound Property Models</b> – Ce type de modèle permet de changer le comportement du modèle en fonction du composant qui y accède. Les méthodes get et setObject prennent le composant en paramètre pour cela.</li></ul><p>Le <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/model/PropertyModel.html">PropertyModel</a> et le <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/model/Model.html">Model</a> restent les deux modèles les plus courants.</p><p>Exemple : </p><pre class="brush: java; title: ; notranslate"> Label myLabel = new Label("myLabel", new Model("Hello world !")); Person person = .... // Obtenir un objet Person TextField myTextField = new TextField("myTextField", new PropertyModel(person, "name")); </pre><h3>La navigation dans Wicket</h3><p>Avec Wicket, la navigation se code en Java. Ici, pas de fichier xml de configuration des mappings URL/Class. Une méthode principale est utilisée pour ceci, il s’agit de setResponsePage() disponible sur la classe <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/Component.html">Component</a>. Cette méthode prend en paramètre soit une classe, soit une classe avec des paramètres, soit une instance de page (dans les deux cas, la classe passée en paramètre doit hériter de la classe Page).</p><ul><li>setResponsePage(Class) permet de rediriger vers une page indépendante des données de la page courante. L’instanciation de la page et la gestion de son cycle de vie sont effectuées par Wicket.</li><li>setResponsePage(Class, <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/PageParameters.html">PageParameters</a>) redirige vers une page en lui passant des données. L’instanciation de la page et la gestion de son cycle de vie sont là aussi effectuées par Wicket.</li><li>setResponsePage(Page) La troisième (avec une instance de page passée en paramètre) permet de pointer vers une page que l’on aura instanciée nous-même et à laquelle on a passé des paramètres.</li></ul><pre class="brush: java; title: ; notranslate"> setResponsePage(MySecondPage.class); setResponsePage(new MySecondPage(myTextField.getModel())); // On passe des données dynamiques à la page cible </pre><p>Nous allons appeler cette méthode en répondant aux "événements" de l’application à la manière d’une application Swing (onClick, onSubmit, etc.) ou en spécifiant pour certains types de lien, la page à afficher en cas de click.</p><p>Il y a deux principaux moyens de naviguer dans Wicket :</p><ul><li><b>les formulaires</b> : Dans ce cas, on utilise (ou hérite de) la classe <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/markup/html/form/Form.html">Form</a> à laquelle on ajoute les composants du formulaire. Le traitement associé à la validation du formulaire est codé dans la méthode onSubmit(). C’est aussi dans cette méthode que l’on peut définir la page qui sera affichée après soumission du formulaire via la méthode setResponsePage().</li></ul><pre class="brush: java; title: ; notranslate"> /** * @see org.apache.wicket.markup.html.form.Form#onSubmit() */ public final void onSubmit() { // Do the submit stuff (update the database, etc.) setResponsePage(MySecondPage.class); } </pre><ul><li><b>les liens</b> : Les liens héritent en général de la classe <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/markup/html/link/Link.html">Link</a> qui fournit les mécanismes de base pour créer un lien. Pour définir l’action à effectuer lors d’un click, on redéfinit simplement le méthode onClick(). On peut effectuer dans cette méthode un traitement pour finir par donner la page à afficher en résultat via la méthode setResponsePage(). Il est aussi possible d’utiliser la classe <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/markup/html/link/PageLink.html">PageLink</a> qui redirige simplement vers une page donnée en paramètres.</li></ul><pre class="brush: java; title: ; notranslate"> Link addToCartLink = new Link("addToCartLink") { private static final long serialVersionUID = 1L; public void onClick() { AddToCartPage page = new AddToCartPage(book.getId()); setResponsePage(page); } }; // ou new PageLink("viewLink", ViewPage.class); </pre><p>Par défaut, les liens ne peuvent être ajoutés aux favoris (si on retourne sur une page "bookmarkée", on obtient un message "Page expired"). Les liens sont en fait maintenus en session, ce qui explique la possibilité de créer ses liens en Java de cette façon. Pour créer un lien "bookmarkable", il faut utiliser la classe du même nom : <a href="http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/markup/html/link/BookmarkablePageLink.html">BookmarkablePageLink</a>. Ce type de lien peut être ajouté aux favoris.</p><p>C’est tout pour cette fois, il vous faudra un peu de patience avant d’en savoir plus sur les fonctionnalités de Wicket.</p> </article> <article> <h1>Hands on Wicket – Partie 1</h1> <p>Manuel Eveno — Thu, 14 Feb 2008 11:16:03 +0000</p> <p><a href="http://wicket.apache.org/">Wicket</a> est un framework plutôt en rupture avec les frameworks web actuels. Ici pas de fichier XML qui définit la navigation, pas de librairies de tags spécifiques, juste de la simplicité et du pragmatisme … tout pour nous plaire ! Wicket a choisi de ne pas mélanger les genres : les pages se font en pur html et le développement, à proprement parler, se fait en pur Java.</p><p>Dans cette première partie, nous verrons comment démarrer avec Wicket.</p><h3>Quickstart</h3><p>Démarrer avec <a href="http://wicket.apache.org/">Wicket</a> est plutôt simple. Il suffit de lancer une commande <a href="http://maven.apache.org/">Maven2</a>, ce qui a deux avantages :</p><ul><li>Générer automatiquement un pom avec les dépendances Wicket</li><li>Générer un squelette de projet Wicket</li></ul><p>Il existe donc un archetype Wicket pour Maven2 que l’on peut utiliser comme suit :</p><pre class="brush: python; title: ; notranslate"> mvn archetype:create -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.3.0-rc1 -DgroupId=com.mycompany -DartifactId=myproject </pre><p>Qu’obtient-on d’intéressant avec cet archetype ?</p><ul><li>Un fichier pom.xml</li><li>Un fichier webapp\WEB-INF\web.xml préconfiguré pour Wicket</li><li>Quelques fichiers sources dans src\main\java\com\mycompany :<br /> - Une page d’accueil constituée d’un fichier HTML (HomePage.html) et d’un fichier Java (HomePage.java)<br /> - Une classe Java (WicketApplication.java)</li><li>Une classe Java src\test\java\com\mycompany\Start.java qui permet de lancer Jetty</li></ul><p>Vous avez déjà une application Wicket fonctionnelle à ce stade.</p><p>Ensuite, générer la configuration Eclipse avec la commande :</p><pre class="brush: python; title: ; notranslate"> mvn eclipse:eclipse </pre><p><em>(Attention, le plugin maven eclipse n’est pas encore compatible WTP 2.0, c’est la version de WTP livrée dans Eclipse Europa, pour avoir ce support, il faut compiler le plugin maven eclipse 2.5-SNAPSHOT, en attendant sa sortie officielle.)</em></p><h3>Configuration de l’application web</h3><p>Revenons sur certains des fichiers générés par l’archetype Maven2. Pour utiliser Wicket dans une application web, il faut ajouter quelques lignes dans le web.xml. On y référence en fait un simple Servlet Filter qui lui-même pointe vers une classe de l’application.</p><pre class="brush: xml; title: ; notranslate"> <filter> <filter-name>wicket.myproject</filter-name> <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class> <init-param></init-param></filter> <param-name>applicationClassName</param-name> <param-value>com.mycompany.WicketApplication</param-value> <filter-mapping> <filter-name>wicket.myproject</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> </pre><p>C’est tout pour la configuration en XML. Le reste des développements se fera en HTML et en Java !!</p><h3>La pièce maîtresse</h3><p>Le Servlet Filter pointe vers la classe principale de l’application qui doit hériter de <a href="http://people.apache.org/%7Etobrien/wicket/apidocs/org/apache/wicket/protocol/http/WebApplication.html">WebApplication</a>. C’est le point d’entrée de l’application Wicket. Cette classe permet :</p><ul><li>de configurer l’application en utilisant les nombreuses méthodes de type getXXXXSettings() (où XXXX peut être remplacé par Session, Markup, Framework, Resources, Security, etc.).</li><li>de définir la page d’accueil en surchargeant la méthode getHomePage() :</li></ul><pre class="brush: java; title: ; notranslate"> import org.apache.wicket.protocol.http.WebApplication; public class HelloWorldApplication extends WebApplication { public void init() { // getXXXSettings().set ...... } /** * @see org.apache.wicket.Application#getHomePage() */ public Class getHomePage() { return HelloWorld.class; } } </pre><p>Cette « HomePage » sera affichée, par défaut, lorsqu’un utilisateur accédera à l’application sans adresser directement une page visible de l’application <em>(nous reviendrons sur ce point dans les articles suivants)</em>.</p><p>Et voilà, la magie Wicket vient d’opérer : vous avez déjà une application exécutable. Pour la tester, c’est encore très simple.</p><p>Le pom Maven2, généré par l’archetype Wicket, est configuré pour pouvoir lancer jetty avec l’application web.</p><p>Démarrer le serveur Jetty (préconfiguré lui aussi dans le POM généré) via :</p><pre class="brush: python; title: ; notranslate"> mvn jetty:run </pre><p>Ouvrez votre navigateur à l’adresse http://localhost:8080/myproject. Vous verrez apparaître votre première application Wicket .</p><p>A bientôt, pour de nouvelles aventures avec Wicket …</p> </article> <article> <h1>L’analyse de couverture de code en Java</h1> <p>Alexandre De Magalhaes Garcia — Thu, 07 Feb 2008 07:40:34 +0000</p> <p>Il ne reste plus grand’monde pour soutenir que l’écriture de tests unitaires automatisés est une perte de temps sur un projet logiciel – la notion de dette technique entre dans les moeurs. Cette prise de conscience salutaire se heurte pourtant souvent à deux grandes catégories de difficultés :</p><ul><li>Le conservatisme – pour ne pas dire la stupidité – de certains chefs de projet, qui persistent à voir dans l’écriture des tests une activité contre-productive, qui servira de variable d’ajustement au moindre coup de grisou</li><li>L’existant : quand le projet n’a pas systématisé la pratique du test dès son origine et que la multiplication des anomalies tardives le pousse à la réintroduire. Par où commencer ?</li></ul><p>Pour le premier point, la solution passe par un effort pédagogique, ou, pour les cas désespérés, par une reconversion imposée ou un congé sabbatique.<br /> Pour le second, il faut un peu de bon sens, et un peu d’outillage.</p><p>C’est sur le deuxième aspect qu’interviennent les outils d’analyse de <strong>couverture de code</strong> (ou « <strong>code coverage</strong> » en anglais). Dans la suite, nous verrons que ces outils ne permettent pas d’évaluer les tests unitaires d’un point de vue qualitatif, mais qu’ils peuvent en revanche apporter au bon sens un précieux appui en répondant aux questions suivantes :</p><ul><li>Quels sont les tests unitaires déjà en place ?</li><li>Les tests sont-ils en phase (à jour) avec le code qu’ils testent ?</li><li>Les fonctions critiques de l’application sont-elles couvertes par les tests ?</li></ul><h3>Quelques définitions</h3><p>Pour rappel, on distingue 2 grandes catégories complémentaires de tests pour un projet logiciel :</p><ul><li>Test par « <strong>boîte noire</strong> » (<strong>black box testing</strong>) : les tests sont effectués sans connaissance de la structure interne et des objets manipulés par le système. On ne s’intéresse qu’aux entrées et sorties de ce système. Les tests fonctionnels ou les tests manuels par exemple, appartiennent à cette catégorie.</li><li>Test par « <strong>boîte blanche</strong> » (<strong>white box testing</strong>) : les tests s’intéressent au fonctionnement interne du système. Ainsi, les tests unitaires manipulent les objets et éléments qui composent le système. L’analyse de couverture de code permet d’obtenir une mesure indirecte de la complétude des tests effectués à ce niveau.</li></ul><p>La couverture de code est une mesure qui décrit le degré auquel le code source d’un programme a été testé. Ainsi c’est l’exécution de tous les tests (unitaires, fonctionnels, etc…) qui va permettre de déterminer notre mesure de couverture.</p><p>Les outils fournissant cette mesure savent déterminer quels fragments de code ou quelles méthodes ont été exécutés. La mesure (ou « <strong>métrique</strong>« ) principale est calculée en faisant le rapport du nombre de lignes de code exécutées sur le nombre de lignes total du code source : c’est la couverture de ligne (« <strong>statement coverage</strong>« ).</p><p>Plusieurs autres métriques (ou « <strong>critères</strong>« ) existent et permettent de calculer la couverture de code à différents niveau de granularité :</p><ul><li>Method coverage : Est-ce que toutes les méthodes ont été exécutées ?</li><li>Branch coverage : Est-ce que les structures de contrôle (if ou while par exemple) ont été testées pour les 2 cas vrai et faux ?</li><li>Path coverage : Est-ce que tous les chemins possibles d’exécution des fonctions d’un programme ont été exécutés ?</li></ul><h3>Les stratégies d’instrumentation</h3><p>En Java, il existe plusieurs manières de déterminer quelles parties du code ont été exécutées.</p><div align="center"></div><p>On distingue 2 techniques :</p><ul><li>L’instrumentation des classes :<br /> - L’outil d’instrumentation ajoute des lignes dans le code source du programme lui permettant de détecter le code exécuté.<br /> - L’outil intervient directement sur le code compilé (byte-code) et ajoute ses modifications (« <strong>tracking hooks</strong>« ).</li><li>L’utilisation des options de la JVM : il est possible d’utiliser une configuration particulière de la JVM pour utiliser des « listeners » (utilisant les interfaces JVMPI ou JVMDI, remplacés par JVMTI depuis Java 5). Ainsi certains outils de profiling utilisent un environnement d’exécution particulier permettant de détecter le code exécuté.</li></ul><p>Les outils les plus courants utilisent la technique d’instrumentation des classes, le plus souvent au niveau byte-code. Les raisons principales en sont les suivantes :</p><ul><li>La surcharge à l’exécution (« <strong>runtime overhead</strong>« ) pour les classes instrumentées est comprise entre 5 et 20%. L’utilisation de profilers JVM est beaucoup plus pénalisante.</li><li>Pas besoin du code source pour instrumenter.</li><li>Instrumentation des jars tiers possible.</li><li>Indépendant de la plateforme.</li><li>Facilité de branchement de l’outil ad-hoc.</li></ul><p>A noter que certains outils utilisent une approche complémentaire : l’instrumentation dynamique (au runtime). Par exemple <a href="http://emma.sourceforge.net/">Emma</a> permet d’instrumenter les classes à la volée (on the fly) et avec l’utilisation d’un classloader modifié, d’obtenir les informations de couverture d’un programme en cours d’exécution. <a href="http://hansel.sourceforge.net/">Hansel</a> encapsule les tests unitaires (JUnit par exemple) dans des classes spécifiques permettant d’injecter à l’exécution (à l’aide d’un classloader modifié) le code permettant de tester la couverture.</p><h3>Exemple d’utilisation avec l’outil Cobertura</h3><h4>Caractéristiques</h4><ul><li>Le projet <a href="http://cobertura.sourceforge.net/index.html">Cobertura</a> est basé sur JCoverage :<br /> - Il est gratuit (licence Apache et GPL).<br /> - Utilise l’instrumentation du byte-code en mode déconnecté (après compilation).</li><li>Génération de rapports en HTML ou XML :<br /> - Possibilité de fusion de différents rapports de couverture (merge).<br /> - Possibilité d’incorporer les rapports dans les outils d’intégration continue (Hudson, Cruise Control).</li><li>Metrics :<br /> - Statement et branch coverage pour les classes, packages et l’ensemble d’un projet.<br /> - Affichage de la complexité cyclomatique du code de McCabe pour chaque classes, moyenne pour chaque package et globale pour l’ensemble du projet.</li><li>Intégration possible en ligne de commande, dans une tâche Ant ou avec Maven.</li></ul><h4>Exemple de tâches Ant</h4><p><strong>Instrumentation des classes compilées</strong></p><p>Cette tâche permet d’instrumenter les classes :</p><pre class="brush: xml; title: ; notranslate"> <cobertura-instrument todir="${instrumented.dir}"> <ignore regex="org.apache.log4j.*" /> <fileset dir="${classes.dir}"> <include name="**/ui/**/*.class" /> <exclude name="**/*Test.class" /> </fileset> <fileset dir="${jars.dir}"> <include name="domain.jar" /> </fileset> </cobertura-instrument> </pre><div style="border:dotted 1px #4F2F4F; background-color: #FEEEBA; text-align: left; margin-top: 20px; margin-right: 20px; margin-bottom: 20px; margin-left: 0px; padding-right: 5px; padding-left: 5px;"> <strong><i>Tips & Tricks :</i></strong></p><ul><li><i><code><ignore regex="org.apache.log4j.*" /></code> : cette ligne permet d’ignorer tous les appels à toutes les méthodes des classes qui correspondent à l’expression régulière. Toutefois les classes correspondantes seront instrumentées.</i></li><li><i>On peut utiliser les filesets Ant standards pour inclure ou exclure certains packages ou classes du chemin d’instrumentation. De la même manière on peut instrumenter des jars.</i></li></ul></div><p>Cobertura peut également instrumenter des archives incluses dans d’autres archives. Par exemple, des jars contenu dans le répertoire WEB-INF/lib d’un war seront instrumenté et le war sera reconstruit avec les jars instrumentés inclus.</p><p><strong>Exécution des tests unitaires</strong></p><p>Les parties entre [ ] sont à ajouter/modifier dans une tâche Ant JUnit classique :</p><pre class="brush: xml; title: ; notranslate"> <junit [fork="yes"] dir="${basedir}" failureProperty="test.failed"> [<sysproperty key="net.sourceforge.cobertura.datafile" file="${basedir}/cobertura.ser" />] [<classpath location="${instrumented.dir}" />] <classpath location="${classes.dir}" /> [<classpath refid="cobertura_classpath" />] ... </junit> </pre><div style="border:dotted 1px #4F2F4F; background-color: #FEEEBA; text-align: left; margin-top: 20px; margin-right: 20px; margin-bottom: 20px; margin-left: 0px; padding-right: 5px; padding-left: 5px;"> <strong><i>Tips & Tricks :</i></strong></p><ul><li>Il est nécessaire de spécifier la valeur « yes » pour le mode fork de la tâche JUnit pour qu’elle soit exécutée dans une JVM différente de celle de Ant. En effet, Cobertura n’écrit les données de couverture que lorsque la JVM a terminé son exécution. Or on a besoin que ces données soit écrite avant que Ant ne termine car il faut générer le rapport Cobertura.</li><li>Il faut déclarer le chemin vers le fichier dans lequel seront stockées les informations de couverture (ici cobertura.ser).</li><li>Ajouter le chemin vers le répertoire contenant les classes instrumentées. Il est important que la déclaration de ce chemin soit placée avant celui du classpath vers les classes non instrumentées.</li><li>Il faut ensuite ajouter dans le classpath les jars nécessaires à l’exécution de Cobertura (cobertura.jar + librairies asm + jakarta oro)</li></ul><p>Dans le cas d’utilisation de Cobertura avec un serveur d’application les données de couverture de code ne seront écrites dans le fichier que lorsque le serveur sera arrêté. Si cela pose un problème, il est possible d’ajouter dans le code (à la fin des tests unitaires par exemple) un appel à la méthode net.sourceforge.cobertura.coveragedata.ProjectData.saveGlobalProjectData() qui forcera l’écriture.</p></div><p><strong>Génération du rapport</strong></p><p>Pour générer le rapport au format HTML on utilisera le code suivant :</p><pre class="brush: xml; title: ; notranslate"> <cobertura-report format="html" destdir="${coveragereport.dir}" srcdir="${src.dir}" /> </pre><div style="border:dotted 1px #4F2F4F; background-color: #FEEEBA; text-align: left; margin-top: 20px; margin-right: 20px; margin-bottom: 20px; margin-left: 0px; padding-right: 5px; padding-left: 5px;"> <strong><i>Tips & Tricks :</i></strong><br /> L’attribut « format » permet de spécifier 2 types de format en sortie : XML ou HTML. Le format XML est utile notamment pour l’intégration à Hudson.</td></tr></tbody></table></div><p>Un exemple de rapport HTML obtenu :</p><div align="center"><a href="http://blog.xebia.fr/wp-content/uploads/2008/02/report-overview.png" title="Exemple de rapport HTML"></a></div><p>Et le détail des lignes couvertes par les tests dans le code source :</p><div align="center"><a href="http://blog.xebia.fr/wp-content/uploads/2008/02/report-detail.png" title="Détail des lignes couvertes par les tests dans le code source"></a></div><h4>Autres fonctionnalités</h4><p>Cobertura propose également une tâche, « cobertura-check », permettant de définir des seuils et de vérifier comment le code est couvert par rapport à ces seuils.</p><p>La tâche « cobertura-merge », permet de fusionner plusieurs fichiers de couverture. On peut ainsi générer des rapports globaux pour les parties client et serveur d’une application ou fusionner des données obtenues sur plusieurs sessions d’utilisation de Cobertura.</p><p>Pour chacune des opérations offertes Cobertura (instrument, report, merge, check), on peut effectuer l’appel via la ligne de commande. Par exemple :</p><pre class="brush: python; title: ; notranslate"> java -cp %COBERTURA_CLASSPATH% net.sourceforge.cobertura.reporting.Main --format html --destination C:\Reports\coverage </pre><p>Enfin <a href="http://cobertura.sourceforge.net/maven.html">2 projets annexes</a> permettent également d’intégrer Cobertura dans une configuration Maven (1 ou 2) en offrant les mêmes fonctionnalités.</p><p>Cobertura ne propose malheureusement pas de plugin d’intégration à Eclipse. Comme outil proposant les même fonctionnalités et l’intégration à Eclipse, on peut citer l’outil gratuit open source <a href="http://www.eclemma.org/">EclEmma</a> qui est une extension de Emma cité un peu plus haut.</p><h3>Comment bien utiliser l’analyse de couverture de code</h3><p>Comme souvent dans l’ingénierie logicielle, l’utilisation d’une métrique de mesure de la qualité s’accompagne de son lot d’apôtres plus ou moins extrémistes. Le taux de couverture des tests n’échappe pas à cette règle, et l’on voit certains définir des objectifs quantitatifs rigides dans ce domaine. Certains affirment que le taux de couverture doit être de 100% ; d’autres, plus modestes, se contenteraient de 90%.</p><p>Dans la pratique il est difficile, voire impossible d’atteindre 100% et sur un projet conséquent ce n’est même pas pertinent de vouloir le faire. La valeur du taux de couverture n’est pas en soit une mesure pertinente de la qualité des tests.<br /> En effet, Il est important que les équipes chargées du développement ne se focalisent pas sur un chiffre à atteindre mais plutôt sur la qualité des tests effectués. Ainsi, grâce aux informations de couverture de code, les équipes peuvent repérer et corriger rapidement les tests critiques et ne pas s’attarder à optimiser les tests concernant des parties du code moins importantes.</p><p>Brian Marick, dans <a href="http://www.testing.com/writings/coverage.pdf">« How to Misuse Code Coverage »</a> explique de manière très claire comment bien utiliser la couverture de code dans un projet TDD (Test Driven Development). Je ne vais pas reprendre ici les points abordés, mais il est important de répéter que la mesure de couverture de code ne doit pas être une fin en soi mais un moyen d’améliorer la qualité globale du code et des tests effectués pour le valider.</p><h3>Liens</h3><ul><li><a href="http://www.javaranch.com/journal/2004/01/IntroToCodeCoverage.html">JavaRanch : Introduction to code coverage</a></li><li><a href="http://www.testing.com/">Brian’s Malick Testing website</a></li><li><a href="http://www.ericsink.com/articles/Code_Coverage.html">Advocating the use of code coverage</a></li><li><a href="http://www.topcoder.com/tc?module=Static&d1=features&d2=021307">TopCoder.com : An introduction to code coverage</a></li></ul> </article> <article> <h1>Laissez les coder !</h1> <p>Benoit Moussaud — Thu, 06 Sep 2007 07:30:55 +0000</p> <p>Les grands intégrateurs ont depuis longtemps institué un chemin d’évolution basé sur la gestion de projets. Les jeunes débutants, le plus souvent de formation ingénieurs, sont rapidement formés à encadrer des équipes de développeurs et à piloter les projets : la voie royale ! Ces dernières années, vue la complexité technique des nouvelles architectures, une autre voie a émergé : la filière technique. Cette dernière destinée à promouvoir les compétences techniques et d’architectures applicatives, plus en adéquation avec une formation initiale d’ingénieur. Cependant la pression économique impose que ces personnes progressent rapidement vers une spécialité, une expertise (J2EE ; Les bases de données ; La sécurité …) et en les affectant de plus en plus à des missions en parallèle (2 jours chez Untel, 1 jour sur le projet Bidule). Cette rapidité de progression pose toujours le même souci : qui développe réellement l’application ? Très souvent des stagiaires ou, dans le meilleur des cas, de très jeunes embauchés après leur formation.</p><p>Les techniques de développement demandent de plus en plus d’être polyvalent : de l’écriture de requêtes SQL à la présentation des données dans une page JSP. Cette polyvalence ne s’acquière pas en quelques années et nécessite également de rester à jour dans ses connaissances. Alors pourquoi propulser ces personnes dans d’autres fonctions ?</p><p>Intégrer dans une équipe de développement un ou plusieurs développeurs expérimentés permet deux choses :</p><ul><li>Accélérer les phases de codage et de validation technique et fonctionnelle : l’expérience permet de réduire le nombre d’allers retours entre ces deux étapes.</li><li>Créer une continuité de savoir et d’intérêt entre de jeunes débutants et des profils tels que les chefs de projets voire même les architectes.</li></ul><p>Reste à définir la notion d’expérience. Deux composantes rentrent en jeux : les années passées à exercer cette compétence, 3 à 5 ans et surtout le nombre de projets, 5 à 10. Ce dernier point est très important : confronter sa compétence à différents clients, technologies ou architectures est essentiel pour aguerrir les meilleurs développeurs !</p><p>Alors laissez les coder !</p> </article> <article> <h1>Développement logiciel : Doit on continuer à ignorer l’évidence ?</h1> <p>Luc Legardeur — Thu, 26 Jul 2007 08:24:35 +0000</p> <p>Nous l’avons constaté encore une fois, une fois de trop sans doute. L’un de nos clients s’est mis tout seul (car les responsables d’une telle situation travaillent bien dans la même entreprise que celle où officie notre interlocuteur) dans une situation perdant/perdant avec son intégrateur dans le cadre d’un projet développé au forfait. Quels sont les faits ? Nous pourrions, sans même lui laisser la parole, nommer une à une toutes les difficultés qu’il rencontre, les yeux fermés, à la manière d’un chapelet qu’on égrène.</p><p>Un Appel d’Offre a été émis à destination des principaux intégrateurs de la place car selon la Direction des Achats c’est la seule manière de mener un projet informatique (Nous vous en parlions dans un précédent billet : <em>« <a href="http://blog.xebia.fr/2006/12/04/eloge-de-la-qualite/">Eloge de la qualité</a>« </em>). C’est, selon les mêmes spécialistes reconnus pour leurs compétences informatiques, un moyen de maîtriser les coûts et les délais, de partager le risque avec l’entreprise choisie et d’avoir un moyen de pression (car bien entendu de superbes clauses de pénalités de retard ont été prévues au contrat). L’intégrateur X est choisi. Pour une grande part, parce qu’il avait une proposition alléchante et savait accepter, sans piper mot, tous les principes de ce « contrat de confiance ». Le décor est planté : une atmosphère de sérénité, une confiance réciproque, l’implication des meilleurs profils de la société X, des desiderata d’utilisateurs pris en compte …</p><p>Vous vous en doutez, cette dernière phase est ironique.</p><p>Le chef de projet est sous tension, son entreprise lui a affecté 3 stagiaires et demi, un quart d’Architecte car, après d’âpres négociations, l’affaire gagnée se révèle moins rentable que prévu. Et en interne dans la Société X, un projet mal négocié aboutit à l’affectation de développeurs inexpérimentés (« You pay peanuts, you get monkeys », c’est bien connu). Les acheteurs du client se frottent les mains, ils ont bien mené leur barque. Le chef de projet est contraint de faire travailler tout le monde plus que de raison pour tenir des délais déraisonnables. Le mot « pénalité » se murmure discrètement puis fuse au grand jour dans toutes les réunions de projet, brandi comme la menace suprême. Les services juridiques des deux parties ressortent le contrat et s’y penchent avec beaucoup d’intérêt. Tout le monde passe d’ailleurs plus de temps à voir comment prendre l’autre partie à défaut que de véritablement essayer de résoudre les problèmes ensemble, en toute bonne foi. Et les utilisateurs dans tout ça ? Ils s’inquiètent. L’application qu’ils ont commandée est critique pour l’exercice de leur métier. La MOE leur explique qu’ils ont mal travaillé, que leurs spécifications sont trop floues, que leurs incessantes demandes de modifications sont inacceptables. Ils seraient même pointés du doigt comme deuxième responsable d’un tel chaos, après l’intégrateur, bien entendu.</p><p>Ce projet devient vite un puit sans fond. Le client est allé trop loin pour faire machine arrière. On ouvre la boîte de Pandore : les « avenants », le mot est enfin lâché à la grande satisfaction de tous car, in fine, c’est la seule manière de s’en sortir la tête haute des deux cotés. Mais attention, l’usage de tels coups de canif au contrat liant les deux parties doit se faire avec beaucoup de parcimonie bien entendu, car il doit juste permettre à l’intégrateur de réduire « un peu » son déficit sur le projet, là où vraiment on ne peut pas le prendre à défaut. Ce subterfuge lui permet, tout juste, de se maintenir dans un état financier végétatif sur le projet (pertes réduites ou au mieux rentabilité nulle).</p><p>Le paradigme du développement logiciel au forfait repose sur des principes (pour ne pas dire des valeurs) falsifiés, malhonnêtes, utopiques, désuets.</p><p>Les entreprises qui réussissent comme Google, Amazon et Microsoft, pour ne citer que les plus connues, l’ont compris depuis longtemps. Les méthodes agiles sont une alternative sérieuse. Les principes de ces méthodes sont les suivants :</p><ul><li><strong>Compétence et motivation des équipes</strong><br /> Le personnel mis à la disposition des projets est du niveau de séniorité nécessaire au développement d’applications modulaires, évolutives, performantes, documentées, intégrables et exploitables. Ce personnel s’engage sur le chiffrage et la réalisation de l’application.</li><li><strong>Développement itératif</strong><br /> Le développement des projets est itératif. L’effet tunnel est supprimé. Les modules livrés sont immédiatement opérationnels.</li><li><strong>Un accueil favorable du changement</strong><br /> La rédaction de spécifications détaillées complètes des mois avant sa livraison se révèle être une utopie. Dans ce contexte, l’acceptation du changement de priorités, de fonctionnalités fait partie intégrante du processus de développement agile de Xebia.</li><li><strong>Une collaboration étroite avec les utilisateurs</strong><br /> L’implication forte du management et des utilisateurs tout au long du projet est organisée autour de feedbacks permanents orchestrés par des démonstrations systématiques qui permettent, à chaque itération, de valider le travail effectué et de définir les priorités de l’étape suivante.</li><li><strong>Une attention permanente à l’excellence technique</strong><br /> L’hyperspécialisation Java/J2EE permet, dès le début du projet, de mettre en place les meilleures pratiques en vigueur dans l’industrie et cela à tous les niveaux du projet : Architecture conçue par des Architectes expérimentés, politique d’intégration continue, tests de performance, gestion des erreurs, exploitabilité des applications, choix technologiques pérennes, …</li></ul> </article> <article> <h1>Des closures en Java</h1> <p>Guillaume Bodet — Thu, 10 May 2007 08:28:14 +0000</p> <p>Le débat autour de l’introduction des closures dans le langage Java fait rage – avec toute la mesure et l’absence de pédanterie dont sait faire preuve notre profession sur ce type de sujet. Selon toute vraisemblance, les closures seront l’une des fonctionnalités phare de Java 7. Reste à savoir sous quelle forme.<br /> Deux écoles ont émergé sur le sujet : la première, désignée <em><a href="http://www.javac.info/">BGGA</a></em> (du nom de ses auteurs et promoteurs, Gilad Bracha, Neal Gafter, James Gosling et Peter von der Ahe), propose une extension syntaxique relativement complexe mais permettant d’introduire dans le langage tous les idiomes nécessaires à un support des closures similaire à celui disponible dans Ruby ou Smalltalk : function types, free variables, blocks, etc. ; la seconde désignée par l’acronyme <em><a href="http://docs.google.com/View?docid=k73_1ggr36h">CICE</a></em> (pour Concise Inner Class Expressions) et soutenue par Joshua Bloch, Doug Lea et « Crazy Bob » Lee, propose plus modestement une simplification de la syntaxe java dans le but de désinhiber l’usage des Inner Class en lieu et place des closures.<br /> L’occasion de faire ici un point sur ces deux approches et d’apporter, sinon une pierre à l’ouvrage, du moins des éclaircissements sur les termes du débat.</p><p>La définition la plus répandue des closures est la suivante (Neal Gafter fournit un historique des closures <a href="http://gafter.blogspot.com/2007/01/definition-of-closures.html">dans son blog [en]</a>) :</p><p><em>A <strong>closure</strong> is a <strong>function</strong> that captures the <strong>bindings</strong> of free variables in its <strong>lexical context</strong>.<br /> </em><br /> En substance, une closure est un bloc de code référençable, manipulant optionnellement des variables dites « libres » – libres en ce sens qu’elles sont définies non dans le bloc de code, ni de façon globale, mais par le contexte dans lequel le bloc est exécuté.</p><p>Un peu de code valant souvent mieux qu’un long discours, voici un exemple très simple d’utilisation des closures en Ruby (Ruby fait un usage intensif des closures, ce qui est probablement à l’origine de l’affection que lui porte ses utilisateurs). Cet exemple est tiré de<a href="http://www.martinfowler.com/bliki/Closure.html"> l’article de Martin Fowler sur le sujet [en]</a>.</p><p>Imaginons que vous souhaitiez extraire d’une liste d’employés une sous-liste comprenant uniquement ceux qui sont cadres. Une implémentation possible en java est la suivante :</p><pre class="brush: java; title: ; notranslate"> public static List<Employee> managers(List<Employee> employees) { List<Employee> result = new ArrayList<Employee>(); for (Employee e : employees) if (e.isManager) result.add(e); return result; } </pre><p>En Ruby, la même fonction serait codée de la sorte :</p><pre class="brush: ruby; title: ; notranslate"> def managers(employees) return employees.select {|e| e.isManager} end </pre><p>La méthode <code>select</code> est définie dans la classe Collection de Ruby. Elle prend en paramètre un bloc de code – la fameuse closure – , défini entre accolades. Si le bloc de code prend des arguments, ces derniers sont déclarés entre deux barres verticales (ce sont les variables « libres », dont la portée est définie par le contexte). La méthode <code>select</code> encapsule l’algorithmique : itération sur la collection, exécution du bloc de code pour chaque élément et construction d’une sous-liste contenant les éléments pour lesquels le bloc de code s’évalue à true.</p><p>Il existe bien sûr en Java un mécanisme assez similaire, autorisé par l’usage de classes anonymes imbriquées (Anonymous Inner Class, ou AIC).<br /> Supposons que la classe <code>List</code> possède, symétriquement à sa contre-partie Ruby, une méthode <code>select</code>, prenant en paramètre une interface définie comme suit :</p><pre class="brush: java; title: ; notranslate"> interface Filter<T>(){ public boolean accept(T e); } </pre><p>Alors le code java pourrait s’écrire comme suit :</p><pre class="brush: java; title: ; notranslate"> public static List<Employee> managers(List<Employee> employees) { return employees.select( new Filter<Employee> { public boolean accept(Employee e){ return e.isManager(); } } ); } </pre><p>Les AIC sont l’avatar traditionnel des closures en java. Les API du JDK en font largement usage (pensez aux interfaces <code>Runnable</code>, <code>Comparable</code>, <code>Callable</code> ou <code>TimerTask</code>, qui fournissent des closures aux classes <code>Thread</code> ou <code>Executor</code>, ou encore permettent de configurer les collections). Les Design Patterns callbacks, factories, predicates ou stategies sont des candidats naturels à ce type de construction. Spring, en particulier dans son framework de templates, les exploite à très bon escient pour masquer le caractère fastidieux de certaines API, JDBC en particulier.</p><p>Pour autant, la programmation par closures, très répandue chez les rubyistes, est quasiment inexistante chez les programmeurs java. Le listing ci-dessus fournit une première explication : la syntaxe des AIC, verbeuse à souhait, est propre à décourager les meilleures intentions. Ensuite, le support des AIC dans Java comme mécanisme de closures souffre de sévères limitations : une fois instanciée, une AIC est un objet à part entière, doté d’une portée qui lui est propre, et partiellement aveugle au contexte qui l’a créé. En conséquence, les variables ou méthodes sont résolues dans le portée de ce nouvel objet.</p><p>Examinons, pour illustrer ces quelques lignes de Ruby :</p><pre class="brush: ruby; title: ; notranslate"> i = 1; 1.upto(100) { |num| i *= num; } puts i; </pre><p>Ce code permet d’afficher le factoriel de 100. La variable <code>i</code> est définie en dehors de la closure et modifiée dans son corps. Le code java équivalent ne compilerait pas (à supposer qu’une API similaire soit disponible). En effet, pour qu’une variable externe soit accédée dans le corps d’une AIC, elle doit être déclarée <code><em>final</em></code> (la raison sous-jacente est que la variable est copiée dans le contexte de l’AIC). Elle ne peut donc être modifiée. Cela ne pose pas de difficulté si la variable est d’un type <em>mutable</em> (comme une liste ou un wrapper), mais peut se révéler problématique s’il s’agit d’un type <em>immutable</em> ou d’un <em>value type</em> (en particulier les String et les types primaires).</p><p>Voici un exemple type des contorsions nécessaires en java pour contourner cette contrainte :</p><pre class="brush: java; title: ; notranslate"> final int[] numCompares = new int[1]; Arrays.sort(a, new Comparator<Integer>() { public int compare(Integer i1, Integer i2) { numCompares[0]++; return i1.compareTo(i2); } }); System.out.println(numCompares[0]); </pre><p>C’est sur ce constat primordial que la proposition <a href="http://docs.google.com/View?docid=k73_1ggr36h">CICE</a> a vu le jour. Son objet n’est pas d’altérer le langage java mais de rendre plus concise la syntaxe de création des AIC (en fait, un sous-ensemble de ces dernières, appelées <em>single-abstract-method-types</em> ou SAM, qui sont en substance des interfaces ne comprenant qu’une unique méthode).</p><p>Avec la syntaxe proposée par CICE, notre exemple initial serait réécrit de la sorte :</p><pre class="brush: java; title: ; notranslate"> public static List<Employee> managers(List<Employee> employees) { return employees.select( Filter<Employee> { return element.isManager();} ); } </pre><p>Cette syntaxe dite concise est complétée par une altération des règles d’accès aux variables locales du bloc appelant (en particulier, celles déclarées explicitement publiques peuvent être assignées dans le corps de l’AIC).</p><p>Cette approche a bien sûr le mérite de la simplicité puisqu’ellle n’introduit aucun nouveau concept et ne nécessite pas la réécriture des API existantes ; elle pourrait de surcroît probablement être implémentée à l’aide d’une modification mineure du compilateur.</p><p>Pour certains, cependant, l’approche CICE ne fait qu’effleurer le sujet et ne propose qu’une mise à disposition minimaliste des closures en Java.</p><p>En effet, d’une façon générale, les AIC rompent le contexte d’exécution du code appelant et ne permettent pas de conserver la sémantique d’un nombre important de structures syntaxiques (celles que Neal Gafter appelle « lexically scoped language constructs ») :</p><ul><li>noms des variables</li><li>noms des méthodes</li><li>noms des types</li><li>signification de <code>this</code></li><li>noms des labels</li><li>référent d’une instruction <code>break</code> sans label</li><li>référent d’une instruction <code>continue</code> sans label</li><li><code>checked exceptions</code> déclarées ou interceptées</li><li>référent d’une instruction <code>return</code></li><li>et quelques autres plus exotiques (état d’assignation des variables, <code>reachability</code>, …)</li></ul><p>La proposition BGGA est une extension du langage java permettant la mise en oeuvre des closures sans rupture de transparence. La syntaxe proposée par BGGA est loin d’être triviale, ce qui lui vaut de nombreuses critiques – ses contempteurs sont au demeurant souvent les partisans de CICE.</p><p>Sans entrer dans le détail (qui peut être consulté sur le site <a href="http://www.javac.info/">http://www.javac.info/</a>), on retiendra les caractéristiques suivantes :</p><ul><li>BGGA définit une syntaxe permettant de déclarer des closures littérales ressemblant à ça :<pre class="brush: cpp; title: ; notranslate"> {int x, int y > x+y} </pre></li><li>BGGA définit également le concept des <em>function type</em>, dans lequel une fonction possède une liste d’arguments, un type de retour et une clause <em>throws</em> ; on peut instancier un <em>function type</em> à l’aide d’une closure littérale compatible</li><li>la transparence lexicale est intégralement garantie, tant pour l’association de variables que pour la résolution de noms ou les structures de contrôle (<code><em>break</em></code>, <code><em>continue</em></code>, <code><em>return</em></code>) – certaines closures peuvent cependant être marquées <em>restricted</em> et se comporter de façon identiques aux AIC</li><li>BGGA propose une grammaire simplifiée permettant d’exploiter les closures selon une syntaxe très proche de celle des structures de contrôle natives du langage – avec une telle syntaxe, la modification du langage pour introduire la seconde forme de boucle <code><em>for </em></code>aurait été superflue</li></ul><p>Avec BGGA, l’algorithme suivant</p><pre class="brush: java; title: ; notranslate"> lock.lock(); try { ++counter; } finally { lock.unlock(); } </pre><p>deviendrait</p><pre class="brush: java; title: ; notranslate"> withLock(lock, {=> ++counter; }); </pre><p>dans la forme canonique et, dans la forme simplifiée :</p><pre class="brush: java; title: ; notranslate"> withLock(lock) { ++counter; } </pre><p>Notre exemple initial pourrait être codé de la sorte (pour peu que l’API de Collection java se dote d’une méthode <code>select </code>appropriée) :</p><pre class="brush: java; title: ; notranslate"> public static List<Employee> managers(List<Employee> employees) { return employees.select({Employee e => e.isManager()}); } </pre><p>Comme évoqué plus haut, la médaille a un revers. Si côté client l’utilisation des closures BGGA semble relativement simple, la syntaxe risque de considérablement complexifier les API du JDK ou des frameworks désireux d’en tirer parti. Pour se donner une idée, voici le code de la fonction withLock utilisée plus haut :</p><pre class="brush: java; title: ; notranslate"> public static <T,throws E extends Exception> T withLock(Lock lock, {=>T throws E} block) throws E { lock.lock(); try { return block.invoke(); } finally { lock.unlock(); } } </pre><p>A l’instar des génériques, qui ont rendu presqu’illisible au commun le code source de certaines classes du JDK, une telle évolution syntaxique risque de dresser une barrière supplémentaire à l’apprentissage du langage java, et creuser encore davantage le fossé entre l’utilisateur d’API (<em>Joe Java</em>, comme disent certains) et le concepteur d’API. Le jeu en vaut-il la chandelle ?</p><p>Références (toutes en anglais) :<br /> [1] <a href="http://www.javac.info/">La proposition BGGA</a>, présentée par Neal Gafter aux <a href="http://video.google.com/videoplay?docid=4051253555018153503">Google TechTalks</a><br /> [2] <a href="http://docs.google.com/View?docid=k73_1ggr36h">L’approche CICE</a><br /> [3] <a href="http://crazybob.org/2006/10/java-closure-spectrum.html">Un très intéressant échange</a> sur le site de Crazy Bob, partisan de CICE<br /> [4] Deux articles parus sur developerWorks, le <a href="http://www-128.ibm.com/developerworks/java/library/j-cb01097.html">premier</a> sur les closures en général, et le <a href="http://www-128.ibm.com/developerworks/java/library/j-jtp04247.html">second</a> plus spécifiquement sur le débat BGGA vs CICE.<br /> [5] Un<a href="http://fishbowl.pastiche.org/2003/05/16/closures_and_java_a_tutorial"> article plus ancien</a>, sur l’approche traditionnelle des closures en java</ul> </article> <article> <h1>Codez comme des filles !</h1> <p>Guillaume Bodet — Wed, 11 Apr 2007 08:11:36 +0000</p> <p>Vous avez sûrement déjà , au moins une fois, en parcourant les sources d’un logiciel open source été impressionné par la qualité formelle du code : nommage efficace et pertinent, choix judicieux des paquets et de leur hiérarchie, émergence des concepts au travers de la structure, javadoc riche et dénuée de fautes d’orthographe… même si j’embellis un peu le tableau pour les besoins du propos, on oublierait pour un peu qu’il s’agit du même language que celui utilisé pour développer ce logiciel de gestion aux sources cryptiques dont vous avez hérité la maintenance. En fait, le code source de certains projets open source évoque fortement les fiches bristol que les filles confectionnaient au lycée pour simplifier leurs révisions, vous vous souvenez ? Ces précieuses fiches dont, pour tout dire, vous vous moquiez un peu, mais qui rendaient limpides les cours du semestre précédent quand vous même n’arriviez plus à relire vos propres notes. Jamais vu un garçon faire des fiches bristol bariolées. C’est un truc génétique, je crois, une séquence codante dans la branche manquante du chromosome Y, qui interdit aux mâles l’usage de l’encre turquoise et celle de la règle pour souligner les titres.</p><p>La coloration syntaxique et le formattage automatique des sources proposés par les IDE modernes permettent bien sûr, à peu de frais, de donner au code java l’apparence formelle des fiches bristol (ce qui, au passage, devrait les réhabiliter définitivement et couvrir de honte rétrospectives les anciens moqueurs). Mais ce travail d’enluminure textuelle n’est que rarement suffisant pour masquer la faiblesse des choix de nommage ou l’insuffisance des commentaires – quand ce n’est pas l’indigence des concepts architecturaux. Pire : il les met en exergue.</p><p>Laissé à lui-même, le développeur mâle standard tend à se laisser aller à une négligence peccamineuse, proche dans le principe de la façon dont il prenait ses notes au lycée, et qui transforme rapidement le code source le mieux intentionné en jachère sémantique – et en cauchemar esthétique. Etant moi même l’auteur de certaines des lignes de codes les plus vilaines jamais produites dans l’hémisphère nord (il m’arrive de faire du Perl), je m’interroge : pourquoi les développeurs open source (du moins certains) échappent-il à la malédiction ?</p><p>La raison en est probablement très simple : lorsque l’on développe du code open source, on s’expose à ce que les sources soient consultées par un nombre indéterminé de pairs à l’oeil expert, dont le jugement critique fera ou défera le succès du projet. Alors on tente de produire le plus beau code possible. On renomme 6 fois cette variable. On élague par refactoring. On épure l’architecture. On formatte la javadoc, un espace ici, un saut de ligne là , et là une liste à puces… Bref, on code comme une fille. C’est une bête question d’orgueil, la soif ancestrale de reconnaissance, le besoin de séduire.</p><p>Il resterait, bien sûr, à tenter de trouver une définition un tant soit peu opérationnelle de ce qu’est du <em>beau code</em> ; je ne m’y essaierai pas : les philosophes s’étripent (symboliquement, bien sûr, ce sont des gens d’une extrême mesure) depuis des siècles pour définir le <a href="http://fr.wikipedia.org/wiki/Beau">Beau</a>, et les programmeurs leur ont, à leur modeste échelle, emboité le pas [1]. Ce qui est sûr, c’est que la plupart des développeurs ont un jugement très sûr et savent reconnaître le beau code quand ils viennent à le croiser (ils utilisent le plus souvent le qualificatif d’<em>élégant</em> pour le désigner). Il arrive même à certains d’en produire… Et s’il est une vertu que chacun s’accorde à trouver au <em>beau</em> code, c’est qu’il est facile à comprendre, à maintenir et à utiliser. Des caractéristiques constitutives d’un logiciel de qualité.</p><p>Certaines pratiques clés de l’eXtreme Programming, en particulier le <em>pair programming</em> ou les revues de code systématiques ont pour vocation de stimuler en permanence l’orgueil esthétique des programmeurs en soumettant leur production au regard critique de leurs pairs. Ce n’est pas pour plomber la productivit des codeurs. C’est pour qu’ils produisent du beau code. C’est pour qu’ils codent comme des filles !</p><hr />[1] Pour d’autres considérations sur la féminité du code, consultez l’excellent post de Kathy Sierra <span class="nobr"><a rel="nofollow" href="http://headrush.typepad.com/creating_passionate_users/2006/03/code_like_a_gir.html">Coding like a Girl [en]</a></span>.</p><p></p> </article> </main></body></html>

Blog Xebia France » développement

Xebia à la conférence Software Craftsmanship

NoThunes, MediaPlayer et moteur de recherche

En tant qu’internaute, je dois pouvoir écouter un morceau

En tant qu’internaute, je dois pouvoir rechercher des morceaux par mots-clés

Conclusion

Ressources

NoThunes, AJAX-ification sauce Grails

Sprint Backlog détaillé

Gestion des Tracks

Navigation pour les internautes

Navigation

Sprint Review

Ressources

NoThunes, l’espace VIP

Sprint backlog détaillé

Gestion du profil utilisateur

Confirmation des modifications de mot de passe

Création d’un contrôleur dédié à l’affichage et la mise à jour du profil

Member manages ...

Gestion des CRUD métiers : les classes Band et Album

Member manages ...

Upload d’une image logo pour les Band

Contrôleur de téléchargement

Sprint review

Ressources

NoThunes, naissance d’un projet Grails

Note technique

Product Backlog

Présentation du modèle de données

Démarrage du projet

Mise en place de la sécurité

Création des classes du modèle

Dynamisons le menu

Admin manages ...

Member manages ...

Menu

Debriefing

Ressources

Refactorisation de bases de données avec Liquibase

Problèmes posés par la gestion des bases de données

Refactorisation de bases de données avec Liquibase

Caractéristiques et fonctionnalités principales

Ce que vous avez peut-être raté au troisième trimestre 2008

Les 10 commandements des logs applicatives

Simplifiez votre configuration Spring 2.5 avec les annotations

Programmation concurrente : notions fondamentales

Les 10 commandements des logs applicatives

Les 10 commandements

Entrons dans le détail

1 – Les logs sont un outil collaboratif issu d’un processus itératif

2 – Les logs sont une brique applicative intégrée à l’environnement d’exécution de l’application

3 – Les logs sont paramétrées en fonction des besoins

4 – Les logs doivent avoir un impact minimal sur les performances globales de l’application

5 – Les logs ne doivent pas occasionner de perte d’information

6 – Une utilisation correcte du logger est la première source d’information

7 – L’utilisation du framework de logs doit être simplifiée

8 – Une log efficace doit remplacer le debugger

9 – Le framework mis en place doit servir exclusivement à produire des logs applicatives

10 – Les logs permettent de décrire le comportement aux frontières de l’application

En conclusion

Références

Les frameworks de logs les plus connus

Critiques

Ce que vous avez peut-être raté au second trimestre 2008

Urbanisation pour les nuls

Les 10 commandements des tests unitaires

SpringSource Application Platform : la brèche dans Java EE

Hands on Wicket – Partie 4

Les mécanismes de templating

Hello dans le fils

Upload d’une image logo pour les `Band`