Une meilleure diffusion de la connaissance

Dès la keynote d’ouverture, nous avons appris que l’intégralité des sessions enregistrées à Devoxx France seraient disponibles sur Parleys sur la chaîne dédiée sur laquelle les vidéos des différentes présentations seront ajoutées prochainement. Je vous encourage vivement à aller voir celles dont les sujets vous intéressent le plus (et accessoirement celles du Toulouse JUG que vous auriez pu rater). Avec la Google I/O qui approche mi-mai, ça risque en effet de faire beaucoup de choses à regarder, mais je vous assure, ça vaut vraiment le coup. Je vais essayer de vous détailler un peu ici les sujets ou présentations qui m’ont le plus marqué lors de la conférence. Pour moi ses 3 axes principaux pour cette année concernaient la programmation fonctionnelle (jdk8 et Scala), le JavaScript, et les visions du futur pour Java. Je vais essayer ici de reprendre un peu ces trois aspects. Chaque conférence aurait pu faire l’objet d’une présentation détaillée vu le niveau des intervenants, mais il faut bien faire des choix! Je n’ai malheureusement pas pu voir la présentation sur Java EE 7 par Arun Gupta que j’attendais beaucoup, je me rattraperai lors de la diffusion des vidéos.

What every Hipster should know about functionnal programming

Je dois saluer ici les qualités d’oratrice de Bodil Stokke et son énorme travail de préparation, qui a accessoirement donné deux conférences dans cette édition de Devoxx. Pour ceux qui ne la connaitraient pas, elle s’est illustrée notamment grâce à sa célèbre théorie : “Facial hair theory of programming language design”. Je vous conseille vivement d’aller y jeter un oeil. Cette conférence ayant déjà été donnée lors de JFokus, vous pouvez dores et déjà aller la voir.

Le titre évoque bien le contenu de la présentation. Elle s’est évertuée à vulgariser tous les mots barbares utilisés par ceux qui font de la programmation fonctionnelle. Sans être exhaustif, je sais maintenant mieux ce que sont les “functors”, “combinators” mais aussi les triples de Kleiski, la curryfication et les monades.

La présentation a consisté en un live coding en TypeScript, juste du JavaScript typé, de tous ces mots barbares sur fond de “My Little Poney” (thème récurrent à Devoxx cette année). Elle constitue une excellente piqûre de rappel de nombre d’aspects de la programmation fonctionnelle dont le map/reduce notamment à l’origine de bon nombre de moteurs Big Data que nous utilisons actuellement.

Les présentations autour de la programmation fonctionnelle devaient représenter un bon quart des conférences si on prend en compte Scala, la programmation fonctionnelle en tant que tel et qu’on ajoute une touche de Ceylon et du JDK8. Il y a de bonnes chances qu’on en croise de plus en plus dans le mode du développement logiciel durant les mois et années à suivre.

Du JavaScript propre?

Voilà une question que je me pose depuis pas mal de temps. Je me penche réellement sur JavaScript depuis peu et n’ai jusqu’à présent abordé que les grands classiques tels que jQuery notamment.

J’ai vite compris la puissance cachée derrière ce vieux langage mal compris, ainsi que ses faiblesses (WAT?), notamment au niveau de la lisibilité et capacité à être maintenu. Au vu des avancées des navigateurs (performances x20 notamment), JavaScript est désormais vraiment devenu une arme plus qu’intéressante. Si en plus on l’associe aux fonctionnalités offertes par HTML5, on obtient vraiment un outil puissant pour faire des sites flexibles rapidement.

Cependant, comment s’y retrouver dans un gros projet JavaScript? Comment le garder maintenable au fil du temps? C’est la questions à laquelle ont répondu Julien Jakubowski et Romain Linsolas.

Tout d’abord, s’il y a un livre à avoir dans sa bibliothèque sur JavaScript, il s’agit de JavaScript : The Good Parts. Ensuite, pour contourner le problème, vous pouvez vous tourner vers CoffeeScript ou Dart, mais ce n’était pas l’approche abordée ici. A la place, les orateurs ont proposé une myriade d’outils afin de faciliter la maintenance de gros projets :

• Angular, Backbone et Ember afin de déporter le MVC côté client
• Asynchronous Module Definition (AMD) tel que require.js pour aider à modulariser le code
• JSLint (équivalent de checkstyle et PMD) afin de trouver des erreurs fréquentes
• jQuery pour rendre plus lisible les parcours du DOM
• Mustache.js pour le templating (handlebars + underscore)
• Pour les tests d’intégration, l’indétrônable Selenium ou Windmill
• Pour vos tests unitaires : Jasmine (+CoffeScript?), QUnit, Mocha…
• Karma, PhantomJS, Casper…
• build maven + jenkins + Sonar pour automatiser les tests
• Yeoman (Yo pour le scaffolding, Grunt comme task launcher et Bower pour la gestion des dépendances)

Autant dire que les outils et les solutions sont nombreux! Cependant, il est facile de se perdre dans une telle effervescence, des frameworks JavaScript sortent tous les mois. En résumé, utilisez du MV*, modularisez votre code, évitez les “parties sales” de JavaScript, mettez en place des tests et automatisez vos tests, déploiement etc.

What I want in Java 9

Autant le dire tout de suite, cette session est celle qui a le plus piqué ma curiosité au vif. Je ne vais pas ici vous décrire ce que sera Java 9, il y a cependant déjà des choses prévues (Jigsaw, l’Arlésienne des JDKs?) auxquelles je m’attaquerai dans un prochain post. Je vais plutôt essayer de retranscrire ici ce que j’ai compris et ce qui m’a plu de la vision de Rémi Forax.
A l’origine était invokedynamic, ou du moins depuis le JDK7, vous savez le truc utilisé par à peu près tous les langages de programmation basés sur la JVM sauf Java pour augmenter de façon drastique leurs performances. Le principe est simple : noms et typages symboliques à la compilation. On référence ensuite des pointeurs de fonction au moment des appels et on gagne énormément en performances pour les langages dynamiques. Je ne vais pas m’étaler dessus, ce n’est pas là le fond de notre problème, le truc important est que ça permet de comprendre un peu que la JVM gère déjà des choses (du moins des langages) dynamiques. La réflexion qui en découle consiste en une phrase : “Pourquoi ne pas utiliser aussi ça depuis Java?”
On se retrouve enfermés depuis un moment dans des frameworks complexes pour gérer l’inversion de contrôle, nous obligeant à écrire des proxys pour appliquer nos concepts d’AOP, d’injection de dépendances et j’en passe. Du coup, on se trimballe dans la JVM à la fois la classe et la définition de son proxy, qui embarque toutes ses méthodes notamment. De plus, Java EE définit des services que doivent fournir les conteneurs de nos serveurs d’application avec les problèmes de compatibilités inter conteneurs qu’on leur connait.

Selon notre cher conférencier, il y aurait un moyen d’unir ces deux mondes de Java SE et Jave EE qui ne se sont plus beaucoup parlé depuis un petit moment. Pour cela, il propose un nouveau mot clé dans le langage Java : interceptable. Ce mot clé magique permettrait de définir qu’une classe peut être interceptée, écoutée. La JVM se chargerait ensuite simplement d’appeler les intercepteurs enregistrés. Je n’ai malheureusement pas toutes les informations nécessaires pour rentrer plus dans le détail, mais à priori, cette amélioration du langage ne demanderait que relativement peu de développement dans javac et permettrait entre autres choses :

• De ne plus avoir besoin d’autant de boxing et des stack traces toute pourries!
• De baisser fortement le coût d’entrée des technos Java EE
• D’utiliser simplement des concepts avancés disponibles sous Java EE en Java SE

Il proposait aussi un mot clé ghost qui permettrait que le typage soit connu par le compilateur mais pas par la VM (dans un souci de gain de performance je présume).

Apparemment, il cherchait du monde pour faire pression avec lui pour qu’Oracle écoute ses dires, je manque de précisions à ce sujet, mais si on me dit où, je signe de suite!

Au final, Devoxx a été pour moi une expérience très enrichissante. C’est vraiment le genre d’évènement qui vous redonne la foi dans votre métier et vous rappelle pourquoi vous vous levez tous les matins, pas juste pour vous nourrir, mais parce que vous faites un boulot qui vous plait. Vivement l’année prochaine! D’ici là, n’hésitez pas à demander des précisions ou à me compléter si vous avez des informations supplémentaires!

Elastifiez votre application : du SQL au NoSQL en moins d’une heure

Intervenants :
- David Pilato technical advocate chez Elasticsearch (twitter @dadoonet)
- Tugdual Grall Technical Evangelist  Couchbase (twitter @tgrall)

Les bases de données relationnelles peuvent subir des grosses montées en charge et la solutions de scalibilité verticale (plus gros serveur) a ses limites et elles ont des structures de données rigides. Les deux conférenciers pour résoudre ces problèmes de charge, nous proposent d’utiliser Couchbase, une base NoSql, et Elastic Search, un moteur de recherche fulltext  à la Google.

Les 2 conférenciers pour démontrer l’efficacité de leurs produits, sont partis d’un exemple simple constitué de 3 tables, basé sur une architecture classique de DAO avec une base relationnelle. Ils ont montré selon eux, les limites de ce modèle, implémentation complexe, problème de performances, moteur de recherche trivial et non performant …
Ils ont ensuite appliqué des modifications successivement par couche pour démontrer l’efficacité de leur produit : mise en place d’un service REST via
Spring, remplacement de la base relationnelle par la base NoSql Couchbase, mise en place d’Elastic Search, utilisation de leur outil de reporting en temps réel et enfin injection d’un million d’enregistrements.

La démonstration était impressionnante. La mise en place des outils a été rapide et paraissait simple.  L’injection des 1 million s’est réalisée en moins de 5 minutes et les performances de l’application étaient toujours aussi bonnes après. Les avantages d’une base NoSql sont séduisants par rapport à une base relationnelle classique, on peut modifier facilement les schémas des données, scalibilité horizontale , performance …

Blog de Tugdual Grall

Ancienne présentation des conférenciers :
http://fr.slideshare.net/normandyjug/normandy-jugmarch2013
http://fr.slideshare.net/dadoonet

Le Space-Mountain du développement Java d’entreprise
Intervenant : Florent Ramière (twitter : @framiere)

Florent Ramière a plus de quinze années d’expérience dans le développement logiciel et la conduite de projets informatiques.
En 2009 il a lancé www.SpringFuse.com, produit de génération de code en ligne.

A travers une démo en direct-live avec Eclipse, Florent Ramière a présenté une application web d’entreprise de type CRUD, avec entre autres les technologies suivantes:
Maven 3
Spring 3.2
JPA 2.2
Bean Validation 1.0
JSF 2.1
Primefaces 3.4
Junit 4
Mockito
Selenium 2
Jprofiler

Pour cette conférence voici les points que j’ai découverts ou redécouverts :
- Guava , librairie utilitaire de Google qui nous offre un ensemble de classes utiles pour des usages assez fréquents comme la gestion des collections, la gestion des fichiers, des types simples ou de la synchronisation.
- Lombok, framework qui permet de générer des méthodes (par exemple les getter et les setter) au lancement de l’application à l’aide d’annotations. Cela permet de rendre plus visible le code en supprimant l’implémentation des méthodes triviales.
- Selenium : permet d’automatiser des tests fonctionnels d’application web.
- JMeter : pour faire des tests de charges
- JProfiler : Outil de profiling capable de mesurer les performances de la partie java d’une application, mais aussi Sql et hibernate. Par contre ce logiciel est payant.
- ISpace : outil pour trouver les dépendances cycliques.

Le conférencier a aussi mis en avant les avantages de l’intégration continue.

IDE Java : astuces de productivité pour le quotidien
Conférence par Xavier Hanin (@xavierhanin)

Xavier Henin a présenté des astuces pour des gains de productivité avec les IDE principaux Eclipse, Netbeans et IntelliJ. Le conférencier a bien sûr mis en évidence l’avantage des raccourcis clavier pour gagner en productivité sur les IDE. Selon lui, le raccourci à connaître en priorité est la recherche rapide (CTRL + 3 sous Eclipse). Cela permet d’accéder rapidement aux éléments de l’interface graphique.

Voici les principales astuces que je ne connaissais pas ou que je n’utilise pas assez:
- la programmation par intention  on écrit l’appel de méthode et l’IDE crée la méthode dans la bonne classe
- on peut mettre des points d’arrêt conditionnels
- on peut revenir en arrière lors d’un debuggage grâce à l’option “inspect” (CTR + SHIFT +I). On pose le point d’arrêt dans la méthode dans lequel on veut revenir, on sélectionne l’appel de la méthode et on inspecte ce dernier.

Le point le plus intéressant est que le conférencier a créé pour la conférence un tableau de correspondance des différents raccourcis sur les 3 IDE, très pratique lorsqu’on connaît un IDE et que l’on veut en tester un autre.

Xavier Hanin  connaît plus de cent raccourcis, je suis loin d’en utiliser autant. Cette conférence m’a donné envie d’en utiliser plus et surtout d’essayer un autre IDE.

Correspondance des raccourcies dans les différents IDE :
https://docs.google.com/spreadsheet/ccc?key=0AgJVaeoL2ksbdDNWaWpSeDMzRkt6aHZHbVJteGZzNEE#gid=0

De Devoxx au CAC40
Conférence par Julien Dubois (@juliendubois)

Julien Dubois a co-écrit le livre “Spring par la pratique”, et a dirigé la filiale française de SpringSource.

Tatami, est un projet Open Source de réseau social d’entreprise. Il a été lancé à l’occasion d’un concours de code pendant le Devoxx 2012. Il est actuellement utilisé par deux groupes du CAC40. Les technologies utilisées sont le HTML 5, Backbone.js, Spring, Apache Cassandra, Elastic search.

Je pense que ce projet est un bon exemple de réussite d’un projet Open Source, une société chargée de la commercialisation de ces service va bientôt être créée. Le code du projet peut être une bonne source d’inspiration pour approfondir les technologies citées précédemment.

Tatami en version SaaS
Le code source de Tatami
Slide de la présentation

Conclusion

Je découvrais cette année le salon Devoxx, j’ai beaucoup aimé, cela m’a permis de connaître les tendances actuelles et futures dans le domaine du développement. Les conférences avaient des thèmes variés, elles étaient bien organisées, et ce que je retiendrais surtout c’est qu’ils avaient beaucoup d’enthousiasme. Les conférenciers étaient enthousiastes pour présenter leur travail et leur retour d’expérience, mais aussi sur l’avenir de notre profession et sur le marché français.

L’ensemble des conférences sera bientôt disponibles en vidéo sur le site Parley.

En résumé, je n’ai qu’une envie, c’est d’y retourner l’année prochaine !

Dans le cadre de la diffusion d’un nouveau produit innovant dans le domaine de la mobilité, Génitech recherche pour son siège social un(e) Assistant(e) Marketing en stage.

Vous contribuez au développement de l’activité d’un nouveau produit innovant mobile et tactile sans contact, conçu en collaboration avec un consortium Européen de recherche, en lien avec le Responsable Projet et les autres membres du consortium. Vous participez à la réflexion stratégique, l’élaboration concrète ainsi qu’au suivi des actions marketing Européenne du produit.Dans une démarche prospective, vous mènerez des études ciblées de marché afin de cadrer et d’optimiser la communication et de proposer des adaptations produits en fonction des retours « terrains ». Vous coordonnerez ensuite les actions de communication et de dissémination afin de maximiser le taux de reconnaissance du produit auprès de la population cible.

De niveau Bac+2 à 5, vous êtes force de proposition et possédez une réelle créativité dans l’élaboration de stratégies d’actions Marketing et de dissémination d’un produit innovant ainsi que de rigueur dans la gestion de leur suivi et leur mise en place.

Bon niveau d’anglais écrit nécessaire.

Démarrage :
Avril 2013

Durée : 3 mois

Lieu du stage:
Malakoff (ligne 13 du métro)

Lors du Mobile World Congress à Barcelone, Samsung a annoncé Knox.

Il s’agit d’une version d’Android personnalisée permettant de basculer très facilement entre environnements (appelé Persona)  : d’un environnement personnel à un environnement professionnel. Les deux environnements sont hermétiques en termes de données et donc de vulnérabilité potentielle pour le système d’information de l’entreprise.

Nous avons pu par exemple rencontrer un représentant de DropBox qui nous a présenté son produit DropBox for Teams adapté à Knox : on accède à des espaces de stockage et partage de fichiers qui sont différenciés selon le Persona.

On ne discutera pas ici des points forts et faibles (pas d’approche via les standards, obligation d’adapter les applications par les éditeurs etc.) du produit mais on s’attachera à souligner le nouveau paradigme popularisé.

En effet, les utilisateurs de mobiles n’ont jusqu’à présent pas à se soucier de leur rôle dans leur utilisation de leurs services mobiles (Apps, m-services connectés) et en particulier de leurs données personnelles. La frontière donnée personnelle / donnée publique s’est progressivement effacée par l’utilisation généralisée des réseaux sociaux. Certes, beaucoup s’en émeuvent, demandent le droit à l’oubli, commencent à lire les conditions générales d’utilisation des services auxquels ils sont abonnées. Mais le mal est profond pour l’entreprise : comment faire confiance dans un dispositif mobile (smartphone ou tablette) qui serait une passoire à données  où espaces public, privé et professionnel seraient perméable ? Généraliser le BYOD présente donc un risque important pour l’entreprise au coeur d’une guerre économique sans frontière.

C’est pourquoi l’initiative de Samsung avec Knox a le mérite de familiariser le grand public avec le concept de rôle, d’habilitation, de séparation des espaces de données et ceci dans un vocabulaire simple (le Persona) et une ergonomie des plus utilisables (un simple clic permet de basculer de contexte).

Samsung réussira-t-il dans son défi de popularisation des Espaces de données personnelles (PIMS pour Personal Information Management System) et des fédérations d’identité (même si elle reste réduite à deux identités) là où Apple a réussi pour le Cloud avec son service iCloud. Nous le lui souhaitons.

PS : vous trouverez plus d’informations sur nos travaux sur les PIMS dans la description du projet PIMI.

Les problèmes suivants se posent alors :

• Comment exploiter un jeu de données réaliste et disposer d’adresses e-mails différentes pour tous les utilisateurs simulés durant les tests (Pour un service en ligne : des demandeurs, des gestionnaires, voir d’autres intervenants…) ?
• Comment réaliser un test de bout en bout : envoi d’un e-mail, réception de ce mail, voir plus – par exemple : clic sur un lien reçu dans le mail et permettant d’accéder directement à une application web pour valider notre compte utilisateur, etc.

Bien sûr, on peut y parvenir en bricolant :

1. Si on utilise une base de données et que les messages y sont stockés, on peut aller consulter les messages en base et vérifier, voir récupérer leurs contenus. Cela peut convenir pour les tests unitaires, mais dès qu’on entre en phase de validation ou de démonstration, il faut trouver une autre solution, plus proche de la réalité finale de l’application.
2. On peut utiliser une unique adresses e-mail : notre adresse personnelle. Cela ne suffit pas toujours. En particulier, si l’application impose comme contrainte d’utiliser l’adresse e-mail comme identifiant. il est alors impératif de disposer de plusieurs adresses distinctes.
3. On peut demander la création d’adresses de tests – étrangement, tout d’un coup, l’administrateur système commence à nous éviter quand il nous croise dans les couloirs…

Heureusement, il existe d’autres solutions – au moins une autre !

Pour ma part, j’ai testé l’utilisation d’un serveur SMTP local : Papercut http://papercut.codeplex.com/. Il  existe d’autres serveurs de ce type.

Après une installation simplissime, il suffit d’indiquer à l’application à tester que le serveur SMTP se trouve sur la machine locale (localhost). L’interface utilisateur du serveur SMTP permet alors de consulter les messages envoyés par l’application, au travers de 3 vues : “Raw View” (en-tête complet et les diverses autres parties du message), “Body View” et “HTML View”.
Mais ce n’est pas tout ! Papercut dispose d’une fonctionnalité très sympathique nommée “Forward” : on peut ainsi transférer les messages vers une autre boîte aux lettres. Pour cela, il suffit de préciser le serveur SMTP sortant à utiliser et l’adresse de destination finale.

Donc si vous êtes utilisateur de smartphone et que vous souhaitez participez à la recherche sur l’utilisation des smartphones dans votre vie citoyenne, alors vous pouvez participer à l’enquête en ligne sur ce sujet (durée d’environ 15 minutes).

Cette enquête porte sur l’application UBILOOP qui permet de déclarer, en ligne sur un smartphone, différents types d’incidents urbains comme des lampadaires cassés, des nids de poules, des tags/graffitis, des nids de frelons ou tout autres incidents du même type. Une fois déclarés, ces incidents sont pris en compte par les services compétents qui seront en charge de les corriger.

Les bénéfices que vous pouvez retirer de la participation à cette enquête sont à la fois une appréciation d’un exemple de service lié à l’action citoyenne à l’aide d’un smartphone et également une opportunité de contribuer à la recherche scientifique.

Si vous souhaitez participer alors cliquez sur le lien suivant:

http://edu.surveygizmo.com/s3/1080030/Enqu-te-Ubiloop

Merci par avance pour votre contribution.

AGILE TOUR TOULOUSE 2012

C’est avec grand plaisir que je me retrouve pour la seconde fois présent à l’Agile Tour Toulouse, à l’espace de congrès Diagora. Pour rappel, vous pouvez retrouver mon compte rendu de la précédente édition à l’adresse suivante : Agile Tour Toulouse 2011

Je ne ferai donc pas ici de redite des notions déjà présentées dans mon précédent billet.

Cette conférence qui dure toute la journée a rassemblé cette année près de 500 personnes dont environ une moitié de nouveaux venus.

En plus des conférences et ateliers habituels, une nouveauté a fait son apparition dans cette édition : les Open Talks. Pour les déçus qui n’auraient pas été sélectionnés afin d’effectuer des présentations ainsi que pour les gens qui se posent des questions particulières ou voudraient lancer des débats, de petites conversations étaient organisées toutes les 30 minutes à la demande des personnes présentes (il suffisait d’écrire le sujet sur un bout de papier).

Mon programme, cette fois-ci axé sur les ateliers et la mise en pratique ne m’a pas laissé ne serait-ce que 5 minutes de répit afin d’aller voir de quoi il retournait exactement.

Keynote

Après une présentation succinte de chacun des sponsors (Valtech avec une vidéo “Agilité et Rugby”, ekito qui a conçu le site de l’évènement, Kagilum qui organise un jeu pour une licence d’IceScrum et Ubleam, concurrent Toulousain des QRCodes), David Brocart et Thierry Cros nous ont offert quelques scènettes théâtrales afin de mettre en avant les valeurs liées à l’Agilité. Munis de déguisements plus criants de vérité les uns que les autres (spéciale dédicace pour Thierry avec son Tshirt Metallica et sa perruque de chevelu, son accoutrement de coach des années 80 et à David qui incarnait le CEO à moumoute de manière magistrale), les deux présentateurs ont mis en avant de très nombreuses notions : les niveaux logiques de Dilts-Bateson qui nous poussent à chercher la cause des problèmes au niveau directement supérieur à celui dans lequel ils se produisent, la nécessite de limiter le stock et d’attendre le feed-back avant d’agir, la théorie X et Y de Mac Gregor ainsi qu’un grand nombre de concepts liés au code : clean code, refactoring, tdd, YAGNI (You Ain’t Gonna Need It). Je vous enjoins encore à aller jeter un oeil à mon retour sur l’édition précédente afin de trouver plus de détails autour de ces sujets. Pour tout vous dire, cette keynote présageait sans que je le sache à cet instant précis de ce qu’allait être le programme de ma journée : particulièrement chargée.

Innovation Games (par Eric Rubinat)

Je me suis donc prestement dirigé vers le premier des 4 ateliers qui m’intéressaient particulièrement en ce jour : à savoir une mise en pratique des Innovations Games. Ce sujet me tient particulièrement à coeur, étant un grand amateur de jeux de société depuis mon plus jeune âge et étant déjà sensibilisé à leur apport en terme d’apprentissage. A mon grand regret, étant donné le nombre trop élevé de participants, le présentateur nous a annoncé la couleur d’entrée de jeu : pas de démonstration en live malheureusement. La séance s’en est donc tenue à une présentation des jeux “Innovation Games” (attention, le nom et les 13 jeux correspondants sont déposés depuis 2003 par Lukue Homan, leur créateur).

Les jeux quels qu’ils soient commencent à perdre la mauvaise image qui les accompagnait depuis bien longtemps (associabilité, déni des réalités…) et les gens commencent désormais à comprendre leur intérêt (développement de l’esprit de combativité, de la créativité, mise en place d’un lien de communication important).

On peut découper les jeux liés à notre domaine en trois ou quatre grandes catégories :

• les meeting games (comme ROTI par example : Return Of Time Invest)
• les serious games utilisés depuis bien longtemps dans des domaines tels que l’armée, la médecine etc afin de pouvoir s’entraîner et pratiquer sur des reproductions de situations réelles.
• les jeux agiles qu’on utilise le plus souvent pour enseigner des concepts utilisés dans les différentes approches agiles.

Les serious games sont utilisés le plus souvent comme leviers du ROI Agile (Return Over Investment cela va sans dire). On s’en sert pour trouver la liste des features, les prioriser…

Il ne faut pas prendre cela à la légère en tant qu’animateur : il est nécessaire de passer beaucoup de temps à préparer de tels ateliers afin que les choses se passent au mieux.

Il faut tout d’abord définir l’objectif principal, poser la BONNE question.

Il est ensuite nécessaire de planifier : prévoir les personnes, déterminer quel jeu conviendrait.

On prépare ensuite le jeu, puis on y joue.

On agrège enfin les données, sans sous-estimer le temps nécessaire. En effet, il est nécessaire de passer beaucoup de temps sur cette partie afin de tirer le meilleur parti des jeux effectués.

Enfin, on définit et on communique le plan d’action à adopter pour la suite.

Durant la session, on peut noter plusieurs rôles :

• l’organisateur
• un maître de cérémonie (peut être la même personne mais pas forcément)
• un photographe si on peut, c’est toujours plus sympa et peut permettre de voir des choses qu’on n’aurait pas vues sinon (qui a parlé d’artefacts bizarres sur les photos?).
• un observateur, qui garde un oeil extérieur et prend des notes sur des choses qui n’auraient pas été notées sinon.

Les jeux Innovation games présentés :

• le Speed Boat : une île représente l’objectif majeur, on identifie les aides, freins et esquifs qui peuvent surgir pour l’atteindre. Ce jeu peut être utilisé pour remotiver les rétrospectives ou pour les kick-off meetings.
• la Product Box : on donne du matériel de papeterie aux différents participants (ciseaux, carton, papier, colle, feutres…) et on leur donne pour objectif de définir le packaging de leur produit. Cela permet de découvrir de nouvelles features pour le produit et de les prioriser fonction de leur emplacement sur la boîte. Il est plus que fortement conseillé d’avoir un observateur pour ce jeu.
• Prune the Tree : les branches représentent des features existantes, on donne aux participants les restantes à placer sur l’arbre (sans leur permettre d’en rajouter) en considérant que plus une feature est proche de la racine plus elle est importante.
• Buy a Feature : des billets permettent d’acheter des features et sont donnés en nombre limité. D’après l’intervenant (mais pas d’après Lukue Homan…) il ne faudrait pas donner un coût par feature. Je suis en désaccord avec cette notion. Pour moi, ce jeu sert surtout en cas d’indécision du client pour le contenu des itérations et les coûts par feature doivent représenter son coût réel en temps de développement.

L’intervenant a ensuite présenté brièvement une liste de jeux Agile, qui servent pour la formation et n’apportent pas de valeur produit, ils permettent simplement de faire passer un message :

• Bottle-Neck Game (60 à 90 min)
• the Real Options Space Game (90 à 120 min) : notion de décision au dernier moment
• The Toyota Way (45 à 90 min)
• Marble Run (20 à 30 min) : planification agile
• Origami (10 à 20 min) : importance de la communication -> OFFSHORE
• Swiss Army Knife (10 à 15 min)
• Start Your Day
• Remember the feature (dans 2j ? 2 ans ? 10 ans ?)

Les maîtres mots :

• Préparer
• Garder du temps pour les retours
• En lieu et place d’une réunion

Kanban par la pratique (par Laurent Morisseau)

Ne connaissant pas du tout la méthode Kanban, je me suis ensuite rendu dans cet atelier pour en savoir plus. Le jeu (un serious game disponible sur getKanban.com) était un jeu de plateau avec 7 dés à 6 faces de 3 couleurs différentes (2 rouges pour le design, 3 bleus pour le développement et 2 oranges pour les tests). Des cartes avec des points à compléter dans chaque catégorie sont disposées dans des colonnes avec un nombre d’éléments limités. Le but est d’arriver à remplir les cartes avec les dés et à les faire avancer dans les différentes colonnes sans créer de blocages. Les dés lancés comptent double si on les affecte à la catégorie pour laquelle ils sont prévus, simple sinon.

Des impondérables viennent rythmer la partie pour corser un peu et rendre le jeu plus intéressant.

Il permet de se rendre compte de l’importance de la fluidité de la chaîne de bout en bout et de l’importance de limiter le nombre de tâches simultanées dans chacune des catégories. Le temps moyen de réalisation par tâche s’en retrouve lissé et plus prévisible.

Cependant, on constate rapidement que cette méthode de gestion permet d’accomplir certaines actions prioritaires à une cadence énormément plus élevée qu’à la normale, et semble donc potentiellement plus souple.

Pour en avoir discuté par la suite avec la personne qui nous faisait cette présentation, cette méthode est particulièrement adaptée dans les cas où l’agilité serait mal perçue, et permettrait d’effectuer une transition en douceur.

Piqué au vif, je tâcherais donc d’en savoir plus prochainement à ce sujet.

Et un carpaccio ! Un ! (par Géry Derbier)

Rencontrant parfois des problèmes de découpage de tâches avec certains clients, j’ai voulu essayer de voir si cet interlocuteur n’avait pas par hasard la solution miracle. Eh bien non !

La séance consistait à découper une problème très simple : le calcul du prix total en appliquant une ristourne fonction du montant total de la commande et en appliquant des taxes fonction de la région géographique.

La séance était constituée de 5 itérations de 8 minutes. A la fin de chaque itération, il fallait montrer une nouvelle fonctionnalité développée.

Autant dire que le timing était serré, d’autant plus que j’ai voulu, comme à mon habitude dans ce genre de cas partir sur une approche en TDD. Ceci dit notre groupe s’en est aussi bien sorti que les autres au final : les tests en plus !

Projet dont vous êtes le héros (par Antoine Vernois et Pablo Pernot)

Autant le dire tout de suite, c’était là mon gros coup de cœur de la journée. Je me suis régalé.

3 ballons étaient disposés dans la salle et notre groupe devait répondre à des questions liées à l’agilité en se rapprochant de l’un des 3 fonction des questions posées.

Les questions étaient assez ambiguës pour que des doutes se posent et que chaque réponse puisse sembler valable à certains.

Une petite discussion s’installait du coup sur les résultats. Si la majorité des personnes s’était trompée, on procédait à une épreuve subsidiaire (des petits jeux agiles).

Nous évoluions ensuite sur une carte en choisissant notre prochaine destination.

Le contexte était sympa, les questions pas mal tournées et souvent drôles, les discussions intéressantes et les jeux instructifs, un vrai régal !

Je ne saurais que vous conseiller d’aller jeter un coup d’œil sur le site du jeu

Cependant, si vous comptez assister à cet atelier lors d’un prochain atelier, évitez.

Agile Unlimited (par Alexandre Boutin)

J’avais adoré les présentations d’Alexandre Boutin l’an dernier et attendais donc avec impatience sa note de clôture. Ses slides tournaient cette fois-ci autour de l’univers de Star Trek et traitaient de l’application possible des méthodes Agiles à d’autres domaines que l’informatique. Effectivement, on peut reprendre les concepts suivants assez facilement :

• le Management Visuel à grands coups de Post-It
• le stand up d’équipe
• la rétrospective
• la Vision Partagée
• l’Ordonnancement
• les Boîtes de Temps (le fait de borner le temps alloué aux réunions et de filtrer les participants utiles)

Cependant, de nombreux freins se lèvent au sujet de cette adoption :

• les REX personnels
• la tolérance à l’erreur dans certains domaines
• le Command & Execute
• les problèmes de Communication
• la Visibilité (certaines personnes n’ont pas forcément envie que ce qu’ils font comme travail soit plus transparent)
• l’Autonomie (certains préfèrent travailler seuls)
• le Travail Répétitif

Le point principal abordé par Alexandre et sur lequel il a le plus insisté est qu’on ne peut pas faire d’agilité si la culture de l’entreprise ne s’y prête pas. L’agilité est une histoire de culture et nécessite bien souvent un changement de culture, qui est un processus particulièrement difficile.

Ainsi s’achève mon deuxième Agile Tour Toulouse. N’hésitez surtout pas à me demander des précisions !

Le but de cet article n’est pas d’identifier toutes les sources possibles de conflit de classloading, mais d’expliquer les différences de fonctionnement de classloading entre JBoss EAP 5 (ou A.S. 5) par rapport à JBoss EAP 6 (ou A.S. 7).

1. Présentation rapide du concept
Un chargeur de classes (classloader) représente typiquement un ensemble de jars composant un module, un composant ou une application. Chaque classloader possède un classloader parent. De fait, les classloaders forment une hiérarchie arborescente avec le classloader de démarrage (bootstrap) à son sommet. Lorsqu’un classloader charge une classe, il peut d’abord demander à son parent de charger celle-ci. Si le parent ne réussit pas à charger la classe, ce classloader essaie alors de charger la classe. Dans ce scénario appelé « parent-first class loading », les classes communes sont toujours chargées par le classloader parent. Ceci permet à une application ou à un module de communiquer avec une autre application ou un autre module à l’intérieur de la même VM. Une alternative est de demander à un classloader de trouver lui-même une classe, puis s’il échoue de demander à son parent. Cette stratégie permet à une application d’avoir une version d’une classe différente de celle trouvée dans le classloader de son parent. Cependant, il est parfois nécessaire de modifier la séquence de chargement par défaut, ou bien d’isoler les classes à l’aide de classloaders distincts afin de résoudre des problèmes de déploiement. Le problème le plus courant étant un conflit de version d’une librairie entre celle incluse dans l’applicatif et celle du serveur. Les exceptions suivantes sont les plus courantes lors de problème de classloading avec JBoss EAP 5 : ClassCastException, IllegalAccessError, VerifyError ou LinkageError.

2. Classloading en EAP 5
Le classloading en EAP 5 est basé sur un modèle hiérarchique.

Cette approche soulève les problèmes suivants :
• Tous les JAR sont toujours chargés, utilisés ou non ;
• Conflits de version ;
• Temps de lookup et de chargement élevé ;
• Difficile d’identifier la source des problèmes.

Différentes résolutions de problèmes de classloader sont possibles avec JBoss 5 :
• Identifier les JARs coupables et les supprimer si c’est possible ;
• Isoler les classloaders. Ceci implique les changements suivants :
• Pour un WAR : commenter l’élément WarClassLoaderDeployer dans le fichier $JBOSS_HOME/server/<ma_config>/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml
• Pour un EAR : affecter la valeur true au flag isolated (dont la valeur par défaut est false) situé dans l’élément EARClassLoaderDeployer du fichier $JBOSS_HOME/server/<ma_config>/deployers/ear-deployer-jboss-beans.xml.
• Définir un fichier WEB-INF/jboss-classloading.xml qui est à déployer avec l’application et permettant de définir la stratégie à utiliser pour le chargement des classes de l’application.

3. Classloading en EAP 6
Le principe de chargement des classes pour JBoss EAP 6 / JBoss A.S. 7 est radicalement différent de JBoss 5 et est désormais basé sur le principe de modules. Ses particularités sont les suivantes :
• Chaque application déployée est un module isolé des autres ;
• Les modules applicatifs n’ont pas de visibilité des modules du serveur et vice versa ;
• Les modules doivent déclarer explicitement leurs dépendances aux autres modules.

Distinction WAR/EAR :
• Pour les WARs : un WAR est considéré comme un module simple et les classes définies dans WEB-INF/lib sont traitées de la même façon que celles sous WEB-INF/classes. Toutes les classes packagées dans le WAR seront chargées par le même chargeur de classes.
• Pour les EARs : le déploiement de fichiers .ear correspond à un déploiement multi-module, c’est-à-dire que toutes les classes à l’intérieur d’un EAR ne seront pas forcément visibles depuis les autres classes de ce même EAR, sauf si des dépendances explicites sont définies. Par défaut, le répertoire EAR/lib correspond à un module simple, et chaque WAR ou EJB est déployé en tant que module distinct. Ces WAR ou EJB ont toujours une dépendance avec le module parent ce qui leur donne accès aux classes situées dans EAR/lib, mais n’ont néanmoins pas toujours une dépendance automatique les uns par rapport aux autres. Ce comportement peut être contrôlé à l’aide du paramètre ear-subdeployments-isolated situé dans la configuration du sous-système ee (par exemple dans le fichier standalone.xml dans le cas d’une utilisation en mode standalone) :
<subsystem xmlns=”urn:jboss:domain:ee:1.0″ >
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
</subsystem>
La valeur false par défaut permet aux sous-déploiements (c’est-à-dire aux WARs et EJBs) de voir les classes appartenant aux autres sous-déploiements du même EAR.

Exemple : pour le EAR suivant :
myapp.ear
|
|— web.war
|
|— ejb1.jar
|
|— ejb2.jar
Si la valeur de ear-subdeployments-isolated est à false, alors les classes dans web.war ont accès aux classes situées dans ejb1.jar et ejb2.jar. De même, les classes dans ejb1.jar ont accès aux classes de ejb2.jar (et réciproquement).
Si la valeur de ear-subdeployments-isolated est à true, alors il n’y a pas d’ajout de dépendance de modules mise en place automatiquement : l’utilisateur doit définir manuellement les dépendances :
• soit dans le fichier de manifeste (section Class-Path). L’avantage de cette solution est la portabilité : la spécification Java EE précise que les applications portables ne devraient pas se baser sur le fait que des sous-déploiements peuvent accéder à d’autres sous-déploiements sauf si une entrée Class-Path est explicitement définie dans le fichier MANIFEST.MF.
• soit en définissant de façon explicite les dépendances aux différents modules (fichiers module.xml de chaque module en question). L’avantage de cette méthode est d’avoir une gamme d’options plus larges, ainsi que de pouvoir référencer des modules qui ne sont pas packagés dans l’application.
• soit dans un fichier jboss-deployment-structure.xml spécifique à JBoss et inclus à l’application. L’avantage de cette approche est de permettre de définir les dépendances dans un seul fichier.

Priorités de chargement de classes :
Le serveur se base sur les priorités suivantes lors du chargement des classes afin d’éviter des conflits :
• Les dépendances système chargées automatiquement (y compris les APIs Java EE)
• Les dépendances déclarées explicitement par l’utilisateur, soit dans le fichier de manifeste, soit dans le fichier jboss-deployment-structure.xml.
• Les librairies packagées avec l’application (classes sous WEB-INF/classes ou .jar sous WEB-INF/lib).
• Les dépendances inter-modules.

Voici un modeste retour d’expérience chez un client (appelons le “S.”) qui peut vous intéresser si votre projet comporte des tests automatiques pour lesquels il n’existe aucun framework. Cela peut arriver lorsque les tests sont écrits avec des langages exotiques ou “faits maison” comme c’est le cas chez S. :
L’exploitation des résultats de tests se faisait jusqu’à maintenant par des rapports de sortie de test au format texte, dans lesquels il fallait faire une recherche manuelle sur le mot clef “error”, un bon vieux “grep” en quelque sorte… méthode rudimentaire et efficace mais qui peut commencer à poser des problèmes pratiques lorsque le nombre de tests devient important.

Pour bénéficier de la plus-value des outils existants comme Ant ou Jenkins, il suffit de rajouter en sortie de chaque test automatique un fichier XML qui respecte le format JUnit.
Si, de plus, vos tests sont classés dans une structure hiérarchique de type “arbre”, vous pouvez réutiliser les noms des niveaux de hiérarchie en lieu et place des packages Java utilisés par JUnit dans ces fichiers XML.
Par exemple :
Ma_campagne_de_tests\mon_domaine_fonctionnel_n1\mon_test_1
Ma_campagne_de_tests\mon_domaine_fonctionnel_n1\mon_test_2
Ma_campagne_de_tests\mon_domaine_fonctionnel_n2\mon_test_1
Ma_campagne_de_tests\mon_domaine_fonctionnel_n2\mon_test_2

Une fois que ces fichiers XML sont générés, il suffit d’appeler la tâche <junitreport> dans un script Ant pour générer à partir de ces fichiers un rapport synthétique au format HTML, avec navigation entre packages et sous-packages.
Ca marche bien, mais par défaut, la tâche <junitreport> génère un rapport orienté JUnit (on ne saurait lui en vouloir), avec des libellés tels que : “Designed for use with JUnit”.
Pour corriger ce genre de détails, on peut fournir en entrée de la tâche ant un fichier .xsl adapté au contexte, en utilisant le paramètre styledir de <junitreport>. Pour tout savoir sur junitreport et styledir : http://ant.apache.org/manual/Tasks/junitreport.html

Et pour ne pas tout réecrire, on peut prendre comme modèle le fichier .xsl de Ant qu’on peut trouver ici : ...\apache-ant-1.8.4\etc\junit-frames.xsl (ou ...\apache-ant-1.8.4\etc\junit-noframes.xsl selon le cas)

Et voilà : Arrivé à ce niveau, on dispose d’une tâche Ant capable de générer un rapport de tests HTML structuré, synthétique et personnalisable, lisible par un non-informaticien et qui nous permet d’oublier notre grep initial.

Et pour jenkins alors ? Il faut réussir à écrire un script qui passe les tests et qui place les fichiers XML de sortie de ces tests dans un Workspace Jenkins, et ça suffit : Jenkins appelle ce script régulièrement, et se débrouille tout seul pour analyser chaque série de résultats, pour la comparer avec les résultats précédents, et tracer les courbes qui vont bien, comme l’évolution du nombre de tests “OK” ou de tests  “KO” dans le temps.
On dispose alors d’un historique sur les résultats des tests automatiques, ce qui permet de cibler, par exemple, quelle modification du code a entraîné une régression, pour peu qu’on passe régulièrement tous les tests.

NOTE : Je n’ai pas trouvé de documentation sur le format exact utilisé par Ant pour les fichiers XML en sortie de tests Junit : cependant, il suffit d’écrire un test Junit trivial en Java, et de le passer via la tâche <junit> d’un script Ant, on dipose alors de fichiers qu’on peut facilement utiliser comme modèles.

• Convaincus, par nos expériences,
• Convaincus, parce que la communauté nous en fait l’écho.

Mais parfois, un simple besoin utilisateur peut engendrer de petites déceptions …

J’ai la chance de participer à un projet qui met en œuvre le fleuron de la technologie Java :
EJB 3.1, Context and Dependency Injection,  JSF2, et j’en passe, tout ça sur une plateforme JBoss AS 6.1 Final.
Bref, tout pour être heureux.

Architecte en charge l’intégration de briques technologiques dans le projet et actuellement sur la conception d’un moteur d’exécution de traitements batchs, je lorgnais déjà depuis quelques temps sur cette nouvelle annotation @Asynchronous, introduite avec EJB 3.1.

Celle-ci permet d’indiquer que l’exécution d’un service EJB doit se faire de manière asynchrone. Elle permet surtout d’obtenir en retour immédiat un Future (http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Future.html) qui donne la main sur le thread d’exécution du service.

Très intéressant dans mon cas puisque les traitements exécutés sur le moteur peuvent prendre un certain temps et que l’Utilisateur, dans sa grande sagesse, a exprimé le besoin de pouvoir arrêter l’exécution du traitement à tout instant.

Et jusqu’à présent, avec les EJB, ça n’était pas possible ! Tout le monde sait que jouer avec les threads instanciés par le serveur JEE, c’est mal. Jamais personne n’oserait killer le thread d’exécution d’un EJB, en tout cas pas sans avoir conscience des conséquences irréversibles que cela peut avoir sur l’état du serveur… Une fois un service invoquer, on avait jusqu’alors qu’à attendre qu’il aboutisse.

Enfin j’allais pouvoir killer un service EJB, le rêve. Formulé de façon plus diplomatique, enfin il était possible d’arrêter proprement un service en cours d’exécution.

Pour illustrer, voilà à quoi peut ressembler l’implémentation d’un service asynchrone :

@Stateless
public class MonService {
@Asynchronous
public Future<String> faireQuelqueChoseDeTresTresLong()  {
thread.sleep(10000000); //très très long
String result = "j'ai bien dormi";
return new AsyncResult<String>(result);
}
}


Génial, avec ça je peux donc très simplement arrêter l’exécution de mon service quand je le souhaite par un appel à cancel(boolean) sur mon Future, dont j’ai conservé au chaud la référence.

Ca devrait fonctionner, les spécifications JEE6 sont formelles, mais malheureusement, ça ne fonctionne pas. L’appel à cancel reste sans effet…

Je cherche donc dans mon moteur de recherche préféré à voir si je me suis loupé quelque part, s’il y a  une subtilité qui m’aurait échappé, si c’est un problème connu de JBoss 6, …

Et quelle n’est pas ma surprise de lire (https://community.jboss.org/thread/177433#647108):

“@Asynchronous support in AS 6.x was not fully completed. I would recommend that you use AS 7.1.x and report any issues that you encounter. AS7 has fully functional @Asynchronous feature.”

Je comprends pas… pour moi il est évident que JBoss 6 est certifié JEE6, c’est justement là-dessus que se base sa réputation : le 1er serveur JEE OpenSource certifié ! Et là j’apprends qu’une fonctionnalité telle que les EJB asynchrone, présentée comme une des grosses améliorations de JEE6, n’est pas supportée ?!

Et bien effectivement, difficile à croire mais JBoss 6 n’est pas “Full Java EE 6 Certified”, mais uniquement “Java EE 6 Web Profile Certified” et ça fait une grosse différence !

Je vous laisse lire https://community.jboss.org/thread/160813 et https://community.jboss.org/thread/162247, discussions enflammées pour mieux comprendre le pourquoi du comment. Et aussi le résultat d’une enquête sur les attentes concernant la certification de JBoss exprimées par la communauté et les utilisateurs http://blog.webagesolutions.com/archives/357

D’où ma déception : JBoss 6 n’est pas “Full Java EE 6 Certified”  …. c’est a savoir !!!

Je ne suis bien évidemment pas le seul à être surpris de l’apprendre ; Je fais quoi moi maintenant ? Je passe en version 7…?

PS : tout est parti du dernier Java Magazine de Juillet-Août 2012, avec un article très intéressant sur le threading et la concurrence en JEE6, je vous laisse apprécier : http://www.oraclejavamagazine-digital.com/javamagazine/20120708/?pg=59&pm=1&u1=friend#pg59