Comment ça va se passer ?

• la session se passera à l’ISEP la 3ième ou 4ième semaine de février
• 5 mn par langage pour nous dire pourquoi vous l’aimez
• après ces présentations, les participants voteront pour sélectionner quelques ateliers
• les gens pourront participer aux ateliers pour des démos de code ou des discussions plus approfondies sur ces langages.

Quels langages ?

Tous ! Des langages utilisés, des langages nouveaux, des langages rares, des langages bizarres… Nous sommes prêts à partager tous vos coups de coeurs avec vous !

Comment participer ?

Si vous voulez présenter un langage, voici les règles à suivre :

• envoyer un email à duchessfr @ gmail.com avant le 31 janvier avec le titre “Battle Langage”et indiquez nous le langage de votre choix.
• vous pourrez faire votre présentation sans slides, ou avec quelques slides que vous nous transmettrez la veille de la session. Pas de troll, pas de longues explications sur toutes les caractéristiques du langage, choisissez uniquement les quelques points qui vous ont donné envie de découvrir ce langage et qui donneront à d’autres l’envie de vous rejoindre en atelier
• amenez votre machine et un environnement de développement prêt pour le langage que vous avez choisi. Attention ! La salle de l’ISEP n’a pas d’accès Internet public, préparer un peu de code si vous ne maîtrisez pas tous les recoins du langage.

A vous de jouer, nous attendons vos propositions de langages et pour les autres ne ratez pas cette occasion de découvrir de nouveaux langages avec ceux qui les pratiquent.

@sdouche

Pour cette première session “Autour de la marmite” de l’année, Sébastien Douche nous a fait le plaisir de venir nous faire une courte présentation sur les langages dynamiques et notamment sur un de leur élément de base : le typage.

En nous exposant rapidement les avantages et les inconvénients d’un typage fort tel que celui de Java ou d’Eiffel et ceux d’un typage faible à la Python ou Ruby, Sébastien nous a invité à réfléchir à notre rapport à la programmation, et en particulier à notre langage préféré, car tout développeur ou développeuse a une préférence marquée pour un langage en particulier.

Tous les participants ont donc pu poser les questions qu’ils souhaitaient voir débattre, ce qui a amené un premier groupe a discuter Python avec Sébastien, pendant qu’un autre groupe avait retenu les deux questions suivantes :

• On a toujours tendance à revenir à ce que l’on connaît. Quelles bonnes pratiques pour apprendre un nouveau langage de programmation ?
• Pour apprendre les bonnes pratiques de la programmation, vaut-il mieux un langage à type statique ou dynamique ?

Comme souvent dans les sessions OST, les discussions ont eu tendance à dévier, les deux questions ont été traitées dans le désordre le plus total, des gens sont partis d’un groupe pour aller dans l’autre, des groupes se sont formés et se sont défaits bref c’était le bazar et c’est tant mieux ! L’objectif de la soirée à ainsi été respecté : se faire plaisir en venant débattre avec des gens aussi passionnés que soi

1/ On a toujours tendance à revenir à ce que l’on connaît. Quelles bonnes pratiques pour apprendre un nouveau langage de programmation ?

Concernant cette question, trois solutions nous ont d’emblée été proposées :

• Faire de l’IRC : les gens qui adorent leur langage de prédilection aiment aider à favoriser son adoption par d’autres
• Lire le livre du concepteur du langage car c’est celui qui possède la philosophie du langage. Et comme le dit Sébastien, l’intérêt d’un langage est plus dans sa philosophie que dans sa syntaxe.
• Trouver un projet Open-Source auquel contribuer : et apprendre directement avec des passionnés, ce qui reste encore la meilleure façon d’apprendre à coder dans un langage, quel qu’il soit.

Pour autant, en cas de difficultés, la tentation est grande de ne pas continuer l’expérience et de retourner à son langage de prédilection ! Il ne faut donc pas négliger le ticket d’entrée dans l’apprentissage d’un langage : certains sont réputés plus difficiles que d’autres (Scala ou Clojure par exemple) et la motivation qui vous pousse à l’apprendre doit être proportionnelle, sans quoi le découragement fera vite son oeuvre.

L’écosystème est également un point important dans l’apprentissage d’un langage : on dit souvent que ce qui fait la richesse de Java c’est son écosystème … et de fait c’est incontestablement lui qui a le plus lourd. Mais on peut vite être découragé devant le nombre de frameworks ou de librairies qu’il va nous falloir connaître, sans parler de l’installation du poste de travail qui peut se révéler franchement laborieuse, longue et pénible pour peu qu’on soit sous Windows (troll inside )

C’est là que coder en groupe apparaît comme étant la solution idéale : comme on l’a déjà dit la transmission humaine reste ce qui est le plus simple, le plus enrichissant mais aussi sûrement le plus motivant. Et finalement même si on succombe sous les difficultés, ce n’est pas dramatique, il s’agit juste d’une expérience avortée qui nous aura néanmoins enrichi

2/ Quel langage de programmation pour apprendre à bien coder ?

Nous avons tous les capacités d’apprendre, pourtant, force est de constater que certains langages nous paraissent plus faciles à apprendre que d’autres.

Intuitivement, la plupart des participants sont tentés de répondre qu’un langage fortement typé est préférable pour commencer : un langage comme PHP dans ses premières versions avait la réputation d’un langage facile à apprendre pour des débutants en programmation mais qui allait totalement à l’encontre des bonnes pratiques avec sa permissivité à outrance.

La question de l’Objet se pose donc tout de suite après celle du typage : certes un langage Objet est naturellement plus contraignant, néanmoins ça n’empêche pas de coder n’importe comment ! Tout le monde a en tête des exemples de C++ ou de Java dont on espère sincèrement que l’auteur a changé de métier alors qu’à contrario on peut tout à fait faire du code propre et structuré en javascript.

Le typage et l’objet ne sont donc pas la réponse mais en font néanmoins partie : nous avons abordé la notion de ticket d’entrée dans la réponse à la première question et ce ticket repose sur notre aisance avec ses notions et avec d’autres, ce qui le rend intrinsèquement lié au développeur. Certains développeurs ne seront pas à l’aise avec la syntaxe de Kotlin et d’autres ne pourront jamais se résoudre à passer des fonctions en paramètres d’autres fonctions dans une forêt de parenthèses comme on peut le faire en Clojure …

Il n’y a donc pas de réponse “toute prête” à la question posée car il y a une grande part d’affectif dans notre adoption d’un langage : notre langage préféré ne sera peut être pas le plus populaire dans la communauté des développeurs, il a peut être des défauts, peut être même ne convient-il qu’à un usage particulier … mais c’est le nôtre. Et c’est rapport affectif qui va nous donner envie de progresser, et donc de bien coder. Alors n’hésitez pas, même si pour cela vous sortez des sentiers battus du monde professionnel, à cultiver cette affectivité pour progresser !

En France, seulement trois Code Retreat ont été organisés à l’occasion de cette journée:
- un à Paris dans les locaux de Xébia
- un à Bordeaux dans les locaux d’Arpinum
- et un à Toulouse dans les locaux de DocDoku

Connaissant déjà les Coding Dojo, j’étais curieuse d’en savoir plus sur les bienfaits d’un Code Retreat que l’on m’avait décrit comme une journée de code composée de 5 ou 6 itérations de 45 minutes ; chaque itération étant consacrée à coder le même problème dans le langage de son choix… et tout cela en prenant bien soin à la fin de chaque itération d’effacer le code écrit et de changer de binôme !
Et c’est surtout ce point qui m’intriguait : effacer et recommencer à coder….mais pourquoi ?

C’est donc, avec une certaine curiosité, que j’ai rejoint dès 8h30 du matin les 15 autres participants de ce premier Code Retreat toulousain. Là, j’ai pu constater qu’un des premiers mérites du Code Retreat avait été de regrouper des habitués de plusieurs User Group toulousains : Toulouse JUG ,  Apéro WEB , et les agilistes de la SigmaT

Après un café, Antoine, notre animateur du jour (“facilitator”) nous a présenté le déroulement de la journée, mais surtout le problème à coder qui n’était autre que le jeu de la vie (Game of Life). Le jeu de la vie est un  automate cellulaire imaginé par John Horton Conway en 1970. L’univers du jeu de la vie se déroule sur une grille à deux dimensions, théoriquement infinie. Chaque cellule a 2 états possibles vivante ou morte. À chaque étape, l’évolution d’une cellule est entièrement déterminée par l’état de ses voisines. Les règles suivantes nous ont été proposées :

• Si une cellule est vivante et a strictement moins de 2 voisines vivantes, elle mourra à l’étape suivante en raison d’une sous-population.
• Si une cellule est vivante et a strictement plus de 3 voisines vivantes, elle mourra à l’étape suivante en raison d’une sur-population.
• Si une cellule est vivante et a 2 ou 3 voisines vivantes, elle restera vivante à l’étape suivante.
• Si une cellule est morte et a exactement 3 voisines vivantes, elle naîtra et deviendra ainsi vivante à l’étape suivante.

Cette journée étant consacrée au code, il était donc fondamental de rappeler également les 4 règles élémentaires requises pour écrire du code de qualité :

• Faire passer les tests, autrement dit pratiquer du TDD (Test Driven Developpment)
• Eviter la duplication de code (principe DRY  :  Don’t Repeat Yourself )
• Faire en sorte que le code soit clair, expressif, autrement dit qu’il révèle l’intention (noms de variables, de méthodes explicites…y compris pour les tests)
• Ecrire du “petit code”, autrement dit minimiser la longueur des classes et des méthodes.

Un des principes du Code Retreat est que chaque participant vienne avec un ordinateur portable sur lequel il a installé au moins un environnement de développement de son choix (comprenant bien sûr une libraire de tests unitaires…).
Les itérations se déroulent ensuite en pair-programming (en binôme) où le ping pong est encouragé :

• un membre du binôme écrit un test unitaire,
• l’autre membre doit écrire le code métier qui fait passer ce test,
• puis avant de repasser le clavier à son collègue, il écrit un nouveau test unitaire, que son collègue doit faire passer,
• et ainsi de suite…

La présentation terminée, il était grand temps de découvrir les langages du jour. La plupart des participants étaient venus avec un environnement Java, mais il était également possible de développer en C++, Python, C#, Php et même Javascript.
Tout était dit. La première itération de code pouvait être lancée !
Les binômes se sont rapidement formés au hasard et le marathon des six itérations a pu commencer…

Première itération :  Installation & Compréhension du  problème…
Cette première itération sert en quelque sorte d’échauffement pour la suite de la journée.
Après l’installation des binômes et le lancement des environnements de développement vient le temps de la réflexion et de l’analyse du problème donné. On commence alors à s’approprier les règles du jeu de la vie, à griffonner un diagramme d’états, puis le code peut enfin s’exprimer. Dans cette première itération, nous avons choisi d’implémenter l’univers du jeu de la vie de manière très simple (tableaux à deux dimensions) afin de s’intéresser au plus vite aux règles métier. Aucune consigne n’avait été donnée pour cette itération, à part le respect du ping pong. Mais 45 minutes passent très vite (trop vite) et c’est vraiment lorsqu’on commence à être un peu  productif, à rentrer dans le vif du sujet, que l’on doit s’arrêter. Et oui, c’est déjà fini…  Au bout de ces premières 45 minutes, l’application est loin d’être terminée et le code écrit pas vraiment optimisé.
Je dirais que cette première itération sert de défrichage et permet de se mettre dans l’ambiance de la journée.
Chaque itération est ensuite suivie d’une rétrospective de 15 minutes animée par le “facilitator”.
A la fin de la rétrospective, Il faut respecter une des règles d’or du Code Retreat : effacer le code produit au cours de l’itération. Cela est un peu déroutant la première fois. Donc ce n’est pas sans quelques réticences que nous avons supprimé notre code, mais c’est la règle !

Deuxième itération :  Vers une conception Objet mieux pensée …
Chaque itération donne l’occasion de coder avec une nouvelle personne, les binômes devant être recomposés à chaque fois. Il est même possible de changer de langage d’une itération à l’autre …
Avant chaque itération, une nouvelle consigne est donnée par l’animateur afin d’encourager une création différente à chaque fois. La première rétrospective avait montré que la plupart des binômes était partie sur un tableau pour implémenter rapidement l’univers du jeu de la vie. Dans cette deuxième itération, la consigne donnée était donc de penser plus Objet en terme d’Univers et de Cellule…
Dès cette deuxième itération, j’ai pu constaté que l’écriture du code était beaucoup plus fluide, moins hésitante, plus rapide. Le code produit à l’itération précédente était naturellement repensé et optimisé pour la nouvelle itération. Le fait d’effacer le code permettrait-il alors vraiment d’écrire du code différent et plus performant d’itération en itération ?
La consigne étant l’Objet, notre binôme a cependant beaucoup discuté  lors de cette itération sur la manière de prendre en compte le caractère extensible du problème (cellules à n facettes, univers à n dimensions) pour finalement convenir avec l’animateur que nous resterons par la suite seulement dans un espace à deux dimensions. Avons-nous perdu notre temps ? Je ne pense pas car nous avons pu mener une réflexion commune. Et cela fait également partie de la magie du Code Retreat de pouvoir s’adapter immédiatement à son binôme, de pouvoir partager ses points de vue, ses bonnes pratiques de code et ses astuces de programmation.
A la fin de cette deuxième  rétrospective, il n’a pas fallu déroger à la règle de base du Code Retreat qui consiste à supprimer définitivement le code, et cette fois-ci c’est même avec un certain plaisir que chaque binôme a effacé son code !

Troisième itération :  No For, No if …
La consigne de la troisième itération était de n’écrire  ni boucle, ni test : “No for, No if” devait désormais être notre devise. Je n’avais jamais envisagé avant d’écrire un programme Java sans for, ni if (ni while, ni switch) et je dois dire que cette consigne nous a laissés perplexes pendant un certain temps : pas vraiment évident de respecter une telle consigne …
Certains binômes ont essayé de contourner la contrainte en dissimulant dans leurs instructions des tests via des opérateurs binaires et ternaire (&&, ||,?), d’autres ont évoqué le pattern Visiteur.
La notion de récursivité est également venue naturellement à l’esprit dès lors que les boucles n’étaient pas permises. Mais classiquement, qu’est-ce qui stoppe une récurrence ? Une condition d’arrêt que l’on écrit généralement avec un if !…Et hop, il est encore nécessaire de pousser la réflexion un peu plus loin. Ce test conditionnel peut alors être évité en faisant appel à des notions de polymorphisme. Vincent propose dans son retour un exemple de code pour illustrer cette solution.
Personnellement, c’est l’itération de la journée que j’ai préférée. Ecrire un code sans structure de contrôle est une contrainte qui ne me serait jamais venue à l’esprit…et pourtant au final, on constate que c’est un excellent exercice pédagogique !

A la fin de la troisième itération, il était déjà plus de midi : l’heure de la pause déjeuner.
Le repas fait intégralement partie du concept du Code Retreat : c’est un moment convivial d’échanges entre les participants. Il est donc  important de prendre une vraie pause repas d’environ une heure et demie. Le repas est généralement offert par le sponsor de l’événement. Merci DocDoku !

Quatrième itération :  Tell don’t ask, no primitive obsession …
La consigne de la quatrième itération était de respecter le principe Tell don’t ask. Ce principe de connaissance minimale consiste à demander directement à un objet ce qu’il doit faire, plutôt que de l’interroger sur son état interne afin de prendre des décisions qui mènent à des actions de sa part… Autrement dit, les getters/setters devaient cette fois-ci être bannis de notre code, et les méthodes judicieusement choisies et nommées en fonction de nos besoins.
Le principe Tell don’t ask imposé dans cette itération devait également nous amener à repenser notre code en évitant toute “primitive obsession” c’est-à-dire que nous devions éviter d’utiliser des types primitifs comme attributs (autant que possible).
Durant cette itération nous nous sommes donc plus particulièrement intéressés aux cellules, à leurs coordonnées, et à la notion de voisinage ? La Cellule doit-elle connaître ses coordonnées ?  La Cellule doit-elle connaître ses voisins ? Ne serait-il pas plus judicieux que l’Univers gère lui-même la notion de voisinage ? etc …
De nombreuses questions qui  devaient nous amener à écrire un nouveau code “tout objet”, vraiment très différent de celui de la première itération.

Cinquième itération :  Itération sans parole …
La cinquième itération fut une itération qui se déroula sans bruit, puisque la consigne consistait à interdire aux membres d’un même binôme de parler entre eux. Seuls les tests, écrits de manière expressive, devaient permettre de révéler les intentions de l’un et de l’autre. Sans discussion préalable possible, cette itération, bien plus que les précédentes, demandait de porter une attention particulière à l’expressivité du code  pour que chacun puisse comprendre l’attente de l’autre. Il fut  indispensable de  nommer les méthodes de manière très significative, ce qui nous amena bien souvent à écrire de véritables phrases pour nommer les méthodes des classes de test .
Cette itération fut une itération assez difficile à mener. En effet, arrivés à la cinquième itération de la journée, chacun a avancé dans sa vision du problème en menant au cours de la journée ses propres réflexions avec des binômes différents. Et bien que les contraintes de chaque itération soient communes, les choix de conception et d’implémentation sont parfois bien différents. Ce fut le cas pour cette itération où avec mon binôme nous avions deux approches différentes, ce qui compliqua la tâche mais nous incita doublement à écrire des tests expressifs afin d’essayer de trouver une solution commune.

Sixième itération :  A La Carte …
La sixième et dernière itération était une itération “à la carte” destinée à se faire plaisir où chaque binôme pouvait choisir une consigne parmi les propositions suivantes :

1. Désaccord  ou  écrire du code pour aller dans le sens inverse du test à vérifier…
2. Pire code possible
3. Sans la Souris … pour les spécialistes des raccourcis claviers (1)…
4. Des méthodes de 3 lignes maximum.

(1) Une discussion a depuis été lancée sur la mailing list du Toulouse JUG !

Rétrospective finale
Lors de la rétrospective finale chaque participant a dû répondre aux 3 questions suivantes :

1. Qu’est-ce que j’ai appris aujourd’hui ?
2. Qu’est-ce qui m’a surpris aujourd’hui ?
3. Qu’est-ce que je vais mettre en application dès Lundi ?

Les expériences des participants étaient diverses, mais chacun s’est accordé pour dire :

• que la journée avait été très riche en échanges et en partage de bonnes pratiques,
• que les six itérations avaient chacune conduite à la production d’un code bien différent,
• et que dès lundi les tests bien écrits allaient être (re)mis à l’honneur dans les équipes de développement !

La journée s’est terminée par l’annonce de la création d’une communauté Software Craftsmanship sur Toulouse qui, espérons-le, proposera très prochainement d’autres Code Retreat !

Liens :
http://globalday.coderetreat.org/
http://jduchess.org/duchess-france/blog/resolutions-2011-coding-dojo-code-retreat/
http://coderetreat.com/gol.html
http://c2.com/cgi/wiki?XpSimplicityRules
http://coderetreat.org/facilitating/structure-of-a-coderetreat
http://coderetreat.ning.com/profiles/blogs/how-a-coderetreat-works
http://pragprog.com/articles/tell-dont-ask
https://groups.google.com/forum/#!topic/toulouse-jug/SpOWtYPxJa0
http://antoine.vernois.net/dotclear/index.php?post/2012/01/09/Software-Craftsmanship-%C3%A0-Toulouse

Autres retours sur le Global Day of Code Retreat :
http://blog.genigraph.fr/2012/01/03/code-retreat-de-toulouse-le-03-decembre-2011/
http://blog.r0ly.fr/?p=67

Des Photos du Code Retreat toulousain
https://plus.google.com/photos/116856815308605996307/albums/5682276859165947169

Agnès & Alexis: Peux-tu te présenter? Quel est ton parcours professionnel et quelles sont tes activités aujourd’hui au sein de ForgeRock?

Ludovic: Bonjour, je m’appelle Ludovic Poitou et je suis chef de produit chez ForgeRock. J’ai une formation universitaire : un Magistère en Informatique et Sciences de l’Ingénieur, obtenu à l’Université de Nice Sophia Antipolis (formation qui existe encore sous l’enseigne Polytech Sophia-Antipolis après s’être appelée ESSI). J’ai commencé ma carrière dans une startup dans le domaine des serveurs de messagerie et d’annuaires, E3X, rachetée par TéléSystèmes puis Sema (maintenant Atos). En 1995, j’ai été embauché comme développeur logiciel chez Sun au centre Recherche et Développement de Grenoble, où j’ai principalement travaillé sur les serveurs d’annuaire LDAP, aussi bien au niveau produit (Sun Directory Server) que standardisation à l’IETF, ou sur l’évangélisation de projets open sources comme OpenDS.
Après 15 ans, et suite au rachat par Oracle, j’ai rejoint ForgeRock en tant que chef de produit pour les produits d’annuaire et le projet OpenDJ, et directeur du centre recherche et développement en France, basé à Grenoble.

Agnès & Alexis: Tu vas aborder la problématique des performances en Java dans ta session pour le LyonJUG. Question simple pour commencer : imaginons que je me rende compte un matin que mon application que j’ai mise en production la semaine dernière s’exécute de plus en plus lentement sur son serveur Tomcat. Quels sont les outils que tu utilises pour mesurer les performances d’une application Java en production, et quels sont les métriques sur lesquels tu vas particulièrement te concentrer ? Au niveau de la JVM, Quels sont les règlages à faire en priorité dans ma JVM ?

Ludovic: Tout d’abord, je vais parler de performances du serveur en Java, et pas des applications qui tournent dans un serveur d’application, tel que Tomcat. Mon expérience s’appuie sur le projet OpenDJ, qui est un serveur d’annuaire LDAP écrit en Java. Dans notre cas d’utilisation, nous avons deux critères principaux : le nombre d’opérations exécutées par secondes, et le temps de réponse. Pour mesurer cela, nous avons nos propres outils de charge LDAP qui produisent des statistiques en temps réel, mais aussi les statistiques du serveur lui-même.
Et dès qu’il s’agit de commencer à regarder comment se comporte la JVM, nous utilisons les outils standards Java, en priorité le log du Garbage Collector, et JConsole.
Donc, au niveau de la JVM, les premiers réglages sont définir la taille minimum et maximum de la JVM et activer le log du GC.

Agnès & Alexis: Le garbage collector G1 est apparu assez récemment. Est-il vraiment mature, début 2012 ? Est-ce qu’il doit devenir le GC par défaut, remplaçant tous les autres ? En particulier, le CMS a-t-il encore un raison d’être ?

Ludovic: Lorsque je travaillais encore chez Sun (avant Septembre 2010), nous étions en relation régulière avec l’équipe HotSpot et plus particulièrement Tony Printezis qui développait G1. Notre serveur d’annuaire avait été intégré dans une suite de tests automatiques de toutes les JVMs, et a énormément servi pour stresser G1, principalement avec des JVM de 16 à 64 GB. Nous avions d’ailleurs des versions de développement de la JVM pour nos propres tests, qui se révélaient prometteurs. Mais avec le rachat par Oracle et la réorganisation qui s’en ait suivi, j’ai l’impression que G1 a été mis de coté temporairement. Les quelques tests que nous avons fait avec les dernières mises à jour de Java 6 et avec Java 7 à sa sortie n’ont pas été probants.
Par contre, nous avons vu une flopée de correctifs sur G1 apportés dans Java 7 update 2 et nous sommes encore en train de faire des tests pour voir si G1 peut être utilisé en production.
Pour résumer, mature, probablement pas encore. Et donc CMS a encore des raisons d’être.

Agnès & Alexis: Que penses-tu de la suppression annoncée du Perm Space (inspirée de JRockit et de la JVM d’IBM) dans les releases à venir de la JVM V7? Pourquoi était-il utile par le passé et plus maintenant ?

Ludovic: Le PermGen Space est un espace mémoire de la JVM qui sert/servait à stocker les méta-données concernant les classes utilisateurs. Sa taille est devenu un problème récurrent avec tous les serveurs d’application qui chargent et déchargent les classes des applications. Personnellement, avec OpenDJ, nous ne nous en sommes jamais vraiment préoccupés.
Ces méta-données sont toujours nécessaires, et donc elles ont été déplacées de la pile Java à la pile native. Cela permet de simplifier la tache du GC, mais va obliger les administrateurs à surveiller la taille du process natif pour éviter que la JVM swappe.

Agnès & Alexis: Récemment au lyonJUG nous avons proposé une session “Architecture stateful vs stateless”. En terme de performances, penses-tu qu’une architecture stateless soit réellement plus scalable qu’une architecture stateful (notamment parce qu’on s’évite le problème de synchronisation de sessions entre plusieurs serveurs)?

Ludovic: J’avoue ne pas avoir vraiment d’opinion sur le sujet, ni de réelle expérience. Le protocole LDAP est un protocole connecté et qui garde l’état d’authentification. Donc nous sommes obligatoirement amenés à travailler en stateful.

Agnès & Alexis: Le “scale-out” est-il plus efficace que le “scale-in” pour une application Java ?

Ludovic: Cela dépend vraiment de l’application et de son modèle.
Si on regarde les serveurs d’annuaires, ils sont construits autour d’une base de données spécialisée (un B-Tree) et donc sont plus orientés scale-up. Mais depuis longtemps, le scale-out est disponible pour les opérations de lecture grâce a la réplication des données, souvent une fonctionnalité intrinsèque au produit.
OpenDJ est donc dans un modèle scale-up, avec une réplication multi-maître pour la disponibilité.
Sun Directory Server, le serveur sur lequel je travaillais avant OpenDS et OpenDJ, est déployé chez quasiment tous les opérateurs télécom avec plusieurs dizaines de millions d’utilisateurs, le plus gros ayant 120 Millions d’entrées dans leur service d’annuaire. Nous avions fait un “Proof of Concept” de scale-out pour un client qui voulait un annuaire avec 420 Millions d’entrées, en distribuant les données sur plusieurs serveurs d’annuaires et une couche de proxy LDAP pour faire le routage. Les résultats étaient impressionants en terme de performance, mais le coût hardware de la solution rédhibitoire !

Agnès & Alexis: Tu vas nous parler d’OpenDJ . Peux-tu présenter brièvement cette solution? Comment se démarque-t-elle d’autres solutions comme Apache Directory ou OpenLDAP. Ayant démarré comme un fork d’OpenDS, comment les deux solutions évoluent-elles en parallèle aujourd’hui?

Ludovic: OpenDJ est un serveur d’annuaire LDAP écrit en Java, qui est très complet fonctionnellement, offre de très bonne performances, mais surtout est simple à déployer et administrer. Au départ, il a été conçu chez Sun Microsystems pour remplacer le produit Sun Directory Server, écrit en C (hérité de Netscape Directory Server), mais qui avait une conception datant de plus de 15 ans.
Par rapport à Apache Directory, OpenDJ est vraiment orienté entreprises, avec un aspect qualité et fiabilité mais surtout conçu pour de gros volumes avec des besoins de performance.
Par rapport à OpenLDAP, OpenDJ apporte de la simplicité, la portabilité grâce à Java (le serveur et ses données sont indépendants du matériel et de l’OS). Et une compatibilité ascendante, surtout au niveau réplication, ce qui permet de faire évoluer les serveurs sans interruption de service.
Pour ce qui est d’OpenDS, les équipes qui travaillaient dessus chez Oracle ont été redéployées, et le projet n’évolue plus. Oracle a sa propre fork propriétaire et a annoncé un produit basé sur OpenDS : Oracle Unified Directory. Ce qui en fait le 4eme produit d’annuaire chez Oracle, et je doute de leur stratégie a ce sujet.
De notre coté, le développement d’OpenDJ continue en open source, et une grande partie de la communauté d’OpenDS nous a rejoint. Nous avons d’ailleurs eu plus de contributions en 2011 que pendant les 4 ans de développement d’OpenDS.

Agnès & Alexis: Vous avez pris le parti de sortir fréquemment des releases OpenDJ. Quel est votre processus d’intégration et de livraison (outils, méthodes)?

Ludovic: Depuis le début d’OpenDS, notre usine logicielle s’appuie sur Ant. Nous utilisons Jenkins CI pour l’intégration continue et les tests automatiques. Nous avons près de 30000 tests unitaires, écrits avec TestNG, qui sont lancés à chaque build et encore quelques milliers de plus la nuit. Nous avons toute une suite de tests fonctionnels (environ 2800 tests) qui sont exécutés aussi toutes les nuits dans un framework basé sur Stax.
Le cycle de livraison est celui que nous utilisions chez Sun. Préparation du build et vérification par les suites de tests automatiques, puis suit une phase de tests par l’équipe de QA pour couvrir certains aspects comme le GUI, les tests de conformité LDAP, de stress…
Enfin, la mise en place sur le site web est manuelle. OpenDJ est disponible sur forme de Zip, de package SVR4 (pour Solaris) mais aussi avec un installeur en Java Web Start. Et avec la prochaine version, nous devrions rajouter les packages RPM et Debian.
Nous travaillons aussi à mettre notre processus de livraison sur Maven, afin de faciliter l’intégration avec les autres projets de ForgeRock ou d’ailleurs. Le Toolkit LDAP qui inclut une librairie LDAP cliente et des outils de tests est déjà entièrement sous Maven.

Merci Ludovic!

Les inscriptions pour la session de Ludovic au Lyon JUG le 17 janvier sont ouvertes !

L’avant Jug c’est quoi ?
Pas de sujet imposé, c’est l’occasion pour nous de se retrouver tous les mois juste pour discuter. Ca nous permet de revoir les copines Jduchess, les anciens collègues et de faire connaissance avec d’autres développeurs.

Où ? Quand ?
Rdv mardi 10 janvier au Café Vavin (18, Rue Vavin, 75006 Paris) entre 18h30 et 19h15. Oui, c’est tôt mais ce n’est qu’une fois par mois   Pour nous retrouver dans le Vavin n’hésitez pas demander où sont les Jduchess aux serveurs.

Attention !
Pour des questions d’organisation au Vavin, prévenez nous de votre venue par mail à duchessfr(at)gmail(dot)com au plus tard le mardi matin. Cela nous permettra de réserver des places dans la salle du JUG et ainsi de passer un bon moment en toute sérénité

J’avais prévenu tout le monde pour ma première, mari et collègues : ce soir, c’est soirée entre filles. On code.

Je ne vous raconte pas la surprise en trouvant au 8ème étage des locaux de So@t, une salle remplie de garçons : “- Euh, les Duchess, c’est bien là ?”

Oui, c’était bien là. 23 garçons et 4 filles – quand même – tous réunis pour découvrir Apache Mahout (dire maoute), une librairie Open Source Java. Parce que les soirées code des Duchess sont ouvertes à tout le monde et c’est tant mieux.

Donc je m’installe au premier rang, pour prendre une des dernières places restantes et refais avec celui qui sera mon binôme de la soirée l’inventaire des tâches préparatoires (Inquiétude soudaine, n’ai-je rien oublié ? Il faut dire que je suis un peu venue les mains dans les poches, sans même préparer le sujet !) :

• installer Play! Framework
• télécharger Git.

Ouf, c’était bon, très facile d’ailleurs.

La soirée commence. Le principe : une présentation avant de passer au concret avec un petit exercice de codage à réaliser.

Michaël Figuière et Jean-Baptiste Lemée nous font découvrir la librairie Apache Mahout.

Quelle chance ! Je suis tombée sur un sujet passionnant : le Machine Learning. Pour rappel, ce sous-domaine de l’ Intelligence Artificielle, étudie les machines capables “d’apprendre”, c’est-à-dire qui adaptent leur comportement en fonction des données reçues.

La librairie Apache Mahout est donc un ensemble d’implémentations d’algorithmes permettant de rajouter des fonctionnalités intelligentes aux applications à partir des données issues du comportement des utilisateurs.

On rencontre déjà sur le web des applications utilisant des algorithmes de Machine Learning :

• sur Amazon, les recommandations des articles achetés par d’autres utilisateurs “similaires” (par un algorithme de Recommandation),
• les filtres de mails capables d’identifier les spams en entrée grâce à une classification déjà existante (algorithme de classification automatique des documents),
• ou encore Google News regroupant les news similaires et attribution de tags (algorithme de Clustering).

Le machine Learning est un bon complément aux moteurs de Recherche puisqu’il peut être utilisé pour améliorer l’affichage des résultats d’une recherche utilisateur. (Tiens ça, j’ai déjà entendu parler dans un sujet connexe, le Web Sémantique, par Nuxeo. Cette fonctionnalité de filtre de recherche est en effet intéressante pour un ECM (Enterprise Content Management).)

Bref, Apache Mahout, propose justement de mettre en oeuvre ce type de fonctionnalités et ce de manière très aisée.

Alors, c’est parti pour la pratique!

Nous devons réaliser un moteur de recherche de recettes de cuisine. Plus précisément, l’application propose des recettes de cuisine proches des goûts de l’utilisateur, si, si, ça marche !

En quelques lignes de code (5 précisément), et un ajustement empirique du paramétrage, j’obtiens sur mon écran une suggestion de recettes (éclair au chocolat, fondant au chocolat, salade au fenouil…) rentrées dans la base par mon voisin (lui aussi aime le chocolat). Tout cela après avoir défini les recettes que j’aime…dont quelques unes à base de chocolat.

Alors, comment fonctionne le moteur de recommandations ?

1) Vous spécifiez le datamodel (l’ensemble des données à prendre en compte en entrée) :

DataModel dataModel =

2) vous définissez le type de “similarité” :

UserSimilarity userSimilarity =

3) vous calculez le “voisinage”, un ensemble d’utilisateurs proches selon la règle de similarité définie au point 2 :

UserNeighborhood userNeighborhood =

4) Votre moteur est prêt, vous pouvez l’utiliser pour récupérer des items à recommander à l’utilisateur.

Ici, c’est l’algorithme de Recommandation “User-based” qui a été mis en oeuvre. Au lieu du critère des utilisateurs similaires, il est possible de retrouver les items qui ont des points en commun : c’est l’algo Item-based. L’application ayant reconnu que j’avais des points communs avec mon binôme m’a proposé ses items. Tout un programme !

Bien sûr, agilité et bonnes pratiques obligent, nous avons réalisé la fonctionnalité après avoir fait fonctionner le test unitaire !

Vous voyez, c’était vraiment très simple et rapide, même en comptant les pauses pour déguster les sushis. (et boissons de toutes sortes, de quoi sustenter tous les amateurs de marmite à volonté. Bravo pour l’organisation. ) Bon, je ne vous cache pas, la méthode de choix des implémentations restait pifométrique à ce stade :  LogLikelihoodSimilarity et pourquoi pas TanimotoCoefficientSimilarity ? NearestNUserNeighborhood plutôt que ThresholdUserNeighborhood, etc… On peut encore s’améliorer.

Quelle soirée sympa et intéressante.

J’ai hâte d’être à la prochaine marmite avec les Duchess. Hé les filles, vous venez la prochaine fois ?

http://mahout.apache.org/

Qu’est-ce-que Agile Open ?

Agile Open est un cycle de conférences au format Format Ouvert. Il est organisé par des agilistes un peu partout dans le monde. Vous avez peut être vu l’article de Linda Van Der Pal à ce sujet sur le blog World Wide Duchess. Le concept est tout simple : des participants auto-organisés proposent des sujets en rapport avec le développement logiciel et les méthodes agiles. Vous voulez partager des pratiques, idées, codes, expériences sur le sujet ? Cette conférence est faite pour vous !

Agile Open France 2012

Agile Open France est organisé toutes les années depuis 2008 en Alsace. Pour suivre l’actualité de cette conférence, vous pouvez suivre leur blog : http://blog.agileopenfrance.com/

Dans un cadre magnifique et avec un format participatif, cet évènement rencontre chaque année beaucoup de succès. Mais les conférences se suivent d’année en année mais ne se ressemble pas ! Car les sujets sont faits par et pour vous.

Informations pratiques

• Où ? En Alsace à Itterswiller.
• Quand ? Le 18-19-20 Janvier 2012.
• Combien ? 360 euros pour toute inscription jusqu’au 25 décembre 2011.
• Comment ? Tout est expliqué ici .

Attention les places sont limitées alors inscrivez-vous vite !

Lyon JUG Team : Peux tu nous dire en quelques mots quel a été ton parcours avant Exo et quelle est ta mission aujourd’hui chez eux? As-tu commencé ta carrière par le coté Dev ou Ops?

Henri : J’ai commencé ma carrière comme développeur sous Mac, C et 68000, pour une société qui faisait un logiciel pour salle de marchés.
Environnement donc temps réel mais aussi interface graphique sous Mac OS 5/6/7 (et oui ça date)… Puis nous sommes passés à proposer des services de fournitures de cotations temps réelles pour des compagnies de gestion de portefeuilles. Là, découverte des environnements Unix et notamment Linux dans ses toutes premières versions 0.99999. Surtout premiers contacts avec le monde OpenSource, Linux certes mais surtout Gnu. Dans cette petite société, j’avais une activité qui couvrait développement (la nuit), support client et production (le jour). Donc une approche de développement très teintée des besoins de productions (en plus des attentes clients).
Après quelques rachats, me voici à m’occuper de développement en Powerbuilder (no comment) mais surtout mise en place de stations Sparc sous Redhat Linux. Deuxième contact avec l’OpenSource, Apache HTTPd serveur et découverte du système de packaging RPM. Voici une solution qui permet d’installer et supprimer des applications mais gère en plus très finement les dépendances.
Nouvelle aventure professionnelle dans la patrie des Gones cette fois-ci, dans une maison traditionnellement AS400. Cela correspond au démarrage de Java (1998) et va suivre une longue période de prosélytisme et lobbying pour pousser des technologies OpenSource et Java. Tout d’abord Chef de Projet sur les projets Nouvelles Technologies (Java l’était à l’époque), avec encadrement d’une bande de jeunes loustics et quelques projets majeurs autour de Java. En parallèle, je découvre Apache JServ puis Tomcat, et devient commiter sur Tomcat et le connecteur mod_jk, puis membre de l’Apache Software Fondation.
Mais je n’oublie pas mes premières amours sur le packaging et le déploiement et lance le projet JPackage dont le but était d’apporter à l’écosystème Java ce qui existait en Perl via CPAN. Le bébé a bien grandi par la suite puisqu’on le retrouve maintenant dans des distributions comme CentOS, RHEL, Suse ou Amazon (AWS).
Après quelques années comme Chef de Projet, je deviens Architecte, où j’assure la veille technologique autour de Java et OSS, développe des protos et assiste les chefs de projets et équipes de développements. Une fois le passage de Ant à Maven finalisé pour l’ensemble des projets, j’en ai profité pour monter une usine logicielle basée sur Subversion, Nexus, Hudson et Sonar.

Lyon JUG Team : Aujourd’hui : fais-tu plutôt du Dev ou de l’Ops (Exo/hors Exo) ? Et est-ce temporaire ou cela peut changer du jour au lendemain?

Henri : Chez eXo, j’ai commencé avec 2 casquettes, Ops et QATech et j’ai donc monté une usine de QA, permettant d’automatiser les tests de performances et fonctionnels, taches autrefois faites manuellement et en journée.
Actuellement je ne fais quasiment que de l’Ops, administration des infrastructures dédiées et Cloud (Amazon). J’ai aussi une mission de conseil sur nos produits pour traduire aux équipes de développement les attentes d’équipes de production (interne ou externes).

Lyon JUG Team : Aujourd’hui : Suite à ton expérience, quelles sont les trucs en terme d’organisation d’équipe, de répartions des tâches et des rôles qui vont faciliter le fait que les Ops bossent réellement et “main dans la main” avec les équipes de dev (Casser les équipes? Travailler en peer-mode? Préférer travailler en itératif / mode agile etc.? Assigner des tâches purement de prod à des devs? L’inverse peut-être également?) En synthèse : Comment intéresser réellement les uns aux sujets des autres?

Henri : Le premier pré-requis, c’est de sortir des guerres de clocher. Qu’on soit Ops, Devs ou QA, on travaille tous ensemble pour des clients, qui s’attendent à un résultat. S’il y a incident, que la faute soit à un Dev, un QA ou un Ops, leur importera peu. En finir donc une bonne fois pour toute avec la patate chaude.
Il n’y a pas solution unique, mais casser les équipes et mélanger Ops/QA/Devs n’est pas forcément facile à réaliser en terme d’organisation interne. Ce que j’ai expérimenté et qui marche bien, est un travail en peering, Ops/Devs (voir QA) qui permet à chacun d’apprendre l’environnement de l’autre, notamment les contraintes.
Au risque de sortir une évidence, le message fort dans DevOps, c’est DIALOGUE. On verra lors de la présentation comment on peut utiliser de l’outillage plutôt Devs pour des Ops et des QA, de façon à ce que l’information soit disponible à tous et de la même manière.

Lyon JUG Team : Sur le mouvement Devops : Quand as-tu entendu parlé du mouvement pour la première fois? Qu’est ce représente ce mouvement pour toi aujourd’hui? Comment y participes-tu? DevOps faisait partie des sujets tendance à Devoxx 2010 et absent à Devoxx 2011. Est-ce déjà passé de mode ?

Henri : J’en ai entendu parlé comme beaucoup dans le courant 2010 mais j’ai commencé à m’y intéresser début 2011. Ce mouvement m’apparait un rien BuzzWord, un peu comme Agile en son temps. Tweeter sur un produit avec un tag #devops est un bon moyen d’attirer des clients potentiels, il faut aller au delà.
Il y a de vraies bonnes idées dans DevOps, sur de l’outillage certes, mais aussi sur le débordement Ops/Devs. Trop souvent on cloisonne Devs ou Ops alors qu’ils peuvent parfaitement se recouvrir ou à ma préférence travailler ensemble.
Ma participation à DevOps est en premier lieu sur des présentations dans les JUG afin de faire mieux comprendre ce que cache ce mot “magique”.
On trouve beaucoup de présentations techniques mais peu sur les contextes humains et la réalité du terrain, c’est ce que j’essaie d’adresser dans mes talks en 2011.
Pour l’absence à Devoxx 2011, je ne serais dire pourquoi, l’actualité Devs était déjà très riche notamment avec tous les nouveaux langages autour de la VM et n’a pas laissé de places disponibles. De plus, il existe maintenant des conférences spécifiques comme les DevOps Days.

Lyon JUG Team : Quels sont les bons blogs/tweets a suivre pour découvrir/se perfectionner sur la culture Devops

Henri : Devops Weekly en tout premier lieu. C’est un excellent résumé de ce qu’il faut voir et savoir. Tout n’est pas utilisable forcément immédiatement, on le garde dans un coin pour y revenir quand le besoin sera là. Je suis aussi les listes Paris et Lille Devops, mais il y a quand même moins d’activité. Autre source d’informations, l’ami Patrick Debois, à suivre sur Twitter!
Au final, ce qu’il manque, ce sont des DOUG (DevOps User Groups) comme cela existe pour Java et les JUG.

Lyon JUG Team : On parle beaucoup de “Continuous Delivery” depuis quelque temps… Quelles sont ta pratique et ton retour sur le sujet?

Henri : Continuous Delivery (CD) est un sujet intéressant puisqu’il est clairement à cheval entre Devs et Ops. C’est d’ailleurs généralement un domaine qui peut se retrouver dans le giron d’un ForgeMaster (clin d’oeil à mon camarade Arnaud Héritier). Pour moi, il y a 2 types de Continuous Delivery :

• Celui pour de la pré-prod et notamment des tests unitaires ou de charges, mais sans nécessité d’assurer un service de type production
• Et il y a le Continuous Delivery directement vers la production. Là je dois dire que ce n’est pas une mince affaire, surtout lorsqu’on a des SI complexes et des référentiels chargés.

J’aurais tendance à privilégier le CD type pré-prod, qui renforce les garanties sur le CD pur prod. Et rien n’empêche d’utiliser l’outillage mis en place pour le CD pré-prod une fois qu’il est bien rodé pour du CD prod, mais gardons la surveillance des Ops et Devs.

Lyon JUG Team : Est-ce que les langages comme Java sont compatibles avec DevOps ? Quand on parle de DevOps, on pense plus facilement à du Ruby par exemple.

Henri : DevOps, ou la vengeance de Ruby passé du coté obscur ?
La grande majorité de l’outillage DevOps est développé en Ruby voir Python et très peu est fait en Java. Plusieurs raisons :

• Pour les Ops, la JVM donne toujours l’impression d’être gourmande en mémoire et longue à démarrer.
• La simplicité apparente de Ruby ou Python car Java apparait encore trop pour les Ops comme un outil de développement pur, ce qui n’est pas vrai.
• Copy/Paste effect, quand un écosystème est construit avec un outil, on va le voir grandir et s’étoffer autour du même outil.

Après Java sert souvent en DevOps. Typiquement lorsqu’on utilise un repositiory de livrables Maven, comme Nexus ou Artifactory, c’est bien une application Java qui est dans la boucle. Il n’est pas impossible que, dans les années à venir, on voit apparaitre de plus en plus de solutions en Java suite au basculement de certains développeurs Java vers le coté obscur

Lyon JUG Team : En Java, est-ce qu’il y a des architectures ou frameworks plus adaptés que d’autres au DevOps (Full JavaEE, Spring+Tomcat,…)

Henri : Pour moi, c’est moins une question de frameworks que d’architecture du produit. Si on a des systèmes bien découplés, légers et rapidement déployables, on a les pré-requis DevOps. Si votre application nécessite des opérations complexes, par exemple sur un référentiel au démarrage ou pour une migration, on s’est déjà tiré une balle dans le pied.
De même, ne pas espérer faire du DevOps si les opérations de mise en place ou démarrage/arrêt des composants de l’application ne peuvent se faire qu’à la main. DevOps c’est aussi l’automatisation de taches de production.

Lyon JUG Team : Quelle serait la technique de ninja du Devops pour déployer des applis web Java ?

Henri : Tout dépend, mais je répondrais le Packaging Natif (dont je parlerai dans des présentations futures). Pourquoi?
Parce qu’il permet non seulement de déployer une application, mais de se garantir que les pré-requis seront présents. Et que l’ensemble des composants suivront un cycle de mise à jour comme des composants OS.
Une application est un ensemble de composants logiciels, qu’ils soient fournis par le système d’exploitation ou par nous. Autant utiliser le même outillage pour s’assurer du cycle de vie des composants.

Lyon JUG Team : Est-ce que DevOps et PaaS sont des tendances distinctes, communes, convergentes,… ?

Henri : PaaS, c’est quoi ? Platform as a Service, autrement dit, un couple hardware/middleware est prêt à recevoir vos développements. Si votre fournisseur du PaaS vous permet de déployer vos applications via scripting par exemple, vous pourrez faire du DevOps avec. On mélange souvent Iaas, Paas, Saas et DevOps, les uns n’impliquent pas les autres. On peut parfaitement faire du DevOps sur une infrastructure interne traditionnelle

Lyon JUG Team : Est-ce que DevOps et outsourcing ou infogérance sont compatibles ?

Henri : J’aurais tendance à demander si Agile et outsourcing/infogérance sont déjà compatibles Si la communication est bonne entre Dev et Ops, qu’elle passe par mail, skype, chat, la distance compte peu. On a tous connu des situations/compagnies où des personnes à 1 mètre les unes des autres ne communiquaient pas.
De même, l’OpenSource démontre tous les jours que des personnes de nationalités différentes, ne parlant pas la même langues et n’étant pas sur les mêmes fuseaux horaires peuvent collaborer et fournir des résultats exceptionnels.
Mon retour d’expérience me ferait donc dire que l’important c’est le dialogue et la volonté de travailler ensemble.

Lyon JUG Team : Quels sont tes outils préférés, ceux qui représentent ce mouvement?

Henri : J’ai plusieurs outils dans ma musette qui me semblent indispensables :

• Jenkins: Le couteau suisse avec lequel on peut pratiquement tout faire, du build/ci traditionnel mais aussi du contrôle d’instances via les agents remote (ex: ssh agent). C’est le composant principal des usines eXo (dev, qa et continuous deployment)
• VirtualBox : C’est LA solution permettant de monter rapidement des VM Linux ou autres pour faire des expérimentations ou simuler des déploiements.
• Vagrant / Veewee : 2 outils pour construire des VM Linux opérables en VirtualBox via scripting. Idéal pour construire des images précises d’OS.
• SuseStudio : Si on est utilisateur OpenSuse ou SLES, SuseStudio est un superbe outil Web, gratuit, qui permet lui aussi de construire des images OpenSuse avec une grande facilité et à destination de VBox, VMWare, DVD ou même Amazon EC2. Si vous souhaitez couvrir plus d’OS, UShareSoft Builder est excellent aussi.
• SCM : Subversion ou Git, par qu’on ne doit jamais perdre la trace des opérations. Ops ou Devs, toute modification du SI doit pouvoir être suivie et connue.
• JIRA/Confluence : Que ce soit pour des sprints Devs ou pour des taches Ops, je trouve le couple JIRA/Confluence parfait pour tout le suivi activités et la partie documentaire.
• shell & co : quoi qu’on en dise, on se retrouve fatalement un jour dans la console et une bonne pratique des outils shells permet d’à peu prêt tout faire.

Vous me direz qu’il n’y a ni Puppet ni Chef dans ma musette et je répondrai qu’après les avoir évalué, je les ai trouvé un poil complexes à mettre en oeuvre pour mes besoins. On finit tôt ou tard à sortir du DSL fourni (Puppet) et/ou devoir développer en Ruby (Chef), ce qui peut complexifier la tache dans un mode Devs + Ops, ajoutant un nouveau langage comme pré-requis de discussions.
Par contre, si on a déjà du monde connaissant bien Puppet ou Chef en interne, ce sont de bons outils pour le DevOps.

Merci Henri! Rendez-vous sur le site du LyonJUG pour vous inscrire à sa session du 20 décembre!

Antoine Sabot-Durand est consultant et architecte Java EE chez Ippon Technologies. Il intervient sur toute sorte de missions : conceptions d’architecture applicative, audits d’applications existantes, formations. Il est également en charge de la capitalisation des savoir faire au sein de la société. Il a acquis une expertise sur Java EE et plus particulièrement sur EJB 3.X et CDI. Il est l’auteur de quelques articles ayant alimenté le débat sur les standards et les choix technologiques sur les développements Java comme “Les rendez-vous manqués de Spring” ou plus récemment une suite d’article sur Java EE 6. Il est également membre de l’Expert Group CDI 1.1 et technical Leader sur le module Seam Social du projet Open Source Seam 3. Vous pouvez suivre Antoine sur Twitter ou Google+.

Philippe Charrière s’est présenté lui-même comme suit : “Je suis “avant-vendeur” à Lyon chez Steria. Avant d’être “ingénieur informaticien” j’ai commencé à coder sur une TI57 (beaucoup ne doivent pas savoir ce que c’est, normal j’ai 42 ans (ça c’est geek)) et depuis la passion du code ne m’a plus quitté. J’ai fait différents métiers en passant par technico-commercial, développeur cobol, responsable informatique, chef de projet, architecte .Net (désolé), directeur de projet, responsable technique, avant-vendeur… et ce n’est certainement pas fini. Mais je n’ai jamais lâché “le code”, plutôt multi-techno, ça m’aide à faire des propositions commerciales qui tiennent la route et à la livrer avec des prototypes quand je peux. @Home, c’est Javascript, Coffeescript, Play!Framework, et tout ce qui touche au mobile (grosse passion pour les jouets Apple, mais bidouille aussi Android)”. Vous pouvez consulter le blog de Philippe ou le suivre sur Twitter ou Google+.

Loïc Descotte s’est également présenté lui-même : “JUG Leader à Grenoble (Alpes JUG) et développeur chez Kelkoo. Ce que j’aime particulièrement dans le métier/hobby de développeur c’est l’évolution permanente des technologies qui permet de découvrir sans cesse de nouvelles choses. Dès que j’ai un peu de temps j’essaie de parler un peu des frameworks que je teste sur mon blog CoffeeBean. J’ai découvert Play début 2010 grâce à une présentation de Guillaume Bort. J’ai tout de suite été séduit par la puissance, la simplicité de ce framework, qui contrairement a pas mal de ses concurrents côté Java (Wicket, JSF…) ne cherche pas à masquer les principes et le fonctionnement du Web.” Vous pouvez également le suivre sur Twitter ou Google+.

Cet interview a été préparé conjointement par Agnès CREPET et Cédric EXBRAYAT, deux membres de la team du Lyon JUG. Merci également à Cyril Lacôte de l’équipe du podcast Cast-IT pour son aide sur la relecture de cet interview.

Agnès & Cédric : Pour introduire un peu les concepts d’une architecture avec ou sans état, comment définiriez-vous ce qu’est un état ?

Loïc (Equipe Stateless): Dans une application il existe (presque) toujours un état. Lorsqu’on parle d’architecture sans état il s’agit souvent d’un raccourci pour dire qu’il n’y a pas d’état au niveau middleware (sur le serveur d’application par exemple). Dans ce contexte, l’état est un ensemble de données relatives à une session utilisateur à un instant t. Ces données peuvent comprendre les informations relatives à l’authentification et aux droits de l’utilisateur, un historique des actions effectuées durant cette session (sélection de paramètres d’affichage, sélection de produits sur un site marchand…)

Philippe (Equipe Stateless): Globalement, je dis “comme Loic”. plus spécifiquement, j’aurais tendance à “déshumaniser” le concept et à rattacher l’état à une page plutôt qu’à l’utilisateur, voire même de manière plus abstraite à une ressource (ex: client lourd à la place de la page). Et cet état existe côté client et côté serveur, pas forcément en même temps selon si l’on est en stateful ou en stateless :

• en stateful : la page/client a un état, dont la représentation/(persistance ?) côté serveur est une session en mémoire quasiment au même moment
• en stateless : la page/client a un état, dont la représentaion côté serveur est finalement très furtive puisqu’elle peut n’exister qu’au moment où l’on interroge le serveur.

Antoine (Equipe Stateful): Un état est une information temporaire gérée au sein d’une application pour un utilisateur donné ou l’application dans sa globalité. Cette information permet de conserver de manière transitoire des données concernant l’utilisation actuelle de l’application ou un statut d’avancement dans un processus donné de celle-ci.

Agnès & Cédric : Imaginez que vous atterrissiez sur une île déserte et que vous n’ayez la possibilité d’emmener avec vous qu’un seul framework Java de référence pour coder une application, lequel choisiriez-vous ?

Loïc (Equipe Stateless): Si on part du principe qu’il n’y a pas d’électricité sur une ile déserte, il va falloir faire le maximum de chose avec le temps de batterie qu’il nous restera sur notre laptop… Il nous faut donc un framework productif… ensuite je pense que vous vous doutez de la réponse

Philippe (Equipe Stateless): perso, je préférerais partir avec un manuel de construction navale et une canne à pêche. Sinon je partirais avec SL4A sur android + moteur beanshell parce que j’aurais plus de batterie sur mon smartphone que Loic sur son netbook. (Bon, ok, je prendrais Play! aussi parce que je peux utiliser TextMate et que ça consomme moins de ressource)

Antoine (Equipe Stateful): Pour coder : Java EE 6, parce que c’est la solution permettant le plus de choix d’architecture : Stateful ou Stateless, webapp ou client lourd. Sinon la bibliographie Spring est plus volumineuse et avantageuse si on souhaite faire des feux de camp!

Agnès & Cédric : Selon votre approche préférée (stateful/stateless), comment “suivre” et contrôler l’activité d’un client sur mon site? En prenant le fameux exemple d’un client faisant une commande sur un site marchand: comment puis-je lier entre elles les requêtes HTTP d’un même client? Comment je persiste son panier?

Loïc (Equipe Stateless): Si on prend l’exemple de Play, pour lier les requêtes HTTP d’un même client on dispose d’un objet d’accès à la session d’un utilisateur dans les contrôleurs. Cet objet est initialisé à l’aide un cookie sur le navigateur. Ce cookie est signé et crypté pour des raisons de sécurité. Si on veut stocker le contenu d’un panier dans la session utilisateur, on a plusieurs possibilités. La solution la plus pratique et qui sera bientôt la solution la plus standard est d’utiliser les API de stockage côté navigateur fournies par HTML5.

Philippe (Equipe Stateless): Facile! Comme Loïc. Bon je détaille un peu. Pour lier et persister : localstorage (donc il faut faire du js) est une super solution, facile à mettre en oeuvre. Beaucoup l’associe à HTML5, mais en fait la notion de localstorage existait avant, et il existe différents types de localstorage : SQLite, local storage (key-value), DOM Storage, user-data (anciennes versions de navigateurs). Pour plus d’infos : voir cet article “5 Obscure Facts About HTML5 LocalStorage“. Pour les navigateurs plus vétustes, il y a aussi la possibilité d’utiliser les fonctionnalités de storage de flash, il est très facile de discuter en js avec actionscript (et inversement). Pour les inquiets du JS, il existe de très bonnes librairies qui encapsulent et abstraient tout ça, une des plus connues est lawnchair.js de Brian Leroux (de chez Nitobi / Adobe / Phonegap) et qui fournit tous les adapters nécessaires en fonction des navigateurs. Un des plug-ins lawnchair fait du clé-valeur avec la base SQLite embarquée qui est plus rapide que la version clé-valeur de base (ça s’utilise par contre de manière asynchrone avec des callbacks). C’est aussi intéressant de se coder la sienne au moins pour comprendre les concepts.

Antoine (Equipe Stateful): [Pour lier les requêtes HTTP :] en les stockant dans un contexte session ou mieux conversation. Pas de persistance explicite. Le panier reste en mémoire, il sera sérialisé en cas de besoin (charge importante). Si j’attends une durée de vie plus importante, je peux mettre un listener à la fin de la session pour le stocker explicitement.

Agnès & Cédric : Comment je contrôle la conversation web de mon client : comment gérer par exemple le bouton back du navigateur?

Loïc (Equipe Stateless): Le problème du bouton back du navigateur se pose beaucoup moins avec un serveur stateless. Le principe d’architecture stateless est fortement lié à celui d’architecture RESTful : avec des URL bien définies, n’importe quelle étape de la navigation doit être bookmarkable. Si on revient sur une de ces étapes, le fait d’avoir un serveur stateless fera qu’on ne risque aucune incohérence d’état sur le serveur : la page s’affichera toujours correctement quel que soit le contexte. Si vous avez déjà utilisé des frameworks comme JSF vous savez que ce n’est pas toujours le cas quand vous devez tenir compte de l’état du serveur.

Philippe (Equipe Stateless): Pour le bouton back, cela peut se gérer côté client : toujours avec le localstorage, une solution peut être aussi de faire une application ‘monopage’ (webapp) et de jouer aussi avec les api de gestion de l’historique du navigateur , des hashtags (window.onhashchange), …

Antoine (Equipe Stateful): Plusieurs stratégies en fonction du contexte :

• Stocker l’état des vues précédentes pour gérer le back
• Demander à JSF de générer des URL Rest avec prettyface
• interdire au navigateur de cacher une page pour forcer son rafraîchissement
• gérer correctement les erreurs d’incohérence entre l’état serveur et l’état client
• Faire mon rendu en ajax : le bouton back me fera sortir de l’application

Agnès & Cédric : Est-ce possible de gérer plusieurs espaces de travail pour le client, à savoir plusieurs conversations avec la même application dans différents onglets de son navigateur?

Loïc (Equipe Stateless) : Je ne suis pas du tout expert sur cette question, le cookie de session étant partagé entre les différents onglet (du moins sous Firefox et Chrome), en principe on ne peut pas avoir plusieurs sessions en même temps avec ce procédé. Après avec Play tout est possible, on peut très bien se contenter de créer une session côté client, encore une fois avec local storage, et associer une session à une instance de page à l’aide de JavaScript.

Philippe (Equipe Stateless): avec le module Secure de base de Play, ça va pas le faire (perso j’utilise différents navigateurs, ou mode incognito) pour les raisons expliquées par Loic. Quelles solutions ? -> faire sa propre solution d’authentification et passer des infos dans la requête (bof) -> faire avec -> quand tu es connecté sous google tu ne peux l’être qu’avec un seul user -> on perd en souplesse, on gagne en sécurité.

Loic (Equipe Stateless): En dernier recours il existe aussi des plugins pour les navigateurs qui permettent d’avoir des sessions distinctes dans différents onglets via une manipulation des cookies (voir exemple).

Philippe (Equipe Stateless): pour l’aspect “plusieurs espaces de travail” : le localstorage peut prendre plusieurs formes :

• accessible par l’ensemble des onglets du navigateur (ou par plusieurs instances du navigateurs), bon ok dans le cas de 2 navigateurs de marques différentes, faudra faire plus classique (on parle de localstorage)
• accessible uniquement sur la page en cours et uniquement pendant la session (on parle de sessionstorage)

Antoine (Equipe Stateful): Yep, CDI contient un scope conversation permettant de faire ça. Apache CODI l’étend en permettant de gérer des sous conversations (mise en pause d’une conversation, lancement d’une autre)

Agnès & Cédric : Puis-je définir facilement un workflow obligeant mon client à enchaîner plusieurs écrans pour une conversation donnée (le paiement par exemple)?

Loïc (Equipe Stateless): Pour gérer un workflow de navigation, il y a tout ce qu’il faut aujourd’hui dans les librairies côté client pour faire ça. On peut enregistrer les différentes étapes et y revenir avec l’history API HTML5 par exemple.

Antoine (Equipe Stateful): Concernant le worklfow, actuellement il existe à ma connaissance trois solutions stateful gérant ce besoin :

• Spring Webflow mais bon c’est spring
• Seam 2 pageflow mais pas compatible CDI
• Oracle ADF task flow qui sera standardisé dans JSF 2.2 (sortie été 2012)

Si tout ça ne convient pas, on peut déjà faire deux ou trois trucs avec le fichier de navigation JSF, mais ce n’est pas vraiment une machine à état.

Agnès & Cédric : Comment sont classiquement démarquées vos transactions (base de données) au sein de vos applications? Quelle est dans la majeure partie des cas la durée de vie de la transaction ?

Loïc (Equipe Stateless): La durée de vie de la transaction est liée à celle du cycle de la requête HTTP : si une erreur survient lors du traitement d’une requête, tout ce qui s’est passé entre la demande du client et l’envoi de la réponse est annulé (rollback). C’est un moyen de rendre atomique chaque traitement lié à une requête. Il n’y a pas besoin d’utiliser un pattern du type open session in view, avec ce procédé on accède à nos objets (et mêmes aux éléments à charger en “lazy”) durant tout le traitement de la requête, quelle que soit la couche dans laquelle on se trouve.

Philippe (Equipe Stateless): ben je crois que Loïc a répondu à la question!

Antoine (Equipe Stateful): Par défaut la durée de vie d’une transaction est liée à la requête HTTP. L’utilisation de l’extended persistence context permet de retarder la transaction après plusieurs écrans (un wizard).

Agnès & Cédric : Comment une architecture (avec/sans) état, répond elle aux problématiques de scalabilité, et de reprise sur activité en cas de panne ?

Philippe (Equipe Stateless): Pas d’état conversationnel : le serveur ne conserve aucune information entre 2 requêtes différentes d’un même client, du coup la 1ère requête pourrait être traitée par un serveur A, la 2ème par un serveur B, etc. … Mon “identité” existe côté client uniquement, donc on pourrait même imaginer que le serveur soit coupé entre les 2 requêtes.
-> côté serveur : pas de mémoire utilisée pour les sessions -> pas de problème de synchronisation de sessions entre plusieurs serveurs.

Loïc (Equipe Stateless): Il est plus simple d’assurer la scalabilité avec une architecture sans état : rien n’est partagé entre les serveurs. Si on veut ajouter un serveur derrière notre loadbalancer pour monter en charge on évite ainsi tout le paramétrage lié aux sessions que l’on trouve avec les architectures stateful : mise en place d’un cache de session distribué, duplication de sessions ou encore affinité des utilisateurs à un seul serveur… Pour gérer les pannes c’est également plus simple, si on coupe un serveur, l’utilisateur pourra continuer sur un autre serveur sans qu’on ait à se demander comment il va récupérer l’état qu’il avait stocké sur le premier serveur.

Antoine (Equipe Stateful): En stateful, la scalabilité c’est le cluster, mais c’est un sujet très vaste et souvent regardé que du point de vue du serveur d’application et pas de la base de données. La tolérance de panne est également assurée par le cluster bien que l’architecture de l’application soit primordiale pour limiter la perte d’information lors du basculement. Le sujet de la résilience des applications est également vaste.

Agnès & Cédric pour l’équipe “Stateless” : commençons par une question naïve : Quelle est la bonne pratique pour gérer la sécurité de l’application ? Où est stocké l’état si nécessaire ? Purement en base de données, purement côté client ?

Philippe (Equipe Stateless): Différentes solutions, oauth (f… je ne sais pas le prononcer) openid, … Play est fourni avec une “basic authentication”, il suffit de passer en mode SSL pour “renforcer” la mécanique. On peut aussi utiliser une “digest authentication” dans ce cas là, il faut se faire sa propre mécanique ou utiliser openid.

Loïc (Equipe Stateless): L’état doit être stocké sur le client, cette information doit être de taille minimale (loggé ou pas + rôle de l’utilisateur). C’est ce qui se passe lorsque vous êtes loggés sur GMail par exemple. Ceci n’empêche pas le mécanisme d’authentification d’être robuste (ex : oAuth, https…). Pour rappel le cookie de session est signé et crypté.

Agnès & Cédric pour l’équipe “Stateful” : Est-ce simple de tester une webapp stateful ?
Antoine (Equipe Stateful): Aujourd’hui oui grâce à JBoss Arquillian. J’en ferais une démo lors de ma prez

Merci Antoine, Loïc et Philippe!

Les inscriptions pour leur session au Lyon JUG le 22 novembre sont ouvertes! Rendez-vous sur le site du Lyon JUG.