Lorsqu’il s’agit de construire un projet Java, des outils tels que Ant ou Maven viennent généralement les premiers à l’esprit.
Mais existe-t’il des solutions alternatives à ces « poids lourds » ?
Vous avez peut-être entendu parler de Gradle, Ivy, GAnt ou encore EasyAnt. Mais que valent ces solutions aujourd’hui ?

Je vous propose donc de faire un tour d’horizon le plus complet possible des outils de builds du monde Java au travers de mon dernier article sur le site developpez.com

Start Slide Show with PicLens Lite

Voilà. C’est fait !
La conférence CitConf Europe 2009 est terminée. Elle s’est tenue en fin de semaine dernière à Paris, vendredi soir et samedi.
CitConf est l’une des conférences à laquelle je voulais absolument assister depuis au moins 2 ans, entre autre grâce à l’énorme publicité qu’Eric Lefevre a su faire autour de l’événement.
A vrai dire, sur les 120 participants, je pense que pas loin de la moitié d’entre eux ont connu cette conférence grâce à Eric ! Un grand bravo à lui donc !

Alors ça parle de quoi CitConf ? De tests et d’intégration continue. Sans doute est-ce pour cela que CitConf signifie Continuous Integration and Testing Conference !
Cette conférence existe depuis 2006 et fait le tour du monde. Ainsi, chaque année CitConf se rend en Amérique du Nord, en Europe et en Asie.
Après Londres (2006), Bruxelles (2007) puis Amsterdam (2008), c’est au tour de Paris d’acceuillir CitConf Europe.
Dès lors, comment rater cet événement ?

CitConf Paris s’est donc déroulé sur deux jours. Ou pas tout à fait.
En effet, la première journée n’était en réalité qu’une soirée. Elle a été dédiée essentiellement à la présentation de la conférence, des participants et le choix des sujets !
Eh oui, malgré la présence d’environ 120 personnes, chacun de nous s’est présenté – brièvement certes – en indiquant en particulier ce que l’on attendait d’une telle conférence.

Ensuite est venu le temps de définir les sujets. Contrairement à la plupart des conférences existantes, CitConf ne définit aucun programme particulier. C’est aux participants de les choisir.
On pourrait qualifier de « conférence wiki » ou encore de « conférence pilotée par la communauté » !
Officiellement, ce principe porte de nom d’Open Space : chaque participant propose un ou plusieurs sujets, puis en écrit le titre sur un post-it.
Une fois ces sujets définis vient la ronde des votes. Chacun vient voter sur les sujets qui l’attirent, en plaçant une croix sur le post-it en question.
Ainsi se dégagent une vingtaine de sujets populaires, qui sont alors ventilés dans les différentes sessions de la journée de samedi.
Autre originalité de ce format : le planning est dynamique. Autrement dit, une session peut être déplacée vers un autre créneau horaire, et ce même quelques minutes avant le début de la dite session !
Cela peut paraître plutôt chaotique, mais au final ça se gère très bien. Après tout, Wikipédia fonctionne bien aussi
Dernière règle à connaître pour les participants à un Open Space : la « règle des deux pieds ». Vous assistez à une session qui ne vous intéresse pas (ou plus) ? Il suffit de sortir, et d’en joindre une autre ! C’est bête, c’est simple, mais ça marche !

La journée de samedi est donc divisée en 5 sessions, 2 le matin, 3 l’après-midi.
Chaque session étant séparée par une pause d’un quart d’heure, cela favorise énormément les échanges, et c’est bien là la chose la plus passionnante de cette conférence.

En ce qui me concerne, les sessions auxquelles j’ai assisté sont les suivantes :

• Done and Testing
• TDD
• Future of Continuous Integration
• Cloud computing and Continuous Integration
• 100 learning ideas

J’y reviendrais dans un second post…

La conférence s’est finalement conclue comme elle a commencé, à savoir par un tour de « table » (ou plutôt « tour de salle », car à 120 la table devrait être plutôt grande).
Cette fois-ci, chaque participant était invité à dire quel avait été son « AA moment« , autrement dit son coup de coeur, son kiff de la journée.
Je ne pense pas beaucoup m’avancer en disant que ce sont plus les discussions autour de ses sessions qui ont véritablement passionné les participants, bien que les sessions ont été le théâtre de très instructifs débats !

Voilà, j’ai vraiment passé un bon moment, et je tenais donc à remercier une fois de plus Eric Lefevre pour sa participation à cet événement, aux deux Jean-Michel qui ont également pris part dans l’organisation, mais aussi à Paul Julius et Jeffrey Fredrick, les co-fondateurs de l’événement !

Déjà de nombreux retours sont présents sur la toile :

Les sessions avec leur contenu : http://citconf.com/wiki/index.php?title=CITCONEurope2009Sessions

Des réactions sur les blogs en anglais :

• http://ericlefevre.net/wordpress/2009/09/21/mock-objects-at-citcon-paris-2009/
• http://ericlefevre.net/wordpress/2009/09/22/faster-tests-at-citcon-paris-2009/
• http://gojko.net/2009/09/19/citcon-europe-09/
• http://gojko.net/2009/09/21/mocks-are-not-about-isolation-but-about-responsibilities/
• http://www.exubero.com/joe/2009/09/citcon-europe-2009/
• http://blog.dahanne.net/2009/09/18/citcon-europe-2009-paris/
• http://www.testingreflections.com/node/view/8274

et en français :

• http://www.touilleur-express.fr/2009/09/20/citcon-2009-paris/
• http://www.touilleur-express.fr/2009/09/20/citcon-2009-done-and-testing/
• http://www.touilleur-express.fr/2009/09/20/citcon-2009-mock-mock-and-mock/
• http://www.touilleur-express.fr/2009/09/20/citcon-2009-user-acceptance-test/
• http://www.javasioux.fr/blog/2009/09/20/compte-rendu-citcon-paris-2009/
• http://blog.xebia.fr/2009/09/21/citcon-paris-2009/
• http://www.parisjug.org/xwiki/bin/view/Blog/LeParisJugAuCITCON

Et enfin, quelques photos pour les curieux qui se demandent à quoi cela pouvait ressembler :

• http://dedibox.mathieu-bolla.com/citcon-europe-2009/ (Mathieu Bolla)
• http://www.flickr.com/photos/elefevre/sets/72157622419361134/ (Eric Lefevre)

A noter aussi qu’un bon nombre de tweets ont été réalisés pendant l’événement (dans les 300 selon Eric Lefevre). J’avoue avoir ma part de responsabilité là dedans (merci mon iPhone ) !

Start Slide Show with PicLens Lite

Onze mois exactement après sa publication, mon article de developpez.com sur Sonar se refait une jeunesse !

L’article parlait de la version 1.4.1 de Sonar. Or aujourd’hui – normalement – la version 1.10 devrait officiellement être disponible !

Que de chemin parcouru depuis une année ! Le support des plugins est sans doute l’ajout qui m’aura le plus marqué, mais de nombreuses évolutions ont aussi vu le jour. L’interface web s’est encore améliorée, de nombreuses métriques ont été intégrées. Le développement de Sonar Squid a également permis d’offrir une meilleure analyse du code…

Allez, courrez lire mon article pour tout savoir sur cet excellent outil, et n’hésitez pas à réagir sur le forum de developpez.com !

Start Slide Show with PicLens Lite

Profitons-en, de telles dates n’apparaissent que très rarement ! Il y aura bientôt le 11h11m11 le 11/11/11, et bien plus loin, le 12h34m56 le 7/8/90 !

La matinée

La keynote « La Longue Défaite : un retour sur l’histoire des méthodes de gestion de projet informatique » de Godefroy Beauvallet a donc ouvert le bal de la deuxième journée des XPDays France 2009.
Cette keynote nous a donc retracé, en 3/4 d’heure, l’histoire de la gestion des projets informatiques.
En 1994, on estimait que sur les projets informatiques, nous avions :

• 31% de projets annulés
• 53% des projets qui coûtaient au mieux deux fois plus cher que prévu initialement
• 9% des projets finissant dans les temps et dans le budget (chiffre pour les grandes compagnies)
• 16% des projets finissant dans les temps et dans le budget (chiffre pour les petites compagnies)

Si la même estimation pour l’année 2002 montre une certaine amélioration, cela n’est pas forcément dû à de meilleurs développements, mais plutôt au fait que nombre de projets sont de petits projets, donc moins susceptibles d’échouer…
Alors pourquoi une telle situation ?
C’est donc en étudiant l’histoire de la gestion des projets informatiques que nous pouvons trouver quelques réponses…
Godefroy nous a donc beaucoup parlé des modèles en cascade, de waterfall, de modèle en spirale, en insistant bien sûr sur les défauts de ces techniques.

Il nous a également conté l’histoire passionnante du projet Polaris dont le développement (capital, en temps de Guerre Froide) s’était basé sur le PERT (Program Evaluation Review Technique).
Le PERT a été ainsi créé en 1956 à la demande de la marine américaine afin de planifier la durée de son programme de missiles balistiques nucléaires miniaturisés Polaris.
Alors que le délai initial de ce programme – qui a fait intervenir 9000 sous-traitants et 250 fournisseurs – était de 7 ans, l’application de la technique du PERT a permis de réduire ce délai à 4 ans.
Mais en réalité, la technique du PERT n’était que peu utilisée dans les faits, mais il servait essentiellement de sécurité pour les décideurs, pour montrer que tout allait bien…

Une keynote vraiment intéressante au final, bien que peut-être un peu courte, car il y avait tant à dire !

J’ai ensuite réalisé ma présentation sur Sonar au cours des Lightning Talks, ensemble de sessions rapides dédiées aux outils.
Si je suis plutôt content de ma prestation, je regrette toutefois le peu de temps dont j’ai disposé pour aller véritablement au fond des choses, en particulier sur l’aspect plus théorique comme le suivi de la qualité du code source.
D’un autre côté, il faut dire qu’une autre présentation « qualité du code source et l’intégration continue » devait aborder ces sujets…
Les Lightning Talks se sont ensuite poursuivi avec les présentations sur les outils agiles dans le monde .Net, puis sur GreenPepper.

J’ai donc ensuite été voir la « Qualité du code source et l’intégration continue » par Erwan Alliaume et Nicolas Le Coz de Xebia.
A vrai dire, je n’ai pas beaucoup appris lors de cette session, mais il faut dire aussi que ces sujets sont loin de m’être étrangers
Le contenu était toutefois intéressant, et présentait plutôt bien l’état actuel de la réflexion sur la qualité du code, ainsi que son suivi au cours du développement d’un projet.
A noter une (courte) démonstration de l’outil Sonar a été faite à la fin de la session, ce qui tend à prouver l’importance que prend cet outil aujourd’hui !

J’ai passé ma deuxième moitié de la matinée à chercher la réponse à la question « Scrum est-il dangereux ?« , animée par Guillaume Tardif et Eric Lefevre-Ardant.

Il ne s’agissait pas d’une présentation, mais d’une sorte de forum, de débat ouvert.
Première étape : prendre le pouls de l’assemblée. Qui pense que Scrum est dangereux ? Qui pense que Scrum est une bonne chose ?
Nous devions être entre une cinquantaine de participants, et mon estimation est qu’environ 60% d’entre eux avait un avis plutôt positif sur Scrum, le reste un avis plutôt (voire très) négatif, à quelques exceptions près dont Emmanuel Gaillot d’Octo pour qui Scrum reste un mot (ce en quoi, il n’a pas tort ) …

Eric a divisé la session en deux parties, où chacun était libre de donner son avis, son point de vue sur Scrum.
Considérant la grande qualité des personnes présentes dans l’assemblée, je dois dire que le débat a été très passionné, et je pense même que les 90 minutes de la session n’étaient pas suffisantes !

Nous avons donc commencé par penser que Scrum est dangereux car :

• il donne une certaine méfiance aux personnes extérieures au projet
• il donne du mal pour collaborer avec des équipes non Scrum
• il marginalise
• il peut s’apparenter à une dérive dogmatique
• il ne fait pas sérieux, avec son jargon
• il révèle les incompétences
• il provoque des départs dans l’équipe
• il remet en cause l’organisation
• il radicalise les équipes
• il supprime le chef de projet
• il rend plus difficile la valorisation des collaborateurs
• il peut (se) décridibiliser en cas d’échec
• il existe des certifications, incitant à penser qu’il y a des gens qui savent mieux que d’autres
• il représente une solution de facilité
• il n’implique pas assez le Product Owner
• il est viral
• il est simpliste
• il peut casser le reste de l’agilité
• il est trop formel
• il est incompatible avec la Recherche & Développement
• il est difficile à faire

Malgré ce déluge de critiques, on s’est dit aussi que Scrum est une bonne chose car :

• il accroît la communication
• il accroît l’implication de l’équipe dans le projet
• il fait émerger les problèmes
• il est compréhensible par les non-développeurs (contrairement à XP)
• il offre une grande visibilité de l’avancement du travail
• il détruit le waterfall
• il fait de la publicité pour l’agilité
• il ouvre la porte à XP
• il permet de lisser l’effort
• il permet d’échouer plus vite !
• il amène à la réflexion
• il donne un codage plus efficace
• il donne une plus grande motivation, plus de plaisir
• il offre une certaine liberté
• il n’est pas une méthodologie
• il offre une impression de fluidité, de rythme
• il est honnête
• il donne un meilleur contrôle du client, grâce au rôle du Product Owner et de son rôle de prioritisation
• il se focalise sur le produit
• il y a beaucoup de documentation, de retours d’expérience

Voilà pour la liste des aspects positifs ou négatifs sur Scrum.
Un compte-rendu plus élaboré sur cette session est donné par Nicolas sur son blog du Touilleur Express.
Il a également eu la bonne idée d’enregistrer la session, disponible en Podcast.
Eric a également fait une rétrospective – en anglais – de cette session, visible ici.

A noter que cette session a été fortement inspirée de Is Scrum evil? de Jeffrey Fredrick, et que le choix de la traduction d’Evil par dangereux était sujet à controverse (mais a-t-on une meilleure traduction ?)…

Eric a conclu très furtivement en disant que la meilleure méthode agile était la ARxTA, ou Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism… Tout un programme !

L’après-midi

J’ai commencé mon après-midi avec une « Introduction à TDD pour les managers« , d’Eric Lefevre-Ardant et Stéphane Labati.
Si je suis assez au fait de la méthode TDD (Test Driven Development ou encore Développement Piloté par les Tests), j’étais assez curieux de voir comment elle allait être présentée à un public de non techniciens.
Cela peut toujours être intéressant de trouver des nouvelles idées pour convaincre les grands chefs et les managers de l’utilité d’une telle pratique…
Ici, point d’Eclipse, de Netbeans ou autre IntelliJ. Le seul outil utilisé est Excel ! Eh oui, faire du TDD avec Excel, c’est possible.
L’application a développer reste relativement simple – quoique – puisqu’il s’agit d’un « traducteur » de chiffres arabes en chiffres romains.
Sans être très technique, j’ai trouvé cette mise en pratique plutôt sympathique, montrant efficacement l’intérêt de la méthode TDD.

Viennent ensuite deux présentations proposées par mon ami Rémy Sanlaville, dont la première, « Coding-dojo : un retour d’expérience« , expose un retour d’expérience sur les Coding Dojo.

Mais avant toute chose, qu’est-ce qu’un coding-dojo ?
Le constat de départ est que trop de développeurs utilisent uniquement leur travail (et leurs réalisations professionnelles) comme terrain d’entraînement pour parfaire leurs techniques.
Le principe d’un dojo de code est de proposer un espace sûr pour que les développeurs puissent expérimenter, tester et apprendre en dehors du cadre d’un projet.
Un coding dojo est donc l’endroit idéal pour apprendre un nouveau langage (le Ruby par exemple) ou encore une technique particulière (le TDD).

Rémy nous propose donc de faire un retour d’expérience consécutif à l’organisation de plusieurs coding dojo sur la région grenobloise, en insistant en particulier sur les problèmes rencontrés :

• Les problèmes liés à l’organisation : il faut du temps, répondre aux problèmes de logistique et de matériel…
• Les problèmes liés au bon déroulement de la séance. Ne pas oublier l’objectif premier, qui est celui d’apprendre, pas forcément de terminer les exercices proposés. D’où l’importance d’un bon facilitateur, qui saura diriger la session convenablement.

Bref, les coding dojo, ça marche, c’est gratifiant, mais ce n’est pas de tout repos à organiser !
Toujours est-il que CARA – Club Agile Rhône Alpes – organise son 11e coding dojo cette semaine ! Preuve du succès de ce type d’événement…

Cela me donne d’ailleurs une idée : ne pourrait-on pas organiser des coding dojo au sein de sa propre entreprise ?

Edit : Rémy, car c’est un gars bien, a mis ses slides à disposition, ici !

La deuxième session animée par Rémy Sanlaville que j’ai pu suivre traitait « De l’atelier à l’usine logicielle : enjeux et retour d’expérience d’Orange Labs« .
Grâce à son expérience au sein d’Orange Labs, Rémy nous a proposé un tour d’horizon très complet sur les solution d’usine logicielle qu’il a pu déployer.
La première étape consistait à nous expliquer l’intérêt d’une telle usine logicielle, puis à comprendre les différentes problématiques liés aux builds.
Un point important est de pouvoir assurer la reproductibilité du build dans l’espace (quelque soit l’environnement) et le temps (quelque soit la date du build).
En effet, différents facteurs impactent directement un build :

• Les fichiers source (code source, fichiers de ressources…) qui évoluent sans cesse
• La plateforme d’exécution, avec son OS, ses outils, ses librairies…
• Les ressources externes (repositories Maven2, ressources Web Services, etc.)
• Les facteurs humains, mais qui sont volontairement omis, car nous sommes dans une démarche d’automatisation des builds.

Bien entendu, Rémy a abordé la question de l’Intégration Continue, en expliquant entre autre l’importance d’une détection précoce des bugs…

Coût de correction et découverte des bugs au cours du cycle de développement

Un chapitre a été par la suite consacré à la question de la traçabilité, grâce à des outils de gestion de bugs (Jira par exemple).
Cela m’a fait comprendre qu’il est nécessaire de renforcer les liens entre l’outil d’Intégration Continue et celui de Tracking, le premier pouvant par exemple injecter des bugs dans le second en cas d’échec d’une compilation…

Bien évidemment, la surveillance de la qualité logicielle est un aspect important dans une usine logicielle, et Rémy a mis en avant l’intérêt qui a été porté à l’outil Sonar (eh oui, encore lui !).

En ressortent au final les aspects positifs d’une telle démarche :

• L’industrialisation réussie d’outils d’ingénierie logicielle
• La recommandation au niveau du groupe France Télécom
• La mise en place de bonnes pratiques
• Les projets sont demandeurs de telles solutions, et souhaitent aller encore plus loin
• L’ingénierie logicielle se renforce dans la culture d’entreprise

mais également les difficultés rencontrées :

• Beaucoup de travaux à mener en parallèle
• Certains sujets (les métriques en particulier) sont difficiles à conceptualiser
• Industrialiser un outil demande du temps et des compétences
• Prise en compte des nombreuses contraintes liées à la taille d’un groupe tel que France Télécom

Les slides de Rémy sont disponibles ici.

Bilan

Les XPDays sont à nouveau un joli succès.
Mon principal problème a été le planning très chargé, 6 sessions en parallèle sur ces deux jours, ce qui imposait de faire parfois des choix difficiles !
D’après le questionnaire fourni, il n’est pas à exclure que la conférence se déroule sur 3 jours dès l’année prochaine…
A ce propos, XP Days France prendra le nom de Agile Paris dès l’année prochaine. Un nom certes plus en adéquation avec son contenu, mais qui ne me séduit pas forcément…

Une dernière fois, encore merci aux organisateurs pour leur fantastique travail !

De nombreux consultants ont réagi suite à leur présence aux XP Days.
Vous pouvez les retrouver sur le blog de Valtech, ici, ici ou encore ici…

Start Slide Show with PicLens Lite

Pour ma troisième fois, je participe à la conférence XP Days.
Cette année, le choix du lieu des organisateurs a été plutôt bien acceuilli, puisque le Châlet de la Porte Jaune, à quelques encablures de Paris, proposait un décor très agréable, en particulier pour le premier jour qui fut très ensoleillé.
Un bémol toutefois sur la disposition des salles, ainsi que sur l’absence de climatisation qui a rendu les présentations de l’après-midi un peu difficiles…

Le programme était très chargé sur ces deux journées.
En effet, pas moins de 6 sessions étaient proposées en parallèle, ce qui nous amenait parfois à des choix difficiles.

La matinée

J’ai donc commencé par une session avec un nom un peu barbare, à savoir « Un projet extrêmement ambitieux et flou, utilisant les technologies les plus récentes, distribuées sur plusieurs continents« .
Cette présentation, proposée essentiellement par Isabelle Therrien de Pyxis ainsi que ses collaborateurs de BeTomorrow et Orange services, nous a décrit la vie au quotidien d’un projet dont le développement se déroule sur trois sites (Paris, Bordeaux et Montréal).
L’aspect primordial au sein de ce type de projet est la communication. Sans bonne communication, et donc sans confiance, un projet ne peut avancer correctement. Il était donc essentiel de lever les obstacles liés à la distribution géographique (et horaire) de l’équipe.
L’un des tournants dans ce projet a été la mise en place de rencontres réelles entre les équipes, ce qu’ils ont baptisé les semaines bordelaises.
Cela a permis de créer de véritables liens entre les membres de l’équipe, et donc d’accroitre leurs confiances réciproques.

Les leçons que l’équipe a pu tirer de cette expérience sont les suivantes :

• Le choix des outils de communications est essentiel.
• Il faut faire attention à trop d’optimisme !
• Il est important de donner une grande visibilité sur ce qui est terminé pour la production.
• Il est nécessaire de créer de petites équipes.
• La propreté du code doit être valorisée!
• Il est préférable diviser les équipes selon une architecture modulaire.
• Il faut y aller, ne pas avoir peur de faire des erreurs…
• Il faut attendre d’être prêt avant d’implanter des changements.
• Etre attentifs et créatifs !

Bref, un retour d’expérience plutôt intéressant, qui montre que les contraintes de ce genre de projet ne sont pas insurmontables !

J’ai ensuite assisté à la présentation, par Arnaud Bailly de « Ceintures et bretelles : Tests pour une application web java« .
L’idée est de tester une interface web constituée d’un formulaire relativement simple.
Au début, on part de tests réalisés en Scala, exécutés par Maven2. Si les tests fonctionnent correctement, leur temps d’exécution n’est pas très bon. Comptons une bonne demi-minute pour exécuter 3 tests !
Autre problème, ces tests ne sont pas très lisibles et sont trop liés à la structure du code HTML. Ainsi, en changeant le formattage d’un lien, le test ne passait plus, car ce dernier ne retrouvait plus le lien dans l’arbre DOM (la requête XPath devant être modifiée pour que le test réussisse de nouveau).
Arnaud a donc montré différentes évolutions du code des tests, afin de les rendre plus faciles à lire et à écrire, et à les rendre indépendants de la couche de présentation.
Ainsi, nous avons pu voir en oeuvre différents frameworks pour tester les interfaces graphiques, différents concepts (le pattern Page object par exemple) pour améliorer l’écriture et la conception des tests.
Nous sommes également passé par la virtualisation de l’environnement (via HtmlUnit) dans le but que le navigateur (ici Firefox) ne soit plus directement utilisé pour lors de l’exécution des tests.

Au final, si l’on a réussi à rendre les tests beaucoup plus efficaces et beaucoup moins liés au code HTML, il n’en reste pas moins que les avancées furent minimes pour ce qui est du temps d’exécution.
C’est donc à ce moment qu’Arnaud nous a présenté la dernière version de ses tests, qui s’exécutent cette fois-ci directement au niveau client, donc sans avoir besoin du serveur.
Le gain temporel est devenu tout de suite évident, bien que j’ai trouvé que l’on perdait beaucoup des améliorations réalisées précédemment au niveau de la lisibilité du code des tests, puisque ceux-ci sont désormais écrits en Javascript, avec jQuery pour être précis (en utilisant la librairie de tests jQUnit).

Bref, si la présentation contenait des concepts intéressants, j’ai trouvé que le temps imparti – 30 minutes – était bien trop court pour les explorer complètement. D’où mon impression d’être resté sur ma faim…

Pour terminer la matinée, je me suis rendu à la présentation de Virgile Delécolle Chef, la recette.
Virgile nous a parlé de l’agilité non pas en nous parlant technique (TDD, XP, ou ce genre de chose), ni même de méthodologie (exit Scrum…) mais en nous rappelant les évolutions des tâches de management telles que la planification, le suivi ou encore le reporting.
Il en est également venu à aborder des sujets un peu moins communs, liés aux aspects humains. Ainsi, il a parlé du recrutement, ou encore des entretiens annuels, de l’animation des équipes.

La matinée se terminant, nous avons pu profiter d’un excellent repas. A nouveau, bravo pour l’organisation !

L’après-midi

Ma première session de l’après-midi était consacrée au « rôle du Product Owner et conception produit » de Sébastien Sacard.
Sébastien, passé du coté du rôle du Product Owner, désirait nous faire partager ses retours d’expérience sur les relation entre le responsable business, les responsables du design graphique, ou encore l’équipe de développement.
Les slides de cette présentation sont visibles ici.

J’ai également assisté à « TDD : avec ou sans mocks » de mes collègues de Valtech Anthony Dahanne, Yannick Ameur et Stéphane Malbequi.
Grâce une mise en scène assez agréable – malgré quelques petits ratés techniques – nous avons pu voir comment introduire les mocks dans la démarche des tests au sein d’une application.
Yannick joue le développeur, nouvellement arrivé dans l’équipe, et qui ne sait pas correctement mettre en place des tests unitaires. Grâce à l’aide de ses deux collègues, il va découvrir comment réaliser de bons tests unitaires, puis mettre un pied dans le monde du TDD (Test Driven Development).
Par la suite, les choses se compliquant quelque peu, l’équipe va faire appel aux mocks, en utilisant la librairie EasyMock (qui est moins bien que Mockito – ce message étant sponsorisé par David Gageot ).
Une présentation technique, sans trop de jargon pour autant, qui était assez agréable à suivre.
Peut-être que la mise en scène aurait gagné à être un petit plus « punchy »…

Ma seconde partie d’après-midi a commencé par « Mon Javascript est aussi agile« , toujours d’Arnaud Bailly.
Sur cette présentation, les avis divergent. Certains l’ont trouvé géniale, d’autres n’ont pas accroché du tout.
Personnellement, je me situerais un peu au milieu.
Arnaud nous a donc parlé énormément de Javascript – on s’en doutait – mais également de TDD et de DSL (Domain Specific Language), afin de nous montrer que l’on peut effectivement écrire plus proprement du code Javascript.
Ainsi, on a pu voir comment écrire un test de validation de formulaire à la façon « old school », puis en utilisant jQuery et enfin, en DSL. Voici un exemple de chacune de ces façons :

Javascript:

Javascript:

Javascript:

Bien que le contenu soit intéressant, j’avoue être parti pour deux raisons.
La première est que j’ai fini par être un peu perdu, cela allait un peu vite (et pourtant, j’ »aime » bien le Javascript).
La seconde, c’est que j’étais vraiment curieux d’aller voir la session sur « la parabole du trafic urbain, l’agilité expliquée autrement ».

Comme j’adore les embouteillages, j’ai donc finalement ma journée sur « La parabole du trafic urbain – l’Agilité expliquée autrement » de François Bachmann de Sprint iT.

François nous a montré de nombreux exemples de problèmes liés à la circulation automobile (bouchons, signalisation, etc.) et a essayé d’en faire un parallèle avec le monde de l’informatique en général, et de l’agilité en particulier.
François a ainsi comparer les voies de circulation aux ressources humaines du projet, les signalisations aux méthodes de gestion et les véhicules aux livrables.
On a ainsi pu observer que cet ensemble a un impact important sur la vitesse moyenne de circulation, et donc, selon cette analogie, sur le débit de production.
Savions-nous par exemple que la vitesse moyenne d’un automobiliste dans une grande ville, comme Tokyo ou encore Paris n’est que de 15 km/h, soit l’équivalent d’un déplacement à cheval !
François a donc mis en avant les avantages offertes par les méthodes agiles sur ce type de problème, comme l’importance de la communication ou la réactivité.
En continuant son parallèle avec la circulation, il a pris l’exemple du giratoire, qui sans être parfait, incarne certaines valeurs de l’agilité :

• La communication, par l’observation des autres.
• La simplicité, car il n’y a qu’un seul sens de circulation.
• Aucun flux n’est priviligié par rapport à un autre.
• La responsabilité et le respect des conducteurs.

(en ce qui me concerne, j’ai toujours pensé que dans beaucoup de cas, un sens giratoire était préférable à un carrefour traditionnel).

En conclusion, une présentation attrayante, expliquant tout à fait simplement les principes de base de l’agilité.
Une bonne session pour terminer agréablement cette première journée bien chargée !

A suivre…

Start Slide Show with PicLens Lite

RichFaces

Je n’ai pas encore eu l’occasion d’en parler sur ce blog, mais j’aime beaucoup RichFaces.
RichFaces est LA librairie de composants pour qui développe des applications JSF.
En plus d’offrir un support complet d’Ajax, RichFaces dispose de la plus complète des palettes de composants, avec pas moins de 101 composants différents !
Et tout cela pour une somme dérisoire, puisque c’est gratuit !

RichFaces 3.3.1

RichFaces vient tout juste de sortir en version 3.3.1, et intègre comme principale nouveauté les composants de layouts, destinés essentiellement à la présentation et à l’aspect visuel des pages.
Les composants <rich:page/>, <rich:layout/> et <rich:layoutPanel/> vont ainsi permettre un design plus aisé des pages JSF.
On notera l’utilisation de Yahoo! UI Grids CSS au niveau de l’implémentation de ces composants.
On peut en voir un exemple sur cette page.

Hormis cela, un nouveau composant fait son apparition. Il s’agit de <rich:colorPicker/> qui, je pense, a un nom suffisament explicite pour que je n’en fasse une description plus approfondie…
De nombreuses corrections (plus de 1100 bugs JIRA corrigés !) sont également de la partie. Parmi ces corrections, on notera celles-ci :

• Mise-à-jour de la librairie JQuery en 1.3.2.
• Le Maven Resource Dependency Plugin.
• Implémentation du lazy load pour le composant Calendar (RF-6884).
• Tree Adaptors configurable recursion order (RF-6639).
• Ajout de rich.isUserInRole() pour l’intégration de la sécurité, avec Acegi, etc.. (RF-6551).
• Mécanisme de Queue mis-à-jour (RF-5788).
• Possibilité de configurer le repositionnement DOM du Modal Panel (RF-5588).
• Optimizations côté serveur de l’attribut limitToList (RF-5838).
• etc.

Afin de montrer les capacités de cette librairie, en plus du classique site de LiveDemo, l’équipe de JBoss a crée un Album photo. Le site est plutôt lent actuellement, mais gageons que cela est dû à une forte affluence consécutive à l’annonce de la sortie de la version 3.3.1 de RichFaces !

RichFaces 4.0

La version 3.3.1 devrait être la dernière version majeure de RichFaces avant l’arrivée de la version 4.0. Pour l’heure, seule une version 3.3.2 est prévue, mais elle ne contiendra que des correctifs.

Concernant RichFaces 4.0, cette version est prévue aux alentours du mois d’Octobre 2009.
Son principal objectif sera de supporter la toute fraiche version 2.0 de JSF (prévue mi-2009, à la sortie de JavaEE 6).
Pour l’occasion, une refonte en profondeur de la librairie est prévue, dans le but d’en améliorer sensiblement la stabilité et les performances.

Start Slide Show with PicLens Lite

Personnellement, j’y serais essentiellement pour m’instruire, rencontrer des gens, discuter, mais aussi pour faire une démonstration de l’outil Sonar.
Ma présentation, qui fait partie des « Lightning Talks » et dont l’intitulé exact est « Suivre la qualité de son code source avec Sonar », sera divisée en deux parties :

• Une première partie mettant en lumière les défauts d’un code source, et présentant succinctement les outils permettant de les détecter et les corriger.
• Une seconde partie, où grâce à une démonstration de l’outil Sonar, je montrerais comment améliorer sensiblement la qualité de ses applications.

Le site officiel.
Le programme complet est visible ici.

ps : la SNCF annonce une grève pour le mardi 26 mai, alors faites attention !

Start Slide Show with PicLens Lite

Parmi les nouveautés apportées par cette mise-à-jour, nous pouvons y trouver :

• L’intégration avancée de LDAP. Team City offre maintenant la possibilité de se synchroniser avec l’annuaire LDAP d’une société.
• Les groupes d’utilisateurs. Il est désormais possible de rassembler les utilisateurs de l’outil au sein de différents groupes. On pourra ainsi spécifier les droits et notifications d’un ensemble d’utilisateurs beaucoup plus rapidement. Comme d’habitude, tout se gère depuis l’interface graphique :

• Amélioration de l’interface : des efforts ont été également apportés dans le but d’améliorer l’utilisation et l’intuitivité de l’interface graphique de TeamCity.

• Amélioration de la gestion des IDE et SCM. Lors de mon test de TeamCity, j’avais particulièrement apprécié les interactions poussées entre le serveur TeamCity et les IDE.
  Je regrettais toutefois que le plugin pour Eclipse propose moins de fonctionnalités que celui pour IntelliJ, en particulier concernant les commits pré-testés.
  Cela dit, étant donné que IntelliJ et TeamCity sont tous deux développés par JetBrains, cela peut se comprendre
  Le plugin Eclipse profite donc de cette mise-à-jour pour s’enrichir de cette fonctionnalité très intéressante, mais propose également de réaliser des builds distants, et gère désormais Perforce 2008.2.
• Rapports XML. En plus de la traditionnelle gestion des résultats des tests, TeamCity peut désormais analyser les rapports XML générés par des tâches Ant, NUnit, Surfire, PMD ou encore FindBugs.

• Framework Mono. TeamCity détecte automatiquement le framework Mono et peut-être utilisé comme plateforme pour l’intégration continue des projets .Net.
• Il y a également d’autres améliorations, plus mineures, sur cette release.

On notera enfin que le support du gestionnaire de sources Git est dès à présent proposé sous forme de plugin additionnel (en EAP, soit Early Access Program)…

Les nouvelles fonctionnalités sont détaillées ici.

Start Slide Show with PicLens Lite

D’après une étude publiée par l’éditeur des solutions Linux Red Hat et l’institut Georgia Tech, la France serait en pôle position des pays engagés dans le monde de l’open source. Ce rapport prend en considération plusieurs critères à savoir : l’indice global national d’adoption des solutions open source et la pénétration de ces dernières au sein des instituts publics et du secteur privé. Les chercheurs se sont aussi intéressés au nombre d’oeuvres publiées traitant du sujet, à la proportion d’ingénieurs certifiés par Red Hat, ainsi qu’aux statistiques du Linux Counter, un site au travers duquel l’internaute peut s’enregistrer en tant qu’utilisateur Linux.

La France obtient le meilleur score en ce qui concerne le déploiment du logiciel libre au sein des infrastructures gouvernementales. Ainsi le mois dernier nous apprenions que la Gendarmerie Nationale avait économisé 50 millions d’euros suite à son processus de migration vers les logiciels bureautiques d’OpenOffice.Org initié en 2004. L’on peut aussi mentionner le Ministère de l’Agriculture qui annonçait en 2007 vouloir adopter le système d’exploitation Mandriva. En France, le logiciel libre est principalement représenté par l’association April qui a récemment lancé une campagne promotionnelle afin de sensibiliser le grand public et les entreprises.

Derrière la France, nous retrouvons l’Espagne, l’Allemagne, l’Australie et la Finlande. Etant donnée la nature-même du logiciel libre, cette étude, qui donne une idée de l’activité globale, n’est bien évidemment pas définitive. Certaines statistiques pourraient évoluer, notamment le nombre de traductions fournies pour chaque logiciel open source, l’un des autres critères également pris en considération par les analystes.

Source

Cliquez sur l’image pour accéder à la carte interactive…

Start Slide Show with PicLens Lite

Une question intéressante est de savoir ce que vont devenir les produits Sun (voire ceux d’Oracle) qui font désormais doublon. Je vous renvoie sur une très bonne analyse de Sami Jaber, présentant entre autres un excellent tableau récapitulant le nouveau portefeuille d’Oracle…

Oracle prend à revers tout le marché de l’industrie et annonce finalement le rachat de Sun pour 7 Milliard de dollars. (…) voici mon analyse de la nouvelle donne griffonnée rapidement entre deux coups de fil.

Contrairement à IBM, Oracle dispose d’un portefeuille beaucoup plus concentré. Une offre qui s’articule autour de sa base de données maison et s’est étoffée au fil des acquisitions.

Mais globalement, je pense que ce rachat est un moindre mal. Là où IBM aurait difficilement trouvé de complémentarités avec Sun, Oracle s’enquiert d’un portefeuille riche qu’il devra conserver pour l’essentiel. (…)

IBM aurait racheté Sun pour le faire mourir à petit feu, Oracle achète Sun pour se renforcer, c’est une situation somme toute bien différente

Start Slide Show with PicLens Lite

Sonar 1.8

La dernière version de Sonar est sortie en fin de semaine dernière.
J’avais déjà évoqué les prochains chantiers de l’équipe de SonarSource lors de la sortie de la précédente version de l’outil.
En voici quelques résultats:

• Tout d’abord, l’apparition des « Hotspots », ces fameux dashboards récapitulant les principales faiblesses d’un projet (voir ici l’exemple des Hotspots pour le projet Tomcat sur le site de démonstration de Sonar Némo).
• Nous avons désormais la possibilité de visualiser les codes dupliqués directement depuis l’interface web.
• Maven 2.1 est dès à présent supporté par Sonar.
• Enfin, un meilleur paramètrage de FindBugs nous est offert.

Au delà des nouveautés fonctionnelles ou techniques, SonarSource souhaite également aider la communauté à développer de nouveaux plugins pour Sonar.
C’est la raison d’être de la Sonar Plugin Library.

A l’occasion, je me lancerais peut-être dans un petit tutoriel pour créer son propre plugin… A condition d’avoir un peu de temps pour cela, bien entendu !

Téléchargez Sonar 1.8

Concernant Sonar 1.9, dont la sortie est prévue courant mai, la principale nouveauté sera l’intégration de Sonar Squid, le remplaçant de JavaNCSS.

Et de 300 !

La 300e version d’Hudson est sortie ! Comme à chaque release, peu de nouveautés, mais toujours ces petits plus qui rendent cet outil si performant et indispensable !

J’ai prévu de me lancer d’ici peu dans la mise à jour de mes articles sur developpez.com traitant de ces deux outils.
J’en profite d’ailleurs pour faire un peu de publicité sur ces articles : celui sur Hudson, et celui sur Sonar.

Le principe en est fort simple : Google Chart API génère dynamiquement un graphique en fonction de paramètres et de données qui lui sont transmis via une certaine URL.

Prenons un exemple simple, en considérant l’URL suivante :
http://chart.apis.google.com/chart?cht=p3&chd=t:60,40&chs=250×100&chl=Hello|World

Dans les attributs de l’URL, nous retrouvons les paramètres suivants:

• cht=p3, indiquant quel type de graphique nous utilisons (ici, une « pie 3D »)
• chs=250×100 pour la dimension de l’image rendue.
• chd=t:60,40, correspondant aux données (ici 60 et 40).
• chl=Hello|World, correspondant aux labels des données.

Cette URL va ainsi produire l’image suivante :

Bien évidemment, de nombreux autres graphiques peuvent être créés :

Voilà de quoi s’amuser très rapidement !

Toutes les informations, les paramètres, les types, etc. sont disponibles sur la page officielle de Google Chart API.

Merci Google…

Start Slide Show with PicLens Lite

Les hotspots

Les hotspots sont en quelque sorte une vue centralisant l’ensemble des points à corriger au sein de l’application offrant un RoI (« retour sur investissement ») maximal.
En d’autres termes, c’est ici qu’il faudra se rendre afin de savoir quelles corrections apporter afin d’améliorer son application significativement, et ce, en contrepartie de relativement peu d’efforts.

Sur ces maquettes d’écrans, on peut y voir les hotspots, montrant par exemple quelles sont les violations les plus fréquentes, les classes ayant le plus de violations, ou encore un rapport sur les tests unitaires et leur couverture.
Reste à voir si ces hotspots seront paramétrables ou non…

Concernant cette nouvelle fonctionnalité, pas de révolution, puisque toutes ces données existent déjà sur Sonar. Toutefois, le fait de les retrouver centralisées en un point sera sans aucun doute appréciable !

La gestion du PHP

Sonar supporte nativement le langage Java. Il est également possible, via un plugin, de faire analyser le code PL/SQL de son application.
Sonar s’oriente désormais vers l’analyse du code PHP.
Comme pour le Java, Sonar se basera sur des outils du monde PHP pour l’analyse du code. On devrait y trouver des outils tels que :

• PHPUnit : tests unitaires et couverture de code.
• PHP_CodeSniffer : détection des violations de règles de standard.
• PHP Depend : différents types de métriques sur le code (complexité cyclomatique, statistiques, etc.)
• …

(la liste de ces outils ne semble pas encore définitive)

Plus d’informations à venir quant au support du PHP…

Ré-écriture de JavaNCSS

JavaNCSS est un outil plutôt ancien (il date de 1997, ce qui correspond presque aux tous débuts de Java !), mais plutôt intéressant.
Il offre de nombreuses statistiques sur le code source Java, indiquant le nombre de lignes, de commentaires, de méthodes, de classes, etc.
Le principal souci de JavaNCSS est qu’il n’a pas suffisament suivi les évolutions du langage, et de nombreuses limitations sont ainsi apparues, dont celles-ci :

• les classes internes ne sont pas analysées,
• il est impossible de faire ignorer à l’analyseur les commentaires de début de fichier (décrivant généralement la licence utilisée par le programme),
• annotations ou génériques (« nouveautés » intégrées depuis Java 5) mal supportés,
• etc.

L’équipe de Sonar a donc décidé de corriger ces problèmes en réécrivant le moteur de parsing de l’outil JavaNCSS.
Il est à noter que ces améliorations viendront donner se greffer directement sur le projet JavaNCSS, et seront donc disponibles en dehors de Sonar !

Voir ici pour de plus amples informations à ce sujet.

Start Slide Show with PicLens Lite

C’est donc la version 1.7 qui est sortie hier, le 18 mars 2009.
Qu’apporte cette nouvelle version, à l’exception de quelques bugs fixes ?

• Possibilité d’ignorer certaines classes ou package du contrôle de qualité. Voilà une fonctionnalité utile quand il on dispose de nombreuses classes générées automatiquement par des librairies tierces.
• Affichage des détails des erreurs des tests unitaires (ça, ça me manquait dans la version 1.6 !)
• Visualisation des lignes dupliquées d’une classe.
• Nuage de couverture disponibles désormais pour les packages et modules (et non plus seulement pour les classes).

Détails des erreurs des tests unitaies

Visualisation de la duplication des lignes dans le code

Bref, que du bon !

Pour le téléchargement, ça se passe par ici.

Start Slide Show with PicLens Lite

Ca fait un petit moment (quelque chose comme 6 – 8 mois) que j’entends parler de Wicket.
Aujourd’hui, je décide de franchir le pas, et de voir ce que ça vaut vraiment…

Mais alors qu’est-ce que c’est que Wicket ?
Je pourrais faire un copier coller du site web officiel de l’outil, et dire ainsi :
With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML, Apache Wicket makes developing web-apps simple and enjoyable again. Swap the boilerplate, complex debugging and brittle code for powerful, reusable components written with plain Java and HTML.
Mais non, ce serait un peu trop facile !

Wicket est donc un projet de la communauté Apache correspondant ainsi à un framework de présentation, basé uniquement sur du Java et du HTML.

On se prépare

Qui n’est pas bien équipé ne pourra pas bien travailler !
Je jette tout d’abord un oeil sur les IDEs compatibles avec Wicket.
La page du site me propose ainsi des plugins pour les plus populaires des IDEs, à savoir Eclipse, NetBeans et IntelliJ.
Optant pour ce dernier, je regarde donc du côté de WicketForge.
Pour la configuration sur Eclipse, je laisse mon ami Jawher s’occuper des explications…
Du côté Java, je reste sur mon Java 5, et un petit Maven 2.0.9.

On jette les bases

La première chose à faire, c’est de créer un nouveau projet sur IntelliJ.
Pour me faciliter la tâche, j’utilise l’archetype dédié à Wicket, qui me permet de créer la structure pour mon projet Wicket.

La commande Maven en ligne correspondante serait celle-ci :

mvn archetype:create -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.3.5 -DgroupId=romain -DartifactId=wicket-test

Comme le précise le site de Wicket, ce dernier utilise obligatoirement slf4j qui est un logger (un peu comme log4j).
Pour utiliser log4j au sein de son projet, il suffit d’ajouter la dépendance vers slf4j-log4j12.
Cette dépendance est obligatoire pour toutes les versions Wicket depuis la 1.3.0

Mon pom.xml ressemble donc à ceci :

XML:

Le projet créé par l’archetype a la structure suivante :

Le web.xml est constitué essentiellement par la définition du filtre de Wicket :

XML:

Au niveau du code source et des pages, il existe trois fichiers :

• WicketApplication.java : cette classe est le point d’entrée de l’application, qui étend org.apache.wicket.protocol.http.WebApplication et défini principalement la méthode getHomePage(), qui retourne la classe Java gérant la page d’accueil de mon application.
• HomePage.java est la classe Java gérant ma page d’acceuil. Elle étend org.apache.wicket.markup.html.WebPage
• HomePage.html est la page d’acceuil, en version HTML.

Si l’on jette un oeil sur le fichier HomePage.html, on voit ceci :

HTML:

A priori, rien de particulier, à ceci près que le span contient un attribut wicket:id.

Premier test

On va maintenant démarrer le serveur.
L’archetype a eu la gentillesse de nous créer un test JUnit qui se charge en réalité de créer et démarrer un serveur Jetty.
On lance donc le serveur, et voici les logs :

…
INFO – log – Logging to org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via org.mortbay.log.Slf4jLog
>>> STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP
INFO – log – jetty-6.1.4
INFO – log – NO JSP Support for /, did not find org.apache.jasper.servlet.JspServlet
INFO – Application – [WicketApplication] init: Wicket core library initializer
INFO – RequestListenerInterface – registered listener interface [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
INFO – RequestListenerInterface – registered listener interface [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
INFO – RequestListenerInterface – registered listener interface [RequestListenerInterface name=IFormSubmitListener, method=public abstract void org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted()]
INFO – RequestListenerInterface – registered listener interface [RequestListenerInterface name=IFormSubmitListener, method=public abstract void org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted()]
INFO – RequestListenerInterface – registered listener interface [RequestListenerInterface name=ILinkListener, method=public abstract void org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
INFO – RequestListenerInterface – registered listener interface [RequestListenerInterface name=ILinkListener, method=public abstract void org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
INFO – RequestListenerInterface – registered listener interface [RequestListenerInterface name=IOnChangeListener, method=public abstract void org.apache.wicket.markup.html.form.IOnChangeListener.onSelectionChanged()]
INFO – RequestListenerInterface – registered listener interface [RequestListenerInterface name=IOnChangeListener, method=public abstract void org.apache.wicket.markup.html.form.IOnChangeListener.onSelectionChanged()]
INFO – RequestListenerInterface – registered listener interface [RequestListenerInterface name=IRedirectListener, method=public abstract void org.apache.wicket.IRedirectListener.onRedirect()]
INFO – RequestListenerInterface – registered listener interface [RequestListenerInterface name=IRedirectListener, method=public abstract void org.apache.wicket.IRedirectListener.onRedirect()]
INFO – RequestListenerInterface – registered listener interface [RequestListenerInterface name=IResourceListener, method=public abstract void org.apache.wicket.IResourceListener.onResourceRequested()]
INFO – RequestListenerInterface – registered listener interface [RequestListenerInterface name=IResourceListener, method=public abstract void org.apache.wicket.IResourceListener.onResourceRequested()]
INFO – RequestListenerInterface – registered listener interface [RequestListenerInterface name=IActivePageBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
INFO – RequestListenerInterface – registered listener interface [RequestListenerInterface name=IActivePageBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
INFO – Application – [WicketApplication] init: Wicket extensions initializer
INFO – WebApplication – [WicketApplication] Started Wicket version 1.3.5 in development mode
********************************************************************
*** WARNING: Wicket is running in DEVELOPMENT mode. ***
*** ^^^^^^^^^^^ ***
*** Do NOT deploy to your live server(s) without changing this. ***
*** See Application#getConfigurationType() for more information. ***
********************************************************************
INFO – log – Started SocketConnector@0.0.0.0:8080

Je me connecte donc à mon serveur, à l’adresse http://localhost:8080, et je vois le résultat suivant :

Je constate qu’effectivement Wicket a utilisé le fichier HomePage.html, mais le span donc le wicket:id était précisé a vu son contenu modifié par la classe Java HomePage.java.
C’est plutôt un bon début, non ?

Voilà un premier pas dans le mode Wicket.
Rendez-vous dans un prochain billet, pour des tests un peu plus poussés !

Start Slide Show with PicLens Lite