Ce Samedi 31 Janvier a eu lieu un JavaCamp à Paris, le JavaCampParis 3.

A partir de 9h30 – 10h, les premiers participants sont arrivés; et après un détour par la machine à café, le JavaCamp a démarré.

Les personnes présentes ont alors proposé des sujets qui les intéressaient (et se sont aussi présentées); ensuite, une “refactorisation” des sujets proposés a mis en évidence 7 thèmes :

• TDD (Test Driven Development)
• langages de scripting autour de la JVM (Scala, Groovy, Ruby)
• DDD (Domain Driven Design)
• les langages RIA et les frameworks Web: GWT, Flex, Wicket
• Scrum
• JEE 6 et Spring
• SOA
• Les Mocks

Ces thèmes ont pu être débattus/présentés par les participants dans 2 salles et sur 4 créneaux horaires : 10h15 -11h30, 10h45-13h00, 13h30-14h30, 14h45-16h.

Pendant la séance “les langages RIA et les frameworks Web: GWT, Flex, Wicket”, Tarik, et Eric, nous ont présenté Wicket (en avant premiere de ParisJug) et leur framework au dessus Wicket (pour faciliter et mettre à jour dynamiquement les formulaires dans Wicket); et avant de plus partir sur Flex, j’ai pu présenter la mise en oeuvre de GWT.

En abordant les “langages de scripting autour de la JVM (Scala, Groovy, Ruby)”, on a pu parler de la facilité d’intégration, de la mise en oeuvre, de l’intéret et de la pertinence des iDE dans le cadre des développements Scala (qui est compilé), Ruby, Groovy et Java Fx.

En parallèle, dans la salle “Solaris”, les débats ont porté sur la testabilité des programmes java. Nous avons eu un bon aperçu des différentes pratiques et technologies associées aux tests logiciels. En vrac: les x-Unit, Selenium, GreenPepper, FitNesse, Concordion, Bumblebee, SWTBot. Le débat suivant fut une présentation de DDD (Domain Driven Design) par Sébastien Letélié et le principal framework : Qi4j. Une approche intéressante qui est une “sur-couche” à la programmation orientée objet. Cette vision incite les objets java à se décomposer par comportement. On obtient donc un composite formé de plusieurs associations.

Dans l’autre salle, durant la séance “Scrum”, après de brefs retour d’expérience, Eric (pas le même que celui de Wicket, mais le co-organisateur) a pris la parole, et après avoir défini Scrum, nous a fait part de son avis sur combien Scrum peut être mal appliqué, et, ainsi souffrir d’une image négative; d’ailleurs le sujet a ensuite débordé sur le cycle de vie des méthodologies projets (la courbe des experts, early adopters, main stream users, …), et un comparatif entre ces dernières.

Un grand merci aux sponsors de la journée, Sun (pour les locaux) et Valtech (pour le petit déjeuner et les pizzas à midi), ainsi qu’à Jean Yves Pronier (côté Sun pour les locaux), Eric Lefevre-Ardant (co-organisateur avec moi-même), Eric Le Merdy, Claude Falguière (soutiens) et Alexis Moussine-Pouchkine (qui nous a mis en contact avec Jean-Yves), ainsi qu’aux participants pour le bon déroulement de la journée.

D’autres retours:

• I.T. Aware (Sébastien Letélié): http://www.itaware.eu/2009/01/31/javacamp-iii-tdd-et-ddd/
• Tom’s Quest: http://www.tomsquest.com/blog/javacamp-3-compte-rendu/
• The Coder’s Breakfast: http://thecodersbreakfast.net/index.php?post/2009/02/01/Java-Barcamp-3-%3A-compte-rendu
• Photos d’Eric Lefevre: http://flickr.com/photos/elefevre/sets/72157613231545482/

La semaine dernière, avec Pascal, nous présentions une seconde fois l’after work GWT (voir le post précédent pour le 1er afterwork).

Si vous n’êtes pas très saumon fumé ni champagne, mais plutôt Eclipse et Widget, je vous propose de réveillonner avec notre présentation mise à jour, ainsi que les workspaces d’execices et de correction !

Ces workspaces sont utilisables sous windows (avec un JDK 5 minimum).

Pour n’avoir aucun problème, vous devrez installer gwt et gwtext C:\dev, selon l’arborescence suivante (des chemins en dur sont présents dans les .launch entre autres) :

C:\dev\gwt\gwt-windows-1.5.3

C:\dev\gwt\gwtext-2.0.5

Pour Linux et MacOsX, le mieux est de récupérer les projets et de corriger les chemins de lancement (.launch).

Le succès était encore une fois au rendez vous, je remercie encore l’organisation côté Valtech Technology Consulting et côté Valtech Training !

Joyeux Noël à tous !

AfterWork GWT : présentations et TP

Tout comme à la maison (d’après ma femme !), il est utile pour retrouver ces petits de faire un peu de rangement.
L’organisation du code source ne déroge pas à cette règle. Cela peut paraître simpliste, voir inutile de faire un papier sur ce sujet, mais l’expérience me prouve que ce sujet n’est pas toujours appliqué.

Le principe est simple :

• L’environnement de développement doit être identique à l’environnement de production.

J’entends par là que les sources, les fichiers de configuration, les scripts et tous autres artefacts qui servent à la mise en œuvre de l’application doivent être rangés dans des répertoires organisés de la même manière que ceux déployer pour exécution.
Ce principe de base d’organisation de la configuration logicielle simplifie le déploiement, les procédures d’installation en évitant les « pertes » de fichiers.

Autre avantage à cette organisation des sources et de limiter la divergence d’exécution entre la version lancée sous Eclipse et celle déployée. De permettre donc de traiter (identifier, voir reproduire) les bugs en environnement de dév, plutôt qu’en environnement d’intégration où il n’y a souvent pas de débugger.

Avec Eclipse, j’engage les développeurs à utiliser un projet par package fonctionnel mais aussi technique : 1 pour le client, 1 pour le serveur, 1 pour les tests, 1 pour les « commons ».
Cela garantie la séparation des couches et évite au développeur de tirer des classes serveurs directement dans le package client.
L’utilisation des Working Set Eclipse permet d’améliorer la vue lorsqu’il y a une multitude de projets.
Sans parler de standardisation (breeuuu…), l’organisation des sources pour le développement d’une appli web est souvent contrainte par l’organisation des conteneurs (webapps).
Répertoire WEB-INF, lib, js, conf, … Certains plugins Eclipse imposent même l’arborescence des sources.
Il est intéressant de s’inspirer de ces principes pour le développement d’application non web.