Soirée David Gageot
Mardi dernier le Paris JUG avait invité David Gageot, responsable technique d’Algodeal pour nous parler des tests. Soirée très intéressante et très pragmatique. Pourquoi accélérer les tests unitaires et donc le temps pour construire globalement son logiciel ? Il cite le cas d’une équipe qui avait un build de 12 heures. Petit à petit, ce nightly build n’était lancé que toutes les 30 heures… Un build quotidien qui dure plus de 30 heures… cherchez le problème.

Lorsqu’il devient héroïque ou compliqué de construire, déployer et tester votre logiciel, il y a un souci. Cela veut dire que vous acceptez d’attendre 2 ou 3 jours avant de savoir si votre dernière modification fonctionne. Ajoutez à cela le fait que vous êtes 6 ou 7 développeurs, et vous l’avez compris, nous sommes en plein Chaos. Imaginez un médecin qui vous donne un médicament et qui revient 30 heures plus tard pour vérifier si tout va bien…

David parle de « Continuous Testing« . Les tests doivent tourner presque en permanence. Pour cela il nous montre Infinitest. Ce plugin Eclipse permet de lancer les tests unitaires en tâche de fond dès lors que vous modifiez une classe. L’outil est assez intelligent pour n’exécuter que les tests en rapport avec la class Java sur laquelle vous travaillez. Il montre aussi MoreUnit qui est un plugin Eclipse pour faciliter la navigation entre les tests et le code.

Pour accélérer les tests David présente 3 stratégies :
– le tricheur
– le paresseux
– le brave

Le tricheur achètera une machine plus puissante. Il essayera de faire tourner plusieurs agents sur plusieurs machines, ou il essayera de ne pas faire tourner toute la compilation. Surefire 2.7.1 permet de faire tourner des tests unitaires dans plusieurs Threads. Avec Maven 3 il est possible de compiler son projet en parallèle lorsque vous avez plusieurs modules… Mais ces solutions ne s’attaquent pas au coeur du problème. Avec maven 3 vous pouvez par exemple lancer ceci :

mvn -T1 clean install --> 5mn
mvn -T4 clean install --> 3mn


Le paresseux va chercher le moindre effort. Il va par exemple effacer les tests unitaires qui ne servent à rien. Et c’est une très bonne chose. Il va aussi effacer le vieux code qui n’est plus utilisé. Vous pouvez aussi remplacer des tests d’intégration avec Oracle par des tests in-memory avec H2 ou HSQLDB. David cite Apache Comons VFS pour remplacer des tests avec accès réseaux par exemple.

Le brave enfin va vraiment s’attaquer à ce qui fait ralentir votre système. Premier conseil de David : ne testez pas les règles métiers de votre application via des tests d’intégration. Cela rajoute une couche d’infrastructure entre ce qui test et ce qui est testé. Ne prenez pas Selenium pour valider les règles métiers de votre application. Il est plus simple, plus rapide et plus efficace de prévoir des tests unitaires sur la partie purement métier. Le reste ne doit être que de l’infrastructure.

Pour optimiser son build, David recommande de s’attaquer aux 10 tests les plus lents dans votre compilation. Essayez de les repenser pour qu’ils ne testent que ce qui est indispensable. Utilisez aussi Mockito pour bouchonner les parties les plus lentes de l’application. Si vous faites un test d’intégration, vous n’avez pas forcément besoin d’une base de données en mémoire. Il suffit de moquer les DAO pour valider le métier. Pas l’accès à la base. C’est un travail qui demande de la pratique mais qui est très intéressant.

David termine en nous recommandant de garder une approche simple. Non Ajax n’est pas une bonne approche à systématiser. Le coût est-il supérieur au gain attendu ? Je partage son idée de KISS (Keep it simple and stupid) et sa démarche qui est de faire toujours simple et efficace. Le dernier billet du Touilleur Express sur la complexité a reçu 2200 visites en quelques semaines, ce qui est énorme.

Après le buffet offert par Objectif Informatique, David a présenté ses outils préféres comme InfinitTest, MoreUnit et des techniques avancées avec JUnit 4. J’ai découvert par exemple les annotations @Theory et @DataPoints ainsi que @Rule. Il parle aussi de FEST (Fluent Interface) qui permet de rendre plus clair l’écriture des tests unitaires. JUnit 4 propose Hamcrest qui est déjà très bien, mais FEST est l’outil favori de David.

Rendez-vous le 28 février pour l’anniversaire du Paris JUG
Les slides de présentation de David sont sur le site du Paris JUG à cette adresse si vous souhaitez les parcourir. Le prochain RDV du Paris JUG c’est le lundi 28 février à la Cité Internationale Universitaire. Pour l’occasion nous avons trouvé une grande salle de 500 places avec Antonio. Il y aura de part et d’autre de cette salle un espace pour les exposants, pour les partenaires du Paris JUG. Le thème de la soirée sera « Sifflet en travaillant » avec le témoignage de plusieurs développeurs sur leur métier. Comment pouvons-nous travailler et continuer à s’amuser ? A exercer notre métier avec passion ? Si vous souhaitez venir partager votre expérience vous pouvez proposer un sujet via la page « Call for Paper« . L’équipe délibère et rendra publique le programme mi-février.

En attendant, je vous souhaite une bonne année 2011 !

Autres articles
- Cédric Vidal a publié un résumé plus précis sur le blog de Proxiad.

Ruby on Rails

En première partie, Christian Blavier d’Octo nous a présenté le framework Ruby on Rails. Il a publié un billet sur le blog d’Octo intéressant : « Confession d’un Javaiste repenti« . Il commence très fort avec l’image d’un hamburger, où chaque tranche du hamburger est estampillée du nom d’une technologie Java. Spring, JSF, Richfaces, HTML, et souvent, un petit pattern maison, pour justifier notre boulot d’architecte. Un ange passe dans la salle, mais personne ne se lève et ne crie au scandale. Le slide suivant représente le même hamburger passablement moisi, avec la réalité de certains projets, qui pour faire du Web, n’arrivent pas à mettre en oeuvre ce socle correctement.
Lors d’une mission, il découvre Ruby On Rails. Ce framework Web qui fête ses 6 ans est basé sur le langage Ruby. Dans le statut même de RoR (Ruby on Rails) les fondateurs mettent en avant la joie de programmer comme l’un des facteurs clés du framework. La productivité et le support du Web aussi. Personnellement je retrouve les mêmes valeurs dans Play!

Christian présente l’architecture du framework, purement MVC. Du côté du modèle relationnel, le moteur ActiveRecord (j’aurai plutôt pensé au pattern de M.Fowler Active Record) offre à RoR un socle à la fois simple mais suffisamment puissant pour réaliser des sites Webs et des applications d’entreprise. N’en déplaise à certain.

Concernant Ruby, Christian nous montre quelques exemples qui me font penser à Groovy. Langage dynamique et faiblement typé, Ruby offre par exemple ce type de syntaxe pour la manipulation des dates :

	now = DateTime.now

	tomorrow = now + 1.day

	one_week_ago = 7.days.ago

Le support des closures fait bien entendu partie de Ruby :

Closure,
["one","two"].map{ |word| word.upcase }

RoR est un framework fait pour le Web. Votre classe de base étend une classe ApplicationController. Pour ceux qui ont suivi ensuite la présentation de Play! nous retrouvons la même approche. C’est l’approche « Skinny controller / fat model » ou l’approche Domain Driven Design.

Dans cet exemple, la méthode index charge l’ensemble des Books puis la place dans une variable @books, qui est retournée à la vue.

class BooksController < ApplicationController
 def index
  @books = Book.all
  end

Pour exemple, l'approche Play! Framework donnerait quelque chose comme cela:

public class Application extends Controller {
    public static void index() {
        List books=Book.findAll();
        render(books);
    }
}

Ruby on Rails utilise un moteur de templating pour ce qui est de la partie vue. Il dispose de plusieurs moteurs, comme par exemple Haml

#profile
  .left.column
    #date= print_date
    #address= current_user.address
  .right.column
    #email= current_user.email
    #bio= current_user.bio

Le moteur Haml vient en remplacement je crois du moteur de base de Rails, appelé ERB:

<div id="profile">
  <div class="left column">
    <div id="date"><%= print_date %></div>
    <div id="address"><%= current_user.address %></div>
  </div>
  <div class="right column">
    <div id="email"><%= current_user.email %></div>
    <div id="bio"><%= current_user.bio %></div>
  </div>
</div>>

haml utilise l’indentation comme Python pour séparer les blocs. Christian cite aussi le projet SASS qui a été porté sous la forme d’un module pour Play! Framework aussi. Si vos CSS sont un vrai millefeuille, regardez SASS. Ce moteur permet de définir des variables que vous utilisez souvent dans vos feuilles CSS.

Concernant l’architecture, RoR est au plus proche de l’architecture REST, avec des URLs signifiantes. Un fichier de route permet enfin de construire des URLs bookmarkables et propres… comme un autre framework dont on parlera plus tard

Concernant la partie ActiveRecord, rails comme grails dispose d’un ensemble de scripts très puissants pour générer rapidement des entités. Par exemple pour construire une entité Book avec quelques attributs :

 rails generate model book title:string description:string 

Pour terminer, il est important de noter que Rails est l’un des frameworks Webs les plus utilisés sur les projets Webs et les projets de startups. Avec des livres de références et les années d’expériences sur ce framework, c’est un moteur qui est souvent le point de départ de nombreuses aventures Webs. Lors du dernier Startup Weekend à Paris, les 3 premiers projets étaient basés sur Ruby on Rails. L’un des projets a utilisé Play! Framework, et il me semble que cela sera amené à se développer dans les mois qui viennent.

Bon, sinon le jour où vous passez au Paris JUG : ne faîtes pas de slides avec un fond noir, prenez le template du Paris JUG.

HTML 5

Alain Duval, directeur technique d’Objectif Informatique et Cédric Beurtheret, expert Java EE, présentent HTML 5. J’ai bien aimé cette présentation car elle nous fait prendre conscience des changements à venir dans la façon d’appréhender la réalisation d’une application Web. J’ai vraiment l’impression que le métier d’architecte web est une nouvelle compétence qui va exploser dans les années qui viennent.

HTML4 c’est 1998. Jusqu’en 2004 il ne se passait pas grand chose. HTML 5 est un effort tourné vers les nouvelles architectures avec un gros effort de standardisation. A priori la version finale est prévue pour dans 2 ans. Les problèmes de rétro-comptabilité et de support entre les navigateurs sont derrières nous. Les acteurs du marché travaillent ensemble pour proposer des standards. Cela dit, concernant par exemple l’initiative d’Apple sur le codec vidéo… je ne suis pas certain que cette belle lune de miel ne dure longtemps.

Des balises HTML seront progressivement retirées comme applet, frame ou font par exemple. J’ai retrouvé le lien cité par Alain pendant la présentation : HTML5_Visual-cheet-sheet.pdf. Le Doctype d’une page HTML 5 est ultra simple :

<!DOCTYPE html>

A titre d’exemple, le site de Zengularity est écrit en HTML 5 si vous voulez tester. C’est une plateforme de vidéos courtes sur le Web, le HTML 5, le framework Play!, réalisée par les équipes de Zenexity.

HTML 5 apporte des balises pour structurer la page. Il sera facile de définir par exemple une section header ou footer, sans devoir appliquer systématiquement un habillage avec des DIV comme aujourd’hui.

Concernant les Formulaires, nous notons l’apparition de nouveaux tags :

 <search>
 <tel>
 <url>
 <email>

Sur le site du W3C, vous pouvez trouver des articles complets et intéressants si vous souhaitez découvrir comment nous ferons des formulaires webs demain.

Prenez par exemple ce code source :

<form method="post"
      enctype="application/x-www-form-urlencoded"
      action="https://pizza.example.com/order.cgi">
 <p><label>Customer name: <input name="custname" required></label></p>
 <p><label>Telephone: <input type=tel name="custtel"></label></p>
 <p><label>E-mail address: <input type=email name="custemail"></label></p>
 <fieldset>
  <legend> Pizza Size </legend>
  <p><label> <input type=radio name=size value="small"> Small </label></p>
  <p><label> <input type=radio name=size value="medium"> Medium </label></p>
  <p><label> <input type=radio name=size value="large"> Large </label></p>
 </fieldset>
 <fieldset>
  <legend> Pizza Toppings </legend>
  <p><label> <input type=checkbox name="topping" value="bacon"> Bacon </label></p>
  <p><label> <input type=checkbox name="topping" value="cheese"> Extra Cheese </label></p>
  <p><label> <input type=checkbox name="topping" value="onion"> Onion </label></p>
  <p><label> <input type=checkbox name="topping" value="mushroom"> Mushroom </label></p>
 </fieldset>
 <p><label>Preferred delivery time: <input type=time min="11:00" max="21:00" step="900" name="delivery" required></label></p>
 <p><label>Delivery instructions: <textarea name="comments"></textarea></label></p>
 <p><button>Submit order</button><p>
</form>

Si vous avez un navigateur assez récent, voici ce que cela donne :

De nouveaux attributs comme PlaceHolder, AutoComplete ou Autofocus font aussi partie des balises HTML 5. Nous aurons donc de moins en moins besoin de javascript. Le support natif sera la garantie que le poids des pages va fortement baisser je pense.
Alain pense que la validation des formulaires sera effectuée plus facilement du côté du navigateur.

Le côté multimedia et les différentes démonstrations sur la balise Canvas sont très prometteurs. Le support du multimédia, de la vidéo, de la 2D et de la 3D, le support natif de SVG, tout ceci devrait remplacer le player Flash dans les années qui viennent. Encore faut-il que les industriels s’accordent sur les Codecs. Et là, c’est le foutoir. Donc Flash a encore de longues années devant lui je pense.

Pour terminer, Cédric nous montre une application HTML 5 avec géolocalisation, drag and drop, support du mode offline. HTML 5 introduit la notion de Web workers. Cette application de gestion de la relation client à usage des commerciaux tourne sur TabletPC. Lorsque le commercial n’est pas connecté à Internet, une partie de sa base client est téléchargée sur le navigateur afin qu’il puisse travailler en mode déconnecté. La synchronisation a été implémentée avec un Web Worker. C’est une APi qui permet de lancer des scripts Javscripts en tache de fond. Cédrid explique qu’il était parti sur Google Gears, mais que Google arrête le support de cette technologie pour plutôt privilégier le socle HTML 5.

Concernant la possibilité de stocker des données sur le poste client, HTML 5 propose 3 niveaux différents selon vos besoins :
-> SessionStorage volatile, durée de la session
-> LocalStorage persistant mais limité en taille
-> WebDatabase basé sur SQLLite ou IndexB

Cédric attire notre attention quant à la sécurité des données sur le navigateur client. A priori la base n’est pas sécurisée, il faut donc prévoir une solution de cryptage.

En conclusion, en 30 minutes ce fut une belle présentation sur HTML 5, avec des pointeurs sur ce qui sera forcément notre futur demain. En tant que développeur, je le dis et je le répète, il n’est plus possible de ne pas connaître le HTML, CSS et Javascript en 2010. La récréation est terminée, la vision du « web-designer » qui fait ma page est très franco-française. Nos amis américains se marrent bien lorsque je raconte cette histoire.

Bref si tu n’as pas codé une page HTML à 30 ans, tu as raté ta vie de développeur.

Zenexity et le projet Zengularity

Le buffet était offert par Zenexity. J’aimerai parler un peu du projet Zengularity. Allez voir sur le site les différentes vidéos. Le concept ? Vous présenter en quelques minutes un sujet technique. Les premières vidéos parlent de Scala, de Web Workers, d’architecture, de programmation fonctionnelle. Sympa comme initiative. A tester.

Présentation Play! Framework avec Guillaume Bort

La deuxième partie de la soirée était consacrée à une présentation de Play! Framework puis à une démonstration par Guillaume. Je mettrai les slides en ligne la semaine prochaine, je vais faire cette même présentation lundi 18 octobre à la conférence Soft-Shake à Genève. Si vous voulez voir ce qu’il est possible de faire en une heure, rendez-vous lundi matin à 11h30.

Les retours sur Twitter ce matin étaient positifs, j’espère qu’avec Guillaume nous vous avons passé notre passion pour ce framework. Je le dis et j’insiste : si vous voulez vous faire plaisir avec du Java, que vos problèmes soient pour du Web ou une application lourde, testez Play! Framework.

Adam Bien est consultant indépendant, Java Champion, auteur de plusieurs livres en anglais et en allemand sur Java. Il a carte blanche ce soir pour présenter Java EE 6 par la pratique. La présentation s’est découpée en 2 parties. Pendant la première heure, nous avons plus parlé conception et architecture. La deuxième heure fut une démonstration de programmation en direct. Les quelques 200 geeks présents ont bien apprécie et le message est passé.

Java EE 6 est plus simple, plus rapide, plus facile à apprendre et plus productif que Java EE 5. Si votre entreprise utilise encore Java J2EE 1.4, il est temps de regarder la dernière version. Dites bye-bye aux nombreux fichiers de configuration XML, le framework est vraiment bien pensé.

Avant que quelqu’un ne pose la question, il parle de Spring vs JEE 6. Spring offre plus de configurations, le framework est vraiment très configurable. Java EE 6 utilise plutôt des conventions afin de ne pas avoir à tout déclarer. Le conteneur EJB est vraiment petit. Moins d’1Mb. Il nous montrera par la suite que Glassfish v3 est vraiment véloce, dès lors qu’il s’agit de déployer une application.

Nous attaquons enfin le cœur du sujet, discussion qui va faire mal aux yeux pour certains architectes, pour mon plus grand plaisir. Adam Bien parle tout d’abord du pattern d’architecture « Boundary/Control/Entity » et de son application dans l’architecture des futures applications JEE 6. C’est un pattern similaire au pattern MVC, avec cependant une approche plus adaptée aux applications webs.

Il encourage une nouvelle approche basée sur la philosophie D.D.D (Domain Driven Design), où l’Entité n’est plus agnostique, où les Data Access Objects ne sont pas utiles. En clair : plus de DAO. Comme il va l’expliquer ensuite, vous avez beau mettre des couches et des couches, cela ne bloque pas pour autant l’évolution.

L’approche DDD (voir le compte-rendu de la formation de Zenika) met au premier plan le Domaine. Les Entités deviennent plus importantes que les Services. L’approche de ces dernières années, avec service/domain/dao est ce que l’on appelle l’approche orientée service. C’est une approche pratique pour les clients légers, pas forcément pour les applications webs. L’approche DDD fait que vos Entités portent des méthodes métiers. Le DAO de votre système est l’Entity Manager, qui se retrouve injecté dans votre Entity ou sinon simplement dans votre service.

Ce principe fait que les services, et les contrôleurs dans le Web, perdent la logique de l’application. L’architecture avec état permet alors d’adresser d’autres problèmes plus simplement qu’avec l’approche classique orientée service.

J’aime beaucoup ce concept. C’est l’approche de Play! Framework et je constate avec plaisir que c’est donc un mouvement qui peut aussi s’appliquer rapidement avec Java EE 6.

Les architectures classiques appelées « Service Driven Architecture » sont ce que nous faisons tous plus ou moins. Une couche de domaine, une couche DAO, une couche Service. Les Entities du domaine sont anémiques et ne sont que le reflet de la base de données. Les DAO ne servent souvent pas à grand chose. Les NamedQueries qu’ils portent pourraient être placées sur les Entités comme dans l’approche DDD. C’est une manière de programmer assez procédurale. Les Services sont les responsables de la logique de l’application. Cela marche bien si vous devez faire des Web Services et du SOAP, ou des architectures sans état. Mais cela vous demandera plus de code.

Adam parle ensuite des Interfaces et commence à nous montrer notre premier Bean Java EE 6 :

@Stateless
public class SimpleSample {
    public void doSomething() {

    }
}

Voilà c’est tout. Pas de XML de configuration et pas d’interface. Adam décourage l’usage des Interfaces si vous n’avez pas de réelles motivations architecturales. Les gens continuent à penser qu’il faut des interfaces pour que le code soit testable. C’est faux et cela fait 5 ans que l’on vous le dit. Allez lire cet article sur Mockito pour comprendre. Il est tout à fait possible de mocker des classes, c’est très simple. Donc définir une interface pour les tests : pas une bonne pratique. Par contre définir une interface pour structurer son application : oui si cela vous permet d’utiliser des choses comme le Strategic Pattern par exemple. Même pour les interceptors et les dynamiques proxies : Java EE 6 est capable de se baser sur les annotations et de gérer vos Beans très simplement.

Nous passons en revue les différents Beans de Java EE 6, les Entities, les Interceptors et même les Cron. Tout est relativement simple, et permettra d’écrire des applications rapides et puissantes. Investir en 2010 dans un livre sur Java EE 6 me semble une bonne idée pour les architectes et les développeurs. Vivement que nous puissions en faire dans nos projets. Cela fera des économies et redonnera du plaisir à utiliser Java EE en général.

En résumé pour cette première partie, Adam nous a montré qu’il est intéressant d’apprendre une nouvelle manière de construire une application d’entreprise, en se basant sur l’approche DDD plutôt que l’approche SOA. J’ai vraiment bien aimé cette partie, c’est une approche qui renforce la simplicité. Je pense qu’il va y avoir de longs articles pour montrer cette nouvelle approche. C’est très religieux, et proposer une nouvelle approche ne se fera pas sans grands débats enflammés, jusqu’à ce que tout le monde se rende compte qu’il avait raison.

A la pause, nous avons discuté autour du buffet. La remise en question de la tartine « domain/dao/service » ne va pas forcément convenir à tout le monde. Comme le dit Adam, ce n’est pas une mauvaise pratique. C’est une pratique qui n’est pas adaptée à tous les problèmes. Lorsque votre domaine est assez riche, il est plus facile de prendre l’approche DDD. Ce n’est pas plus compliqué, cela demande une petite remise en question de nos connaissances. Mais après tout, on apprend en permanence non ?

Après le buffet, nous avons eu une bonne heure de démonstration de Java EE 6. Avec des exemples de code, il a démontré qu’il était pratique et simple de travailler en 2010 avec Java EE 6 et Glassfish. Pour cela, il conseille d’utiliser NetBeans 6.9.

Pour terminer, je pense qu’il faut que je bosse sur un article afin de vous montrer les similarités d’approche entre Java EE 6 et Play! Framework. Si à terme un standard comme Java EE 6 me permet de coder de la même manière qu’avec Play! alors je serai le plus heureux des développeurs. Et même si j’adore Play!, je serai encore plus heureux d’utiliser un standard pour ma partie serveur, avec cette nouvelle approche plus simple.

Adam Bien sera ce vendredi dans le sud à la conférence SophiaConf 2010 organisée par l’équipe du Riviera JUG de Sophia-Antipolis. Ne manquez pas sa présentation !

Rendez-vous à la rentrée pour le Paris Java User Group, passez de bonnes vacances. Merci à José Paumard pour les excellentes photos.

Sadek Grobi a fait une présentation en codant en direct quelques concepts avec Scala. Son objectif est de nous parler de la programmation orientée fonctionnelle par l’exemple. Pour cela, il débute sa présentation en nous parlant des types. Un Int, une String, une List, sont des Types. Puis vient les fonctions, qui sont finalement des Types. Tout objet est fonction, toute fonction est un objet comme disait Alexandre Bertails dans un des commentaires du Touilleur Express.

Cette présentation orientée live coding a bien été résumé par Olivier Croisier sur The Coder’s Breakfast et par Ellene Dijoux sur le blog des JDuchess. Yannick Grenzinger d’Objet Direct (l’un des sponsors du Paris JUG) a fait un résumé sur le blog d’Objet Direct, ainsi que Claude Falguière sur le blog de Valtech. Bref vous trouverez certainement une couverture de la présentation plus complète qu’ici.

Après un buffet, primordial pour bien réussir une soirée du Paris JUG, nous avons repris par une présentation de Nicolas et de Romain de Xebia sur Scala à proprement parlé. C’était une très bonne présentation. J’espère qu’ils auront l’opportunité de la faire à d’autres conférences comme l’USI, comme d’autres JUG en province, car cette présentation est très sympa. L’objectif de la présentation est de parler de Scala par la pratique, pour le développeur Java.

Comme vous le savez peut-être, Scala a été lancé en 2003 (voir cet article sur l’histoire de Scala) par Martin Odersky, un enseignant chercheur de l’EPFL. Romain et Nicolas présentent les Traits, le pattern matching, les Actors et parlent aussi du framework Akka.

La 3ème mi-temps et la 4ème
Parlons un peu de ce qui se passe après une soirée du Paris JUG. Après la fermeture de la salle pour 22h30, tout le monde (plus de 200 personnes) se retrouve dehors. Les plus motivés (souvent 20 à 50 personnes) partent ensuite au restaurant pour diner. Les très motivés (votre serviteur) terminent tranquillement en sirotant une infusion en parlant de sujets très sérieux, vers les 2 heures du matin. Record : 4h du matin. Certains se lèvent quelques heures plus tard pour aller chez des clients, avec un cerveau aussi embrumé qu’un consultant devant sa console Websphere.

Ces moments de convivialités sont importants. Une soirée JUG c’est un moment de formation, de veille techno, la possibilité de venir apprendre quelque chose le temps d’une soirée. C’est aussi l’occasion de rencontrer des passionnés, des gens sympas et accessibles, prêt à refaire le monde, ou des gens qui vous parlerons pendant 2 heures d’IDEA IntelliJ vs Eclipse.

Je vois qu’il y a une multitude de Users Groups en France, sur les thèmes les plus divers et parfois les plus improbables. Si vous vous lancez dans la création d’un JUG, pensez au moment « coca/cacahuètes » qui est aussi important que le moment « slides/présentation ». Et ne sous-estimez pas les efforts et le temps que cela prend. Il y a 3 personnes derrière le Paris JUG (David, Antonio et Zouheir) et 5 autres personnes qui donnent un coup de main (Claude, Tanguy, José, Charles et moi-même).

Merci à APress pour les livres sur Scala et sur JEE6. Pour le livre « Beginning with Scala » de David Pollack, je vous le conseille les yeux fermés. 2 autres livres achetés auparavant ne m’ont pas donné de bonnes bases pour apprendre Scala. Pour le livre « Beginning Java EE 6 Platform with Glassfish 3 » écrit par Antonio Goncalves, j’avais écris une revue en octobre dernier.

Rendez-vous le mardi 11 mai pour une soirée sur Git, sur DVCS, sur Maven et sur DeployIt, ainsi que d’autres surprises.

Sur le thème des ChuckNorris facts, Emmanuel a envoyé à l’équipe du Paris JUG son propre pitch pour la soirée d’hier soir. S’en est suivi plusieurs Emmanuel’s facts sur la liste de diffusion du Paris JUG, ce qui était très sympa pour donner un style fun pour une très bonne soirée.

Encore 210 personnes ce soir, sans problèmes. Quelques nouveaux sponsors pour le Paris JUG, comme Ippon Technologies qui devient sponsor Gold par exemple. Le buffet de ce soir est offert par la société DRiMS. Ils ont organisé un tirage au sort entre les 2 présentations afin de faire gagner quelques cadeaux aux juggeurs, ainsi que leur aide pour le buffet. Drims intervient dans différents secteurs sur les pôles MOA, MOE et le décisionnel. Nous sommes toujours content d’avoir de l’aide ponctuellement pour les Buffets, ce qui permet de recevoir 200 personnes et d’animer la soirée.

JDuchess
La soirée débute avec l’arrivée sur scène des JDuchess France. A l’initiative de Mathilde Lemée (Indépendante/blog Java-Freelance.fr) et d’Ellène Dijoux (Xebia France) qui avaient rencontré lors de Devoxx 2009 les JDuchess hollandaises, elles se sont regroupées avec Laure Némée (Leetchi[Updated]) et Claude Falguière (Valtech).

L’objectif du groupe JDuchess France est de proposer un groupe de rencontre aux femmes dans la communauté Java. Mesdames, que vous soyez développeur, architecte, ou autre, vous pouvez venir aux soirées du Paris JUG et être assurée d’être accueillie par une communauté sympa. Mathilde explique que le groupe JDuchess compte 158 membres dans le monde. Pour rappel, il y a 15 user groups en France, plus de 440 dans le monde. Et l’initiative de proposer un site communautaire, et des événements pour les femmes est une très bonne idée.

L’équipe de JDuchess a organisé un Avant-JUG au restaurant le Vavin à 18h30 auxquelles 10 femmes ont participé. C’est aussi la possibilité de parler Java, de parler du métier entre elles, d’assurer une meilleure représentativité de Java auprès des femmes, qui motive le groupe.

Enfin c’est encore un succès pour la communauté et pour les Users Groups. Donc si vous êtes une femme intéressée par Java, et que vous êtes sur Paris, n’hésitez pas à vous inscrire sur le site communautaire de JDuchess. Il y a 8 membres pour l’instant, j’espère que cet article fera venir du monde dans le groupe.

Hibernate Search

Emmanuel Bernard prend ensuite la parole pour nous présenter Hibernate Search. Il travaille chez JBoss RedHat à Paris après un parcours aux USA pendant quelques temps. Emmanuel est un membre de l’équipe de développement d’Hibernate. Il intervient souvent dans différentes conférences, et nous sommes très content qu’il participe régulièrement au Paris JUG. Je pense qu’il a trouvé rapidement sa place depuis septembre dans la communauté parisienne. C’est aussi l’un des auteurs du Podcast sur Java « Les CastCodeurs« , donc le prochain sujet sera sur Oracle et SUN avec la participation d’Alexis Moussine-Pouchkine.

Emmanuel a présenté Hibernate Search ce soir. J’avais vu cette présentation à Jazoon, je vous invite à relire ce que j’écrivais à l’époque. J’ai revu et réécouté celle-ci avec plaisir, Emmanuel ayant ajouté quelques points intéressants.

Sur la présentation, je pense que la partie code a satisfait ceux qui regrettent parfois le niveau trop général des présentations du JUG. Ce soir nous avons vraiment mis le nez dans le moteur. Pendant une heure, tout le monde a découvert la notion de recherche, l’indexation, la construction et l’interrogation des indexes Lucene.

J’aurai aimé un peu plus tard entendre Emmanuel sur le positionnement d’Hibernate Search par rapport au Cloud et JPA. Sur Google App Engine pour mon projet-toujours-pas-terminé « Geek Date » j’avais utilisé Compass. Cela me permet d’indexer les événements à la création et de proposer une zone de recherche full-text multi-critère sur la page d’accueil.

Et le Buffet !
Une soirée JUG c’est 2 conférences et bien entendu, le Buffet. Au sondage pour l’anniversaire du Paris JUG, vous aviez été 70 personnes à répondre, et la place du buffet est très importante pour vous. Charles pourra vous détailler les chiffres, mais voici 2 indicateurs intéressants :

C’est un moment où chacun se rencontre, les discussions s’ouvrent, et où nous sommes content de nous voir.

Si je vous parle du buffet c’est pour vous faire passer une information. Ce soir encore, quelqu’un m’a dit qu’il cherchait un nouveau boulot. Fraichement arrivé à Paris, il lit régulièrement les différents blogs. Il m’a confié qu’il a envoyé son CV aux différents sponsors du Paris JUG car pour lui, ces boîtes représentent les entreprises où il souhaite travailler. C’est-ti pas beau comme histoire ?
Moi je dis +25 points de Bisounours pour le Paris JUG qui contribue à un meilleur monde.

Travailler sur l’écriture d’une API

Emmanuel Bernard présente ensuite un sujet intéressant, et pas forcément évident au premier abord : quelles sont les difficultés et les particularités à prendre en compte lorsque l’on écrit une API ?

Il nous fait partager son expérience tirée du travail en tant que Spec Lead sur la JSR-303 (Bean Validation) et de ses années sur Hibernate Search. L’objectif est de présenter la notion d’API, les difficultés rencontrées, et de nous faire partager son boulot. Ce fut très intéressant, pour une présentation qu’il donnait pour la première fois.

Ecrire une API est un travail de longue haleine. Il y a toujours des personnes mécontentes, et apporter un changement à posteriori est difficile. Lorsqu’il explique ceci, nous prenons tout de suite conscience qu’il s’agit d’un travail à part entière, bien distinct de l’écriture de sa bonne grosse appli de gestion (BGAG). La difficulté de figer à un instant T un ensemble de méthodes et d’objets force celui qui écrit à travailler 5 fois plus qu’un projet classique. C’est donc non pas le volume, mais la qualité du code que l’on recherche ici.

Emmanuel explique que le temps passé est important aussi car une API est destinée… à des êtres humains. Elle doit donc être orientée utilisabilité. Le développement TDD ne suffit pas à assurer une qualité et une cohérence. Il semble que l’itératif soit obligatoire pour réussir.

Ecrire une API vous force à monter en compétences. La notion de DSL apparaît rapidement dans la présentation d’Emmanuel. Il s’agit bien d’utiliser l’expressivité de Java pour décrire comment faire quelque chose. D’ailleurs, la gymnastique sur les Annotations dans Hibernate Search en a surpris plus d’un.

J’ai demandé à Emmanuel s’il avait regardé Scala plus tard dans la soirée. En effet, il parle à la fin de sa présentation de l’avantage des classes Abstraites par rapport aux interfaces. C’est justement la notion de Trait que l’on trouve dans Scala. Le temps de terminer mon deuxième article, vous verrez cela d’ici à la fin de cette semaine.

Pour revenir en arrière, écrire une API est un exercice sportif. Il parle de chuter plusieurs fois pour progresser, comme en Snow board. Il faut mettre en place une stratégie pour proposer à l’utilisateur de nouvelles fonctions, tout en gérant le cas où vous n’êtes pas certain de vous… ce qui arrive souvent. Il faut donc prévenir le développeur que vous êtes susceptible de modifier certaines fonctions.

En fait, c’est l’inverse du @deprecated utilisé pour indiquer qu’une méthode ne doit plus être utilisée dans votre code. Emmanuel tu devrais proposer une annotation comme @candidate, @proposed ou @ChuckNorris.

Crédit photo : Rolf Hiker

Emmanuel présente ensuite quelques exemples de patterns utilisés lors de l’écriture d’API. La partie sur l’utilisation des annotations a certainement comblé le geek le plus obscurantiste de la salle. Il a cependant évité l’effet jantes-alliages tuning avec « regardez mes belles annotations« . Les explications sur le changement des APIs de Mapping étaient vraiment intéressantes. On retient que l’écriture d’API reste un sport de haut niveau, où la maîtrise de Java est vraiment importante.

Emmanuel termine sa présentation en donnant quelques bonnes pratiques. Tout d’abord, si vous écrivez une API sur un projet, il est indispensable de la faire vivre sur des exemples d’intégration. Les tests unitaires ne suffisent pas.

Lors des choix des verbes et des noms de méthodes ou d’objets, travaillez à plusieurs sur vos choix de mots. Car une fois ceux-ci à l’intérieur de l’API, il est difficile de changer. Je pense que sans le savoir, Emmanuel parle de Domain Driven Design. Dans cette pratique, nous travaillons sur la définition de l’Ubiquitous Language. C’est un exercice qui permet de créer une langue commune entre les gens du métier et les développeurs. Dans le cadre du travail sur une API, il faudrait lister les verbes, les noms, dessiner une MindMap de ce que fait l’API. Cela permettrait de s’assurer que les mots sont correctement choisis.

Emmanuel encourage l’utilisation de DSL interne afin de rendre plus facile l’utilisation de l’API. A propos de DSL externe, le plus connu que vous avez tous utilisé sans le savoir est… le langage SQL. Il nous montre l’enchainement de verbes d’actions et d’adjectifs pour la définition de la configuration dans Hibernate Search. Je crois qu’il s’agit du pattern Builder si je ne dis pas de bêtises. Plus facile à mettre en oeuvre avec Groovy que Java.

Une astuce aussi pour l’API est de penser « comportement par défaut ». Ne demandez pas à vos utilisateurs de déclarer trop de paramètres qui ne changent pas ou peu. Il montre un exemple avec Hibernate Search où l’API s’arrange pour se configurer avec un comportement par défaut, afin d’alléger la quantité de code. Cela rend l’API plus Agile.

Conclusion et 3ème mi-temps
Emmanuel a bien animé la soirée. Les 2 sujets étaient intéressants. C’est un bon speaker qui fait passer son message, sans fioritures. Il a même répondu aux questions posés sur la Wave d’Olivier Croisier lorsque nous étions au restaurant. C’était vraiment sympa de sa part.

Si j’avais un truc à demander à Emmanuel, ce serait d’ajouter quelques images dans ses slides pour appuyer ses idées.

Documentez l’utilisation de votre API

Crédit photo : penguin http://www.flickr.com/photos/48600074504@N01/

Pensez au pattern Adaptor

Crédit photo : DeaPeaJay http://www.flickr.com/photos/deapeajay/2969264395/

Votre API doit être simple à utiliser

Crédit photo 1D110 http://www.flickr.com/photos/22297595@N02/

Note : les photos de cet article sont en licence Commons Creatives, trouvées sur FlickR.

La traditionnelle 3ème mi-temps cette année a demandé aussi une organisation particulière. Nous avons réussi à privatiser un restaurant, et nous avons mis en place un système afin de régler au plus tôt le restaurateur, ce qui nous permettra de recevoir tout le monde, et ce qui vous permettra de profiter de la soirée. Attention, le nombre de places est limité, que ce soit à la soirée elle-même, ou ensuite le buffet dinatoire.
Les inscriptions sont ouvertes depuis samedi 16h00, vous pouvez aussi nous suivre via le compte Twitter du parisjug.

Pour la première fois, il y aura aussi un espace pour quelques exposants. L’idée est aussi de vous proposer d’aller discuter et de rencontrer les geeks qui font les soirées du Paris JUG avec vous, et pourquoi pas, d’aller travailler avec eux. Il y aura aussi des concours et des lots à gagner, chacun de nos partenaires s’est investi pour que cela reste « geek » dans l’esprit du Paris JUG. Grâce à leur aide et à leur support financier au Paris JUG, cela permet de louer cette année une grande salle de plus de 500 places.

Rendez-vous mardi 9 février. S’il n’y a qu’une soirée à faire en février, c’est celle-ci.

Nous comptons sur vous pour en parler autour de vous cette semaine !

Pour en savoir plus :
Le programme détaillé de la soirée : http://www.parisjug.org/xwiki/bin/view/Meeting/20100209
L’inscription et le paiement pour le repas sont expliqués sur cette page.

Si vous souhaitez réutiliser des logos pour vos blogs, servez-vous :