Le 30 Mai Duchess France vous invite à fêter ses 2 ans d’existence. Comme l’année dernière l’équipe organisera un Trivial Java avec des questions autour de Java mais pas uniquement !
Vous n’avez pas pu y assister l’année dernière ? C’est le moment de vous rattraper !
Vous y étiez l’année dernière et vous avez apprécié la soirée ? Courez vous inscrire et parlez-en autour de vous !

Informations pratiques

• A quelle heure ? L’accueil débute à 19h et la soirée débutera à 19h30.
• Où aura lieu la soirée ? A l’ECE : 37 quai de Grenelle dans le 15ème arrondissement.
• Comment s’inscrire ? Sur EventBrite et pour plus d’informations ça se passe ici.

L’équipe vous attend nombreuses et nombreux !

Cette formation de 2 jours couvre tout ce dont a besoin un administrateur, un développeur et un responsable d’exploitation pour déployer et maintenir une base de donnée MongoDB en production. Au delà du déploiement et de la maintenance, les stagiaires aborderont les problématiques de performance, d’import et d’export de données ainsi que les backups. A la fin de la formation, les stagiaires auront également une compréhension du shell MongoDB, de l’API de query et des drivers tools.

Si cette formation vous intéresse, n’hésitez pas à nous contacter au 01.53.89.99.99 ou par courriel à info@xebia-training.fr.

La règle n°2 sera une découverte pour beaucoup car nous n’en avons pas encore parlé en dehors des murs de Xebia. C’est une règle qui s’avère polémique à souhait et qui vient en complément de la règle n°1. Nous espérons bien qu’elle fera couler de l’encre dans les commentaires.

Règle n°2: Le manifeste agile n’est pas la déclaration des droits du développeur

En 2012, l’agilité en France est une réalité pour de nombreuses équipes de développement. Beaucoup d’observateurs s’accordent pour dire que la courbe d’adoption de l’agilité a franchi le point critique au delà duquel le sujet devient un courant dominant. A titre d’exemple, l’enquête nationale qu’avait menée le French SUG il y a maintenant 3 ans montrait déjà l’ampleur du phénomène. Les enquêtes régulières menées par l’éditeur de logiciel VersionOne nous éclairent également sur la profondeur de cette adoption au niveau mondial. Cette popularisation entraîne immanquablement une dilution des valeurs et des principes fondateurs parmi la masse des adoptions. Les agilistes de la première heure y voient, souvent à juste titre, une perversion du modèle. Cette dérive est souvent portée par des organisations soucieuses de ne pas se laisser déborder par le vent nouveau qui souffle sur le développement logiciel mais qui ne veulent pas vraiment changer de culture. C’est l’objet de la règle n°1: oublier les valeurs du manifeste conduit à une application faussée de l’agile. Autrement dit faire de l’agile ne signifie pas être agile. Cependant, les strates décisionnelles ne sauraient être les seules responsables de ces dérives. J’observe au sein de certaines équipes agiles l’émergence de comportements qui se réclament de l’agilité mais me paraissent dépasser largement le cadre du manifeste agile. Ces comportements peuvent prendre la forme de combat social – « J’ai le droit de ne pas faire d’heures supplémentaires », ou de lutte des classes – « J’ai le droit de dire Non à mon client », ou encore de plaidoyer pour la sauvegarde des libertés individuelles – « J’ai le droit de choisir mes tâches ». Je force volontairement le trait, mais n’appelons pas « agiles » tous les arguments qui visent à améliorer le confort et le bien-être des équipes de développement. À l’heure de son adoption massive, cela me paraît desservir le mouvement agile plus que de l’encourager.

Il faut reconnaître que le mouvement agile draine dans son sillage un écosystème riche de pratiques manageriales et organisationnelles plus humaines. Ces pratiques tirent leurs inspirations de la psychologie sociale ou de l’observation de systèmes complexes. Les experts agiles piochent allègrement dans ce vivier pour étayer le bien-fondé des principes agiles ou développer de nouvelles approches, comme par exemple: Radical Management, Cynefin Model, Management 3.0. Certains créent même de nouveaux mouvements à part entière, comme le réseau STOOS. Cette démarche, louable pour des experts, ne doit pas faire oublier la nécessaire courbe d’apprentissage pour maîtriser ces concepts. Pour un Scrum Master qui fait ses armes, je lui conseille de rester simple dans son discours et son application des techniques agiles. Si vous venez juste d’apprendre à skier, vous n’allez pas prendre une piste noire (je l’ai fait mais j’étais jeune), vous risquez de vous blesser et de mettre les autres skieurs en danger. Alors je m’adresse à toi, jeune Scrum Master, ne te laisse pas griser par les perspectives d’un lendemain qui chante grâce à l’agilité. L’agilité met les problèmes en lumière beaucoup plus vite, et les problèmes s’appellent souvent « course à la productivité », « manque de budget », « indisponibilité », « visions divergentes », « culture d’entreprise », « décisions des actionnaires », etc. Les réponses à tous ces problèmes sont à chercher ailleurs que dans le manifeste agile. Cette règle n°2 vise à apporter du discernement lors de l’utilisation du mot agile.

A venir: règle n°3 – Le burndown est publié tous les jours après le standup.

Le coin de la technique

• Vert.x 1.0, le node killer ? (par Aurélien Maury)
• Hive 0.9 (par Bertrand Dechoux)

Le coin de la technique

Vert.x 1.0, le node killer ?

Vert.x est un nouveau framework applicatif inspiré par Node.js tournant sur la JVM (7 uniquement). Vert.x expose son API en Java, et Groovy, mais également en Ruby et JavaScript (merci à JRuby et Rhino). Les supports de Scala, Clojure et Python sont sur la roadmap. Et la version 1.0 vient juste de sortir.

Il y a un certain nombre de composants out-of-the-box :

• un bus évènementiel distribué (entre les instances Vert.x qui supportent un mode cluster)
• gestion des WebSockets
• gestion de SockJS
• un persisteur MongoDB

Parmi les fonctionnalités clés :

• Polyglotte : Il est possible de choisir entre les langages supportés pour son application, ou de mixer selon les modules et de les faire communiquer via le bus évènementiel.
• Modèle de concurrence simplifié : Vert.x permet d’écrire son code comme single-threadé, tout en exploitant au maximum les capacités de la machine.
• Modèle de programmation asynchrone et librairies pour écrire de vraies applications non bloquantes.
• Le bus évènementiel inter-module traverse les cotés client et serveur pour les faire communiquer de façon transparente.

Les briques sous-jacentes incluent : Netty, JRuby, Rhino et Hazelcast. Ce projet parait très prometteur et est sponsorisé par SpringSource (donc VMWare). Tout y est, une bonne documentation, des exemples de code à la pelle et il est également possible de l’embarquer sans soucis (et comme tout framework qui se respecte, les benchmarks).

Prenez quelques minutes pour en savoir plus. Il devrait faire parler de lui sous peu.

Autour du sujet : une interview sur InfoQ et un post de blog sur le déploiement d’application Vert.x sur Heroku.

Hive 0.9

Hive est un outil de requêtage inspiré de SQL pour Hadoop MapReduce. Le 30 avril, la version 0.9 est sortie et Cloudera a fourni une vue d’ensemble du changelog. Coté utilisateur, Hive supporte maintenant l’opérateur between, la comparaison compatible avec NULL et quelques nouvelle fonctions dont printf() et sort_array(). Coté performance, la planification et exécution des requêtes a été améliorée pour les UNIONs, pour les jointures coté map et pour les group by multiples.

Certains avaient peut-être oublié qu’OVH est le 4^e hébergeur mondial et qu’ils n’ont pas attendu un plan quinquennal parisien pour lancer leurs ingénieurs dans l’aventure du Cloud.

Iaas, Paas et Saas, nous vous invitons le 22 Mai 19h15 à découvrir les coulisses du Cloud OVH.

Pierre Ourdouillé, staff engineer chez Ovh.com, lèvera le voile sur un des fleurons de l’IT française.

Cette présentation se prolongera autour d’un buffet campagnard.

Inscription et informations pratiques sur EventBrite vous attendent ici pour participer à notre soirée.

Par ailleurs, il reste des places pour les sessions « les essentiels pour aller sur le Cloud » de 10h45 à 18h30, l’inscription et les informations pratiques sont ici.

Actualité éditeurs / SSII

• Sonar 3.0 (par Bertrand Dechoux)
• Oracle reprend Java sous Mac OSX (Par Mathieu Breton)

Le coin de la technique

• Embedmongo : un mongo « light » pour java (par Jean Helou)
• MRUnit 0.9 (par Bertrand Dechoux)
• CDH4, Hadoop en haute disponibilité (par Bertrand Dechoux)
• Guava release 12 (Par François Sarradin)
• Sortie de la version 1.0 de Cloud Foundry Eclipse Plugin (Par Diego Lemos)
• Meteor (Par Xavier Bucchiotty)

Actualité éditeurs / SSII

Sonar 3.0

Cette plateforme de contrôle de qualité de code arrive avec son lot d’améliorations :

• Meilleure gestion de la sécurité : cryptage du mot de passe de la base de données, mots de passe cachés (***), informations sur les licences …
• Définition d’alertes sur les métriques booléennes.
• Nouveau design de la TimeMachine : les curieux pourront regarder le sonar pour sonar et sa TimeMachine.

Oracle reprend Java sous Mac OSX

Flashback ! C’est ce qu’il aura fallu pour qu’Oracle se décide enfin à prendre en charge le développement de la JVM sur Mac OS.

Pour rappel, Flashback est un trojan qui affecte les machines sous Mac OS Léopard et Lion, en utilisant une faille Java permettant de transformer votre machine en BotNet. Ce n’est pas la première fois qu’un problème survient au sujet de la mise à jour de Java sous Mac OS. Fin 2010, la firme de Cupertino avait fait savoir qu’elle ne maintiendrait plus la version de Java pour Mac, et que cela reviendrait donc désormais à Oracle.

Cette décision d’Oracle pérennise le support de Java sous Mac OS, après une longue période d’incertitude (comme l’avait expliqué l’épisode 30 des cast-codeurs). Une bonne nouvelle pour les développeurs fans de laptops à pomme.

On peut donc espérer que les mises à jour et autres corrections de failles de sécurité seront dorénavant beaucoup plus rapides que par le passé ( ~ 6 mois de délais pour certaines failles). Vous pouvez d’ailleurs dès maintenant retrouver le JDK 7 pour Mac OS sur le site d’Oracle.

Le coin de la technique

Embedmongo : un mongo « light » pour java

Il existe plusieurs questions stackoverflow sur la « bonne » façon de faire des tests d’intégration automatisés pour du code qui interagit avec MongoDB. La plupart des réponses invitent à installer un serveur mongo sur la machine et à contrôler l’état du serveur depuis un @BeforeClass / @AfterClass.  Outre que cela rend complexe la parallélisation des builds, on ne maîtrise pas toujours son serveur d’intégration continue.
Heureusement, Michael Mosmann propose une librairie maven qui permet d’émuler le comportement de mongoDB pour les tests. La documentation de la librairie est assez légère pour le moment, mais des exemples commentés sont présents sur stackoverflow et dans un article sur le blog cubeia. (hat tip @samklr pour le pointeur)

MRUnit 0.9

MRunit est un librairie de test unitaire (xUnit) pour Hadoop MapReduce. La version 0.9 vient de sortir. On notera :

• Une façon plus concise d’exprimer ses attentes vis à vis des compteurs.
• L’ordre de la sortie peut désormais ne plus être validé.
• Les combiners peuvent désormais être testés avec l’API mapreduce (la nouvelle) tout comme avec l’API mapred (l’ancienne).
• Un meilleur support des différentes sérialisations en enlevant toute supposition sur celle utilisée.
• De meilleurs messages d’erreurs pour prévenir d’une utilisation incorrecte de la librairie.

CDH4, Hadoop en haute disponibilité

Le 27 décembre 2011, Hadoop est sorti en version 1.0, témoignant de sa maturité. Cependant un problème n’était toujours pas résolu : la haute disponibilité. En effet, le Namenode, le processus responsable de la structure du système de fichier, était un point unique de défaillance (SPOF). En cas d’arrêt de la machine l’hébergeant, aucune action n’était prévue par défaut pour assurer la continuité du fonctionnement du cluster sans intervention manuelle, humaine.

Le 24 avril 2012, Cloudera a annoncé la beta publique de CDH4 (Cloudera’s Distribution Including Apache Hadoop). La haute disponibilité est parmi les avancées majeures décrites. La solution implémentée est une approche maitre-esclave. Les deux processus Namenode se synchronisent sur un espace de stoquage partagé. En cas de défaillance, le Namenode esclave prend la relève évitant ainsi toute coupure de service due à un arrêt du Namenode maitre pour cause de défaillance ou de maintenance.

Guava release 12

Si vous utilisez Guava sur votre projet, c’est le moment de le mettre à jour, car Guava vient de passer récemment en version 12. La grande particularité de cette version est qu’elle brise la compatibilité avec le JDK 5. Vous avez bien lu ! Pour utiliser Guava 12, vous devrez d’abord installer au moins un JDK 6 ou plus, car cette version interagit avec les nouveaux types de collections introduites dans cette version du JDK (Deque, NavigableMap, NavigableSet). Si vous ne pouvez pas décoller du JDK 5, vous pouvez toujours utiliser la version 11.0.2 de Guava.

Pour en revenir à la version 12, voici une liste de certaines nouveautés :

• L’ajout d’un package reflect, contenant des outils pour étendre votre expérience avec la réflexion de Java.
• La classe FluentIterable qui permet de faire des chaînages de méthodes spécialisées dans le traitement de flux (donnant au passage un avant goût de ce que sera Java 8).
• Un début d’utilisation du type Optional dans d’autres classes de Guava (dans FluentInterface et Enums).
• Ajout de la méthode transform() dans Optional qui permet d’appliquer une fonction sur la valeur contenue dans Optional si elle existe. Optional devient un functor au sens théorie des catégories.
• Ajout de nouvelles factory methods pour les collections (newArrayDeque, newCopyOnWriteArrayList, Maps.unmodifiableNavigableMap, etc.).
• Collections2 est capable de générer l’ensemble des permutations d’une collection.
• La classe CacheBuilderSpec vous permet de spécifier le comportement de votre cache en une chaîne de caractères (et éventuellement de charger cette spec depuis un fichier, par exemple).

Sortie de la version 1.0 de Cloud Foundry Eclipse Plugin

La semaine dernière, SpringSource a annoncé la sortie de la version 1.0 du plugin Eclipse pour CloudFroundry. À l’aide du plugin, les développeurs pourront contrôler leurs applications déployées sur CloudFoundry à partir d’Eclipse.

Voici quelques fonctionnalités proposées :

• Déploiement et contrôle des applications à partir du workspace
• Support web : Java native, Spring, Grails et Scala
• Paramétrage des instances et monitoring
• Navigation dans les répertoires du serveur
• Support au debug pour Micro Cloud Foundry
• Amélioration des mises à jour incrémentales

Le plugin peut être installé sur Eclipse Indigo (version recommandée par SpringSource) à partir d’Eclipse Marketplace et également sur STS à l’aide de STS Dashboard.

Pour rappel, CloudFoundry est une plateforme PaaS open source développée par VMware/SpringSouce.

Plus de détails sur l’annonce InfoQ.

Meteor

Meteor, c’est le framework web dont tout le monde parle en ce moment. Vous voulez faire du web, avez une exigence d’avoir un comportement temps-réel, et surtout vous voulez développer rapidement? Vous devriez alors y jeter un coup d’oeil.
Les trois screencasts proposés sont bluffants de simplicité et d’efficacité.
Voici quelques points qu’il faut retenir :

• 1 langage, Javascript
  Tout est en Javascript, côté client bien sûr, mais aussi côté serveur avec Node.JS. Le même code peut être exécuté des deux côtés sans avoir besoin de câbler en RPC. Meteor s’en charge pour vous. La priorité est donnée au code côté client. Ainsi, tout le code Javascript que vous pouvez écrire (en dehors des dossiers réservés public et server) est packagé, compressé et servi aux clients. Le concept est intéressant. Tout le modèle et le métier ne sont codés qu’une seule fois, et chargé indifféremment des deux côtés.
  En outre, il est aussi possible d’utiliser votre framework de templating préféré, Coffeescript ou encore Less sans problème.

• Une base de donnée aussi côté client
  Avec Meteor, on attaque la base de données côté client! Les documents utilisées depuis la base (MongoDB par défaut) sont copiée pour faire un cache client, mais l’API reste la même pour manipuler ce cache ou la base. L’écran est rafraîchi et dans le même temps les modifications de données sont automatiquement envoyées au serveur. Les deux se synchronisent ensuite. Le client adopte l’état du serveur s’il y a conflit. Meteor se charge de la communication entre cette requête côté client et sa diffusion, par un mécanisme publish/suscribe. L’asynchronisme a pour effet de compenser les problèmes de latence des applications sur Internet et d’avoir ce comportement proche du temps-réel.

• Le Live Coding
  Changer votre code HTML, et le résultat apparait automatiquement dans votre navigateur. Cela tient presque de la magie car il n’y même pas recours à un plugin de rafraichissement automatique de la page. Meteor détecte le changement, et l’envoie à tous les clients. En plus de cela, il garde votre contexte (session et DOM après possible manipulation) pour afficher la page avec le même état qu’avant le rechargement. Si vous voulez avoir un retour rapide des effets de votre code, vous êtes servis.

• Deploiement simplifié
  Peut-on faire plus simple?
  Démarrer en local :

  meteor
  

  Déployer votre application sur Internet (ils offrent pour l’instant un service d’hébergement gratuit)

  meteor deploy www.myapp.com
  

  Vous souhaitez vous désengager de Meteor.

  meteor bundle myapp.tgz
  

L’idée est d’avoir une plateforme ouverte avec le moins de contrainte possible. Ils proposent une solution simplifiée. Si elle ne vous convient plus, vous pouvez sortir du framework à tout moment.
Quand on épluche la documentation, on remarque quelques points gênants que Cédric Exbrayat a pris le soin de relever dans ce post sur son blog.

C’est encore frais mais très prometteur. Bien sûr ce framework ne s’applique pas à tous les besoins. Mais en bon craftsman que vous êtes, vous savez déjà adapter les outils à votre cas d’utilisation. Pour vous tenir au courant, ce se passe sur Twitter et github .

Nous vous invitons le 22 Mai 2012 à un Cloud Day chez Xebia. Venez découvrir les conseils des grands du Cloud autour de cas d’études concrets .

Au programme :

• 09h15 – 11h00 : « Meet the CEO » : Questions / réponses avec Sacha Labourey, CEO and Founder CloudBees (nombre de places limitées).
• 11h00 – 18h30 : « Les essentiels pour partir sur le Cloud », des présentations, études de cas et ateliers par les grands du cloud et des professionnels du Cloud (Alexis MP – Google, Carlos Condé – Amazon AWS, Raphël Ferreira – eNovance, …).
• 19h30 – 22h00 : « Les coulisses du Public Cloud made in OVH ».

Retrouvez le programme détaillé et inscrivez-vous.

Le but est de fournir des sujets variés et complémentaires, autour de 5 thèmes :

• Techy : Java et son écosystème,
• Agility : L’agilité pour débutants et passionnés,
• Trendy : Tendances novatrices et avant-gardistes,
• Mixy : Le meilleur de l’agilité et des technologies Java,
• Gamy : Jeux agiles et coding dojos.

Cet évènement est organisé par le Lyon JUG et le Club Agile Rhône-Alpes.
En vrac, on y parlera de : Play 2.0, Kanban, HTML5, Automatisation des tests, BigData/Hadoop, Lean Startup, DevOps, Social architecture et bien d’autres sujets.

Xebia participe évidemment à cet évènement en animant 2 slots :

• BigData/Hadoop, exploiter des téraoctets de logs, par Pablo Lopez.
• Automatisation des tests, le mythe du ROI, par Gilles Mantel

Vous pouvez découvrir le programme complet ici et suivre la conférence en direct ici.

À tout moment de la journée peut retentir cette fameuse phrase: « Mais qui a (encore) cassé le build ??« 
Il y a alors plusieurs stratégies d’équipe :

• ce n’est pas grave, cela arrive tout le temps. Cela va bien finir par passer au vert !
• celui qui casse paie et corrige le problème
• l’ensemble de l’équipe se sent concerné, une personne se dévoue pour enquêter et corriger le problème.

La règle d’or : aucune modification ne peut être apportée sur le code tant que l’intégrité du projet n’est pas restaurée.
Une fois le problème résolu, au Scrum Master de créer un système à base de croissants à offrir, de cagnottes à remplir, d’avatars à afficher ou encore de lance-missile USB pour que cela se produise le moins souvent possible.
Une carte Xebia Essentials illustre cette démarche : NO BLAME BUT NO MERCY.

Vient alors l’idée de s’assurer que le commit que je me prépare à envoyer correspond un minimum aux critères de validation de l’intégration continue. Le processus de validation doit être automatisé et en mode bac-à-sable (son exécution ne doit perturber personne).

Personal Build dans Teamcity

Le serveur d’intégration continue Teamcity, de Jetbrains, propose ce service sous forme de personnal build. On peut les déclencher à la demande. Ces jobs ne sont pas visibles aux autres utilisateurs et des plugins permettent d’être averti dans l’IDE du résultat de build.
Cela présente l’avantage de déporter la charge de compilation et tests à des serveurs d’intégration. Vous économisez ainsi de la mémoire et de la CPU sur votre poste de développement.
Si vous utilisez un gestionnaire de source non-distribué (comme SVN), vous pouvez alors déclenchez des Personal Builds sur vos modifications prêtes à être commitées.

Cela va transmettre vos sources sous forme de Patch à Teamcity. Celui-ci va ensuite lancer le job de votre choix. Si le build est un succès, vous avez gagné le droit de voir vos sources promues sur le repository. Sinon, l’IDE vous invite à corriger les erreurs remontées et à retenter votre chance plus tard.
Cette solution est simple et rapide à mettre en place. Teamcity est gratuit jusqu’à trois agents et vingt projets.

Seulement avec Git, Teamcity peut seulement exécuter des Personal-Build sur vos changements en cours, ou vos commits en attente. Il ne pourra pas (en version actuelle) les pousser si le résultat du job est OK.

Personal Build en script

Chez notre client, nous avons donc développé une solution pragmatique qui serait indépendante du serveur d’intégration, une solution à base de script. Pour l’environnement de travail, nous avons :

• MacOS
• Git
• un projet Java
• Maven
• un serveur d’intégration pour chaque développeur, avec les mêmes versions de JDK, Maven et serveur d’application, et un repository Git local

Comme chaque développeur possède sa machine virtuelle distante, chacune d’entre elles possède un repository local Git. On peut alors pousser ses commits sur cette machine, et avec Maven, lancer une liste de tâches pour vérifier l’état des commits.

Initialisation du repository Git distant

Voici la liste des commandes Git pour initialiser ce repository distant:

git init .
git config receive.denyCurrentBranch ignore
git config receive.denyDeleteCurrent ignore

Les deux commandes précédentes permettent à Git d’autoriser un repository distant (celui du développeur) à modifier et supprimer la branche qui est en cours de checkout (interdit par défaut).

Le script côté développeur

Le script repose essentiellement sur la puissance de Git et de communication SSH pour lancer des commandes Maven. Le principe est simple

• Récupération des sources depuis origin
• Détection en local de la branche courante ainsi que la dernière révision à pousser
• Envoi du code sur la machine distante
• Exécution des tests sur la machine distante
• Si tous les tests passent, les sources sont envoyées sur origin.

Le script est disponible sur le repository Github.com de Financeactive (https://github.com/financeactive/fa-toolkit/). Il contient certes des commandes de tests spécifiques au projet mais reste simple à lire.

Schéma descriptif

La solution est détaillée sur ce schéma.

Description de la solution

Vous souhaitez plus d’explication sur le fonctionnement du script ? Voici la liste détaillée de ses étapes.

1. Détection des informations suivantes :

git rev-parse --show-toplevel #Root du projet en cours
git rev-parse --symbolic --abbrev-ref $(git symbolic-ref HEAD) #Branche locale de travail
git log --pretty=%H -1 #Dernière révision à pousser 
git config branch.$CURRENT_BRANCH.remote #L'alias du remote associé à cette branche
git config remote.$REMOTE_ALIAS.url #L'url du remote
git config branch.$CURRENT_BRANCH.merge #Le nom de la branche remote suivie

2. Présentation à l’écran de la liste des commits prêts à pousser

git log $REMOTE_ALIAS/$REMOTE_BRANCH.. --format='; ;%Cred%h%Creset;%C(yellow)%cd%Creset;%f' --date=iso | column -t -s';'

3. Vérification de l’état du repository local avant de faire le pull

git status --porcelain | grep -v '??' | wc -l

==> S’il y a des modifications en cours (fichiers suivis par Git, modifiés mais non commités)

=> SI OUI

git stash

==> SINON RIEN

4. On récupère l’historique distant

git pull $REMOTE_ALIAS $CURRENT_BRANCH

==> S’il y avait un stash

git stash pop

5. On recharge la révision à tester car le pull a pu créer des commits de merge ou de rebase

git log --pretty=%H -1

6. On tente un push en dry-run pour détecter au plus tôt les possibles problèmes de merge

git push -n  $REMOTE_REPO $CURRENT_REVISION:$REMOTE_BRANCH

exemple : git push -n origin f313ae:master

7. On envoie le code sur la VM

git push remote-run +$CURRENT_BRANCH:$CURRENT_BRANCH

Le + avant current-branch permet de forcer l’update quoi qu’il arrive, après-tout c’est votre VM, vous en faites ce que vous voulez. Attention, ne surtout pas utiliser sur Github. Vous écrasez alors tout l’historique de Github avec le vôtre.

8. Sur la VM, on charge la branche

Le git push n’envoie que les blobs dans le répertoire .git. Pour que cela ait un impact sur le filesystem, il faut faire :

git checkout -f ${CURRENT_BRANCH}
git clean -df

Le git clean permet de supprimer les fichiers non trackés par git (dans le cas de passage de master à patch par exemple)

9. Lancement de tous les tests

mvn clean install #via SSH

10. On pousse si tout va bien

git push $GIT_DRY_RUN $REMOTE_REPO $CURRENT_REVISION:$REMOTE_BRANCH

Le fait d’utiliser la commande git push, avec le nom de la révision, le remote et la branche, permet de continuer à travailler sur son environnement local sans soucis. Vous pouvez même changer de branche durant l’exécution du script. Cela n’aura pas d’impact sur le code envoyé en cas de succès. La seule possibilité est d’amender le dernier commit en cours de test. Mais le but de ce script est d’aider le développeur, pas de l’empêcher de faire ce qu’il veut.

Nous avons créer un alias sous git pour appeler ce script. Ainsi, un git remote-safe-push nous lance la validation de notre code avant le push. Nous n’utilisons pas de hook pour permettre une plus grande flexibilité.

Retour d’expérience

L’exécution dure aujourd’hui quinze minutes. Cela peut paraître aberrant d’attendre autant de temps pour pouvoir pousser votre code sur le repository central. Mais vous n’êtes pas obligés d’attendre la fin du script pour continuer de travailler. Il y a donc très peu d’impact pour le développeur.

Dans son discours sur le déploiement continu lors du dernier Devoxx, Dave Farley aborde ce sujet. Il explique que dans son équipe, chaque développeur devait attendre la fin de l’intégration continue pour son commit avant de prendre une autre tâche. Ils n’avaient pas à ce moment de « Personal Build ». Chaque développeur s’assurait donc que son commit n’allait pas impacter les autres. Quand on pense chaque commit comme une release-candidate, cela change la vision des choses !

C’est une solution simple et pragmatique qui répond au besoin : garder une intégration continue en parfait état. Elle est personnalisable et facile à mettre en place. Elle est aussi évolutive ; ajouter des tests fonctionnels avec Selenium, de charge avec JMeter, ou plein d’autres choses reste possible car après tout, c’est un script.
Si vous envisagez de faire du déploiement continu, cela présente encore un avantage. Vous pouvez déjà tester votre procédure de déploiement de production sur cette machine, et cela plusieurs fois par jour et par développeur. Il n’est jamais facile d’avoir un environnement local identique à la production. La virtualisation est une bonne technique pour palier à cela. Si vous pensez à utiliser des solutions cloud de type PaaS, le script peut permettre aussi de tester la création d’instances à la demande, de tester l’installation complète d’un environnement d’un serveur, d’une base de données, ou encore de tester les configurations des proxys.

Nous envisageons d’ailleurs d’utiliser la virtualisation. Des outils comme Vagrant permettent de créer des machines virtuelles sur VirtualBox. Puppet peut ensuite nous permettre de monter un environnement similaire à la production mais en local. Toute la chaîne de déploiement est ainsi testable en local.

Le script personnalisé revêt néanmoins quelques inconvénients. Il ne nous permet pas de gérer des files d’attentes de jobs, ou de l’intégrer pour l’instant dans l’IDE. Plus le temps entre la commande git pull (je reçois) et git push (j’envoie) est long, plus le risque d’avoir un commit « étranger » poussé entre-temps est grand. Git ne vous permettra pas de pousser un seul commit si votre historique n’est pas à jour. Vous serez alors condamné à mettre à jour votre historique local avant de pousser. Il faut donc trouver l’équilibre à mettre en place dans ce mécanisme, pour ne pas rendre l’envoi de modifications complètement impossible. Nous avons avec notre client l’objectif de descendre sous la barre des 10 minutes, ce qui nous semble un temps satisfaisant.

Cette solution nous a permis d’augmenter la qualité globale de l’application en encourageant les développeurs à faire des tests. Depuis, nous poussons notre code beaucoup plus régulièrement. Cela permet d’avoir des retours toujours plus rapides sur nos stories de la part de l’équipe produit.

Un dernier petit inconvénient (c’est à voir) : si vous aviez choisi la méthode « croissants » au petit-déjeuner pour limiter le nombre de casseurs de builds, il faudra vous trouver autre chose pour avoir des viennoiseries le matin !

source image http://www.geekandpoke.com

A travers la création de Xebia Studio, nous cherchons à répondre à un défi de taille : Réaliser des applications innovantes, dans des délais courts avec une qualité et une robustesse irréprochables, le tout dans un climat de confiance et de transparence. Un doux rêve ? Tout est question d’ambition, de culture et d’organisation.

Notre conviction profonde est qu’il est possible de développer des logiciels autrement que ce qui se fait depuis des années, en plaçant la qualité au centre du développement, en accueillant favorablement le changement et en s’imprégnant intimement du métier et des contraintes de nos clients.

Notre philosophie pourrait se résumer en deux mots : Software Craftsmanship.
“Craftsmanship” est difficile à traduire (et à prononcer), il s’agit d’un état d’esprit très particulier que Bob Martin décrit ainsi dans son livre « Clean Coder » :

“Un craftsman est une personne qui travaille rapidement, mais sans précipitation, qui donne des estimations réalistes et qui tient ses engagements. Un craftsman sait dire non, mais fait tout son possible pour dire oui. En un mot, un craftsman est un professionnel.”

D’un point de vue opérationnel, nous construisons des équipes de développeurs agiles expérimentés et complémentaires. Nous proposons à nos clients un mode de co-développement qui permet d’embarquer dans le projet un ou plusieurs développeurs de leurs équipes. Pour nos clients, c’est une garantie d’être au même niveau de connaissance de l’application que nous et ainsi de gagner très rapidement en autonomie. Pour nous, c’est un moyen de s’aligner rapidement sur la culture et les contraintes de notre client.

Nos choix technologiques sont pragmatiques : pas de frameworks inutiles ni d’architectures alambiquées. Un projet réussi c’est avant tout des fonctions utiles à ses utilisateurs. La technologie se met au service du projet et pas l’inverse. Notre expérience et notre connaissance des solutions de PaaS (Platform as a Service) nous permettent de démarrer un projet en moins d’une journée et de délivrer en production et en continu des applications disponibles pour les utilisateurs.

Nous mettons en oeuvre les meilleurs pratiques d’ingénierie conformément aux valeurs de l’eXtreme Programming et nos projets sont tous conduits suivant la méthode agile Scrum.

D’un point de vue contractuel, nous jugeons le forfait incompatible avec notre philosophie agile. Nous privilégions un contrat agile porteur d’engagements forts de notre part.

Nous cherchons en permanence de nouveaux talents pour renforcer nos équipes. Si vous avez déjà plusieurs années d’expérience et que vous êtes fiers de dire : “Je suis développeur !”, alors n’hésitez pas, postulez !

Pour tout ceux qui auront la chance d’y être, nous vous invitons à venir nous rencontrer à Devoxx France sur le stand de Xebia.

Le code source est publié sous license MIT. Nous vous encourageons bien entendu à aller le consulter, le forker ainsi qu’à partager vos retours d’expériences autour de développements d’applications mobiles basées sur des technologies web.

Génèse et objectifs

Le développement de l’application s’est focalisé autour des axes et objectifs suivants :

• Explorer les technologies web pour développer une application mobile, que cela soit par l’utilisation d’HTML5 et CSS3 via le cadre de développement proposé par la librairie jQueryMobile ou bien par l’intégration de différentes librairies JavaScript telles que Require, Backbone, Underscore ou Lawnchair.
• Mettre en oeuvre PhoneGap et son usine logicielle en ligne PhoneGap Build pour délivrer des applications web encapsulées dans des coquilles natives afin de pouvoir les publier sur les markets Android, Chrome ou bien encore iOS.
• Fournir une application qui sera utilisable sur l’ensemble des matériels du marché et vérifier dans quelle mesure les applications mobiles web peuvent se comparer aujourd’hui face aux applications natives. 
• Développer une application ayant une base de code unique afin d’éviter d’avoir à gérer la fragmentation des plateformes.
• Etre en mesure de répondre à un cahier des charges complet en un temps réduit. Ce cahier des charges comprenant:
  • Le développement des différents écrans applicatifs : Liste des sessions par journée avec affichage complet des détails, ainsi que les listes et détails des speakers, des salles, et des tracks.
  • La gestion et le stockage des favoris (On parle ici des sessions)
  • La présentation du programme Xebia pendant les 3 jours de la conférence
  • Une application étant capable de fonctionner en mode offline avec synchronisation et stockage des données
  • Un affichage de la timeline twitter XebiaFr et DevoxxFr
  • Un fonctionnement effectif sur un ensemble étendu des matériels allant du téléphone au PC en passant par la tablette quelque soit l’OS

Un premier bilan

Le pari du développement d’une application mobile web fonctionnant sur un grand nombre d’OS et de matériels est un succès. L’application fonctionne aussi bien sur des plateformes mobiles telles qu’iOS ou Android que sur les navigateurs web classiques. Malgré des avantages évidents, le développement mobile web n’est pas exempt de difficultés. Pour rendre compte de cela nous allons tenter de dresser une liste de points positifs et des difficultés rencontrées au cours du développement de l’application.

Les points positifs

Un développement unifié

Un aspect majeur vient du fait qu’il n’a pas été nécessaire de gérer différentes bases de code. Le travail de gestion de la fragmentation n’a été que secondaire.

Bien que la plateforme web propose un mode de développement unifié avec les technologies HTML, CSS et JavaScript, les différentes OS et matériels imposent des contraintes variées qui peuvent apporter des problématiques venant complexifier les développements : taille de l’écran, performance des navigateurs, latence et vitesse des réseaux de données, etc.

Afin de ne pas se tromper, il est nécessaire de s’assurer de la plateforme cible principale et d’y apporter une expérience utilisateur optimale, vous pouvez ensuite vous assurer du bon fonctionnement des développements sur les environnements cibles secondaires. Il n’est pas difficile dans le cas d’un développement mobile de faire fonctionner l’application dans un navigateur classique. Il est d’ailleurs possible en introduisant quelques notions de Responsive UI d’obtenir un résultat efficace sur l’ensemble des navigateurs.

Les principaux navigateurs mobiles étant basés sur WebKit, il est possible de travailler la majorité du temps avec un navigateur desktop compatible tel que Chrome ou bien Safari. Il est cependant nécessaire de tester dès le départ ses développements sur mobile pour éviter les mauvaises surprises. Pour cela, rien de plus facile, il vous suffit de préparer une configuration Apache pointant sur vos développements, ce qui rend accessible votre application sur vos matériels mobiles via Wifi sans même avoir à déployer quoi que ce soit. Il est biensûr important d’avoir un environnement de recette disponible sur un hébergement externe afin de rendre vos développements testables sur d’autres matériels auxquels vous n’avez accès qu’occasionnellement.

Ce dernier point soulève la problématique du déploiement. Heureusement le déploiement d’une application web n’a rien de bien complexe, et quelques commandes de scripts répondront avec succès à vos besoins.

Des technologies maîtrisées

Les technologies web ont pour avantage d’être généralement déjà maîtrisées par les équipes de développement, par conséquent leur coût d’apprentissage reste faible. Le web fourmillant de tutoriaux, il est facile de trouver les informations dont vous avez besoin pour démarrer ou progresser dans vos développements.

Ce qu’il faut retenir c’est qu’il n’est plus nécessaire d’apprendre les arcanes du SDK de chacune des plateformes que vous ciblez! Le gain à ce niveau est extraordinaire, vous n’avez à vous concentrer que sur une seule technologie ce qui favorise votre montée en compétences, et vous permet d’éviter de vous disperser. Ceci est d’autant plus vrai lorsque vous avez une équipe restreinte à disposition : vous n’aurez qu’une seule application à peaufiner, à maintenir ou bien encore à débogguer. Vous irez d’autant plus vite à fournir une solution viable à vos utilisateurs sans entraîner de déception en excluant telle ou telle plateforme.

Les difficultés

Des problèmes d’intégration

jQueryMobile est une formidable librairie mobile adressant avec succès la fragmentation des plateformes, mais pour autant cette librairie n’est pas exempt de défaut. La gestion des hashtags ne permet pas jusqu’à présent de traiter correctement les paramètres d’URL, ceci reste secondaire puisqu’il est possible de contourner le problème en utilisant un routeur externe tel que celui fourni par le projet jQueryMobile Router. Il est à noter que jQueryMobile ne s’intègre pas parfaitement avec le router de Backbone au moins dans sa version 1.0, il reste à vérifier si la situation a changé avec la version 1.1 de la librairie.

Des problèmes de performance

Les environnements mobiles sont contraints par les performances des processeurs qui équipent votre matériel. De surcroît, de nombreuses optimisations Webkit ne sont pas intégrées aux navigateurs mobiles actuels. Les différences se jouent également sur différents aspects selon les plateformes. Ainsi, la plateforme Android propose de faibles performances concernant les animations CSS, tandis que la plateforme iOS a du mal à optimiser le scroll ce qui pose des problème de transition entre les page d’une application jQueryMobile (Ce problème est décrit dans le changelog de la version 1.1).

Des fonctionalités manquantes

Il n’est hélas pas possible de reproduire l’ensemble des fonctionnalités d’une application native dans une application mobile. Il n’est ainsi pas possible de synchroniser des données en tâche de fond avec les technologies web actuelles. Seuls les WebWorkers pourraient répondre à cette problématique, cependant ils ne sont pas encore supportés correctement sur la majorité des plateformes mobiles. Il est donc nécessaire d’étudier dès le démarrage de votre projet mobile les solutions de contournement possibles.

Le piège de la validation

Attention à ne pas sous-estimer la difficulté de passer l’étape de validation de votre application sur le market iOS. S’y prendre en avance n’est parfois pas suffisant. Apple conditionne l’acceptation des applications à des contraintes extrêmement sévères. Par exemple, une application fonctionnelle mais juste correcte visuellement n’est pas nécessairement suffisante. Si vous voulez mettre toutes les chances de votre côté, il est nécessaire de mettre en avant les possibilités et les qualités de la plateforme iOS. Il est également nécessaire de soumettre uniquement des applications avec un graphisme irréprochable, proposant de préférences des fonctionnalités inédites et originales. 

Il faut également savoir que les applications HTML5 peuvent être refusées pour le simple motif qu’elles n’utilisent pas de fonctionnalités natives, et cela même si aucune application ne propose encore la même fonctionnalité sur le market. Dans ce cas, Apple vous enjoint à proposer votre application via le web. Ce dernier point peut être très dommageable en terme de diffusion et de retour sur investissement. Il est donc nécessaire de prévoir d’exploiter des fonctionnalités natives d’iOS si vous voulez mettre toutes les chances de votre côté. Les solutions sont nombreuses, vous pouvez par exemple utiliser les notifications iOS via PhoneGap et le tour est joué. Quelques tests de support de fonctionnalités natives dans votre code via la présence des API PhoneGap suffiront à faire l’affaire.

A toutes fins utiles, sachez qu’il faut attendre en moyenne 9 jours pour que votre application passe la validation Apple. Prévoyez également la possibilité que votre application soit refusée et qu’il faille la soumettre à nouveau. Ceci nous amène à un délai d’au-moins un mois. Il est nécessaire d’anticiper ces délais si vous ne voulez pas avoir de mauvaises surprises !

Conclusion

Le développement d’applications mobiles viables basées sur des technologies web est bel et bien aujourd’hui une réalité, mais les difficultés sont encore nombreuses, et le support des technologies et des pratiques demandent encore à mûrir. Cependant les choses évoluent très vite, et même si nous sommes aujourd’hui dans un trou technologique entre une fragmentation des développements natifs de plus en plus difficile à adresser et une plateforme de développement unifiée autour des technologies web qui ne demandent qu’à mûrir, il serait dommage de rester là à regarder le train passer sans se mettre à apprendre ce qui sera sans aucun doute une solution de premier choix dans un futur très proche !

Découvrez donc 9 mini TechEvent (dans l’idée de ceux que Xebia a l’habitude de proposer gratuitement à l’ensemble de la communauté Java) sur notre stand.

Pour participer, rien de plus simple, rendez vous directement sur notre stand, à l’heure et au jour indiqué ci-dessous en fonction de vos envies.

• Les 9 mini TechEvent
  • Lego Mindstorm Fight
  • Découvrez la Programmation Fonctionnelle
  • TDD en Pair Programming
  • Déployez du Grails sur Heroku
  • Continuous Deployment avec Jenkins
  • Big Data avec Hadoop
  • Troubleshooting d’application
  • MongoDB
  • Déploiement Continu avec DeployIt
• Xebia vous propose de gagner un MacBook Air !
• Retrouvez tous nos speakers
• Ne manquez pas Code story !

9 mini TechEvent

Lego Mindstorm Fight

Programmez votre robot en Java sur notre stand et affrontez ceux des autres participants dans un tournoi de sumo.
Par sessions de 30 minutes : Mercredi à 12h30 ; Jeudi à 11h00, 12h55 et 16h30 ; Vendredi à 12h55 et 16h30.

Découvrez la Programmation Fonctionnelle

Envie de voir à quoi ressemblera les lambda dans Java 8 ? Découvrez les en action dans cet atelier de programmation fonctionnelle en « pairant » avec un xebian. Au programme : Java 8, flèches, Guava, cartes et ticket.Par sessions de 15 minutes : Jeudi à 10h45 et 17h55.

TDD en Pair Programming

Que vous soyez Padawan ou Jedi, venez découvrir ou vous améliorer en TDD.
Par sessions de 15 minutes : Jeudi à 12h25 et 15h25.

Déployez du Grails sur Heroku

Une application Facebook en 15 minutes avec Grails et Heroku. Deviendrez-vous le prochain Instagram ?
Par sessions de 15 minutes : Jeudi à 12h40 et vendredi à 15h25.

Continuous Deployment avec Jenkins

Scriptez le déploiement continu d’une appli avec Jenkins et Rundeck.
Par sessions de 15 minutes : Mercredi à 11h00 et vendredi à 14h20.

Big Data avec Hadoop

Découvrez les bases du map /reduce avec Hadoop en mettant en valeur les mots-clés les plus twittés de Devoxx.
Par sessions de 15 minutes : Mercredi à 15h00 et vendredi à 10h45.

Troubleshooting d’application

Devenez un héros de la performance en traquant impitoyablement les bugs de notre application web.
Une session de 30 minutes : Vendredi à 11h00.

MongoDB

Mettez un pied dans le NoSql avec le phénomène du moment.
Par sessions de 15 minutes : Jeudi à 14h20 et vendredi à 12h25.

Déploiement Continu avec DeployIt

Découvrez DeployIt, un outil d’automatisation des déploiements.
Par sessions de 15 minutes : Mercredi à 17h15 et 17h55.

Xebia vous propose de gagner un MacBook Air !

Pour gagner, n’oubliez pas de vous inscrire à notre tirage au sort, via le formulaire d’inscription de notre application Mobile Devoxx France 2012.
Vous pouvez aussi vous inscrire directement sur notre stand.
Le tirage au sort aura lieu jeudi 19 avril, à 19h00.

Retrouvez tous nos speakers

• BigData et Hadoop au secours de téraoctets de logs inexploitables chez l’un des plus grands sites marchands du web européen, par Pablo Lopez, jeudi à 17h00/17h55 (salle la seine C).
• Pour un développement durable, par Frédéric Dubois, jeudi à 18h05/19h00 (salle la seine C).
• Changeons la conception de nos applications grâce aux services Cloud, par Cyrille Le Clerc, vendredi à 11h30/12h25 (salle la seine B).

Ne manquez pas Code story !

David Gageot et Jean-Laurent de Morlhon, coderont avec leur équipe (Eric Le Merdy & Sébastian Le Merdy) une application en direct pendant 2 jours.
L’idée : Produire une application exceptionnelle tout en montrant au public des techniques exceptionnelles.

L’équipe Xebia vous souhaite un excellent Devoxx France 2012 !

Actualité éditeurs / SSII

• Amazon dévoile CloudSearch (par Bertrand Dechoux)
• …Et Apache dévoile Lucene et Solr 3.6 (par Alexandre Dutra)

Agilité

• Premier Agile Games France (par Gilles Mantel)

Web

• Frameworks en Javascript : réactifs et innombrables ! (par Jean Helou)

Actualité éditeurs / SSII

Amazon dévoile CloudSearch

Amazon ajoute un moteur de recherche en mode PAAS à son portefeuille de services: CloudSearch. Le coût est lié aux nombres et à la taille des instances, Amazon déterminant quelle est la meilleure configuration. Ce nouveau produit est une sérieuse alternative à l’utilisation d’un cluster Solr ou ElasticSearch qu’il faut administrer par soi-même. CloudSearch est actuellement en bêta, limité à un maximum de 50 instances et possède certaines limites comme l’explique la FAQ et le forum. L’anglais est la seule langue supportée et le moteur ne supporte a priori pas le highlighting ou les recherches spatiales. Mais on peut s’attendre à voir cette offre s’améliorer, une fois le business model confirmé.

…Et Apache dévoile Lucene et Solr 3.6

Hasard du calendrier: Apache vient d’annoncer la sortie conjointe de Lucene et Solr en version 3.6.

Parmi les nouveautés à la clé, outre le support emblématique de Java 7, nous pouvons citer les suivantes:

• Analyse et recherche:
  • Le filtre HTMLStripCharFilter, utile pour indexer du texte en HTML/XML, a subi un lifting complet corrigeant de nombreux bugs tout en en améliorant les performances.
  • De nombreux analyseurs sont désormais capables d’appliquer automatiquement une insensibilité à la casse aux recherches de type wildcard portant sur des champs de type TextField; cela se fait par l’ajout d’un attribut ignoreCaseForWildcards="true" à la déclaration du champ.
  • De nouveaux analyseurs et tokenizers pour le Japonais, fondés sur Kuromoji, permettent désormais une prise en charge out-of-the-box du Japonais dans Solr.
• Mémoire et Performance:
  • En plus du cache LRU, un nouveau cache LFU est désormais disponible; un cache ARC serait également à l’étude.
  • Amélioration des performances de tous les suggesters fondés sur des automates de type Transducteur fini.
• Mode cluster:
  • Le faceting par plage de valeurs (dates et nombres) est désormais compatible avec Solr en mode distribué.
  • Nouvelles options pour la configuration des niveaux de concurrence pour les recherches distribuées: le pool de threads utilisé par les noeuds agrégateurs est désormais totalement configurable pour un équilibre optimal entre débit et latence.
• API cliente (SolrJ):
  • Un nouveau connecteur SolrJ est disponible, s’appuyant sur Apache Http Components, le successeur de Commons HttpClient.
  • StreamingUpdateSolrServer, l’implémentation recommandée en cas de mises à jour massives en mode batch, supporte désormais tous les formats reconnus, y compris le protocole binaire propre à Solr (aka Javabin).

A noter que la version 3.6 sera probablement la dernière de la branche 3.x de Lucene, qui a fêté ses 10 bougies l’année dernière. La version 4.0 de ce qu’il convient désormais d’appeler le projet unifié Lucene/Solr devrait notamment apporter SolrCloud, mais celle-ci n’a pas encore de date de sortie arrêtée, bien qu’une bêta release semble se préciser.

Agilité

Premier Agile Games France

Les 11 et 12 Mai prochains se tiendra à Nantes la première conférence uniquement basée sur les jeux en milieu professionnel. Devant le succès de ce thème lors d’événements agiles, comme la Scrum Night en décembre dernier, et l’utilisation grandissante des jeux pédagogiques en milieu professionnel, un petit groupe d’agilistes a mis au point cette conférence en s’inspirant des références que sont Play4Agile en Allemagne, ou Agile Games à Boston. Cette conférence est organisée sur le format Open Space, c’est-à-dire sans ordre du jour précis: venez avec vos jeux, ou avec la liste de ceux auxquels vous voudriez jouer, et vous trouverez des participants pour partager une expérience enrichissante. Cette conférence sera sûrement le bon moment pour découvrir ou redécouvrir des jeux agiles qui ont prouvé leur efficacité comme le XP Game, ou le Business Value Game, mais aussi de jouer à des jeux plus expérimentaux comme FearlessJourney. Vous pouvez réserver votre place dès maintenant sur la billetterie en ligne ou lire le communiqué de presse si vous souhaitez plus d’information.

Web

Frameworks en Javascript : réactifs et innombrables !

Le site « A list apart » nous propose un article sur la création rapide de prototypes d’IHM réactive en Javascript avec le framework Foundation. Si vous vous demandez ce qu’est une application réactive, vous trouverez sur le même site un article expliquant la conception web réactive. En deux mots, il s’agit d’avoir un site dont le contenu et la mise en page s’ajustent automatiquement à la taille de la zone de rendu. Le framework Foundation est un concurrent de Twitter Bootstrap, qui tente d’éviter l’uniformisation naturelle amenée par ce type de framework en incitant fortement la surcharge de l’apparence de par sa conception. Foundation ne favorise pas le mobile et n’est pas totalement sémantique mais il ne pollue pas trop le code HTML et offre quand même des moyens d’ajuster le layout pour le mobile et mérite d’être investigué ne serait-ce que pour du prototypage.
Dans le même temps, Scott Hanselman publie un glossaire, ou plutôt une liste, de frameworks web et Javascript open source « with cool names« . A sa lecture, on voit vite que le choix d’un framework ou d’une librairie n’est pas encore aussi simple qu’il peut l’être côté serveur où les choix sont plus restreints et peut-être plus mûrs. Ces frameworks sont plutôt orientés sur l’organisation et la mise en oeuvre de logiques métiers côté client: ils viennent donc en complément de Foundation ou de Bootstrap.

Programmez votre robot en java et affrontez ceux des autres participants dans un tournoi de sumo !

Le tournoi débutera mercredi à 12h30 sur le stand de Xebia et se terminera le vendredi à 16h30 par un tirage au sort sur l’ensemble des participants pour déterminer le grand gagnant d’un super Robot Lego Mindstorm ! Des goodies Lego et des decks Xebia Essentials sont également mis en jeu !

Rendez-vous sur notre stand dès mercredi

Les règles ne sont pas classées dans un ordre précis, ni même regroupées par thème. Même si certaines le sont parfois, nous les avons simplement listées dans l’ordre de notre réflexion. En revanche, nous avons choisi avec soin la règle n°1 car c’est une place symbolique et il fallait une règle emblématique. La règle n°1 c’est là où tout commence, la base de la base, la règle dont on se souvient.

Règle n°1 : Connais tes valeurs agiles

Nous commençons donc notre liste avec une règle pleine de bon sens et à la limite de l’évidence pour tout agiliste qui se respecte. Mais la réalité n’est hélas pas aussi triviale. Lors de notre session au Scrum Day et avant de dévoiler cette première règle, nous avons posé les questions suivantes à la cinquantaine de participants:

- Qui pratique l’agilité au quotidien ? Pouvez-vous vous lever ?

90% de la salle était debout.

- Qui connait par coeur les 4 valeurs du Manifeste Agile ? Si vous ne pouvez pas citer les 4 de mémoire asseyez-vous

Il restait moins de 10 personnes debout.

- Qui connaît par coeur les 12 principes du Manifeste Agile ?

Les dernières personnes debout se sont assises.

Cette étude de marché complètement improvisée est malheureusement assez représentative de notre niveau de maîtrise des valeurs de l’agilité. Et je m’inclus dans ce constat, car je suis bien incapable de citer de mémoire les 12 principes qui découlent des 4 valeurs. Il se trouve que le manifeste agile est plein de bonnes ressources et que les réponses à certains des problèmes que nous rencontrons sur le terrain se trouvent souvent dans ce manifeste.

Le manifeste agile nous pousse également à garder du discernement dans l’application d’une méthode agile. Tout agiliste fait des compromis avec la méthode qu’il applique, que ce soit Scrum, XP, ou autre. Ce qui est important c’est d’être cohérent avec les valeurs qui sous-tendent cette méthode, et ces valeurs sont celles du manifeste. Par exemple, je vois sur le terrain des équipes se perdre dans des débats sur par exemple le manque de formalisme des critères d’acceptation, alors même que le Product Owner est un nouvel arrivant qui connaît à peine son produit. Voici un syndrome typique d’une équipe qui a remis l’accent sur le suivi d’un processus, certes agile, plutôt que de chercher si les individus sont les bons et s’ils ont les bonnes interactions avec eux.

Autre exemple d’un principe souvent oublié: « Business people and developers must work together daily throughout the project. » Est-ce le cas dans votre projet agile ?

Beaucoup des règles qui suivent dans notre liste ne seront qu’une pâle redite du manifeste, c’est pour cela que s’il ne doit rester qu’une règle c’est la n°1. Relisez le manifeste et les 12 principes qui en découlent. Si vous avez réappris un élément de base, laissez nous un commentaire

A venir : règle n°2 – Le Manifeste Agile n’est pas la déclaration des droits du développeur.

Chez Xebia, nous nous sommes creusés le ciboulot pour vous proposer une solution originale et innovante qui soit utilisable sur votre téléphone préféré, qu’il soit équipé d’Android, d’iOS ou bien encore d’un système super Geeky !!

Fonctionnalités

Voici quelques fonctionnalités proposées par l’application :

• Détail du programme jour par jour (disponible également par track et par salle).
• Liste complète des speakers avec leur bio.
• Gestion des favoris.
• Mode offline et synchronisation des données
• Le flux Twitter #DevoxxFR et #XebiaFR.
• Le programme du stand Xebia, ainsi que l’enregistrement au jeu/concours !

Installation

Pour installer l’application, il suffit de choisir un des deux liens suivant ou bien de flasher son QR Code correspondant directement depuis votre téléphone !

Web Mobile – Tout OS	PhoneGap pour Android	Google Chrome
http://devoxx.xebia.fr	Cliquez ici !	Cliquez ici !

Code source

Qu’en est-il du code source de l’application ? Chez Xebia, nous pensons que le partage des connaissances est une valeur essentielle. C’est pourquoi nous mettrons à disposition de tous le code source de l’application la semaine de la conférence. Cela sera l’occasion de découvrir nos petites recettes de fabrication d’applications mobiles !

Les indispensables screenshots !

Web

• Dart Hackathon, c’est l’Happy Hour chez Google ! (Par Mathieu Breton)

Le coin de la technique

• Faille de sécurité Java sous Mac OS X (Par Matthieu Dumas)

Evènements de notre communauté en France et à l’étranger

• Second meetup du Hadoop User Group France, le 11 Avril à Paris (Par Bertrand Dechoux)

Web

Dart Hackathon, c’est l’Happy Hour chez Google !

Le Dart Hackathon est un évènement organisé par l’équipe Dart chez Google ayant pour but de vous faire essayer Dart le langage web de nouvelle génération made in Google.

Un Hackathon ? Que nous dit Wikipédia ?
Un hackaton est un événement où des développeurs se réunissent pour faire de la programmation informatique collaborative, sur plusieurs jours. Le terme est un mot-valise constitué de hack et marathon.

De fin avril à début mai dans plusieurs villes du globes, des équipes pourrons participer a ces « ateliers » animés par Google. Chaque équipe devra proposer une idée de projet, et la réaliser. Après démonstration et délibération des juges, des prix seront attribués à l’équipe ayant montrer la meilleur qualité technique. En plus de ces prix, chaque équipe gagnante dans les différentes villes pourra rencontrer l’équipe Dart à l’occasion d’une call conf.
Malheureusement pas de date prévu en France :(

Pour plus de détail, vous pouvez aller voir ici : http://www.dartlang.org/hackathons/2012/happy-hour/.

Le coin de la technique

Faille de sécurité Java sous Mac OS X

Apple vient de sortir une mise à jour de sécurité touchant la version 1.6.0 update 29 de Java sous Mac OS X Leopard (10.6) et Lion (10.7). Ce patch vient notamment combler une faille de sécurité liée à une variante du malware Flashback (encore lui). Ce dernier conçerneraient plus d’un demi million d’utilisateurs Mac OS X (600 000 dont 4000 en France selon les estimations). Un bon nombre de journaux spécialisés et d’entreprises de sécurité en profitent d’ailleurs pour pointer du doigt le fait qu’OS X est loin d’être imperméable aux malwares, ceci remettant fortement en cause l’image de robustesse que s’était forgée la firme de Cupernito autour de ses produits. Par exemple, Trend Micro a produit une infographie présentant 12 programmes malveillants à éviter sous Mac OS X.

Pour rappel, Flashback a été découvert en septembre 2011, tout d’abord sous la forme d’images érotiques, puis d’un document pdf et enfin d’un faux installeur du player Flash exécutable depuis Safari. A l’origine, le malware désactivait les paramètres de sécurité réseau et envoyait des données personnelles à destination d’un serveur distant via une porte dérobée.

La dernière variante du malware quant à elle, nom de code Flashback.K, exploite la faille de sécurité du runtime Java CVE-2012-0507, patchée par Oracle courant février pour le système d’exploitation de Microsoft. Elle a été découverte par F-Secure, qui fournit un descriptif détaillée du malware ainsi que des procédures pour vérifier sa présence et l’éradiquer du système.

Cette faille permet notamment à une applet non signée, d’exécuter du code en dehors de la sandbox Java, et ce, avec les privilèges de l’utilisateur courant. Imaginez si vous avez lancé votre navigateur en root . L’applet invite alors l’utilisateur à saisir son mot de passe, bien que le malware tentera d’infecter le système qu’il soit saisit ou non, ceci influant juste la manière dont il s’y introduira.

Jusqu’ici la seule manière d’éviter cette faille était de désactiver Java de son navigateur, voire de désactiver Java tout court. Désormais, Apple invite à appliquer la mise à jour 1.6.0 update 31. Pour se faire, 2 solutions s’offrent à vous :

• Vous pouvez exécuter l’utilitaire de mises à jour de l’OS pour découvrir l’écran suivant :

• Ou bien télécharger la mise à jour via le site developer d’Apple où il vous faudra créer un compte (gratuit ) si ce n’est pas déjà fait.

Sinon, rien ne vous empêche d’aller jeter un coup d’oeil du côté du projet OpenJDK où la version 7 et 8 (avec lambdas) sont disponibles !

A noter tout de même, bien qu’Apple ait été très passif quant à sa gestion des mises à jour de Java, ce patch est sorti en moins d’une semaine après la mise en évidence concrète de la faille. Malgré tout, il est désormais clair que la clientèle type « développeur » n’est pas la priorité d’Apple, d’autant plus que l’OS de la firme n’intègre plus nativement le runtime Java. Au moins, les nouveaux utilisateurs n’auront pas ce problème !

Evènements de notre communauté en France et à l’étranger

Second meetup du Hadoop User Group France, le 11 Avril à Paris

Le premier meetup a eu lieu le 15 mars. On a pu assister à une introduction à Hadoop ainsi qu’à une présentation de Cascalog mais aussi à un retour d’expérience de Kobojo et une démonstration de Talend Open Studio. Les dernières vidéos seront bientôt publiées sur ce blog afin de ne pas léser ceux qui n’ont pas pu se libérer.

Le programme, le lieu et la date pour le second meetup sont déjà fixés! Il s’agit de demain (le mercredi 11 avril) dans les locaux parisiens de l’INRIA. Chris Harris de 10gen présentera l’intégration de MongoDB avec Hadoop. Benjamin Guinebertière de Microsoft parlera d’Hadoop sur Azure. Et enfin, Ziad Bizri d’Ezako détaillera MapReduce.

Pour assister à l’événement, vous pouvez vous inscrire, tant qu’il reste des places!

Xebia a choisi Heroku pour la création d’un outil de recrutement social sur Facebook et présentera un retour d’expérience à cette occasion à partir de 16h30.

Ce sont des invités de renom, des experts de salesforce.com et leurs partenaires qui seront présents pour débattre et comprendre comment les leaders de la révolution sociale et collaborative transforment leur industrie. Durant cette journée, de nombreux ateliers présenteront tous les produits sociaux et collaboratifs, ainsi que les toutes dernières technologies cloud computing

Il reste encore quelques places pour ceux qui ne pourront pas être présents lors de cette journée, mais qui souhaitent assister au « Developer Garage », de 18h00 à 21h00 .Cette édition rassemble pour la première fois en France, 200 développeurs venus participer à cette révolution sociale et mobile et créer leurs applications !

Vous pourrez rencontrer et échanger avec les équipes engineering sur les technologies force.com et heroku, et :

• Assister à des démos temps réel.
• Découvrir les dernières APIs.
• Récupérer les astuces des experts Cloudforce.

Attention, le nombre de places est limité, inscrivez-vous rapidement !

Événement en anglais.
Pensez à venir avec votre laptop !

Dans ce nouvel article, je vous propose d’aborder le type monadique Either, particulièrement utile pour la gestion des erreurs et qui peut remplacer de manière très avantageuse les mécanismes de checked exceptions. Nous approfondirons à cette occasion notre compréhension des monades et nous verrons comment combiner deux types de monades différents.

Définition du type Either

Comme dans le dernier article, je me permettrai un abus de langage en parlant des types Either et Option même s’ils réfèrent à des types abstrait (aussi appelé constructeur de type) et non à des types concrets (comme Either[A, B] ou Option[A]).

Le type Either[A, B] est un type abstrait générique ayant deux sous types concrets à savoir Left[A, B] et Right[A, B]. Dans le précédent article sur le type Option, nous avions présenté l’implémentation d’une méthode divide retournant une instance de Some[Double] ou None si le dénominateur est 0. Nous pourrions changer notre approche et utiliser le type Either pour retourner soit la valeur calculée, soit un message d’erreur :

scala> def divide(x:Double, y:Double):Either[String, Double] = if (y == 0) Left("Can't divide by 0") else Right(x/y)
divide: (x: Double, y: Double)Either[String,Double]
scala> divide(4, 0)
res0: Either[String,Double] = Left(Can't divide by 0)
scala> divide(4, 2)
res1: Either[String,Double] = Right(2.0)

Si la valeur du diviseur est 0, la fonction divide retourne le message d’erreur encapsulé dans un Left. Dans le cas contraire, elle retournera le quotient dans un Right. Par convention, les erreurs sont retournées à gauche et le résultat à droite. Cette convention n’est pas forcément très explicite mais en l’appliquant scrupuleusement, il n’y a pas de soucis à avoir. Un moyen mnémotechnique pour ne pas les confondre est de voir que Right peut se traduire en « Correct » comme dans it’s all right! et de voir que Left vient du verbe anglais to leave et qu’il peut se traduire en « Parti », car en cas d’erreur nous sommes parti du traitement.

Traitement des valeurs de type Either

Nous pouvons maintenant nous demander comment exploiter la valeur retournée par notre méthode. La première méthode est la suivante :

scala> val result = divide(4, 2)
result: Either[String,Double] = Right(2.0)
scala> if (result.isRight) {
     |   "Result is = " + result.right.get
     | } else {
     |   result.left.get
     | }
res2: java.lang.String = Result is = 2.0

Ce code procédural peut être avantageusement remplacé par l’utilisation de la méthode fold. Pour un type Either[A, B], la méthode fold prendra en argument deux fonctions :

• la première de type f: A => C qui sera appliquée à la valeur gauche,
• la seconde de type g: B => C qui sera appliquée à la valeur droite et retournera un résultat de type C.

scala> result.fold(
     |   { y => y },
     |   { x => "Result is = " + x })
res3: java.lang.String = Result is = 2.0

Composition avec le type Either

Imaginons maintenant que nous souhaitons ajouter les résultats de deux divisions effectuées avec la méthode divide :

scala> def add(x:Either[String, Double], y:Either[String, Double]) =
     | if (x.isRight && y.isRight) {
     |     Right(x.right.get + y.right.get)
     | } else if (x.isLeft) {
     |     x
     | } else {
     |     y
     | }
add: (x: Either[String,Double], y: Either[String,Double])Either[String,Double]
scala> add(divide(4, 2), divide(3, 4))
res4: Either[String,Double] = Right(2.75)
scala> add(divide(4, 0), divide(3, 4))
res5: Either[String,Double] = Left(Can't divide by 0)

Cette implémentation de add est correcte mais peut facilement aboutir à une erreur d’implémentation (surtout si nous augmentons le nombre de Either à composer). Heureusement, il existe une façon beaucoup plus sûre d’implémenter cette fonction add en appliquant le principe : flatmap that shit !.

scala> def add(eX:Either[String, Double], eY:Either[String, Double]) = eX.right.flatMap { x => eY.right.map { y => x + y } }
add: (eX: Either[String,Double], eY: Either[String,Double])Either[String,Double]

Nous retrouvons ici les méthodes map et flatMap que nous avions rencontrées dans l’article sur les Options. La différence avec le type Either est que nous appliquons ces méthodes sur la projection à gauche ou à droite (.left, .right) de la valeur. Dans notre cas, nous souhaitons appliquer ces méthodes sur la projection à droite des valeurs de type Either, afin de n’appliquer les transformations que si le résultat de la méthode divide est un succès (et donc une instance de Right).

La méthode map appliquée à la projection à droite du type Either[A, B] prend en argument une fonction f: B => C et retourne un objet de type Either[A, C]. La méthode flatMap appliquée à la projection à droite du type Either[A, B] prend en argument une fonction f: B => Either[A, C] et retourne un objet de type Either[A, C]. Dans notre cas, A est de type String et B et C sont de type Double.

Nous pouvons aussi utiliser une for comprehension pour définir cette même méthode :

def add(eX:Either[String, Double], eY:Either[String, Double]) = for {
    x <- eX.right
    y <- eY.right
} yield x+y

Là encore, l’utilisation d’une for comprehension apporte un peu plus de lisibilité, qui sera accentuée dans le cas où nous avons non plus deux, mais trois monades ou plus pour lesquelles nous souhaitons extraire la donnée. Le compilateur transforme ensuite la for comprehension en suite de (n-1) flatMap et un map.

Comment faire maintenant si nous souhaitons appliquer un traitement sur la projection à gauche ? Nous allons modifier légèrement notre implémentation de la méthode add :

scala> def add(eX:Either[String, Double], eY:Either[String, Double]):Either[String, Double] = eX.right
       .flatMap { x => eY.right.map { y => x + y } }.left.map { m => "Error during add process : " + m }
add: (eX: Either[String,Double], eY: Either[String,Double])Either[String,Double]
scala> add(divide(4, 0), divide(3, 4))
res6: Either[String,Double] = Left(Error during add process : Can't divide by 0)

Pattern matching

Comme pour le cas de l’Option, il est possible de faire du pattern matching sur le type Either afin de récupérer la valeur qu’il contient :

def addParams(x:Double, y:Double) = divide(x, y) match {
  case Left(error) => BadRequest(error)
  case Right(result) => Ok("The result of %d / %d is %d".format(x, y, result))
}

Nous aurions bien évidemment pu utiliser la méthode fold pour arriver au même résultat.

Composition de Either et Option

Il peut arriver de rencontrer des méthodes retournant des Options et d’autres des Either et que nous souhaitions les combiner pour obtenir un résultat. Prenons l’exemple de notre méthode divide retournant une valeur de type Either et d’une autre méthode retournant une Option contenant un taux quelconque :

def findValue(id:Long):Option[Double] = if (id == 1) None else Some(id - 2)

Cette méthode retourne Some(taux) si l’id passé en argument correspond à un taux existant et None dans le cas contraire.

Nous allons maintenant coupler cette méthode avec divide (définie plus haut) pour effectuer un calcul simple :

def calcValue(id:Long):Either[String, Double] =
    findValue(id).map( x => Right(x) ).getOrElse(Left("The ID doesn't match")) // transform the Option to Either
    .right.flatMap( x => divide(1, x) )                                        // compose it with another Either

De prime abord, cette méthode peut sembler un peu complexe. Nous pouvons la décomposer en deux parties pour mieux la comprendre :

findValue(id).map( x => Right(x) ).getOrElse(Left("The ID doesn't match"))

la méthode findValue retourne une Option[Double]. Or, nous souhaitons la combiner avec une méthode retournant un type Either[String, Double]. La méthode map nous permet de transformer notre Option[Double] en Option[Right[Nothing, Double]]. Nous souhaitons ensuite extraire la valeur de l’Option et nous utilisons pour ce faire la méthode getOrElse qui retournera un Left contenant un message d’erreur dans le cas où findValue retournerait None. A l’issue de cette première étape, nous avons transformé notre Option[Double] en Either[String, Double].

L’étape suivante consiste à combiner l’appel à la méthode divide. Ceci se fait simplement en appelant flatMap sur la projection à droite du résultat issu de la première étape. Pour rappel, le flatMap est défini comme suit :

Either[A, B].right.flatMap(B => Either[A, C]):Either[A, C]

Nous pouvons aussi vérifier que notre méthode retourne bien le résultat escompté :

scala> calcValue(3)
res7: Either[String,Double] = Right(1.0)
scala> calcValue(2)
res8: Either[String,Double] = Left(Can't divide by 0)
scala> calcValue(1)
res9: Either[String,Double] = Left(Id doesn't match)

Intuitions

Nous commençons à mieux appréhender ce qu’est une monade et comment l’utiliser. Nous avons vu qu’elles sont caractérisées par la présence des méthodes map et flatMap permettant d’appliquer des transformations sur leur contenu.

Nous pourrions maintenant nous intéresser à une implémentation possible de ces deux méthodes en commençant par la monade Option :

trait Option[+A] {
  def map[B](f: A => B):Option[B] = ...
  def flatMap[B](f: A => Option[B]):Option[B] = ...
}
case object None extends Option[Nothing]
case class Some[A](a:A) extends Option[A]

Nous avons ici une définition du type abstrait Option[A] et de ses deux sous types Some[A] et None. Notez que nous utilisons le mot-clé case afin de pouvoir utiliser le pattern matching sur Some et None. Nous définissons aussi A comme étant covariant dans Option[+A] afin de permettre l’assignation d’un None à une valeur de type Option[A] où A est quelconque. Nothing étant sous type de n’importe quel type et A étant covariant, Option[Nothing] est un sous type de Option[A] ce qui permet d’avoir une assignation du genre :

val d:Option[Double] = None

Voici une implémentation possible des méthodes map et flatMap :

def map[B](f: A => B):Option[B] = this match {
    case None => None
    case Some(a) => Some(f(a))
  }
  def flatMap[B](f: A => Option[B]):Option[B] = this match {
    case None => None
    case Some(a) => f(a)
  }

On peut voir que l’implémentation est assez simple. Si nous sommes en présence d’un None, les deux méthodes renverront None. Dans le cas où l’Option renferme une valeur, celle-ci est extraite grâce au pattern matching et appliquée à la fonction f.

Nous pouvons aussi imaginer l’implémentation partielle de la monade Either. Celle-ci est un peu moins triviale car nous devons considérer les types relatifs aux projections à droite et à gauche comme vous pouvez le constater dans le code suivant :

trait Either[+A, +B] {
  def left = new LeftProjection(this)
  def right = new RightProjection(this)
}
// right projection of an Either type
class LeftProjection[+A, +B](e:Either[A, B]) {
  def map[C](f: A => C):Either[C, B] = e match {
    case Left(a) => Left(f(a))   // returns a Left with a transformed value a
    case Right(b) => Right(b)
  }
  def flatMap[C, BB >: B](f: A => Either[C, BB]):Either[C, BB] = e match {
    case Left(a) => f(a)         // returns a new Either calculated from f applied to a
    case Right(a) => Right(a)
  }
}
// left projection of an Either type
class RightProjection[+A, +B](e:Either[A, B]) {
  def map[C](f: B => C):Either[A, C] = e match {
    case Left(a) => Left(a)
    case Right(b) => Right(f(b)) // returns a Right with a transformed value a
  }
  def flatMap[AA >: A, C](f: B => Either[AA, C]):Either[AA, C] = e match {
    case Left(a) => Left(a)
    case Right(b) => f(b)        // returns a new Either calculated from f applied to a
  }
}
case class Left[A, B](a:A) extends Either[A, B]
case class Right[A, B](b:B) extends Either[A, B]

Nous voyons que Left et Right sont deux sous types de Either qui lui même implémente les méthodes left et right permettant d’obtenir les projections à gauche et à droite. Les implémentations des méthodes map et flatMap dans les projections à gauche et à droite sont opposées dans le sens où l’application d’une fonction sur une projection à gauche ne s’appliquera que sur une valeur gauche (Left) et inversement.

Nous ne nous attarderons pas sur les définitions des types des classes et des méthodes dans cet article, ce sujet pourrait faire l’objet d’un article à lui tout seul. Néanmoins, vous connaissez maintenant suffisamment bien les méthodes map et flatMap pour comprendre ce qu’elles attendent en argument et ce qu’elles retournent.

Conclusion

Voilà pour ce nouvel article sur les types monadiques en Scala et plus particulièrement sur le type Either[A, B]. Nous avons pu voir comment utiliser cette nouvelle monade, comment la composer avec d’autres du même type et avec la monade Option et pour finir, nous avons vu comment ces deux monades pourraient être implémentées, ce qui a conduit au passage à comprendre un peu mieux leur fonctionnement grâce à cette vue sous le capot.

Dans notre prochain article, je vous proposerai l’étude d’une autre monade, probablement l’une des plus utilisées puisqu’il s’agit de la Liste.

Je vais vous expliquer dans ce billet la genèse et les principes fondateurs de ce séminaire. La Scrum Master Academy est une idée qui m’est venue il y a quelques mois alors que je cherchais un moyen de transmettre mon expérience agile à mes collègues de Xebia dans un format pédagogique, sans écrire un livre de 500 pages et sans donner de certification précise.

Il y a beaucoup de réflexes que j’ai acquis « sur le tas » en me confrontant aux difficultés de certaines situations et sans spécialement lire de livre. L’expérience s’acquiert en faisant des erreurs, en en tirant des enseignements. Les bons réflexes se construisent sur la base d’un vécu. Pour autant, est-il souhaitable de laisser vos collègues se tromper si vous avez de bons conseils à leur donner ? D’autre part, j’ai constaté à de nombreuses reprises que les personnes fraîchement issues de formations agiles (certifiantes ou non) font une application naïve, intégriste, ou pas assez éclairée des méthodes agiles. J’ai aussi remarqué que mes entorses à certaines méthodes agiles étaient parfois perçues comme des actes de crime contre l’agilité. J’ai donc voulu transmettre un message pragmatique dans un format pédagogique et ludique. Mais comment diffuser cette expérience et la rendre accessible au moins expérimentés sans ré-inventer la roue ?

Comme souvent dans ce genre de situation, la réponse est là où on ne l’attend pas. Pour l’occasion, c’est la série américaine NCIS, diffusée le vendredi soir sur M6, qui m’a inspirée. Dans cette série, le chef d’une équipe d’enquêteurs sur des affaires criminelles de la marine américaine a créé une liste de 50 règles d’enquêtes basées sur son expérience du terrain. Il considère que son métier est de les enseigner à ses équipiers, au fil des différentes situations, afin qu’ils deviennent des enquêteurs excellents. Le propre de ces règles est qu’elles ne sont écrites nulle part, elles forment une référence commune à tous ses équipiers et contribuent à renforcer l’esprit de groupe.

L’idée était là ! Restait à formaliser le contenu.

Avec Jean-Laurent, nous avons travaillé d’arrache-pied (le mot est faible) pour rassembler nos expériences agiles depuis 10 ans et définir un ensemble de règles « à la NCIS ». Nous avons ensuite saisi le premier XKE pour présenter une première mouture de la Scrum Master Academy, habillés de treillis militaires, sifflet au bec et casquettes pour renforcer l’impact. Nous avons beaucoup apprécié cette session XKE, non pas parce qu’on aime s’habiller en treillis, mais pour deux raisons. Tout d’abord parce qu’elle a permis aux participants de partager leurs expériences à travers nos règles et de mettre sur la table des situations parfois délicates. Ensuite, parce que cela nous a apporté à Jean-Laurent et moi quelque chose qui nous manquait : la volonté de formaliser notre expérience en confrontant nos histoires sans tomber dans le syndrome de la brève de comptoir. Le résultat auquel nous sommes arrivés dépasse largement l’idée initiale. Encore une preuve de l’intérêt du travail en binôme.

C’est donc tout naturellement que nous avons proposé cette session pour le Scrum Day 2012. Pour l’occasion, nous n’avons pas présenté les 50 règles, car le créneau d’1h ne suffisait pas et le contenu complet nécessite un minimum d’échanges avec les participants. Nous avons donc extrait un sous-ensemble de celles qui nous paraissaient importantes, originales ou trop souvent oubliées. L’exercice s’annonçait délicat car le propre de l’agilité est de ne pas donner de règles d’or et nous allions précisément faire le contraire devant un auditoire comprenant des agilistes forcenés.

Nous sommes vraiment heureux des retours très positifs que nous avons reçus après la session (voir photo), et encore après sur la blogosphère ici ou encore là. Comme promis aux participants, je vais vous dévoiler sur ce blog les 50 règles de la Scrum Master Academy. Mais pas toutes en même temps. Je vous l’ai dit, elles nécessitent un minimum d’explication. Chaque règle fera l’objet d’un article qui lui est propre avec quelques explications et des tranches de vie agiles qui vont avec. Pour patienter, vous pouvez consulter les slides de la présentation qui vous donneront déjà quelques règles… sans les explications. Donc restez à l’écoute du blog.

Je profite également de ce billet pour vous dévoiler le démarrage de deux chantiers:

• la mise au point d’un module de formation sur le principe de la Scrum Master Academy: destiné aux Scrum Master, l’objectif sera de distiller les principes des règles au travers d’ateliers, de retours d’expérience, et de mises en situation
• la création d’un deck de cartes synthétisant ces règles, dans la même forme que les Xebia Essentials

À venir: règle n°1 – Know Your Agile Values

Aussi académique que puisse être cette notion, les monades en informatique correspondent à un concept bien précis, qui peut s’avérer utile pour se sortir de situations délicates. Les monades ont fait leur apparition en informatique dans les années 90. Elles ont été utilisées afin de pouvoir conserver la pureté fonctionnelle au sein des applications (ie. limitation des modifications destructrices / updates) et ainsi de pouvoir bénéficier des divers optimisations qu’offre cette pureté. C’est l’objectif fixé dans le langage Haskell où l’utilisation des monades est très répandue.

Mais quid de la définition des monades ? Une petite recherche sur Wikipédia, vous permettra de trouver ce qui ressemble à une définition perdue au milieu de code à tout va et de décorations mathématiques déroutantes, à défaut de signes cabalistiques. Une recherche sur le wiki du langage Haskell vous mènera à des morceaux de code et des définitions qui ne semblent avoir ni queue ni tête. Une autre recherche enfin vous mènera peut-être à cette fausse citation issue d’un article que nous devons à James Iry (et qu’il attribue à Philip Wadler). À sa manière, cette définition représente bien l’hermétisme qui enveloppe le concept de monade.

Une monade est un monoïde de la catégorie des endofunctors, où est le problème ?
(a monad is a monoid in the category of endofunctors, what’s the problem?)

NB: depuis Philip Wadler aurait fait des progrès : http://vimeo.com/38223410

Mais pour rester dans le commun des mortels, les monades sont avant tout une abstraction permettant de représenter une séquence de traitements et de définir le comportement de cette séquence. Ainsi, les monades sont :

1. une solution issue de la programmation fonctionnelle permettant de représenter une succession de traitements, tout comme la programmation impérative représente par une séquence d’instructions cette succession de traitements,
2. un moyen d’encapsuler la notion d’état mutable et le confiner dans un « espace de travail »,
3. des contextes d’exécution permettant de modifier le comportement non pas des traitements mais du chaînage sur ces traitements.

Il faut bien comprendre qu’en terme de traitement, nous nous attendons ici à des fonctions qui retournent une valeur à transmettre au traitement suivant.

Si à un moment ou à un autre, vous avez pensé ici AOP, c’est que vous êtes sur la bonne voie [2, 5].

Dans cette article, vous trouverez une introduction à la notion de monade à travers le langage Java avec implémentations et exemples. Plus précisément, nous verrons deux types de monades : la monade Option et la monade List. Nous terminerons cet article en discutant notamment de l’intérêt ou non d’utiliser les monades en Java. Bref, faisons du fonctionnel en Java :

public interface Function<T, R> {
  R apply(T value);
}

Monade Option

La monade Option est la monade la plus simple et la plus accessible. Parfois appelée Maybe, elle permet de chaîner des traitements unitaires qui peuvent potentiellement ne pas retourner de valeur. Le cas échéant, le chaînage doit être « cassé ». Autrement dit, si l’une des fonctions ne retourne pas de valeur, il faut pouvoir ignorer les fonctions qui suivent dans le chaînage. Habituellement, le développeur Java utiliserait une référence null pour représenter l’absence de valeur et se baserait sur une levée d’exception (typiquement NullPointerException) pour « casser » le chaînage. La référence nulle est ce que Tony Hoare décrit comme étant son erreur d’un milliard de dollars. Nous allons voir que Option peut être une alternative intéressante.

Définition

Pour notre monade, il nous faut d’abord représenter les notions de valeur et d’absence de valeur. C’est le rôle du type Option. Si nous représentons le type Option par une classe, elle aura alors deux sortes d’instances possibles :

• les instances de type Some qui encapsulent une valeur,
• les instances de type None qui représentent l’absence de valeur.

À partir de là, nous pouvons définir les opérations de la monade Option. Celle-ci, comme les autres monades d’ailleurs, contient deux principales opérations. Pour plus de clarté, nous étendrons la notation introduite par Daniel Spiewak [4].

• wrap : qui converti un objet en Option. Cette opération est parfois nommée unit, pure ou return dans d’autres langages.
• andThen : qui s’applique à une Option pour retourner une autre Option suivant un traitement unitaire. Cette opération est parfois nommée bind, flatMap ou notée >>= dans d’autres langages.

andThen prend en paramètre une fonction qui permet de transformer le contenu de l’Option en une autre Option. C’est cette fonction passée en paramètre qui va représenter le traitement unitaire. C’est aussi à partir d’une succession de andThen que nous représenterons un chaînage de traitements. Pour terminer, andThen est similaire au point-virgule (;), que vous utilisez sans forcément en avoir conscience entre deux instructions dans votre Java quotidien.

À ces deux opérations, nous ajoutons l’opération fail qui représente la situation d’échec ou une situation exceptionnelle. Dans le cadre du type Option, fail renvoie simplement une instance de None.

Voici l’implémentation choisie pour le type Option qui est représenté par le biais d’une classe abstraite.

public abstract class Option<T> {
  // opérations de base
  public abstract T get();
  public abstract boolean isPresent();
  // opérations monadiques
  public static <T> Option<T> wrap(T element) { return new Some<T>(element); }
  public static <T> Option<T> fail() { return new None<T>(); }
  public abstract <U> Option<U> andThen(Function<T, Option<U>> function);
}

Et voici l’implémentation des sous-classes None et Some :

public class None<T> extends Option<T> {
  public T get() { throw new IllegalStateException(); }
  public boolean isPresent() { return false; }
  public <U> Option<U> andThen(Function<T, Option<U>> function) {
    return new None<U>();
  }
}
public class Some<T> extends Option<T> {
  private T element;
  private Some(T element) { this.element = element; }
  public T get() { return element; }
  public boolean isPresent() { return true; }
  public <U> Option<U> andThen(Function<T, Option<U>> function) {
    return function.apply(this.element);
  }
}

Exemple : accès des Map de Map de Map de…

Nous allons voir maintenant comment utiliser la monade Option. Pour nous mettre en situation, nous allons partir d’un exemple de code comme nous pouvons en trouver dans des projets légués. Le principe sera ici d’accéder à la capitale d’un pays classée par continent et par pays. Pour cela, nous allons organiser ces données au moyen d’une structure récursive et complexe basée sur des Map (la classe Splitter ci-dessous provient de Guava).

Splitter.MapSplitter splitter = Splitter.on(", ").withKeyValueSeparator(" -> ");
Map<String, Map<String, String>> capitalCities = new HashMap<String, Map<String, String>>() {{
  put("Europe", splitter.split("France -> Paris, Espagne -> Madrid"));
  put("Amérique", splitter.split("Etats-Unis -> Washington"));
}};

Potentiellement, pour récupérer ici la capitale d’un pays en se basant sur la programmation impérative, il est nécessaire de passer un ensemble de if imbriqués pour vérifier qu’à chaque étape du parcours de la structure de données, nous n’ayons pas récupéré une référence null. Avec notre monade Option, le code permettant d’accéder à la capitale d’un pays s’en trouve simplifié.

Option<String> city;
city = Option.wrap(map)
             .andThen(accessContinent("Europe"))
             .andThen(accessCountry("France"));
assertThat(city.isPresent()).isTrue();
assertThat(city.get()).isEqualTo("Paris");
city = Option.wrap(map)
             .andThen(accessContinent("Europe"))
             .andThen(accessCountry("Assyrie"));
assertThat(city.isPresent()).isFalse();

Pour obtenir ce résultat, il faut définir les méthodes accessContinent et accessCountry. Pour cela, nous utilisons la méthode getFromKey, sachant que les deux méthodes d’accès ont le même objectif : accéder à un élément d’une Map par une clé et retourner l’instance d’Option qui convient selon la présence ou non de la clé. getFromKey prend donc en entrée une clé, mais elle renvoie une closure — c’est-à-dire une fonction conservant le contexte d’exécution dans lequel elle a été créée —. En effet, au moment d’appeler getFromKey, nous n’avons pas encore de Map sur laquelle effectuer la recherche de la clé. Nous retournons donc une closure qui emmagasine la clé dans son propre contexte. Elle va donc attendre un appel avec en entrée une Map et se servir de la clé fournie précédemment pour obtenir la valeur associée en appelant la méthode get. Nous avons ici l’expression de l’évaluation retardée à la Java. Selon le résultat retourné par get, la closure nous renvoie soit une instance de None en cas d’absence de résultat soit une instance de Some sinon.

public static Function<Map<String, Map<String, String>>, Option<Map<String, String>>> accessContinent(String continent) {
    return getFromKey(continent);
}
public static Function<Map<String, String>, Option<String>> accessCountry(String country) {
    return getFromKey(country);
}
public static <K, V> Function<Map<K, V>, Option<V>> getFromKey(final K key) {
    return new Function<Map<K, V>, Option<V>>() {
        @Override
        public Option<V> apply(Map<K, V> map) {
            V value = map.get(key);
            if (value == null) {
                return Option.none();
            }
            return Option.wrap(value);
        }
    };
}

Notons que le fait d’être obligé de définir des méthodes tels que accessCountry ou accessContinent est nécessaire, plutôt que d’utiliser directement la méthode getFromKey. En effet, utiliser directement la méthode getFromKey vous contraindrait à devoir résoudre à la main des problèmes de type générique plus complexes que ceux présents ici. Néanmoins, il faut reconnaître qu’écrire ces quelques lignes de code n’est pas forcément évident pour tout le monde. Mais vous devez le faire, car Java ne sait pas encore deviner pour vous la signature des méthodes. C’est aussi pour ça qu’en Java un bon IDE est nécessaire. En principe, celui-ci est capable de vous aider à déterminer, voire de générer pour vous, la signature de méthodes tels que accessCountry ou accessContinent.

Monade List

Nous avons vu la monade Option. Celle-ci peut prendre deux formes : une forme vide et une forme singleton. En fait, Option est en quelque sorte un conteneur. On pourrait très bien représenter le type Option au moyen d’une List ayant soit aucun élément pour représenter None soit un élément pour représenter Some. Mais que représenterai dans ce cas une liste contenant plus d’un élément ?

Car oui, même dans ce cas, une liste est aussi une monade. Et avec la monade List, vous allez pouvoir adresser des problèmes liés au non-déterminisme.

Définition

Nous allons retrouver les opérations monadiques que nous avons vues précédemment :

• wrap qui retourne un singleton à partir de l’objet passé en paramètre,
• fail qui retourne une liste vide,
• andThen.

Comme la classe java.util.List ne possède de pas ces opérations monadiques, nous allons passer par un wrapper que nous nommerons ListM. Pour faciliter l’exploitation des instances de cette classe notamment dans les boucles for each, nous lui faisons implémenter l’interface Iterable afin que ListM définisse la méthode iterator.

public class ListM<T> implements Iterable<T> {
  private List<T> list;
  public ListM(List<T> list) {
    this.list = list;
  }
  // opérations de base
  public List<T> get() { return list; }
  @Override
  public Iterator<T> iterator() { return list.iterator(); }
  // opérations monadiques
  public static <T> ListM<T> wrap(T element) { return new ListM<T>(Collections.singletonList(element)); }
  public static <T> ListM<T> fail() { return new ListM<T>(Collections.EMPTY_LIST); }
  public <T, U> ListM<U> andThen(Function<T, ListM<U>> function) { return flatten(map(function)); }
  // opération complémentaire
  public static <T> ListM<T> of(List<T> list) { return new ListM<T>(list); }
}

Les opérations flatten et map dont dépend andThen sont définies ci-dessous. map a pour rôle d’appliquer une fonction sur chaque élément d’une liste. Il en ressort une liste contenant les éléments transformés. Dans le cas de notre monade List, chaque élément est converti en une instance de ListM, contenant zéro, une ou plusieurs valeurs selon ce que retourne la fonction donnée en paramètre. Donc, plus exactement, il ressort de map une liste de listes, qu’il faut aplatir. C’est le rôle de flatten.

public <U> ListM<U> map(Function<T, U> function) {
  return new ListM<U>(Lists.transform(list, function));
}
public static <T> ListM<T> flatten(ListM<ListM<T>> list) {
  List<T> result = new ArrayList<T>();
  for (ListM<T> sublist : list) {
    result.addAll(sublist.get());
  }
  return new ListM<T>(result);
}
// autre définition pour flatten
public static <T> ListM<T> flatten(ListM<T>... list) {
  List<T> result = new ArrayList<T>();
  for (ListM<T> sublist : list) {
    result.addAll(sublist.get());
  }
  return new ListM<T>(result);
}

Avec les monades List, nous allons être capable d’établir des relations entre des ensembles de valeurs. Nous ajoutons donc l’opération guard afin d’exprimer ce type de relation. Dans le code ci-dessous, il faut bien comprendre que les valeurs retournées par guard nous importent peu. Ce qui nous intéresse c’est l’effet qu’elle aura sur le chaînage. Si le paramètre de guard est true, alors le chaînage doit pouvoir continuer. Dans le cas contraire, si le paramètre est false, le chaînage doit être « cassé ». Pour en faciliter sa compréhension, il faut voir guard comme un filtre ou un if au niveau du chaînage.

public static ListM<Object> guard(boolean ok) {
  return ok ? ListM.wrap(null) : fail();
}

Exemple : augmentation de salaire !

Nous allons voir un exemple d’utilisation de la monade liste. L’exemple ci-dessous permet de mettre en place des augmentations de salaire pour un ensemble d’employés. Ces augmentations suivent une règle complexe :

• 10 % pour les salaires de moins de 20’000,
• 5 % pour les salaires à partir de 20’000 jusqu’à 30’000,
• 2 % pour les salaires à partir de 30’000 jusqu’à 100’000.

List<Double> SALARIES = Arrays.asList(10000.0, 20000.0, 30000.0, 40000.0, 50000.0);
ListM<Double> result = ListM.flatten(
    ListM.of(SALARIES).andThen(whenSalaryInRange(    0.0,  20000.0, increaseSalaryBy(0.10))),
    ListM.of(SALARIES).andThen(whenSalaryInRange(20000.0,  40000.0, increaseSalaryBy(0.05))),
    ListM.of(SALARIES).andThen(whenSalaryInRange(30000.0, 100000.0, increaseSalaryBy(0.02))));
assertThat(result.get()).containsExactly(11000.0, 21000.0, 30600.0, 40800.0, 51000.0);

Dans cet exemple, chaque ligne située en paramètre dans la méthode flatten produit une liste dont nous donnerons les détails plus bas. flatten permet de concaténer ces listes. Remarquons que dans cet exemple, la liste SALARIES est parcourue trois fois, soit à chaque fois que ListM.of(SALARIES)... apparaît.

Les définitions de whenSalaryInRange et increaseSalaryBy sont données ci-dessous. increaseSalaryBy applique une augmentation par rapport à un taux. whenSalaryInRange vérifie qu’un salaire se situe dans une fourchette donnée grâce à la méthode guard. Le cas échéant, elle exécute la fonction donnée en paramètre.

public static Function<Double, ListM<Double>> whenSalaryInRange(
      final double lower,
      final double upper,
      final Function<Double, ListM<Double>> function) {
  return new Function<Double, ListM<Double>>() {
    @Override
    public ListM<Double> apply(final Double salary) {
      return ListM.guard((lower <= salary) && (salary < upper))
                  .andThen(apply(function, salary));
    }
  };
}
public static <T, R> Function<Object, R> apply(Function<T, R> function, final T element) {
  return new Function<Object, R>() {
    @Override
    public R apply(Object _) {
      return function.apply(element);
    }
  };
}
public static Function<Double, ListM<Double>> increaseSalaryBy(final double rate) {
  return new Function<Double, ListM<Double>>() {
    @Override
    public ListM<Double> apply(Double salary) {
      return ListM.wrap(salary * (1.0 + rate));
    }
  };
}

Le but de apply est de retarder l’évaluation de la fonction passée en paramètre sur salary. En effet, dans whenSalaryInRange, guard va vérifier que le salaire qui sera fournit est bien présent dans les bornes données en paramètres. Nous avons donc d’abord besoin de savoir si l’évaluation de guard à réussi avant de pouvoir appliquer function, sans quoi son évaluation n’a aucun sens. Remarquez l’utilisation de _ au niveau de la fonction retournée par la méthode apply. Il s’agit, par convention, d’indiquer que le paramètre doit être présent mais que nous ne tenons pas compte de sa valeur.

Conclusion

Nous venons de voir les implémentations de deux monades : la monade Option et la monade List. La monade Option permet de gérer une succession d’opérations sans que nous ayons à gérer explicitement l’absence de valeur. La monade List permet, elle, d’appliquer des opérations unitaires sur des ensembles de valeurs. Au delà de toute considération académique, ce qu’apportent en premier lieu les monades dans ce que nous avons vu, c’est la possibilité de traiter des objets sans avoir à se soucier réellement des cas particuliers. Tout ce que vous avez à faire est d’écrire votre succession d’opérations. Si un cas exceptionnel apparaît, il sera absorbé par la monade et transparaîtra d’une manière ou d’une autre dans le résultat sans que cela se traduise par une fin tragique à coup de chaînage d’exceptions sans origine apparente. Cependant, la valeur ajoutée des monades peut sembler moyenne voire minime en Java. Elle varie d’un côté avec notre aisance à lire et écrire des types génériques alambiqués. Elle varie aussi avec notre capacité à comprendre l’enchevêtrement de closures qui n’est pas forcément mis à l’honneur avec la verbosité de Java (même si elle est améliorée avec Java 8 ) et ne rentre pas non plus forcément dans les habitudes du développeur Java. Enfin, et c’est surtout valable pour la monade List, il n’y a aucun gain de performance.

Le gain que va apporter les monades en Java ne se situe donc pas dans la définition des monades et des fonctions annexes ni dans les performances. Le gain des monades en Java se situe en fait dans son intégration dans le code métier et dans la lisibilité qu’elle y apporte. L’adoption des monades en Java sera donc contraint par le gain en lisibilité et le besoin en performance que peut vous apporter une solution impérative. Si vous êtes en présence de code légué et torturé, il y a de fortes chances qu’une monade puisse vous aider à y voir plus clair. Par contre, si vous avez une bonne maîtrise du code de votre projet, la solution impérative sera en général préférable. Mais, dans le cas où c’est la monade qui gagne, prenez le temps d’expliquer le concept à vos collègues en faisant un des points techniques et par le biais du pair programming.

L’ensemble des monades présentées ici est loin d’être exhaustif. Il y en a d’autres pour des usages divers et variés, mais qui n’ont pas forcément d’intérêt en Java au vu de la complexité qu’aurait leur implémentation. Parmi celles-ci, nous avons la monade Writer qui offre un moyen d’ajouter des informations à chaque traitement exécuté et de les agréger. Plus concrètement, la monade Writer permet de mettre en place un système de log ou un système de calcul d’un sous-total. La monade Reader permet de disposer d’un contexte d’exécution en lecture seule. La monade IO permet de confiner les opérations d’entrée/sortie. Toutes ces monades existent afin de conserver la pureté fonctionnelle de l’application et se justifient parfaitement pour des langages comme Scala et plus particulièrement pour le langage Haskell. Ces deux langages offrent un bon nombre de facilités d’écriture pour définir et utiliser des monades ; facilités qui manquent malheureusement en Java.

Vous pouvez comparer ce qui a été vu ici avec l’approche proposée par Scala pour les monades à travers la série d’articles de David Galichet sur le sujet, à commencer par [3].

Enfin, une petite citation issue de Twitter :

@codemonkeyism With all monads you can *flatmap that shit* (© @runarorama) and that powers all of them .. (including Option)
– @debasishg – 7:23 PM – 15 Mar 12

Références

• [1] John Backus. « Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs ». ACM Turing Awards Lecture. 1977 (http://www.stanford.edu/class/cs242/readings/backus.pdf).
• [2] Wolfgang De Meuter. « Monads as Theoretical Foundation for AOP ». International Workshop on Aspect-Oriented Programming
  at ECOOP. 1997 (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.2.4757).
• [3] David Galichet. « Les types monadiques de Scala – Le type Option ». Blog Xebia France. Mars 2012 (http://blog.xebia.fr/2012/03/19/les-types-monadiques-de-scala-le-type-option/).
• [4] Daniel Spiewack. « Monads Are Not Metaphors ». Code Commit. Décembre 2010 (http://www.codecommit.com/blog/ruby/monads-are-not-metaphors).
• [5] Nicolas Tabareau. « A Monadic Interpretation of Execution Levels and Exceptions for AOP ». Modularity: AOSD’12. 2012 (http://hal.inria.fr/docs/00/66/30/88/PDF/aspect_2_category_aosd_2012.pdf).

Illustration : Godzilla vs. Cosmic Monster, Downtown Distribution, 1974.