insideIT.fr : le blog des architectes IT de SFEIR

Jug Summer Camp 2012

Nicolas FRANCOIS — Fri, 17 Aug 2012 17:12:00 +0200

C'est le 14 septembre qu'aura lieu la 3ème édition du Jug Summer Camp. Le Jug Summer Camp, qu'est ce que c'est ? C'est la conférence autour de java (mais pas seulement) de la rentrée. Si vous voulez profiter des derniers rayons de soleil à La Rochelle tout en venant parfaire vos connaissances technique, c'est le lieu idéal.

Le planning vient d'être terminé et est disponible ici.

Pour cette année, je vous recommande 2 sessions qui seront présentées par des Sférien(ne)s :

La Dartologie, découverte du langage Dart (Nicolas François et Guillaume Girou) : Premier aperçu du langage Dart de Google, adapté aux applications web modernes. Présentation des fonctionnalités principales du langage, live coding et démo.
Programatoo pour les grands : how your kid can code ? (Audrey Neveu et Ludovic Borie) : Les geeks sont de grands enfants, c’est bien connu. Il n’y a qu’à voir leur passion pour les Lego et autres robots en tout genre pour s’en convaincre. Mais les geeks d’aujourd’hui sont aussi des papas et des mamans ! Ces mêmes parents ont du découvrir la programmation par eux-même, à l’école ou à la maison, au travers d’ateliers, de clubs, de magazines, etc… Mais aujourd’hui, alors que l’ordinateur est omniprésent dans notre environnement, et apprivoisé par le plus grand nombre, nous nous apercevons que la programmation n’est toujours qu’une science destinée uniquement à ceux qui ont envie d’aller plus loin dans l’informatique... Comment faire comprendre à votre enfant votre passion pour l’informatique et pour votre métier ? Comment lui montrer que tout ce qui est pour lui totalement naturel (facebook, youtube, google, word, …) est en fait le résultat du travail de personnes comme nous ? Comment lui donner envie de prendre le contrôle de son ordinateur, cette machine qui lui est si familière et à laquelle on ne prend pas toujours la peine de l’initier correctement ? Cette session “pour les grands” sera pour nous l’occasion de vous partager nos retours d’expériences, de faire un tour d’horizon des outils existants avec démos et enfin de vous présenter les initiatives déjà existantes. Que vous ayez simplement envie de partager votre passion avec votre (vos) enfant(s) ou que vous souhaitiez allez plus loin et monter des ateliers, cette session est pour vous !

Il reste encore quelques places pour vous y inscrire.

Si les sujets dart et programatoo vous intéresse, n'hésitez pas à cercler nos pages Google+ :

GWT 2.5 : Premiers pas avec le «Super Dev Mode»

Mohamed Abdennebi — Thu, 12 Jul 2012 17:07:00 +0200

Parmi les nouveautés majeures de la version 2.5 de GWT figure le «Super Dev Mode». Le Super Dev Mode est en effet qualifié de majeur, car il a pour but d'améliorer la productivité des développeurs en offrant une alternative au «Dev Mode classique» qui, avouons-le, est contraignant (installation obligatoire de plug-in dans le navigateur), lent et consommateur en mémoire lorsque le code de l'application atteint une taille importante.

Contrairement à ce que l'on pourrait penser, le Super Dev Mode n'est pas un Dev Mode amélioré. En effet :

Dans le Dev Mode l'exécution de l'IHM est distribuée entre la JVM (qui exécute le code Java) et le navigateur (qui exécute le code JavaScript présent dans les méthodes JSNI). La communication entre le code Java et le code JavaScript se fait à l'aide d'un protocole basé sur les messages utilisant une connexion TCP sur le port 9997. Cela génère beaucoup d'aller-retour entre la JVM et le navigateur.
Dans le Super Dev Mode l'IHM ne tourne pas dans une JVM, elle est compilée en mode «Super Draft» sans aucune optimisation. C'est du JavaScript pure. Cela veut dire qu'il n'y plus d'échange verbeux entre la JVM et le navigateur. En revanche, il n'est plus possible de déboguer dans votre IDE préféré, vous le ferez cette fois-ci dans votre navigateur préféré et toujours en Java !

Pour plus de détails sur les différences, je vous invite à consulter l'article de Google Introducing Super Dev Mode.

En résumé, le Super Dev Mode vous permet de compiler et de tester rapidement votre code. Il vous permet, comme dit plus haut, de déboguer et d'inspecter votre code Java directement dans le navigateur si vous utilisez Chrome (Chrome utilise une technique magique appelée Source Maps. Chez Mozilla on est à pied d’œuvre pour l'implémenter dans Firefox).

Nous allons donc vous présenter le Super Dev Mode à l'aide d'un exemple simple. Le tutoriel sera divisé en deux parties : la première concerne le lancement et l'utilisation du Super Dev Mode. La seconde concerne quant à elle le débogage du code Java directement dans le navigateur.

Avertissement:

Ce tutoriel a été réalisé avec la version RC1, il est possible de constater des différences avec la version finale. Il sera éventuellement mis à jour à la sortie de la version finale.
Nous n'expliquerons pas le fonctionnement interne du Super Dev Mode. Un article complet sur le sujet a déjà été publié par Thomas Broyer (contributeur et membre du comité de pilotage du projet open source GWT).
Étant un utilisateur d'Eclipse, j'ai réalisé ce tutoriel avec cet outil. Les principes expliqués dans cet article devraient s'appliquer à n'importe quelle autre IDE.

Partie 1 : Lancement du Super Dev Mode

Avant de commencer, assurez-vous de disposer d'un environnement de développement composé de :

Java 6
Eclipse avec Google Plugin for Eclipse.
Google Chrome si vous voulez expérimenter le débogage Java dans le navigateur (si vous n'avez pas la possibilité de l'installer, la version portable est disponible ici)

Pour illustrer le Super Dev Mode, nous allons nous servir de l'application exemple fournie par GPE (Google Plugin for Eclipse). Préparons d'abord l'environnement de développement :

1 Installez le SDK 2.5 :

Récupérez le version 2.5-rc1 du SDK à cette adresse : http://google-web-toolkit.googlecode.com/files/gwt-2.5.0.rc1.zip
Lancez Eclipse, ouvrez les préférences puis allez dans rubrique « Google > Webtoolkit » pour ajoutez le nouveau SDK.

2 Créez une nouvelle application GWT

Créez une nouvelle application GWT, nommez-la Hello et choisissez comme nom de package hello.
Assurez-vous d'avoir sélectionné le SDK 2.5.0
Décochez "Use Google App Engine"

(cliquez sur l'image pour l'agrandir)

3 Lancez l'application avec le Dev Mode «classique» ou avec n'importe quel Servlet Container

Exécutez l'application avec le Dev Mode « Run As -> Web Application ». Nous utiliserons plus tard l'URL qui est affichée : http://127.0.0.1:8888/Hello.html?gwt.codesvr=127.0.0.1:9997.

Le Dev Mode n'est pas obligatoire nous l'employons juste pour exécuter la partie serveur de l'application. Cela veut dire que vous pouvez utiliser votre serveur habituel, par exemple Tomcat ou Jetty.

4 Préparez le module GWT

Comme vous allez le voir plus loin, le Super Dev Mode est un petit programme serveur qui écoute les demandes de compilation et envoie le résultat sur le port 9876. Ainsi, dans ce mode les ressources statiques sont servies par un serveur autre que le serveur hébergeant les services RPC et la Host Page. Ce scénario est prévu par GWT, mais demande l'utilisation d'un linker spécial nommé xsiframe.

Ceci n'est pas suffisant, il faut que le bootstrap (hello.nocache.js) appel l'autre bootstrap se trouvant sur le serveur du Super Dev Mode c'est-à-dire http://localhost:9876/hello/hello.nocache.js. Ceci est possible en activant la propriété devModeRedirectEnabled.

En résumé, ajoutez au fichier de configuration du module (Hello.gwt.xml) les deux lignes suivantes :

<add-linker name="xsiframe"/>
<set-configuration-property name="devModeRedirectEnabled" value="true"/>

5 Lancez le Super Dev Mode

Pour l'instant GPE ne supporte pas le Super Dev Mode, nous allons donc le lancer manuellement en créant un Launcher Eclipse :

Lancez «Run Configurations», sélectionnez le type «Java Application».
Donnez lui le nom «Hello SuperDevMode» et renseignez les paramètres suivants avec les valeurs correspondantes :
- Projet : Hello
- Main class : com.google.gwt.dev.codeserver.CodeServer (c'est la classe du serveur qui va écouter sur le port 9786)
Nous devons spécifier à la classe CodeServer le répertoire source ainsi que le nom du module. Dans l'onglet «Arguments» ajoutez au champ «Program Arguments» ce qui suit : -src src/ -workDir workdir/ hello.Hello
Dans l'onglet Classpath ajouter le jar externe gwt-codeserver.jar (il se trouve à la racine du répertoire d'installation du SDK).
Vous pouvez lancer maintenant le Super Dev Mode

Voici une capture d'écran de la sortie du CodeServer. Remarquez le message encadré :

Allez à l'adresse indiquée et suivez la procédure décrite dans la page affichée.

(cliquez sur l'image pour l'agrandir)

1 . Ajouter les deux bookmarklets à votre barre de favoris (Dans la plupart des navigateurs la barre n'est pas affichée, affichez là et glissez-déposez les deux liens dans la barre)

2 - Attention, le message "Visit a web page that use one of these modules : hello" est un peu trompeur, car il nous incite à cliquer sur le nom du module (hello). Ce n'est pas ce lien qu'il faut ouvrir mais plutôt l'URL fournie par le DevMode classique (sans le suffixe) ou par votre servlet container :

http://127.0.0.1:8888/Hello.html

Le lien sur le nom du module vous permet de voir ce qui a été généré ainsi que les messages du compilateur.

(cliquez sur l'image pour l'agrandir)

Cliquez sur maintenant sur la bookmarklet Dev Mode On. Une boite de dialogue s'affiche vous invitant à compiler le module «hello». Vous pouvez à n'importe quel moment désactiver le Super Dev Mode en cliquant sur la bookmarklet Dev Mode Off.

(cliquez sur l'image pour l'agrandir)

Partie 2 : Déboguez le code source Java directement dans Chrome :

Pour cette partie vous êtes obligés d'utiliser Chrome, car il est pour l'instant le seul à supporter le Source Maps.

Qu'est-ce le Source Maps

En production, le code JavaScript est souvent obfusqué et compressé. Ce code est quasiment impossible à déboguer. Le Source Maps est une technique qui permet de rendre cela possible en déboguant directement le code d'origine (grâce à des mappings de source), ce code d'origine peut être du JavaScript, du CoffeScript, du Java (notre cas) ou tout autre langage. Le Souce Maps ne concerne pas uniquement le débogage, il conccerne aussi les messages d'erreurs CSS et JavaScript, les logs, la StackTrace, etc.

1 - Ouvrez Chrome et activez le source maps : Affichez les «Outils de développement» en utilisant le combinaison de touches Ctrl+Shift+I. Affichez ensuite les paramètres en cliquant sur l’icône située en bas à droite de la fenêtre :

(cliquez sur l'image pour l'agrandir)

Allez maintenant dans l'onglet Scripts, dans l'explorateur de scripts (à gauche) vous devriez voir tous les sources utilisées par votre IHM (y compris ceux générées). Vous pouvez maintenant poser des points d'arrêt, inspecter la valeur de variables, voir la stack d'exécution, etc.

Happy Debugging !

Liens et références utilisées dans cet article

GWT 2.5 RC1 : Release notes, release notes détaillée et liste de bugs fixes.

How does GWT's Super Dev Mode work ? par Thomas Broyer

Introducing Super Dev Mode par Google

Introduction to JavaScript Source Maps par Ryan Seddon.

Programmation GWT 2 : Sous le capot de GWT par Sami Jaber

Conception du DevMode : Out of Process Hosted Mode par Google

Duchess France fête ses deux ans le 30 mai !

Audrey — Mon, 21 May 2012 12:18:00 +0200

Duchess France fêtera son deuxième anniversaire le 30 mai prochain à l’ECE, à partir de 19h30 : l’occasion pour vous si vous ne connaissez pas encore le groupe de venir rencontrer l’équipe et surtout de vous amuser autour d’une nouvelle édition du Trivial Java !

Le Trivial Java, qu’est ce c’est que ça ??

Le Trivial Java c’est un jeu machiavélique inventé et réalisé par les Duchess durant lequel des équipes de courageux gladiateurs-développeurs s’affrontent entre eux autour de questions sur Java, son écosystème, les Duchess et tous les sujets qui peuvent préoccuper le geek actuel. La bataille est rude mais la victoire vous assure gloire et respect à vie.

Une soirée pour filles ?

C’est une soirée Duchess donc bien sûr … que non ! Comme pour toutes les soirées Duchess, il n’y a qu’un seul critère d’entrée : être développeur et fier de l’être ! Néanmoins si vous avez dans votre entourage des collègues féminines qui ne connaissent pas encore Duchess, c’est une excellente occasion de leur montrer que nous ne sommes pas un groupe féministe qui organisons d’obscures soirées militantes pour la domination du monde par les femmes, mais bel et bien un groupe de geekettes uniquement préoccupées par la qualité de notre code et la domination du monde par les développeurs en général, pas que les développeuses :D

Que dois je faire pour venir ?

Une seule chose, vous inscrire ici et apporter votre bonne humeur le 30. Facile non ?

java #duchess #france #soirée #anniversaire

Programatoo, de retour de Devoxx France

Audrey — Thu, 03 May 2012 13:21:00 +0200

Après une première session début mars dans ses locaux Sfeiriens, l’équipe Programatoo s’était lancé un véritable défi : proposer une session pour les enfants à Devoxx France. L’idée avait séduit... Il restait alors à être à la hauteur des espérances !

L’idée était simple : regrouper des parents et des enfants pour découvrir la programmation ensemble le temps d’un atelier type “Lab” de trois heures. L’objectif : découvrir, jouer, et pour les organisateurs, transmettre la passion de la programmation et l’envie d’apprendre.

En arrivant à Devoxx le mercredi matin, au milieu des parents déjà en plein “networking” au petit déjeûner, on pouvait donc croiser des petits êtres impressionnés et prêts à apprendre comme papa ou maman. La petite salle se remplit doucement, on s’installe, et plusieurs parents dont les enfants n’ont pas pu venir ont déjà quelques regrets en voyant les yeux émerveillés des petits geeks. Il y avait de quoi subsister dans la salle : des gâteaux, des bonbons, des jus de fruits... Ah oui, parce que d’accord on travaille, mais on est là pour en profiter !

On commence par une petite présentation de tout le monde, puis on fait le tour des outils que l’on va utiliser (Scratch et Smallbasic pour cette fois). En bons successeurs des participants à Devoxx, quelques uns ont déjà manipulé un peu ; ce sera l’occasion d’aller plus loin cette fois, il y en a pour tous les goûts et tous les niveaux. La matinée sera entrecoupée de démos, afin que chacun puisse montrer aux autres ce qu’il a fait et appris.

Les adultes qui participent aux autres sessions passent tout au long de la matinée pour voir les créations des enfants, récupèrent la liste des outils utilisés et planifient d’essayer en rentrant à la maison, avec leur fils ou fille.

Programatoo se termine avec une rétrospective, ou chacun, parent et enfant, peut dire ce qu’il en a pensé. Des mots retenus : Super, trop bien, parfois un peu difficile, mais vivement une prochaine fois !

En tout cas les objectifs sont atteints : des enfants ont poussé la porte de Devoxx et on pu voir ce que c’était, des parents vont commencer ou continuer à découvrir avec leurs enfants, l’envie d’apprendre à programmer va se diffuser un peu plus ; alors l’équipe Programatoo part l’esprit léger, avec plein de nouveaux défis à relever en tête. Affaire à suivre...

Sfeir Programatoo à Devoxx France !

Audrey — Wed, 11 Apr 2012 12:04:00 +0200

Devoxx France approche et avec lui la première session Programatoo ouverte au public ! Pour rappel la session aura lieu le mercredi 18 avril de 9h30 à 12h30.

Programatoo qu’est ce que c’est ?

C’est un atelier pour les papas et mamans geeks qui souhaitent faire découvrir leur métier à leurs enfants, tout en s’amusant ! On code, on partage, on goûte et on découvre qu’un ordinateur ne se limite pas à youtube et angry birds, on peut le contrôler, on peut lui faire faire des choses, et on peut même être créatif !

Et concrétement, comment ça se passe ?

D’abord nous sommes là pour nous amuser, donc chaque enfant est libre de travailler sur ce qui lui plait et de changer en cours de route si une autre idée lui passe par la tête. Seul, avec le parent qui l’accompagne, à deux, trois, quatre … peu importe ! L’essentiel est de se faire plaisir, d’apprendre des choses mais en passant un bon moment.

Ensuite nous sommes là pour partager, c’est pourquoi par deux fois, nous ferons une petite pause, pour partager tous ensemble nos créations. On pose les souris, on lache les claviers, on branche le rétro projecteur et chaque enfant peut faire découvrir aux autres son projet, ce qu’il avait envie de faire, de raconter … C’est un moment essentiel car très valorisateur pour l’enfant et très motivant pour l’ensemble des participants.

Mais comme finalement nous sommes surtout là pour nous amuser, il y a aussi un goûter :) Bonbons, gâteaux et jus de fruits seront là toute la matinée pour donner à nos développeurs en herbe l’énergie nécessaire pour coder !!!

De quoi va t'on se servir ?

L’apprentissage de la programmation aux enfants est un sujet qui passionne beaucoup de gens, ce qui nous permet d’avoir des outils très variés à notre disposition.

Le plus populaire d’entre eux est certainement Scratch qui permet de faire rapidement de petites animations en intervenant sur les évènements (clic, interactions entre objets, etc …) mais aussi d’intégrer des élèments personnalisés par les enfants, ce qui leur permet de s’approprier totalement l’outil : ils peuvent inclure des images de personnage qu’ils aiment, des dessins qu’ils ont fait, des sons qu’ils enregistrent ou téléchargent etc …

D’autres outils tels que Microsoft Small Basic (un Turbo Basic simplifié), Robozzle (un jeu conçu pour s’initier aux enchaînements d’instructions), TortueScript (un Logo en HTML5 développé par Salvador Diaz) seront à disposition, afin de proposer à chacun de choisir dans quelle direction aller, ludique ou plus proche de l’écriture de code, selon ses envies.

Quelles sont les conditions pour participer ?

Pour participer, votre enfant doit être agé de 6 à 14 ans. Votre conjoint(e) et vous êtes les heureux parents de triplés ? Pas de soucis, vous pouvez tous les amener, dans la limite des places disponibles bien sûr :)

Les seules choses dont vous aurez besoin sont un ordinateur et un pass Devoxx : aucune connaissance des outils proposés n’est nécessaire car nous serons là en appui pendant toute la session pour vous aider dans la réalisation.

Si vous souhaitez participer, il ne vous reste qu'à nous envoyer un mail à programatoo@sfeir.com avec le nom et l'âge de votre enfant. Vous pouvez également nous contacter à cette même adresse si vous souhaitez avoir plus d'information.

Noël dans les nuages !

Patrice — Mon, 30 Jan 2012 15:57:00 +0100

Ou comment Google App Engine, permet de mettre en place un service supportant une très grosse charge dans un temps très court.

Le projet

L'Église Catholique propose depuis plus de 10 ans un site internet pour chercher les horaires de messes dans toute la France, qui souffrait historiquement d'un problème majeur : le trafic quotidien est raisonnable (environ 1 000 visites par jours, et des pointes à 5 000 visites le WE) mais le site doit faire face à d’importants pics de trafic à Noël et durant la semaine de Pâques.

Or les années précédentes, l'ancien site (messesinfo.catholique.fr), développé en PHP/MySQL, ne tenait pas la charge lors de ces pics, s'écroulant sous les demandes des visiteurs. La technologie utilisée était tout à fait suffisante pour les besoins courants du site, cependant pour répondre à la forte charge sans changer de projet, il aurait fallu, soit disposer d’un serveur plus puissant, soit mettre en place du load balancing entre plusieurs serveurs. Dans les deux cas, ce n'aurait pas été très flexible, obligeant à s’équiper d’un serveur sur-dimensionné, pour seulement 6 jours dans l'année !

Nouveau projet

Nous avons donc fait le choix de migrer vers une technologie permettant de gérer cette surcharge ponctuelle, en ne payant que ce qui est réellement consommé. La refonte du site, permet également d’outrepasser les limitations imposées par l'ancien système (messes en semaine, autres types de célébrations) et d'ajouter de nouvelles fonctionnalités (événements, apis, widget, …).

Notre choix c'est porté sur Google App Engine, par la simplicité de développement que celui-ci apporte, le dimensionnement automatique des serveurs, les quotas gratuits et le paiement à la consommation.

Le projet a démarré en octobre 2010, avec la création d'une simple interface de recherche développé en GWT sur Google App Engine, mais laquelle se connectait ensuite à l'ancien site pour récupérer les résultats de la recherche. Cette première version à été mise en ligne pour Noël 2010, mais les deux sites n'ont pas tenu le coup car la base de donnée n'a pas accepté le nombre très élevé de requêtes simultanées ! Nous ne pouvions pas mettre les données de la base de donnée MySQL directement sur Google App Engine, car déjà l'interface d'administration n'est pas encore refaite, et la base de donnée chez App Engine, ne fonctionne pas exactement de la même manière.

Pour la période de Pâques 2011, Google venait de sortir en test la base de donnée Google Cloud SQL qui permet d'avoir des bases de données MySQL directement sur Google App Engine. Nous avons ainsi développé un service qui recopie la base de l'ancien site, sur le nouveau. Le système a fonctionné, mais du fait de la nouveauté du service et du manque d'optimisation de notre part, les bases de données SQL ont régulièrement planté.

Noël 2011

EgliseInfo a relativement bien fonctionné pour Noël 2011, faisant face à une pointe de 1104 visiteurs simultané, et plus de 800 visiteurs en permanence durant toute l'après-midi, soit 100 000 visites en 3 jours.

Nous avons toutefois rencontré trois problèmes :

Vendredi soir vers 21h, nous avons dépassé le quota que nous avions fixé (25$), donc tous le site s’est retrouvé bloqué, le temps de changer et de mettre à 100$
Samedi matin, nous avons été limité par Google Cloud SQL a 100 requêtes simultanées. J'ai corrigé en faisait un balancing sur 2 bases SQL, et j'ai écrit un mail à Google : réponse dans la fin de l'après midi, ils ne peuvent pas modifier cette limite, et proposaient de passer à un serveur de plus grande capacité sans être vraiment sûr que cela résoudrait le problème : base de donnée plus grande, mais pas plus de connexion simultanées (cela changera plus tard), avec par ailleurs une interruption le temps de redémarrer le serveur. La double base de données a permis de réduire le nombre d'erreurs et de fournir une meilleure réactivité. Les responsables de Google SQL sont en train de tester avec notre jeu de données sur les requêtes les plus lentes.
Samedi 18h : EgliseInfo marchait toujours, mais les pubs ne s'affichait plus (un script PHP sur un serveur de la CEF) car le trop grand nombre de personnes sur tous les sites (le site de pub, messesinfo, les sites de paroisses et diocèses) à surchargé le firewall du datacenter où sont hébergés tout ces sites !

MessesInfo (Ancienne version du site fait en PHP, qui est encore référencé) redirigeait presque tous le trafic vers EgliseInfo, redirection javascript depuis la page de résultat MessesInfo (pouvait venir d'une recherche Google) vers la recherche correspondante sur EgliseInfo. Donc pas de plantage du côté de MessesInfo, et une forte charge sur EgliseInfo qui a bien fonctionné avec des temps de réponse acceptables (forcément plus lent qu'habituellement).

Google nous a mis en place automatiquement jusqu'à 400 serveurs disponibles (instances de l'application, qui sont virtualisées sur plusieurs serveurs réels).

Conclusion

En conclusion, Google App Engine a vraiment permis de gérer la très forte charge du site pour un coût tout à fait raisonnable. Pour les prochaines fois, il nous faudra mettre en place une répartition sur plusieurs bases de données, et dégrader les fonctionnalités pour accélérer les recherches.

Sfeir à Devoxx

Nicolas FRANCOIS — Wed, 30 Nov 2011 21:58:00 +0100

10 ans … Voilà 10 ans que vers cette période de l’année, plus de 3000 passionnés se réunissent à Anvers pour la plus grosse conférence autour de la plateforme java. Elle se découpe en 2 parties : université et conférence.
Pour moi, c’était ma 3ème participation. Par contre, cette fois ci, j'y suis allé pour la semaine complète avec mes collègues Vincent Bostoen et Benito d’Almeida. Les autres Sfeiriens, eux, nous ont rejoint le mercredi. Au total, 15 Sfeirens étaient présent. Même si nous sommes partis 2 jours avant les autres, nous avions tout de même le même point de rendez-vous avant le départ. Malgré une petite mésaventure dans les transports en commun Anversois, nous sommes arrivés à bon port au cinéma multiplexe où a lieu la conférence.
Cette année, gros changement dans l’organisation : au lieu d’un simple badge avec de petits tickets à échanger contre les repas, nous avons reçu un bracelet marqué de notre nom et d’un code barre. Heureusement, ce bracelet était waterproof car nous devions le garder au bras pendant la semaine entière.
C’est donc le mercredi qu’à la station de tramway nous avons rencontré nos autres collègues pour la 2ème partie de l’aventure : la conférence. Celle ci a commencé par l’habituelle keynote de Stephan Jansen, l’organisateur. Pour finir son discours, il nous a montré une vidéo. On y reconnaît quelques têtes connues : les organisateurs du Paris JUG... puis s’affiche “Devoxx France” … Et oui, au mois d’avril, nous aurons une conférence affiliée à Devoxx, ici à Paris, avec 75% des sessions en français. Sfeir est d’ailleurs sponsor de l’évènement.
Le retour s’est fait le vendredi après midi, après une semaine plutôt fatigante.

Mes impressions globales :

On sent vraiment que Google est partenaire : nous avons eu beaucoup de sessions autour d’Android et Html5.
Même chose en avec le duo Spring Source/Cloud Foundry
Les langages jvm ont du succès : Scala a eu droit à beaucoup de sessions et remplaçait même java pour des exemples de codes. Ceux un peu moins populaires : Fantom et Clojure ; et les petits nouveaux : Kotlin et Ceylon venaient se présenter.
Moins de sessions cloud que les années précédentes.
Plus d'animations aux stands : course de petites voitures sur circuit électrique, roulette de casino virtuelle, ...
Pas de grosses annonces (mis à part Devoxx France)
Comme toujours, beaucoup de monde.
De plus en plus de français.

Parmi les sessions qui m'ont le plus intéressé :

JAX-RS 2 qui disposera d'une (meilleure) intégration avec d'autres apis comme Bean Validation (JSR-303), et surtout d’une partie cliente.
MongoBD. Je l'avais récemment découvert pour un POC où je voulais stocker des données en ligne, la session m'a permis de mieux voir les possibilités qu'il offre.
Performance et usabilité Android : beaucoup de conseils divers de développement à ne pas oublier si l’on veut une application qui soit ergonomique et performante.
Android sur Google TV, même si on est loin d'avoir ces télévisions aussi répandues que des smartphones, il est tout de même intéressant de voir les enjeux et l'ergonomie.

Pour ceux qui n’ont pas pu venir et qui seraient intéressés pour revoir les sessions, ou pour ceux qui souhaitent voir certaines sessions qu’ils n'auraient pas pu voir : il y a Parleys. Ce site offre en effet la possibilité de revoir les sessions de Devoxx, mais aussi de certains jugs locaux. Les sessions Devoxx seront disponibles gratuitement pour ceux qui y ont participé, via abonnement pour les autres. Il faudra quand même patienter jusqu’à la fin de l'année pour qu'elles soient disponibles....

Photo par Pierre-Antoine Grégoire.

Code Retreat #1

Nicolas FRANCOIS — Tue, 28 Jun 2011 14:30:00 +0200

Ce 24 juin, j'ai assisté à un code retreat, organisé par Jean-Laurent de Morlhon et Simon Caplette, chez Xebia.
Avant de m'inscrire, je n'en connaissais pas le principe. Je me réfère donc à la définition donnée par les organisateurs :
"Le principe est le suivant: sur la journée coder en binôme sur plusieurs sessions de 30-45 minutes chacune afin de résoudre un problème. A l’issue de chaque session on change de binôme et tout le code produit est effacé. Drastique mais efficace pour rester créatif. C’est aussi le lieu privilégié pour tester de nouvelles techniques et algorithmes."
C'est un concept de coding dojo que je n'avais essayé, d'où mon envie de tester.

Le temps que tout le monde soit là et installé, un traditionnel petit déjeuner nous attendait.
Avant de commencer, l'organisation de la journée nous est présenté :
- Le but n'est pas de finir, mais de faire ce que l'on peut
- Par recommmencement on finit par s'améliorer, on cherche à améliorer la façon de faire.
- Une session est composé de 40 min de développement en pair programming et 20 min de débriefing général.
- Ici c'est différent du boulot, on a le temps, inutile de rusher. Nous sommes ici pour apprendre, tester d'autres façons de faire, essayer un autre langage ou un autre ide, découvrir des plugins d'ide, ...
- Procéder par TDD et suivi les principes de YAGNI. Si ce sont des pratiques que l'on ne fait pas au quotidien dans notre travail, c'est justement l'occasion de s'y exercer
- Une session est composé d'une partie de développement de 40 min en pair programming, suivi de 10-15 min de retrospective globale.
- Une retrospective globale en fin de journée

Souvent le jeu de la vie est utilisé en code retreat, ici pour changer ce sera TicTacToe dont les spécification nous sont fournis en 6 règles :
1/ Une partie est finie lorsque tous les champs sont pris.
2/ Une partie est finie lorsque une colonne est prise par un joueur.
3/ Une partie est finie lorsque une ligne est prise par un joueur.
4/ Une partie est finie lorsque une diagonale est prise par un joueur.
5/ Un joueur peut jouer lorsque un champ n'est pas pris.
6/ Les joueurs jouent à tour de role jusqu'à ce que la partie soit finie.

Au total, sur la journée 5 sessions auront lieu.

Session 1

Au bilan de cette première session, certains remonte l'usage de plugins Eclipse :
- Pair Hero : duels en pair programming où chacun code à tour de role jusqu'à ce qu'un test échoue. Des points sont gagnés en fonction de refacto ou rapidité à faire passer le clavier.
- Infinitest : lance les tests unitaire à chaque enregistrement du code, économise ainsi des switch test/code.
Beaucoup prennent les régles dans l'ordre, mais est ce bien utile ?
Quant à l'implémentation, le plateau est codé sous diverse forme : tableau à 2 dimensions, chaine simple, ...

Session 2

Les noms de classes eux aussi sont variés : TicTacToe, Party, Board, ... tout comme les méthodes de fin : checOver, isOver(), ....
Des questions sur le moment où refactorer se posent. Le mieux est quand on veux, quand celà nous semble un moment logique, une étape. Et il ne faut pas oublier que la refacto concerne aussi bien, le code métier que les tests.
Quelques personnes pense qu'ils ont introduit la notion de joueur trop tôt, ils auraient pu refactorer lorsqu'ils en auraients eu besoine.
Profitant de l'occasion de pouvoir refactorer, certains ont changé leur design, parfois avec regret. Mais y trouve tous l'avantage du recommencement, qu'ils ne peuvent pas faire au boulot.

Session 3

Quelqu'uns trouvent un avantage dans l'implémentation de recherche interne, pour une raison de facilité de recherche interne.
Pour la part, après 2 sessions orientée sur la détection de fin de partie, mon code était plutôt orienté vers la le tour par tour des joueurs.
Une problématique courante remonte : placer le jeu dans un état précis pour tester par exemple des configuration de plateau. Une solution possible serait d'avoir une méthode d'initialisation.
Les animateurs remontent qu'ils entendent parler d'architecture, mais qu'il s'agit là d'une notion bien poussée, car la seule voulue, c'est un simple jeu.

Pause repas

Après toutes ces aventures de la matinée, nous avons le droit à un repas geek : pizza/coca !
Pour l'apres midi, pour ceux qui souhaitent, on monte le niveau avec des objectifs :
- No Mouse : souris interdite, uniquement clavier.
- 5 min par personne : on alterne le clavier toutes les 5 minutes.
- Tdd as if you meant it : Tdd encore plus poussé avec des régles comme coder son code métier dans la classe de test.

Session 4

Pour cette session, 2 groupes ont testé un autre langage :
- JavaScript (Mathilde Lemée et Eric Le Merdy) : Utilisation de JQuery, structure de données portée par la page. QUnit ne semble pas super pour tester du js.
- Ioke (David Gageot et moi même) : Je ne connaissais absolument pas ce langage, j'ai donc était volontaire pour le découvrir. C'est un langage entre lisp, ruby et smalltalk qui tourne aussi bien sur une VM java que .Net. Nos tests sont assez très lisible, au contraire du code. En effet, de refacto en refacto et par jeu, nous avons réduit de façon très importante le code en utilisant toute la puissance du langage. Si bien que notre code pour les régles lignes et colonnes tient en 3 lignes.
Ceux qui avaient l'objectif, Tdd as if you meant it sont satisfaits, par le fait d'avoir pu repousser le moment de décider où placer son code.

Session 5

Le groupe JS a poursuivi ce qu'il avait commencé et nous montre leur réalisation. Le js a permit de connecter facilement à une ihm html, la structure de données est directement dans le dom plutôt que dans des objets js.
David a continué en Ioke avec un autre volontaire pour découvrir le langage. De nouvelles refacto ont eu lieu, et le code pour tester les 4 ères régles tiennent sur environ 6 lignes.
Nos animateurs nous montrent un exemple de Tdd as if you meant qu'ils avaient réalisé. Le retardement du choix du placement du code a fait qu'ils ont eu une approche fonctionnelle, où le modèle est sans état.
Et pour finir, ils énumèrent quelques possibilité de challenge possible en code retreat : No loop, No If, ...
Invonlontairement, ces 2 challenges ont été vaincus par David et son code en Ioke.

Debriefing de la journée

Nous finissons la journée sur une rétrospective finale sur ce que nous avons appris et ce qui sera pratiqué au retour au travail. Dans le désordre :
- Découverte du tdd et voir quelle limite dans l'approche du code nécessaire à faire passer le test.
- Le tdd permet de penser plus au fonctionnel.
- Necessité de plus pousser le principe de code minimal afin d'affiner ses tests.
- Réticence à Infinitest vaincu. Pour des tests volumineux, il est paramétrable.
- Un autre langage qui faire penser différement.
- Pair Hero assez plaisant
- Parfois on pense avoir résolu de manière optimale un problème mais après avoir recommencé avec une autre personne, on se rend compte que non.
- Progression dans les tests car parfois quasiment pas de tests dans les projets au boulot.
- Nouvelle vision à chaque fois.
- Du test fait mais pas tdd, ce qui fait une nouvel outil à utiliser.
- Il peut être utile d'avoir une phase de réflexion avant de se lancer dans les tests.
- Des discussions intéressantes.
- Passer plus de temps sur la refacto.

Un autre Code Retreat aura lieu le 2 juillet, avec Oana Juncu de Sfeir comme animatrice.
A l'heure actuelle, il reste quelques places dépéchez si vous être intéressés.

La marmite des Duchess

Nicolas FRANCOIS — Thu, 23 Jun 2011 00:49:00 +0200

La 1ère édition de la Marmite des Duchess a eu le 7 juin dernier. Nom de code "Crumble".
Ce nouvel évènement, proposait 2 sessions en parallèle, le choix se faisait à l'inscription :
- Atelier Mockito, animé par Mathilde Lemée et David Gageot. (limité à 20 places)
- Open Space Technologique. (limité à 40 places)
Doit on y voir l'anologie du crumble dans ce découpage ? Je ne saurais répondre à cette question.

Au total, une trentaine de personnes (dont 6 Sfeirien(ne)s) étaient présentes pour une durée d'un peu plus de 2 heures.

Atelier Mockito

C'est la partie à laquelle j'ai assisté.
Cet atelier était basé sur le code de tudu-list. Le but était de, en peer programming, compléter des tests et de les faire passer au vert. Pour palier aux différentes connaissances et niveaux des participants, les tests étaient répartis en 3 niveaux de difficulté.
Pour ma part, connaissant un peu Mockito, j'ai affronté le niveau 2. Nos animateurs étaient bien sûr présent pour nos différentes questions sur la façon de développer/organiser nos tests aussi bien sur Mockito mais aussi sur FestAssert.
Ces exercices permettent d'avoir quelques bases sur Mockito en découvrant sa syntaxe et ses particularités mais aussi si nous sommes rigoureux de se familiariser avec le formalisme BDD, conseillé pour bien se concentrer sur une seule chose à tester par méthode de test.

Si vous souhaitez tenter le défi, le code à compléter est ici et la solution là.

Open Space Technologie

D'après ce que j'en ai compris, un open space technologie est assez semblable à un bar camp, mis à part qu'il n'y a pas de sessions parallèles.

N'ayant pas de don d'ubiquité, je n'étais pas présent à cette partie. Mais heureusement, mon collègue Clément Griffoin avait pris des notes.

Différents sujets ont étés abordés dont :
- Women in java
- ForPlay où Pierre-Yves Ricau fera une démonstration de sa réalisation
- Déploiement continu
- Stubs vs Mock
- TDD/DDD/BDD

Vous pourrez retrouver plus d'informations ce qui s'est dit dans cette partie sur le blog des Duchess.

Et pour finir, c'est un autour d'un repas que les derniers motivés se sont retrouvés.

Merci et félicitations pour cette première édition ! Et vivement la suite à la rentrée.

Des photos de cet article ainsi que toutes les photos la soirées sont disponible sur l'espace Flickr de Duchess France

Du Protobuf dans mon Jersey

Nicolas FRANCOIS — Thu, 23 Jun 2011 00:38:00 +0200

J'avais déjà parlé, dans de précédents articles, de la génération de xml et de json avec Jersey. Et si maintenant, on s'amusait à générer du protobuf ?
On parle de protobuf pour Protocol Buffers, une techno Google pour encoder des structures de données. Ce format de données compact est utilisé en interne chez Google des échanges de données. Etant basé sur la déclaration d'une structure de données dans un idl, protobuf possède plusieurs implémentation et est ainsi utilisable dans plusieurs langage. En java, la génération du code cible se fait avec ant. Mais bien sur reste utilisable avec maven par le plugin ant.
Nous allons reprendre notre Hello qui avait d'exemple. Voici sa structure protobuf :

package nfrancois.poc;

option java_package = "nfrancois.poc.protobuf.model";
option java_outer_classname = "HelloProto";

message Hello {
  required string name = 1;
  required string message = 2;
}

La structure se comprend assez facilement. Attention par contre, au trompeur package de 1ère ligne, qui n'est pas lié à la notion de package que nous avons en java. Il sert comme espace de nommage et éviter des collisions de nom si plusieurs objets protobuf portent le même nom. Puisque depuis cette idl, je pourrai aussi bien générer en C++ ou un autre langage, le vrai nom de package java est indiqué par l'option "java_package", de la même façon pour le nom de classe qui va tout encapsuler qui sera "java_outer_classname"
Pour plus d'information sur protobuf, je vous invite à consulter sa page google code.
Le générateur protobuf générera un fichier HelloProto.java, qui permettra de manipuler les Hello : création via pattern builder, encodage/désencodage, ... Le "vrai" Hello sera encapuslé au sein de ce dernier. Comme je disais, je génère le java par le ant plugin de maven :

<plugin>
 <groupid>org.apache.maven.plugins</groupId>
 <artifactid>maven-antrun-plugin</artifactId>
 <version>1.6</version>
 <executions>
  <execution>
   <id>generate-sources</id>
   <phase>generate-sources</phase>
   <configuration>
    <target>
     <exec executable='protoc'>
             <arg value='--java_out=src/main/java' />
             <arg value='src/main/resources/Hello.proto' />
             </exec>
    </target>
   </configuration>
   <goals>
    <goal>run</goal>
   </goals>
  </execution>     
 </executions>
</plugin>

et bien sûr des dépendances protobuf

<dependency>
    <groupid>com.google.protobuf</groupId>
    <artifactid>protobuf-java</artifactId>
    <version>2.4.0a</version>
</dependency>

Le contrat de test sera assez proche de se que nous avions dans les tests précédents :

@Test
public void shoulReplyHello(){
 // Given
 String message = "Hello";
 String name ="Nicolas";
 Hello hello = HelloProto.Hello.newBuilder().setName(name).setMessage(message).build();
 when(helloServiceMock.saysHelloToSomeone("Nicolas")).thenReturn(hello);
 // When
 ClientResponse response = resource().path("hello").path(name).get(ClientResponse.class);
 // Then
 verify(helloServiceMock).saysHelloToSomeone(name);
 assertThat(response.getClientResponseStatus()).isEqualTo(Status.OK);
 assertThat(response.getType().toString()).isEqualTo("application/x-protobuf");
 Hello entity = response.getEntity(Hello.class);
 assertThat(entity).isNotNull().isEqualTo(hello);
}

La resource REST, elle aussi va peut évoluer :

@Path("hello")
@Singleton
@Produces("application/x-protobuf")
public class HelloResource {
 
 @Inject
 private HelloService helloService;
 
 @GET
 @Path("/{name}")
 public Hello reply(@PathParam("name") String name){
  return helloService.saysHelloToSomeone(name);
 }
 
 public void setHelloService(HelloService helloService) {
  this.helloService = helloService;
 }
 
}

La difficulté à laquelle il faut se confronter, c'est que Jersey ne permet pas de gérer de base le protobuf… Pas grave, on va s'occuper de faire le lien entre l'encodage/désencodage de protobuf et Jersey.

Commençons par le reader qui s'occupe de désencoder le protobuff. Pour celà, nous devons implémenter l'interface MessageBodyReader où nous aurons du code technique protobuf.

@Provider
@Consumes("application/x-protobuf")
@Singleton
public class ProtobufMessageBodyReader implements MessageBodyReader<Message> {

 public boolean isReadable(Class<?> type, Type genericType, Annotation[] annotations,
                                                            MediaType mediaType) {
  return Message.class.isAssignableFrom(type);
 }

 public Message readFrom(Class<Message> type, Type genericType, Annotation[] annotations, 
    MediaType mediaType, MultivaluedMap<String, String> httpHeaders, InputStream entityStream)
    throws IOException, WebApplicationException {
  try {
   Method newBuilder = type.getMethod("newBuilder");
   GeneratedMessage.Builder builder = (GeneratedMessage.Builder) newBuilder.invoke(type);
   return builder.mergeFrom(entityStream).build();
  } catch (Exception e) {
   throw new WebApplicationException(e);
  }
 }

}

C'est par le content type "application/x-protobuf" que JAX-RS fera matcher le type le reader/writer à l'entrée/sortie de la resource. Pour l'encodage, c'est l'interface MessageBodyWriter qu'il faut implémenter.

@Provider
@Produces("application/x-protobuf")
@Singleton
public class ProtobufMessageBodyWriter implements MessageBodyWriter<Message> {
 public boolean isWriteable(Class<?> type, Type genericType, Annotation[] annotations,
                                                              MediaType mediaType) {
  return Message.class.isAssignableFrom(type);
 }

 private Map<Object, byte[]> buffer = new WeakHashMap<Object, byte[]>();

 public long getSize(Message m, Class<?> type, Type genericType, Annotation[] annotations, 
                                                                 MediaType mediaType) {
  ByteArrayOutputStream baos = new ByteArrayOutputStream();
  try {
   m.writeTo(baos);
  } catch (IOException e) {
   return -1;
  }
  byte[] bytes = baos.toByteArray();
  buffer.put(m, bytes);
  return bytes.length;
 }

 public void writeTo(Message m, Class type, Type genericType, Annotation[] annotations, 
                MediaType mediaType, MultivaluedMap httpHeaders, OutputStream entityStream)
                throws IOException, WebApplicationException {
  entityStream.write(buffer.remove(m));
 }
}

La configuration de test, quant à elle sera un peu plus complexe, car il faut que la partie cliente puisse désencoder toute seule le protobuf :

protected AppDescriptor configure() {
 ClientConfig clientConfig = new DefaultClientConfig();
 clientConfig.getClasses().add(ProtobufMessageBodyReader.class);
 clientConfig.getClasses().add(ProtobufMessageBodyWriter.class);
 injector = Guice.createInjector(new ServletModule() {
 @Override
 protected void configureServlets() {
  bind(ProtobufMessageBodyReader.class);
  bind(ProtobufMessageBodyWriter.class);
  bind(HelloResource.class);
  serve("/*").with(GuiceContainer.class);
  }
 }); 
 return new WebAppDescriptor.Builder()
          .contextListenerClass(GuiceTestConfig.class)
          .filterClass(GuiceFilter.class)
          .clientConfig(clientConfig)
          .servletPath("/")
          .build();
}

Le code complet est ici.

Bilan Cloud Camp 1 chez Sfeir

Nicolas FRANCOIS — Wed, 22 Jun 2011 22:11:00 +0200

C'est le 30 mai dernier qu'a été organisé le 1er Cloud Camp. Plus de 50 personnes étaient présentes au rendez vous. A l'arrivée, un accueil convivial avec des cacahuètes et boisson attendaient les invités. La soirée commence avec une présentation de Kohsuke Kawaguchi, sur le build en parallèle avec Jenkins.

Dans la foulée, Steven Noels lui aussi vient aussi nous parler de son bébé : Lily

C'est autour de pizza que nous nous remettons de nos émotions, ce qui est aussi l'occasion de discuter entre différentes personnes présentes. C'est après, s'être bien rempli l'estomac que la soirée, s'est poursuivies etlLes sessions camp organisées furent :

Forplay : le framework de Google pour réaliser des jeux pour des cibles Gwt/Android/Flex/Swing
Retour d'expérience sur Appengine
Mvp4g
Démo de Lilly
CloudBees

Le Bilan que je fais de cloud camp est très positif et a plus au participant. Nous avons vu défiler les tweets lors des présentation de nos guest start. Et quelques sujets de blog de participants d'Exilys sur Lily et ForPlay. D'autres sessions, seront probablement organisée. Nous espérons vous y voir.

Agile France 2011

Francois Wauquier — Wed, 08 Jun 2011 13:18:00 +0200

LA conférance annuelle de la communauté agile en france.

http://conf.agile-france.org/
http://agilemanifesto.org/iso/fr/

Jeudi 26 Mai

Jean Claude Grosjean - Dans la peau du manager agile

http://conf.agile-france.org/sessions/4d7758894ff6f7381500008e
Présentation montrant l’évolution de ce poste dans une structure agile: il conserve une partie de ses attributions, mais change de posture vis à vis de l’équipe de réalisation. Au lieu de plannifier, d’attribuer les tâche et de suivre, il donne la vision, priorise, et challenge.
http://www.slideshare.net/jcgrosjean/grosjean-management-agileagile-france2011

Jean-Phillipe Caruana - Buildr : un outil de build moderne, puissant et efficace

http://conf.agile-france.org/sessions/4d8ccbac4ff6f77395000d18
Je n’ai vu que le début de cette session, car je me préparais pour ma session. Mais cet outil est à suivre de près, car les promesses sont grandes: plus performant et plus flexible que maven.
http://www.barreverte.fr/
http://buildr.apache.org/

Francois Wauquier (votre serviteur) - Les frontières de l’équipe

http://conf.agile-france.org/sessions/4d94b7cb4ff6f7089b000094
Je me suis amusé à comparer une équipe de réalisation avec un village gaulois.
Une fois que l’on a vu la frontière, il ne reste plus qu’à la supprimer...
http://www.slideshare.net/wokier/agile-france-2011-les-frontieres-de-lequipe

Gery Derbier - Top Chef : le carpacio de code

http://conf.agile-france.org/sessions/4d9392344ff6f73c470000ae
Une expérimentation de développement en petite équipe avec des stories volontairement floues, afin de mettre en avant le fait que le développement logiciel est avant tout un mécanisme de création de savoir. Une bonne simulation que j’ai eu le plaisir de réaliser avec Etienne Charignon dans un groupe de 3. Petit rappel sur la théorie des jeux coopératifs chère à Alistair Cockburn: Pour bien jouer, il faut réussir le coup et préparer le coup prochain.
http://twitter.com/#!/Gery7/status/73866830187466753

Eric Lefevre - Le Marsmallow Challenge

http://conf.agile-france.org/sessions/4d70b0974ff6f719b10005e4
Un petit jeu divertissant et instructif: fournir à un groupe un chamallow, des spaghettis (non cuits), du scotch et de la ficelle, et leur demander de placer le chamallow le plus haut possible.
J’ai retenu 3 leçons :
- Ne pas sous-estimer le poids du chammallow (ce que vous aller construire devra porter...)
- Avancer par petits pas afin d’avoir toujours quelque chose à présenter sans casser du spaghetti (ah oui, itératif et incrémental...)
- Les enfants s’organisent mieux que certains professionnels.
Le groupe dans lequel j’ etais a gagné alors c’est encore plus drôle.
http://marshmallowchallenge.com/Instructions.html
https://twitter.com/#!/wokier/status/74000767761137664
http://www.ted.com/talks/tom_wujec_build_a_tower.html

Etienne Charignon - Lire du code

http://conf.agile-france.org/sessions/4d8fa5704ff6f752660009f7
Des bonnes pratiques présentées avec un prezi, et des exercices pratique de lecture du code. J’ai retrouvé plusieurs points de vue lus dans Clean Code. Il distingue plusieurs “causes” d’écriture d’une ligne:

Limitation de la machine
Limitation du langage
Limitations du programmeur
Raisons Historiques
Besoin/Spécifications (enfin)

Je retiens la comparaison avec la partition de musique: Quel musicien écrirait do ré mi en commentaire de sa partition?
http://etienne.charignon.free.fr/spip/spip.php?article106

Damien Thouvenin - Centre de service Agile

http://conf.agile-france.org/sessions/4da6001b4ff6f75e0000004e
Retour d’ expérience d’un centre de service qui se rapproche plus de la TMA que du forfait. Je ne pense pas que ce genre de structure soit le coeur de cible des méthodes agiles, mais je retiens 2 bons principes: l’équipe unique et On ne commence pas la story suivante tant que la précédente n’est pas validée.

Vendredi 27 Mai

Mack Adams - Une carte agile de gestion de produits

http://conf.agile-france.org/sessions/4da8bc6d4ff6f73fde000273
Mack distingue les rôles de Product Owner et Product Manager. Le premier terme vient de Scrum, le second du marketing. Pour un produit de petite taille, ces deux rôles peuvent être tenus par la même personne, mais pour un produit plus complexe, avec beaucoup d’interlocuteurs et/ou une dimension marketing forte, seul superman peut tenir ce rôle. Dans son organisation d’éditeur de logiciel multi-continent, il y a même de nombreux rôles intermédiaires. Son outil préféré pour construire la vision et le backlog initial est le story Mapping, qu’il réalise sur des sessions de quelques jours.

Jonathan Scher & Guillaume Duquesnay - Comment réussir un projet agile très court

http://conf.agile-france.org/sessions/4d984fd94ff6f74ad10001ad
Une session courte, comme les projets de quelques mois que Jonathan et Guillaume ont réalisé récemment. C’est un délai si court que l’équipe ne peut pas se stabiliser. Cela nécessite d’être encore plus discipliné. Ils recommandent de s’engager sur un enjeu, de faire sauter le sprint 0.

Pascal Van Cauwenberghe - Les bases des méthodes agiles Lean

http://conf.agile-france.org/sessions/4d961f234ff6f701570005e1
Une grande présentation avec des thèmes chers à Pascal, du rythme, de l’humour, des anecdotes.

Théorie des contraintes
Real Options
Pilotage par la valeur metier
Auto Organisation
Excellence Technique
Amélioration continue

http://blog.nayima.be/2011/06/07/conf-agile-france-2011-les-bases-des-methodes-agiles-et-lean/

Christophe Addinquy - Quand mon produit est un système d’information

http://conf.agile-france.org/sessions/4d96ec514ff6f7417600015d
Retour d’ experience du Système d’ Iinformation Back de Vidal. J’ai retrouvé beaucoup de similitudes avec les propos de Mack Adams. Ils se posent tous les deux la question de prioriser des ensembles plus gros que la story ou l’epic, que christophe appelle chantier, pour des produits de grande taille et complexes. Et ils utilisent la même image de superman pour la personne qui arriverait à définir la vision et suive dans le détail ce genre de produit.

Alexandre boutin - Lorsque Scrum ne marche pas

http://conf.agile-france.org/sessions/4d837c064ff6f70c2d000054
Plusieurs sujets possibles, mais un temps limité? Alexandre propose de choisir en utilisant la technique Buy a Feature . Le sujet est donc choisit en négociant, en criant et en courant. Le point commun des sujets, c’est une difficulté rencontrée lors de la mise en place de Scrum.
http://www.agilex.fr/

Lucian Précup - La revue de code

http://conf.agile-france.org/sessions/4da87ce64ff6f721eb000823
Cette pratique utilisée par Google, Apache, Mozilla peut être outillée afin de définir des flux de validation, revue, correction. Tout commit est considéré comme un patch. Personnellement, je reste fan du binômage.

Soirée JDuchess le 7 juin

Audrey — Wed, 01 Jun 2011 11:12:00 +0200

Ca y est ! La marmite, le rendez-vous régulier des JDuchess, est lancée. Le premier opus aura lieu mardi 7 juin dans les locaux de SupInfo (23 rue du Château Landon, 75010 Paris – à côté de gare du nord). Au programme, deux tracks en parallèle : un atelier sur le framework de tests unitaires Mockito animé par Mathilde et un open-space.

Qu’est-ce qu’un open space ? C’est un peu comme un barCamp à part que les sujets sont présentés au début et que l’on ne traite que les sujets les plus populaires pendant un temps limité. Le but essentiel est de partager et de débattre. Tous les sujets autour de Java et de l’IT sont les bienvenus. Pour vous donner des idées, voici quelques pistes possibles :

une problématique technique que vous avez rencontrée
un super outil qui a changé votre vie de développeur
votre sujet de veille préféré
ou une problématique relationnelle (ex: comment travailler avec une personne au caractère difficile ?).

N'oubliez pas de vous inscrire, les places sont limitées !

Le Scroll horizontal facile en Android

Nicolas FRANCOIS — Thu, 26 May 2011 09:47:00 +0200

Dans un souci d'ergonomie, le scroll horizontal est bien appréciable, par exemple pour passer à l'écran suivant. Même si la fonctionnalité est utilisé, pour se déplacer entre les écrans du home, il n'existe pas de composants qui gère cela. Comme bien, souvent, c'est dans l'open source que l'on trouve une solution.
C'est sur github que j'ai trouvé View Flow for Android qui offre une solution simple à intégrer. En fin de compte, ce comportement de scroll horizontal, c'est une sorte de ListView à défilement horizontal où une cellule = un écran. C'est sur ce principe que se base cette api. Elle offre un composant ViewFlow qui nécessite un BaseAdapter pour réaliser l'affichage de chacun de ses écrans.

viewFlow = (ViewFlow) findViewById(R.id.viewflow);
viewFlow.setAdapter(new MonAdapter());

 <org.taptwo.android.widget.ViewFlow
                   android:id="@+id/viewflow" 
                   android:layout_width="fill_parent"
                   android:layout_height="fill_parent" 
                   app:sidebuffer="3"/>

Qu'est ce que ce sidebuffer ?
Il s'agit tout simplement du buffer des écrans chargés; ce qui permet de fluidifier le scroll. Avec la valeur 3, j'aurai jusqu'à 3 écrans à droite, 3 écrans à gauche ainsi que mon écran actuel, soit 7 écrans, qui sont chargés et en mémoire. Cette valeur, est à 3 par défaut.

Et si j'ai besoin d'écouter le changement d'écran ?
Ca tombe bien, il existe un ViewSwitchListener

viewFlow.setOnViewSwitchListener(new ViewSwitchListener() {
    public void onSwitched(View v, int position) {
        // Your code here
    }
});

Certains Home Android, affiche un indicateur de position afin de connaitre celui sur lequel nous nous trouvons. View Flow for Android offre aussi cette possibilité. A l'heure actuelle, il en existe 2

Cercle

CircleFlowIndicator indic = (CircleFlowIndicator) findViewById(R.id.viewflowindic);
viewFlow.setFlowIndicator(indic);

Texte

TitleFlowIndicator indicator = (TitleFlowIndicator) findViewById(R.id.viewflowindic);
indicator.setTitleProvider(myTitleProvider);
viewFlow.setFlowIndicator(indicator);

Je trouve cette api sympathique à utiliser, et espère y voir de nouvelles fonctionnalités.
Comme beaucoup pour beaucoup de projet sur github, les contributions sont les bienvenues, si vous avez des idées, n'hésitez pas.

CloudCamp chez Sfeir

Nicolas FRANCOIS — Mon, 09 May 2011 19:17:00 +0200

Hey, lecteur !
Qu'as tu de prévu à ton agenda ce 30 mai 2011 à partir de 18h30 ?
Si tu n'as rien, Sfeir te convie à un BarCamp spécial Cloud dans ses locaux à Suresnes. Si tu n'es pas coutumier des barcamps, sache que c'est une "non conférence ouverte". C'est à dire qu'un ensemble personne toutes intéressées par un même sujet s'isole dans un coin pour en discuter toutes ensemble.
Pour ce CloudCamp, nous aurons l'honneur d'avoir un invité de marque : Kohsuke Kawaguchi. Et oui, lui le papa de Hudon/Jenkins qui travaille actuellement chez Cloudbees sera là... Donc, une très bonne occasion, d'échanger sur le cloud.
Comme à tout bon évènement geek, il y aura bien sûr des pizzas et des boissons.
J'espère t'y voir.
Allez viens, les inscriptions, c'est par ici

Manipulation de la Remote Api GAE avec Guice/Objectify

Nicolas FRANCOIS — Tue, 26 Apr 2011 10:09:00 +0200

Avec la version 1.4.3 de app engine, arrive une api qui jusque là était disponible seulement en python : la remote api. Celle çi permet de se connecter de façon sécurisée au datastore afin d’y insérer des données par exemple.
La documentation, bien que courte, donne de bonnes explications sur la façon de mettre en place. Mais, c’est le cas simple... Si au sein de mon application app engine, j’ai mis en place Guice et Objectify, je me retrouve confronté à 2 problèmes :
1/ Pour fonctionner ma servlet doit être déclarée dans la configuration Guice.
2/ Je manipule des objets métier géré par Objectify et non pas des Entity.

Imaginons je possède l'objet "métier" suivant :

public class Hello {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
private String message;
private String name;
public Hello(){
}
public Hello(String message, String name) {
super();
this.message = message;
this.name = name;
}
// Getter & Setter/hascode/equals methods ...
}

Je vais devoir modifier mon GuiceServletConfig pour la mapper avec la servlet. Aussi une servlet déclarée doit Guice doit être un singleton.

public class GuiceServletConfig extends GuiceServletContextListener {
@Override
protected Injector getInjector() {
return Guice.createInjector(new ServletModule() {
@Override
protected void configureServlets() {
bind(RemoteApiServlet.class).in(Singleton.class);
serve("/remote_api").with(RemoteApiServlet.class);
// D'autres bindings ou serve ...
}
});
}
}

Le 1er problème est ainsi résolu.
Il ne me reste plus qu'à transformer mes Hello en Entity. Une petite ballade dans le code source permet de trouver la solution.

public static Entity helloToEntity(Hello hello) {
Objectify ofy = ObjectifyService.begin();
EntityMetadata<Hello> metadata = factory.getMetadataForEntity(hello);
return metadata.toEntity(hello, ofy);
}

Il ne reste plus qu'à écrire un petit batch d'alimentation :

public static void main(String[] args) throws IOException {
RemoteApiOptions options = new RemoteApiOptions()
.server("maSuperApplication.appspot.com", 443)
.credentials("monEmailAMoi@gmail.com", "monMotDePasse");
RemoteApiInstaller installer = new RemoteApiInstaller();
installer.install(options);
List<Entity> hellos = Lists.newArrayList(helloToEntity(new Hello("Hello", "Nicolas")),
helloToEntity(new Hello("Bonjour", "Vincent")),
helloToEntity(new Hello("Salut", "Guillaume")),
helloToEntity(new Hello("Enchanté", "M. Gendal")));
try {
DatastoreService ds = DatastoreServiceFactory.getDatastoreService();
for (Entity hello : hellos) {
Key key = ds.put(hello);
System.out.println("Hello key=" + key);
}
} finally {
installer.uninstall();
}
}

En console, nous obtiendrons :

Hello key=Hello(3001)
Hello key=Hello(4001)
Hello key=Hello(1002)
Hello key=Hello(5001)

Et dans l'interface web du datastore, nous voyons bien nos 4 Hellos :

Des rubis plein les nuages

Nicolas FRANCOIS — Thu, 21 Apr 2011 10:09:00 +0200

Comme vous le savez certainement, WMware au travers de Cloud Foundry propose son offre de cloud, mais pour le moment en bêta. Après une longue semaine d'attente, j'ai enfin reçu mes crédentials.
C'est tourjours par un HelloWorld que commence bon nombre de tutoriaux, celui que j'ai essayé n'échappe pas à cette règle.
Je vais vous faire part de ce petit essai que je trouve intéressant.

En fait, il s'agit de la version Ruby que j'ai essayé. Je n'y connais rien en Ruby, mais qu'à celà ne tienne, Hello c'est pas très compliqué.
Il faut tout d'abord s'assurer de ses version de Ruby et de gem :

bash$ ruby -v

bash$ gem -v

Ils doivent être respectivement en version 1.8.7 et 1.7.2. Il est possible que gem ne soit pas à jour, dans ce cas, la commande suivante est à passer :

bash$ sudo gem update --system

Vous pourrez ainsi installer la gem vmc :

bash$ sudo gem install vmc

Ce qui permettra dans un premier temps de se connecter à son compte :

bash$ vmc target api.cloudfoundry.com
Succesfully targeted to [http://api.cloudfoundry.com]
bash$ vmc login
Email: moiMail@mo.i
Password: ***********
Successfully logged into [http://api.cloudfoundry.com]

On a passé le coté configuration et prêt à déchainer la fureur du code.

bash$ mkdir hello
bash$ cd hello/
bash$ nano hello.rb

Chose promise, chose dûe, un hello tout simple :

require "sinatra"
get '/' do
"Coucou les gens"
end

Et voilà, on a fini la v1, il ne reste plus qu'à déployer, en répondant à quelques questions :

bash$ vmc push
Would you like to deploy from the current directory? [Yn]: Y
Application Name: nfrancois
Application Deployed URL: 'nfrancois.cloudfoundry.com'? y
Detected a Sinatra Application, is this correct? [Yn]: y
Memory Reservation [Default:128M] (64M, 128M, 256M, 512M, 1G or 2G)
Creating Application: OK
Would you like to bind any services to 'nfrancois'? [yN]:
Uploading Application:
Checking for available resources: OK
Packing application: OK
Uploading (0K): OK
Push Status: OK
Staging Application: OK
Starting Application: OK

Aussitôt, dégainage du navigateur à l'url, et c'est déjà accessible :

Mince j'ai oublié des gens importants :

require "sinatra"
get '/' do
"Coucou les gens, surtout toi lecteur"
end

Prêt à déployer ce correctif :

bash$ vmc update nfrancois
Uploading Application:
Checking for available resources: OK
Packing application: OK
Uploading (0K): OK
Push Status: OK
Stopping Application: OK
Staging Application: OK
Starting Application: OK

Un F5 suffit à vérifier :

C'est ainsi que s'est déroulé mon premier essai de déploiement Cloud Foundry et j'ai apprécié sa simplicité. C'est donc un bon point qui donne envie de continuer à s'y intéresser car bien sûr pour s'en faire une bonne idée, il reste de nombreuses choses à tester.
Dans le monde du Ruby dans le cloud, il existe aussi Heroku, assez apprécié me semble t-il dans le monde ruby. Mais mes connaissances rubyste s'arrête là, je ne saurais faire un comparatif des 2 offres.

Ma journée à Mix It

Nicolas FRANCOIS — Sun, 17 Apr 2011 03:05:00 +0200

Ce 5 avril 2011, s'est tenu le mix-it, conférence autour de java et de ses pratiques, organisée par le Lyon JUG et Kara. Celle çi était articulée de 5 thèmes : Techy, Agility, Tendy, Mixy, Gamy.
Soit 25 sessions au total. J'étais parmis les 250 personnes qui s'y sont rendu. Je vais vous faire une petite rétrospective de quelques sessions auxquelles j'ai assisté au cours de cette belle journée.

Nous étions quelques Parisiens, habitués du Paris JG, à s'être déplacé, dont certains en temps que Speaker.
Et c'est justement par Nicolas Martignole que commence la traditionnelle keynote, après une courte présentation de Objet Direct, principal sponsor de d'évènement.

Keynote

Nicolas commence par une question, « Qui est fier ce qu'il a réalisé ? ». Peu de monde, dans l'assistance lève la main. Cette question a pour but d'amener au constant suivant : le plus important, ce n'est pas le résultat mais le processus.
Il y a quelques années, on ne parlait pas de TDD, agilité, ni aucun terme tendance auquel nous sommes aujourd'hui habitués. A la place, on parlait d'architecture, d'UML, …
Nous n'avons plus la même façon de construire une application qu'autrefois (si j'ose dire) : nous livrons régulièrement par exemple. Nicolas aime assez la vision du craftmanship et nous expose 12 points du métier de développeur aujourd'hui.
1/ Pattern de l'iceberg : le client ne voit que ¼ de ce qui se passe, il est donc normal qu'il ne comprenne pas qu'une tache ait pris plus de temps que ce qu'il n'imaiginait.
2/ Comprendre ce qui va changer à la fin : Imaginons que vous naviger dans un bateau, vous préférez un point de rendez vous que vous recalculer chaque jour en fonction des contraintes ou un point de rendez vous cap 180° et on se revoit dans 10 jours ?
3/ Simplicité. Nous autre développeurs java, sommes de passionnés de technique et inventons régulièrement de nouveaux frameworks. Mais tant de complexité et elle nécessaire ?
4/ Itérer et avancer. Tout comme un musicien qui s'entraine, nous devons savoir jeter du code, le mouvement est important.
5/ Vision du jardinier, savoir pensez long terme.
6/ Mouvement permanent. Il ne faut pas attendre mais savoir bouger, en faisant de la veille par exemple.
7/ On ne dit pas de « Je fais de l'architecture » mais du « je fais du code propre ». C'est implicite dans la réalisation logicielle.
8/ Avoir le temps de se planter. C'est un avantage de l'agilité. Si au bout de 15 jours vous vous rendez compte ça passe. Mais si un cycle en V fait que vous vous en rendez compte, les conséquence auprès du client de sont pas les mêmes.
9/ Soyez sans pitié. Le code pourri ou en commentaire, il file tout droit à la poubelle.
10/ Le client est roi (mais on est pas non plus sa mère). Avec lui, on ne parle de qu'il connait : le métier, mais pas de techno. A l'inverse, ce n'est pas à lui, d'imaginer la solution technique. Lorsque vous prenez l'avion, donnez vous de conseils au pilote ?
11/ Gérer son manager. C'est en quelque sorte le ministre des affaires étrangère, c'est lui gère les relations entre l'équipe et le monde extérieur. S'il passe trop de temps à gérer l'équipe en elle même, c'est qu'il y a un soucis.
12/ Nous sommes des développeurs. Nous ne voulons pas être chef, amusez vous.

Spock, les tests du futur

Mathilde Lemée, habituée du Paris JUG mais aussi une des fondatrices des Duchess France, vient nous parler de Spock. Ce dernier, n'est pas qu'un personnage de la série Star Trek, c'est aussi framework de test venu de la galaxie Groovy.
Lorsque l'on écrit des tests, on a tendance à oublier leur partie critique : la maintenance.
Spock se veut de rendre les tests lisibles, ce qui facilite grandement de travail lorsque l'on refactore.
L'approche setup/expect/where ou given/when/then, facilitée par les labels, permet de tester une seule chose à la fois. La première syntaxe est adaptée à des cas de test simple type action/vérification du résultat. La seconde, elle est plus adaptée à des cas complexe où par exemple, je vais devoir faire appel à des éléments externes.
Il est important de différencier les mocks des stubs, ils n'ont pas les même rôles. Le stub est un bouchon stupide. Il sert simplement à tester l'état, mais n'a pas vocation à faire échouer le test. Au contraire, le mock peut faire échouer le test, car on teste son comportement.
En terme de code, la différence est assez simple : sois je vérifie si mon appel est bien effectué, soit je ne le fais pas.
Le problème posé par la sur utilisation des mocks, c'est que les tests casse au moindre refactor et consomme du temps pour les réparer.
Martin Fowler apporte plus de précisions dans son article sur le sujet.
Ce qu'apporte principal Spock aux tests, c'est une syntaxe plus souple.

def "account activation mail sent to user"(){
setup:
UserService userService = new UserService()
def emailService = Mock(EmailService)
emailService.sendMail(_,_,_,_) >> true
userService.emailService = emailService
User user = new User(email : "testUser@gmail")
when:
boolean success = userService.sendActivationMail(user)
then:
1*.emailService.sendMail("testUser@gmail","admin@admin.com",
       "Your account is activated", "Congratulation now you can login")
success == true
}

Ce que l'on note :

Nom de méthode expressif et lisible
Configuration simple du résultat de la méthode du mock grace à >>
Configuration simple de la vérification de l'appel du mock 1* …
Pas d'assert sur le résultat, il est implicite

De façon globale, la syntaxe est assouplie grace aux bloc given/when/then qui permettent d'éviter l'utilisation de mots clés, ce qui au final donne une lecture plus naturelle des instructions.

Cette lisibilité est accru dans le cadre de tests avec jeu de données :

def "String param should correspond to numeric spockInfoDay"() {
setup:
def spockResource = new SpockResource(new CalendarDaoStatic())
expect:
spockResource.findCalendarByDay(day).day == dayNumeric
where:
day | dayNumeric
"1" | 1
"2" | 2
"3" | 3
}

N'est ce pas plus plaisant à lire ?

Intelligence collective avec Apache Mahout

Je suis allé sur ce sujet que je ne connais absolu pas, par curiosité. C'est Michael Figuière qui nous a présenté à ce framework.
L'intelligence collective est supérieure à l'intelligence du plus intelligent. Wikipedia est un exemple, il contient beaucoup plus de connaissance que quiconque.
Aujourd'hui, internet permet d'agréger tout un tas de données. Page Rank agrège par exemple l'intelligence collective des sites web. Ainsi, par de nombreux liens, le site officiel de mix-it est la première réponse à la recherche « mit it ».
Le machine learning est un concept clé de Apache Mahout. Il s'agit d'un sous ensemble de l'intelligence artificielle. Les applications en sont par exemple :

Recommandation à d'un livre à un client en fonction de ce qu'il a déjà acheté ou de ce que les autres ont achetés en même temps.
Classification automatique de mails en fonction de qui a déjà été classé.
Conseil de fonctionnalité : si un utilisateur ne s'en sert pas, peut être qu'il ne la connait pas.
Adapter filtrage en fonctionnalité du profil : quand je cherche un livre sur java, faut il favoriser l'informatique ou les livres sur l'ile ?
Filtrage du spam
Agreger un flux actualité en fonction des tendances.

Pour nous, dans le domaine de l'informatique de gestion, ces concepts ne nous sont pas familliés. C'est justement là qu'intervient Apache Mahout en fournissant un implémentation java des algorithmes dernières ces concepts, facilitant ainsi leur intégration dans nos applications. Un bonne partie de cette implémentation est faite en Map/Reduce. Le framework est encore jeune mais connait une croissance rapide.

Pimp my app

Pour finir en épanadiplose, je finis ma journée par la présentation de Nicolas Martignole sur Play.
Quelques éléments pour moderniser une dans un navigateur web tout en s'amusant :

Html5/css3/jquery
Play
Huile de coude

Play! est développé à la base par Guillaume Bord, une personne du monde du web et de Ruby, et donc qui pas connu les joies des EJB 2. Devant la complexité du développement web en java, il a voulu réconcilier les 2 mondes en récréant ce qu'il connaissait avec Rails.
Tout d'abord, Play! n'utilise pas l'api servlet, est sans état sur le serveur. Choses banale dans d'autres technos utilisés pour faire du web. C'est justement sur Rails, Django et Grails que vient sont inspiration.
Avec Play! devient facile de développer rapidement une idée, ainsi moins de scrupules à jeter du code si l'on est pas satisfait. Un des aspect qui permette sa simplicité, c'est son absence de session coté serveur et qui va en adéquation avec les principes de REST.
C'est un framework fullstack, je fais tous avec lui : écriture de code, compilation, test et déploiement. Tous ça au sein de son environnement. Pour éviter d'être prisonnier de son serveur, on peut même packager en war et déployer sur un serveur d'application, bien que l'esprit de soit un peu perdu dans ce cas.
Nicolas nous explique que la question de se poser l'utilisation chez le client et la même que celle qui se posait il a 5 ans, à savoir si on peut utiliser Play.
Et bientôt, avec la version 1.2 on pourra piocher des dépendances avec modules Ivy.
Pour le moment, un ses points faibles c'est l'industrialisation des développements.

Un projet Play à la même structure qu'un projet Ruby :

src : les sources aussi bien java que html
test
conf : la configuration telle que le routage ou les propriétés

Nous avons le droit à une live démo :

La classe de base qui est un point d'entrée du controller.
La page htlml, est du script groovy
Oh mais on pas recompilé et ça marche.
En mode dev, Play surveille les fichiers et recompile quand il faut, on laisse ainsi tourner le serveur tout en codant
La trace d'erreur est lisible, ça fait gagner beaucoup de temps.
Utilisation d'un cookie pour gérer l'état conversationnel avec des cookies.
Pas de session sur le serveur

Les 2 derniers points nous pousse à avoir une architecture différente.

Niveau graphique, un inconvéniant, c'est qu'il n'y a rien, il faut retourner aux bases : grande utilisation du css et js.
Cela dit, sur ces 2 domaines en cas de problèmes ont peut toujours trouver de l'aide, venant même d'autre communautés comme php et rails.
Pas un peu de code css3, Nicolas nous montre comment embellir sa partie web en ayant par exemple un bouton full-css, de l'ombrage, ….

Cette conférence a été une belle réussite. Aussi, j'ai ouïe dire qu'elle avait été organisées en très peu de temps. Je profite donc de ce billet pour féliciter donc les responsables de celle ci et espère une prochaine édition l'année prochaine. Il est plaisant de voir que les communautés dans toutes la France se bougent pour nous monter de beaux événements à bas coût. Le prochain rendez vous sera le Breizh camp.

Du Jersey, du Guice et de l'App Engine 3/3

Nicolas FRANCOIS — Sat, 16 Apr 2011 14:50:00 +0200

Et pour finir cette série d'article, nous allons nous intéresser à la génération de JSon avec Jersey et bien sûr à sa testabilité.

Le xml, c'est bien gentil, mais dans des échanges REST ça peut être un peu lourd, surtout si le consommateur est un appareil mobile. La génération JSon avec Jersey peut s'appuyer sur JAX-B. Et oui, c'est justement pour cela que l'on s'en est occupé dans le précédant article. Le mapping, lui, ne change pas.

La resource ne nécessite qu'un petit changement :

 @GET
 @Path("{name}")
 @Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML}) 
 public Hello reply(@PathParam("name") String name){
  return helloService.saysHelloToSomeone(name);
 }

Comme on est sympa, on permet de renvoyer soit du Json, soit du Xml, c'est le consommateur qui décide. Par défaut, c'est le 1er format qui est choisit, soit le JSon.

La génération JSon va nécessiter un peu de configuration, principalement à cause du type de JSon généré. C'est le ContextResolver qui va s'occuper de ça :

@Provider
@Singleton
public class JAXBContextResolver implements ContextResolver<JAXBContext> {

 /** Package that contains object that can be mapped */
 private static final String JAXB_OBJECT_PACKAGE = Hello.class.getPackage().getName();

 private final JAXBContext context;

 public JAXBContextResolver() throws Exception {
  this.context = new JSONJAXBContext(JSONConfiguration.natural().build(), 
                                     JAXB_OBJECT_PACKAGE);
 }

 @Override
 public JAXBContext getContext(Class<?> objectType) {
  if(objectType.getPackage().getName().equals(JAXB_OBJECT_PACKAGE)){
   return context;
         }
  return null;
 }
}

Ici le type de JSon souhaité est le natural. Cet objet doit être passés dans le même package que les resources, il profitera ainsi lui aussi de la découverte automatique au démarrage de Guice. Ce resolver n'est pas obligatoire, sans lui, le JSon généré est par défaut en mode mapped.

La configuration des tests, va devoir évoluer un peu pour prendre en compte notre génération en ode natural. La méthode configure() devient :

@Override
 protected AppDescriptor configure() {
  ClientConfig clientConfig = new DefaultClientConfig();
  clientConfig.getClasses().add(JAXBContextResolver.class);
  injector = Guice.createInjector(new ServletModule() {
   @Override
   protected void configureServlets() {
    bind(getTestingResourceClass());
    bind(JAXBContextResolver.class);
    serve("/*").with(GuiceContainer.class);
   }
  }); 
  return new WebAppDescriptor.Builder()
           .contextListenerClass(GuiceTestConfig.class)
           .filterClass(GuiceFilter.class)
           .clientConfig(clientConfig)
           .servletPath("/")
           .build();
 }

Ainsi du coté serveur comme du coté client, les échanges seront dans le même format. Nos tests deviendront :

@Test
 public void shoulReplyHelloInXml(){
  doShoulReplyHello(MediaType.APPLICATION_XML_TYPE);
 }
 
 @Test
 public void shoulReplyHelloInJson(){
  doShoulReplyHello(MediaType.APPLICATION_JSON_TYPE);
 } 
 
 private void doShoulReplyHello(MediaType type){
  String message = "Hello";
  String name ="Nicolas";
  Hello hello = new Hello(message, name);
  when(helloServiceMock.saysHelloToSomeone("Nicolas")).thenReturn(hello);
  
  ClientResponse response = resource().path("hello").path(name)
                                      .accept(type).get(ClientResponse.class);
  
  verify(helloServiceMock).saysHelloToSomeone(name);
  assertThat(response.getClientResponseStatus()).isEqualTo(Status.OK);
  assertThat(response.getType()).isEqualTo(type);
  Hello entity = response.getEntity(Hello.class);
  assertThat(entity).isNotNull().isEqualTo(hello);  
  
 }

Une des différenciation entre les types de JSon générés se fait sur la façon dont sont écrites les listes. En mode natural, nous avons par exemple : objet1, objet2, ... avec des objet {"attributA":"valeurA", ....}

Imaginons que nous avons une autre ressource qui par grande politesse retourne 2 Hellos :

@Path("doublehello")
@Singleton
@Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
public class DoubleHelloResource {
 
 @Inject
 private HelloService helloService;
 
 @GET
 @Path("/{name}")
 public List<Hello> reply(@PathParam("name") String name){
  List<Hello> hellos = new ArrayList<Hello>();
  hellos.add(helloService.saysHelloToSomeone(name));
  hellos.add(helloService.saysHelloToSomeone(name));
  return hellos;
 }
 
}

Pour vérifier sa bonne génération, nous aurions le test suivant :

@Test
 public void shoudHaveTwoHello(){
  String message = "Hello";
  String name ="Nicolas";
  when(helloServiceMock.saysHelloToSomeone("Nicolas"))
                        .thenReturn(new Hello(message, name)); 
  ClientResponse response = resource().path("doublehello").path(name)
                                      .get(ClientResponse.class);
  assertThat(response.getStatus()).isEqualTo(Status.OK.getStatusCode());
  assertThat(response.getType()).isEqualTo(MediaType.APPLICATION_JSON_TYPE);
  List<hello> hellos = response.getEntity(new GenericType<List<Hello>>(){});
  assertThat(hellos).isNotNull().hasSize(2);
 }
 
 @Test
 public void shoudBeInNaturalJson(){
  String message = "Hello";
  String name ="Nicolas";
  when(helloServiceMock.saysHelloToSomeone("Nicolas"))
                                .thenReturn(new Hello(message, name)); 
  ClientResponse response = resource().path("doublehello").path(name)
                                      .get(ClientResponse.class);
  assertThat(response.getStatus()).isEqualTo(Status.OK.getStatusCode());
  assertThat(response.getType()).isEqualTo(MediaType.APPLICATION_JSON_TYPE);
  String hellos = response.getEntity(String.class);
  assertThat(hellos).isEqualTo(naturalHelloJSon(message, name));
 }
 
 public String naturalHelloJSon(String message, String name){
  StringBuilder sb = new StringBuilder();
  sb.append("[{\"message\":\"").append(message)
    .append("\",\"name\":\"").append(name).append("\"},");
  sb.append("{\"message\":\"").append(message)
    .append("\",\"name\":\"").append(name).append("\"}]");
  return sb.toString();
 }

Même s'il est un format intéressant, le JSon souffre d'un problème lié au javascript : celui du cross-domain qui fait que l'on ne peut pas interroger un autre domain que celui de la page web. <a href="http://en.wikipedia.org/wiki/JSONP">JSonP</a> permet d'évincer cette contrainte.

Jersey permet aussi de générer ce type de réponse mais un peu moins facilement. Nous allons créer une nouvelle méthode pour ce type de réponse :

 @GET
 @Path("{name}.jsonp")
 @Produces("application/x-javascript")
 public JSONWithPadding replyWithJsonP(@PathParam("name") String name,
           @QueryParam("callback") @DefaultValue(CALLBACK_DEFAULT_NAME) String callback){
  Hello hello = helloService.saysHelloToSomeone(name);
  return new JSONWithPadding(hello, callback);
 }

Son test reste dans l'optique des précédents :

@Test
 public void shoudBeJsonpWithCallbackNameParam(){
  String message = "Hello";
  String name ="Nicolas";
  when(helloServiceMock.saysHelloToSomeone("Nicolas")).thenReturn(new Hello(message, name));
  String callbackName = "monCallback";
  
  ClientResponse response = resource().path("hello").path(name+".jsonp")
                                      .queryParam("callback", callbackName)
                                        .get(ClientResponse.class);
  assertThat(response.getStatus()).isEqualTo(Status.OK.getStatusCode());
  assertThat(response.getType().toString()).isEqualTo("application/x-javascript");
  assertThat(response.getEntity(String.class)).isNotNull().startsWith(callbackName);
 }

Je n'ai pas malheureusement pas trouvé comment unmarshmaller ce message.

Et voilà, ce tour d'horizon est fini, amusez vous bien avec ces quelques technos. Comme à chaque fois, le code source est disponible

1er anniversaire des Duchess France

Nicolas FRANCOIS — Fri, 15 Apr 2011 02:05:00 +0200

C'est ce 14 avril que s'est tenu le 1er anniversaire des Duchess France.
Pour ceux qui n'ont pas suivi, non la noblesse n'a pas été rétablie en France. Il s'agit d'un groupe principalement composé de filles et qui oeuvre pour donner plus de visibilité aux femmes dans le milieu informatique; et bien sûr pas en gestion de projet, mais dans la technique.

A l'arrivée, nous recevons notre badge ainsi qu'un classique petit questionnaire : comment avez vous connu les Duchesses ? Quelle thèmes souhaiteriez voir traité .... A remettre dans une urne, car il pourra faire gagner l'un des lots offerts par les Sponsors. Tout les badges sont marqués d'une petite forme colorée. Quelle est sa signification ? C'est en rentrant dans l'amphithéâtre que la question trouve sa réponse : Nous sommes placés d'après la couleur de gommette. Et c'est ainsi que sont faites les équipes du Trivial Java, ainsi pas de jaloux dans la formation de ces dernières.
La soirée commence par une traditionnelle présentation, ce sont elles/qui elles ne sont pas, quel est le but ?, .... On connaissait déjà les avant-JUG, les groupes de préparation à la certification et bientôt s'annonce un nouvel événement : la marmite ! Mais qu'est ce donc ? Il s'agira d'une rencontre type coding dojo "main dans le code" (ou plutôt dans la marmite).
Après quelques remaniement de certaines couleurs en sous effectif, le jeu peu vraiment commencer. Les règles sont assez simples, chaque équipe envoi un représentant répondre à une série de question sur un thème comme le code java, la veille techno, les frameworks et même l'histoire geeko-javaïste. Des questions bien tordue, notamment sur le code java.
C'est après quelques séries de questions qu'a lieu la pause buffet bien méritée après ces efforts. Celle-çi est l'occasion de discuter avec les diverses connaissances présentes.
Au retour ce celui ci a lieu le tant attendu tirage au sort permettant de gagner les cadeaux offerts par les sponsors (dont Sfeir fait bien sûr parti). Parmi ces lots : un ipad2 (d'ailleurs remporté par une Sferienne : Yasmine Aite), des formations, des pass parleys, .... ainsi qu'un "cadeau surprise" qui se révélât être la fameuse Barbie informaticienne qui avait fait le buzz l'année dernière, remportée par Brice Argenson

La seconde parti reprend sur la lancée de la 1ère partie. Pour ce terminer, sur une égalité entre les verts foncés et les ciels. Pour les départager, c'est un duel entre Julien Dubois et Cédric Beurtheret sur une question de rapidité qui tranchera. C'est Spock (le framework de test) qui emmènera les verts foncés à la victoire par la réponse de Cédric. Leur équipe s'est vue remettre un mug aux couleurs des Duchess.

Pour les plus chevronnés, la soirée se termine par une traditionnelle 3ème mi-temps autour d'une pizza.

Félicitations aux duchesses pour cette belle soirée avec une très bonne animation. En attendant le prochain anniversaire, nous espérons de bonnes marmites pleines de bonnes technos auxquelles nous voulons tous gouter.