Le groupe Genigraph rejoint le groupe SOFTEAM Cadextan pour renforcer sa position de leader sur ses marchés.

SOFTEAM Cadextan est heureux d’annoncer que le groupe Genigraph rejoint le groupe SOFTEAM Cadextan.

Veuillez trouver ci-joint le Communiqué de Presse Softeam-Genigraph.

Posted in Genigraph | Tagged | Leave a comment

Décisions … Décisions

Après avoir travaillé sur un certain nombre (voire un nombre certain :-)   ) de projets sur les technologies de “Decision Management” (a.k.a “Business Rules”, “BRMS”, “moteurs de règles” etc …), il semble que les projets qui ont marché respectent un certain nombre de patterns, qui au final peuvent se résumer dans 3 grands principes simples :

  1. Les règles métiers doivent être compréhensibles par les gens du métier,
  2. Il doit être possible de lire, mettre à jour et tester les règles à tout moment pour les utilisateurs et les développeurs,
  3. Les règles métiers ont un cycle de vie, il faut le respecter.

D’autres consultants du domaine ont des analyses proches dont James Taylor , fondateur de Decision Management.

Le document The Decision Management Manifesto illustrant plutôt pas mal cette convergence, j’ai proposé une traduction en Français de ce manifeste qui complète assez bien les expériences projets Génigraph dans le domaine de la Gestion de la Décision (Règles Métiers, Analyse Prédictive, Optimisation).

Cette traduction est désormais disponible et partagée ici.

Posted in BRMS, Gestion de Décisions, Moteur de règles | Leave a comment

Devoxx France 2014 !

Du 16 au 18 avril dernier se tenait la conférence Devoxx France à Paris. C’est la première fois que j’assiste à un événement comme celui-ci, et franchement je ne suis pas déçu ! On y découvre plein de choses et on en repart avec l’envie d’essayer de nouveaux langages, de nouveaux outils.

Les conférences sont pour la plupart excellentes, on sent que les speakers sont des passionnés et ça fait plaisir. En fait il y avait tellement de sujets intéressant qu’on avait parfois du mal à choisir quelle conférence choisir pour une plage horaire donnée. Heureusement il y a un site web qui héberge les vidéos de toutes les conférences qui ont été filmées : parleys.com. C’est accessible à tout le monde donc profitez-en !

Voilà quelques-unes des conférences que j’ai appréciées.

Introduction aux Google Glass – Par Alain Regnier

Les Google Glass restent pour le moment un prototype accessible uniquement aux développeurs américains. C’est un projet de recherche et développement qui vise à produire des lunettes de réalité augmentée.

Elle est équipée d’un prisme qui permet de projeter une image sur l’œil qui vient se superposer à ce que voit l’utilisateur. Plusieurs démonstrations nous ont été faites. Par exemple, un capteur infrarouge permet de détecter le mouvement de la paupière. Ainsi le présentateur a pris une photo de la salle en clignant de l’œil. Il y a aussi un micro et un accéléromètre qui permettent de contrôler les lunettes en faisant des mouvements de la tête ou en donnant des instructions vocales.

Une autre fonctionnalité assez intéressante est le fait de pouvoir traduire un texte affiché sur n’importe quel support (dans notre cas il s’agissait d’un t-shirt). Visuellement c’est très impressionnant, car le texte traduit est projeté par-dessus le texte à traduire ce qui donne l’impression que le support a été modifié.

Une API (Mirror) sera bientôt disponible et fournira des outils pour développer des applications que l’on pourra télécharger et installer via Google Play comme pour un téléphone Android.

C’est donc un produit avec un potentiel énorme. Cependant, il y a encore des limites techniques sur lesquelles il faudra que Google travaille. Notamment l’autonomie qui est plus que limitée, vu que les batteries en utilisation vidéo tiennent moins d’une heure. De plus, les lunettes chauffent beaucoup. Pendant la présentation un message s’est affiché indiquant qu’il fallait que les lunettes refroidissent…

Un site de démonstration des fonctionnalités existe pour ceux qui aimerait avoir un aperçu de ce que permettent les lunettes.

33 things you want to do better – Par Tom Bujolk

Une présentation qui m’a beaucoup plus : Tom Bujolk est un très bon orateur. Il explique en citant Aristote que « nous sommes ce que nous faisons tous les jours. L’excellence n’est pas un acte, mais une habitude ». C’est-à-dire que pour devenir excellent il faut chercher à s’améliorer tous les jours et s’entêter à faire les choses proprement.

Il explique également que si on veut faire les choses correctement dans un environnement soumis au stress et aux deadlines, il faut au préalable s’être entraîné dans un environnement calme et sans précipitation pour apprendre à maîtriser les technologies qu’on utilise. Citation: “Deploying our skills is mutually exclusive from mastering them”.

La deuxième partie de la présentation, il la consacre à nous lister quelques un des outils qu’il utilise pour améliorer son code et/ou être plus productif. J’ai noté notamment Unitils, qui est une API Java qui permet de faciliter les tests unitaires.  Dans l’exemple, une simple annotation @FileContent au-dessus d’un attribut String avec comme paramètre le chemin du fichier permet d’injecter son contenu dans la variable.

Lombok parait également très intéressant. Elle facilite la vie en permettant de générer automatiquement tout le code nécessaire dans un JavaBean. Il suffit simplement de rajouter une annotation @Data et tous les getters, setters, hashCode, Equals, etc. sont générés automatiquement. La seule chose qu’il reste à faire c’est de déclarer les attributs.

Enfin il recommande vivement deux livres :

  • Effective Java, de Joshua Bloch
  • Clean code, de Robert C. Martin

Go pour Javaneros – Par Francesc Campoy Flores

Une présentation que j’ai également appréciée. Le présentateur n’est pas français, mais parle très bien notre langue.

Le but de ce talk est de présenter le langage Go de Google de point de vue d’un développeur Java, ce qu’il apporte de plus.

Go est donc un langage crée par Google, open source, qu’ils ont développé pour répondre à leurs besoins en interne notamment. Un des avantages de Go est qu’il compile extrêmement vite 80 à 90% plus rapide que le C. Il s’exécute aussi très rapidement. D’ailleurs contrairement à Java on peut par exemple paramétrer que dans un objet tous les éléments qui le composent seront situés les uns à la suite des autres dans la mémoire. Ce qui permet d’améliorer les performances.

Un des autres avantages de Go par rapport à Java est sa gestion de la concurrence largement simplifiée. Par exemple il suffit d’utiliser le mot clé go pour qu’une fonction s’exécute en parallèle du Thread courant. Go utilise des goroutines comme équivalent des threads en Java. La synchronisation des goroutines est également simplifiée. Plus besoin de passé par des mécanismes compliqués de synchronize, Semaphore, verrou, etc.

Autre chose que j’ai noté qui change beaucoup de Java est l’absence de notion d’héritage. Une classe ne peut pas hériter d’une autre. Les créateurs de Go ont préféré utiliser la composition à l’héritage.

Google utilise déjà ce langage en production en interne sur quelques applications. Comme le serveur de téléchargement dl.google.com ou golang.org qui est le site officiel du projet.

Conclusion

La conférence Devoxx est vraiment un événement à faire pour tout développeur qui aime son métier. La bonne ambiance qui y règne, les gens passionnés qu’on rencontre donnent vraiment envie d’y retourner. C’est aussi l’occasion de se rendre compte à quel point les technologies évoluent vite, et surtout qu’il est très important de se maintenir à jour.

Posted in Conferences, Devoxx France | Leave a comment

Expérience de parallélisation d’une application monolithique monothread old-fashion sur un cluster de machines

Que faire lorsque l’un fournisseur de logiciel nous propose une architecture monolithique séquentielle, uniquement accessible au travers d’une GUI pour résoudre un problème éminemment parallélisable et relativement massif ?

Hadoop vs C

Voici la question à laquelle nous avons eu à répondre au cours des derniers mois. Ce billet présente essentiellement les difficultés rencontrées et les solutions apportées.

Merci à notre client d’en avoir autorisé la publication.

I) Prendre la décision de paralléliser l’exécution d’une application monolithique

1) Notre expérience

Au démarrage de ce projet, nous disposions d’une application de calcul issue d’un travail de plusieurs dizaines d’années, qui réalise des calculs scientifiques dans le domaine de notre client avec une efficacité remarquable.

Malheureusement pour nous, il s’agissait d’une application monolithique, relativement ancienne, codée en C sous Windows et que l’on manipule exclusivement au travers d’une GUI.

En face de cette application nous avions des données à traiter : 2000 archives zip contenant une centaine de GB de XML, qu’il fallait lire, traduire dans le modèle de données de l’application, corriger et sur lesquels il fallait finalement lancer des calculs.

Le temps théorique observé pour la totalité du traitement était de l’ordre de 2 semaines de temps continu. Ce délai n’ayant jamais été atteint, car un incident est toujours advenu en milieu de traitement : crash, coupure réseau, reboot système ou toute autre interruption inopinée.

Heureusement pour nous, chacun de ces fichiers était autonome. C’est à dire que l’on peut le traiter complètement indépendamment des autres. Immédiatement nous est donc venue l’idée de paralléliser : En répartissant les traitements sur n machines, nous saurions diviser le temps de traitement par un facteur pouvant aller jusqu’à 2000, ce qui nous amènerait à un traitement idéal de 10 minutes.

2) Les résultats

Une telle réalisation n’est pas forcément ni très académique ni très rassurante a priori. Notre client nous a fait confiance pour tenter une telle réalisation, nous l’en remercions.

Bien l’en a pris, puisqu’elle est aujourd’hui couronnée de succès : non-seulement nous atteignons désormais des temps de traitement très raisonnables (de l’ordre de 2 heures), mais nous avons aussi substantiellement enrichi l’étendue des traitements effectués sur les données. Nous fournissons donc au client un service à la fois plus rapide, plus robuste et plus complet.

Serialisation

AVANT

Serialisation

APRES

3) Avant de commencer

En décrivant ici les problèmes que nous avons rencontré, je m’adresse à nos collaborateurs qui se trouveraient dans une situation analogue : j’espère les rassurer quant à la faisabilité d’une telle réalisation, mais aussi leur permettre d’anticiper une partie des difficultés qu’ils pourraient rencontrer.

Toutefois, avant de vous mettre à l’œuvre, la première question à vous poser est celle du gain visé.

Si vous n’êtes pas familiers de la loi d’Amdahl , je vous en livre mon interprétation : il ne sert à rien d’essayer de paralléliser un problème qui ne serait pas au moins à 99.9% parallélisable.

Notre cas était de ce point de vue, idéal :

  • Il n’y avait aucune corrélation du cœur du traitement
  • Le “split initial” (*) consistait à rendre accessible les fichiers sources sur les n machines de traitement.
  • Le “merge final” (*) consistait à injecter les données produites dans une base de donnée commune.

Parrallelisation

Nous étions donc dans une cas de parrallélisabilité très avantageux, les seuls éléments non-parfaitement parallélisables étant gérés d’un coté par le système de fichier et de l’autre par une base de donnée.

De plus, les temps jouaient en notre faveur : pour un “split inital” et un “merge final” qui duraient une dizaine de minutes chacun, on avait un cœur de traitement qui durait environ 2 semaines, notre limite de gain, selon Amdahl était donc de l’ordre de 1000.

Le nombre maximal de machine à notre disposition étant de l’ordre de la centaine, cette limite ne nous gênait pas.

(*) Note : je n’emploie pas ici les mots de Map et Reduce pour ne pas surestimer implicitement notre réalisation. A proprement parler, notre solution n’est *pas* un MapReduce. Néanmoins, si vous êtes familiers avec ces notions, nous attaquons bel et bien ici les mêmes problématiques, à un facteur d’échelle moindre.

II) Première étape : Outrepasser la GUI

Évidement la première difficulté a consisté a outrepasser la GUI : si l’on ne peut pas lancer un calcul unique en ligne de commande, on ne pourra pas en lancer 2000 en parallèle.

1) Un robot

Une des solutions que j’ai déjà eu l’occasion de mettre en œuvre à titre personel consiste à réaliser un robot qui simule le comportement de l’utilisateur en :

- manipulant souris et clavier,

- analysant les données reçues à l’écran.

Cette solution pour le moins approximative, et très peu robuste, ne mérite d’être considérée qu’en absence de toute autre solution.

De nombreux outils peuvent nous permettre de réaliser ce genre de choses. Parmi ceux que j’ai pu tester à ce jour, celui qui me convient le mieux est AutoIt.

Il permet de réaliser rapidement un exécutable qui manipulera votre application, pourvu que celle-ci vous fournisse des données d’interface suffisantes.

Voici un exemple d’utilisation d’AutoIt pour identifier de façon certaine un contrôle de la calculatrice Windows.AutoIt

2) Un robot “intelligent”

Il arrive souvent que les contrôles fournis par l’application ne soient pas de contrôles windows standard. C’est par exemple le cas, lorsque l’affichage est réalisé directement par DirectX ou OpenGL. Dans ce cas-là les outils comme AutoIt ne suffisent plus et il faut faire appel à des techniques de traitement de l’image directement sur des captures d’écrans.

Voici un exemple de traitement du signal appliqué à un robot, issu d’un ancien projet. Le robot était supposé jouer à un jeu vidéo, dont l’un des buts était de cliquer sur les différents “rochers” présents à l’écran pour en récupérer le minerais.

Source

Source

Resultat

Resultat

Code

Code

Contrairement à ce que croient la plupart des développeurs que j’ai pu rencontrer dans ma carrière : traiter une capture d’écran n’est pas quelque chose de techniquement compliqué. Le code ci-dessus en témoigne. Ce qui est compliqué, c’est de concevoir l’algorithme, c’est d’expliquer avec des mots, ce à quoi nous reconnaissons telle ou telle forme. Essayez sur l’image source, vous verrez que ce n’est pas facile. Mais nous sortons là du cadre de ce billet.

Si j’ai pris ici un exemple issu d’un projet de robot-joueur, c’est parce qu’il s’agit d’un cas beaucoup plus complexe que ceux que vous pourrez rencontrer dans le cadre de GUI classiques : les formes changent en fonction de la position de la caméra (il s’agit d’une vue en 3D), les couleurs changent avec l’heure du jour (plus sombres la nuit, plus rouge à l’aube et au crépuscule…).

Malgré cela, vous pouvez constater qu’il est possible d’identifier les rochers en une quarantaine de ligne de code en n’utilisant que les bibliothèques Java standard. La difficulté n’est donc pas technique.

3) Inconvénients des robots

Le plus gros inconvénient de ces outils reste qu’ils sont très fragiles face à un changement de contexte ou de comportement de l’application. Ils nécessitent donc la mise en place d’un système de reprise sur erreur efficace. (Le robot-joueur sus-mentionné par exemple, possédait un ratio nombre de fonction / nombre de fonction de reprise proche de 1/20)

Un autre inconvénient majeur est qu’ils s’appuient sur les ressources d’affichages, qui sont rapidement limitantes dans des contextes de machines virtuelles.

De plus, la version “intelligente” consomme énormément de ressources processeur, même si l’on a recours à des techniques de traitements du signal plus avancées (qui en outre sont moins accessibles aux développeurs n’ayant pas eu la chance de suivre une formation de traitement du signal).

Enfin, aussi complexes soient-elles à mettre en œuvre, de telles solutions laissent aux techos que nous sommes un arrière goût amer d’amateurisme et d’absence de qualité, puisque l’on tente de reconstruire de l’information après l’avoir perdue.

Dans le cadre de l’application décrit dans ce billet : nos premiers essais avec AutoIt ont donné d’excellents résultats. Mais nous avons finalement identifié une solution plus robuste.

4) Attaquer directement les dll de l’application

Le fournisseur de l’application est venu à notre secours en nous permettant d’exploiter une idée ingénieuse : nous interfacer directement avec les dll qui composent le produit.

Il faut dire qu’ils ont réalisé un énorme boulot dans ce sens là, en nous présentant une API C relativement simple et lisible qui nous permet de lancer les fonctionnalités de base du produit.

De plus il faut ajouter que l’un des atouts majeurs du produit en question est d’embarquer son propre langage de scripting. Ainsi, les fonctionnalités qui ne sont pas directement accessible via l’API, le sont le plus souvent en créant et lançant, via cette même API, un script idoine.

Au final nous avons donc réalisé un petit programme en C++ qui nous permet de lancer un unique script, et dont voici le workflow :

Exescript : Workflow

Nous avons appelé ce programme “Exescript”.

5) GUI versus ligne de commande

Au lancement de ce projet, nous avions sous-estimé la différence de “culture” qu’il existe entre un programme fait pour être manipulé au travers d’une GUI et un programme fait pour être manipulé en ligne de commande.

Voici la liste des problèmes liés à ce point que nous avons du régler.

5.1) Les logs ne sont pas cruciaux pour une GUI

Vous avez pu voir au chapitre précédent que nous redirigions les logs dans un fichier. Nous croyions que cette redirection suffirait à traiter le sujet des logs. Nous nous trompions.

  • Pour une application en ligne de commande, les logs sont cruciaux : on lance une action, on s’attend à ce qu’elle renvoie un log qui explique, a minima, si elle a réussi ou échoué.
  • Pour une application accessible via une GUI, les logs sont souvent anecdotiques : on lance une action, on s’attend à voir le résultat sous forme graphique (le bouton a changé de couleur, le résultat de notre calcul s’est affiché à l’écran …)

Une des conséquences de cette différence de philosophie, c’est que nous nous sommes retrouvés dans de nombreux cas sans aucune trace à exploiter pour déterminer si les traitements s’étaient correctement déroulés.

Plus grave encore, les logs sont la seule indication que nous ayons du fonctionnement de l’application. De nombreuses applications développées autour de GUIs s’autorisent à se mettre occasionellement dans des états instables et supposent que l’utilisateur voyant la GUI figée aura l’idée de redémarrer l’application. En décidant d’utiliser une telle application sans passer par sa GUI, on se retrouve dans des situations où seuls les logs nous permettent de déterminer que l’application n’est pas dans un tel état instable.

Il nous a donc fallu largement et un peu artificiellement enrichir les logs de nos scripts afin de pouvoir suivre leur comportement.

5.2) L’initialisation des logs n’est pas loguée

Le script de redirection des logs lui-même a posé un problème supplémentaire, dans la mesure où, tant qu’il n’a pas été exécuté avec succès, nous sommes dans le noir : s’il échoue, il logue une erreur dans la GUI. Mais nous ne pourrons la voir puisque la redirection a échoué.

Pour résoudre ce problème nous avons :

  • effectué un maximum de tests en C++ sur la créabilité du fichier avant d’appeler le script de redirection
  • encapsulé la fonction d’appel du script de redirection dans une boucle de tentative-échec, controlée par la lecture du fichier.

Quelque chose comme ceci :

Redirection : Workflow

5.3) Les pop-ups

Autre différence de comportement entre l’utilisation entre une GUI et la ligne de commande : les pop-ups.

Par moment, quand l’application rencontre un évènement inattendu, elle le signale par le moyen d’une fenêtre qui apparait à l’écran. Dans le cas d’une utilisation en ligne de commande, ces pop-ups, sont un problème, puisqu’aucun utilisateur n’étant disponible pour cliquer sur le bouton “ok”, l’application reste en attente indéfiniment.

Trois solutions ont été successivement mises en place pour résoudre ce problème :

  • un robot écrit en Java qui vérifie les noms des fenêtres ouvertes et envoie le message (KEYPRESSED / touche entrée) à toute pop-up.
  • le monitoring des fichiers de log de l’application : tant que l’on observe des changement de taille, c’est que l’application tourne. Si l’application cesse de loguer pendant plus de n minutes, c’est qu’elle est arrêtée. On tue alors le thread et l’on considère que l’action a échoué.
  • une demande évolution de l’application auprès du fournisseur : lorsqu’elle est lancée depuis l’API, celle-ci ne doit plus afficher plus de pop-ups mais lancer des exceptions.

Si le robot a disparu aussi tôt que le monitoring a été mis en œuvre, ce dernier a, lui, vocation a être conservé. En effet, il pourra servir de garde fou à l’évolution de l’application.

S’il advenait qu’un jour l’application génère des boucles infinies, de nouvelles pop-up ou simplement qu’elle cesse d’émettre des logs, ce mécanisme nous permettrait une détection de l’erreur et une reprise immédiatement sans autre développement.

5.4) Les échecs d’identification de l’utilisateur

Le comportement par défaut de l’application, lorsque l’utilisateur entre un login non-présent dans la base de donnée est ce que le fournisseur appelle un “hard exit”.

Autrement dit : il y a quelque part dans la méthode d’identification des dll que nous attaquons, un test qui ressemble à :

if (!exists(bdd,login)){exit (1);}

Un tel comportement est réellement problématique pour nous, car il n’y a aucun moyen pour notre application de récupérer la main et donc d’agir en conséquence. Ceci est d’autant plus grave que :

  • le fournisseur de l’application a refusé de faire évoluer l’application dans ce sens argumentant qu’il s’agit d’un mécanisme de sécurité
  • en cas de non-disponibilité de la base de donnée, le login n’est pas trouvé et le comportement est exactement le même.

Ce problème n’a pas été résolu à ce niveau là de l’application. Nous allons voir dans la suite de ce billet que sa gestion a été déportée au niveau du LoadBalancer.

5.5) Les crashs

Malheureusement, comme cela arrive parfois avec les applications monolithiques un peu anciennes (surtout celles qui embarquent des langages de scripts), notre application peut occasionellement crasher. Les causes peuvent être diverses :

  • fuites de mémoire impliquant sur une absence de mémoire disponible,
  • buffer overflow (l’application utilise des tableaux de taille fixe),
  • segmentation fault (en particulier à cause des scripts embarqués),

Dans notre cas, ces crashs conduisaient à une congestion complète de l’application, car le comportement par défaut de l’OS était d’ouvrir une pop-up de crash qui attendait simplement que l’utilisateur choisisse une action à lancer :

Windows Crash

Outre la résolution des cas de crashs identifiés, notre action a été de paramétrer l’OS de manière à ce qu’en cas de crash, plutôt que de lancer une pop-up, il génère un dump de l’application, que nous pouvons envoyer au fournisseur de manière à ce qu’il puisse l’ouvrir avec son débogueur et ainsi identifier la cause du crash.

Voici un premier et un second point d’entrée dans la MSDN qui vous permettront d’approfondir la question.

III) Deuxième étape : paralléliser

1) Architecture

Parmi les contraintes de planification que nous avions, il y avait, en particulier :

  • La nécessité d’obtenir les premiers résultats immédiatement. En effet, la solution proposée étant peu académique, il n’était pas question de proposer au client d’investir plusieurs semaines de travail avant de pouvoir constater sa viabilité. Autrement dit : il a fallu convaincre.
  • De fortes contraintes quant aux applicatifs que nous pouvions installer. En effet, l’ensemble de l’infrastructure informatique du client étant gérée par un organisme dédiée à cette tâche, celui-ci impose une certaine rationalisation des applicatifs installés.

Ces deux contraintes, associées à notre complète ignorance des frameworks de parallélisation (TerraCotta, OpenMPI, GridGrain …), excluait d’emblée l’utilisation de l’un d’entre eux.

De plus, notre besoin étant relativement basique, nous avons opté pour une architecture spécifique simple :

Architecture

Le principe est simple :

  • un maitre détient une liste de tâches à réaliser et contrôle des esclaves. Maitre et esclaves disposent d’un thread qui contrôle le nombre de tâches lancées en local, notamment en fonction des contraintes locales (logicielles et matérielles : nombre d’installation de l’application disponibles, drivers de base de donnée accessibles, disponibilité des processeurs …).
  • la communication client / maitre, se fait par telnet, les instructions de bases sont :
    • rafraichir la liste des données à traiter,
    • ajouter une tâche,
    • stopper l’ensemble des tâches,
    • mettre à jour l’application
  • la communication maitre / esclave , se fait aussi par telnet, sur un autre port évidemment, les commandes de bases sont :
    • le client demande une ou plusieurs tâches au maitre,
    • le maitre envoie une tâche à un esclave,
    • l’esclave informe le maitre du succès ou de l’échec d’une tâche,
    • le maître demande à l’esclave de s’arrêter,
    • le maître demande à l’esclave de se mettre à jour
  • la plupart des tâches consistent simplement à lancer l’Exescript, c’est à dire l’application que nous avons décrite dans la première partie de ce post, en lui fournissant les paramètres spécifique

2) LoadBalancer

L’application installée sur chaque machine est qui prend le rôle master ou slave (selon la machine) a été développée en Java, nous la nommons “LoadBalancer”.

A ce jour, c’est à dire un peu plus d’un an après la version 0.1, ses métriques sont les suivantes : 11 packages / 121 classes / 560 méthodes / 7500 lignes de code

Mais nous sommes aujourd’hui en version 4.6, un certain nombre de fonctionnalités ont été ajoutées qui ne sont pas strictement nécessaires au fonctionnement :

  • l’analyse des logs à la volée
  • un système de reprise pour les tâches échouées
  • la capacité de brancher et débrancher des slaves à chaud, sans perdre de tâches
  • des verrous qui permettent de détecter des erreurs récurrentes et d’alerter l’administrateur d’une contrainte d’infrastructure anormale
  • une tâche métiers permettant la préparation des données avant le traitement (cf chapitre dédié plus bas)
  • la capacité pour l’application de se mettre à jour à chaud (sans s’arrêter), et à mettre à jour à chaud les installation de l’application monitorée
  • un embryon de capacité à ajouter des tâches sous forme de script lua

Il ne faut donc pas surestimer le travail nécessaire à la création d’une telle application. La toute première version a été écrite en moins de trois jours, et elle permettait déjà de valider le concept, et de diviser les temps de traitement par un facteur 2 ou 3.

3) La raison d’être des instructions : le fonctionnement au flux

Outre la parallélisation, nous avons décidé de mettre en place un fonctionnement “au flux”. C’est à dire que plutôt qu’une application que l’on lance en lui précisant où trouver toutes les données de départ et qui rend la main une fois que toutes les données sont traitées, nous avons réalisé une application qui reste allumée en permanence, et à laquelle on peut demander (par le biais des instructions) de traiter toutes les données qui n’ont pas encore été traitées.

De mon point de vue, il n’y a que des avantages à concevoir toute application de batch “au flux” :

  • lorsqu’on le conçoit dès le départ, le fonctionnement au flux n’est pas techniquement plus compliqué à réaliser qu’un fonctionnement mono-tâche.
  • il permet de se poser de bonnes questions au cours du développement. Par exemple dans notre cas :
    • est-il possible de remplir deux bases de données en même temps (pré-prod et qualif par exemple) ?
    • est-il possible de traiter deux sources de données ?
    • peut-on traiter des données partielles ?
    • peut-on impacter une modification des données ayant eu lieu a posteriori ?

    aucune de ces fonctionnalités ne faisait partie du besoin à l’origine, et à ce jour toutes n’en font pas encore partie. Mais certaines nous ont été demandées a posteriori et d’autres ont été utilisées parce qu’elles étaient disponibles.

  • il est toujours possible d’utiliser de façon unitaire une application développée pour gérer des flux (lancer un serveur mail pour envoyer un mail par exemple), mais il est toujours nécessaire et souvent compliqué de transformer une application développée pour gérer un traitement de façon à ce qu’elle gère un flux

Ces deux mécanismes (le fonctionnement au flux et la parallélisation) sont à la fois complémentaires et concurrents : chacun des deux si nous avions les moyens de l’exploiter entièrement nous permettrait idéalement de ramener le temps de traitement à dix minutes, mais dans des conditions réelles, ils se complètent pour nous permettre d’obtenir un temps de l’ordre de 2 heures.

4) Les tâches de préparation des données

Nous avons dit plus haut qu’il existait des tâches préalables au traitement des données. Concrètement il s’agit d’absorber un défaut du SI émetteur qui n’empaquète pas toujours les données dans les bonnes archives.

orphans

Réorganiser les archives zips ne semble pas être un problème très compliqué en soi. Et de fait nous avons réalisé en quelques dizaines de minutes, en marge du projet, un outil python capable de réaliser cette réorganisation.

Cependant, ce problème est doublement pénalisant pour nous :

  • il ne s’insère pas facilement dans un process au flux
  • il tend à augmenter le temps de “split initial” des données, c’est à dire à faire décroitre notre facteur de Amdahl

Fort heureusement nous avons trouvé une solution permettant de paralléliser la résolution de ce problème en :

  • concervant un pool de fichiers mal positionnés que nous réintégrons à la volée dans les futurs traitements
  • relançant la tâche de traitement d’une archive si l’on reçoit un fichier qu’elle auraient du contenir
  • fusionnant les tâches identiques dans notre task-queue

Cette solution ne fonctionne que parce que le nombre de fichiers déplacés est faibles, mais s’ils étaient beaucoup plus nombreux, l’ensemble de notre travail eut pu être largement impacté. Notre outil python sus-mentionné effectue le travail de réorganisation complet en environ 30 minutes. Comparé aux 2 heures de traitement, ce n’est pas négligeable.

5) De l’importance du logging

Si vous avez lu la première partie de ce post, vous aurez constaté que nous avons déjà deux niveaux de logs :

  • les logs engendrés par l’application
  • les logs engendrés par l’exescript

A ces deux niveaux de logs, nous rajoutons évidement un troisième niveau qui correspond à celui du LoadBalancer lui-même, et en particulier tous les logs liés au travail de synchronisation entre les instances de l’application.

Mais plus important : nous avons intégré dans le LoadBalancer une fonctionnalité de traitement des deux autres niveaux logs à chaud. C’est à dire qu’il parse et synthétise les quelques millions de lignes de log des deux premiers niveaux (4 lors du dernier import), remontant les erreurs graves, ainsi que diverses statistiques.

6) Dimensionnement processeurs

6.1) Architecture matérielle

Une fois notre prototype réalisé et testé sur une dizaines de processeurs, il nous a fallu dimensionner le parc informatique dont nous avions besoin.

Notre première approche fut d’appliquer une règle de trois, mais c’était sans compter :

  • les problèmes de ressources partagées inattendues qui sont traités dans la dernière partie de ce billet
  • les spécificités de l’architecture VM-ware détaillées ci-dessous

Sans réexpliquer les architectures VMware, dont je ne suis d’ailleurs pas spécialiste, l’un des principes en est le suivant : une VM voit n cœurs (ou processeurs) virtuels. Du point de vue de l’OS ou des applications, ces cœurs virtuels sont identiques à des cœurs physiques sur une machine réelle. Mais en réalité, les diverses opérations censément réalisées par ces cœurs virtuels sont ventilées à la volée sur les n cœurs physiques ou logiques.

Il existe donc un facteur multiplicatif qui sert à mesurer la charge d’une VM, il s’agit du ratio entre les cœurs virtuels et physiques (ou logiques). Ce facteur, chez notre client, est nommé “contention”.

Ce facteur multiplicatif, doit être multiplié, dans notre cas, un second facteur qui est lié à l’hyper-threading. En effet, les cœurs des ESX mis à notre disposition ne sont pas des cœurs physiques réels, mais des cœurs logiques.

VMWare

Je ne reviens pas sur les nombreux bienfaits de la virtualisation. Il est pour moi évident qu’à part dans des cas très spécifiques, l’on veut aller vers de plus en plus de virtualisation du hardware.

6.2) Parenthèse sur l’hyperthreading

Je ne reviens pas non-plus sur le très controversé débat sur l’hyper-threading, il me semble que tout le monde est d’accord sur les deux conclusions suivantes :

  • un processeur hyperthreadé est plus rapide que le même processeur non-hyperthreadé
  • un processeur hyperthreadé n’est en aucun cas comparable à deux processeurs physiques

A mon avis l’essentiel du débat réside d’ailleurs dans l’angle marketing sous lequel Intel l’a présenté : avoir introduit la notion de “processeur logique” sous-entend qu’un processeur hyperthreadé équivaut à deux processeurs physiques.

Ce n’est pas le cas, ce n’est d’ailleurs pas ce que Intel prétend.

6.3) Cas pratique

La virtualisation des machines, aussi utile soit elle, nous a toutefois joué un tour, pas tant du à la technologie elle-même qu’à la compréhension que nous en avions.

En effet, notre client négocie deux choses auprès de son opérateur informatique :

  • un nombre de VM
  • une contention maximale (cf plus haut)

La contention maximale négociée, tient compte d’un fonctionnement “normal” des applications. La plupart des applications étant la plupart du temps en attente, le foisonnement naturel fait qu’une très grande contention est parfaitement acceptable.

En écrivant ce billet, je me suis rendu compte, que je n’avais aucune idée de la charge “moyenne” d’une application, j’ai donc réalisé l’opération suivante sur une de mes machines (sur laquelle j’ai installé un postfix) :

$ time smtp-source -s 1 -l 1024 -m 500 -c -f root@localhost -t spam@localhost -4 127.0.0.1:25
500
real 0m33.245s
user 0m0.088s
sys 0m0.460s

J’en déduis que la charge nécessaire à l’envoi de 500 emails sur cette machine (il s’agit d’un Kimsufi de chez OVH) est de l’ordre d’une demi-seconde (répartie sur 33 secondes de temps réel). Autrement dit, qu’une contention maximale acceptable pour cette machine si elle ne faisant qu’envoyer des emails et était située sur une VM serait de l’ordre de 60.

De ce chiffre, l’on comprend facilement l’un des objectifs de l’utilisation de VM : l’économie de processeurs. Chaque application n’ayant besoin d’un processeur que pour quelques millions d’instructions de temps en temps, on partage l’accès processeurs entre les applications sans que cela soit néfaste pour celles-ci.

Cependant, notre cas d’utilisation n’entre pas dans ce schéma de fonctionnement. En effet, nous avons réparti un traitement lourd sur l’ensemble de nos machines. C’est à dire que quand l’une de nos machine travaille, il y a fort à parier que les autres aussi. Ainsi, le mécanisme de virtualisation, vient jouer un rôle directement opposé à celui du LoadBalancer.

Foisonnement

A cela, il faut ajouter le fait que notre application est une application de calcul, et donc typiquement consommatrice de temps CPU, alors que dans de nombreuses autres applications, les accès à d’autres ressources (disque ou réseau) peuvent être limitants. (A cet égard, les chapitres sur l’utilisation successive de NAS, de SAN et de RamDisks explique en quoi nos logs ne nous ralentissent pas).

Lors de nos premiers tests, nous utilisions une dizaines de processeurs sur un ESX présentant un certain nombre de cœurs physiques (16 ou 32 je ne sais plus). Lorsque nous utilisions nos machines à 100%, nous privions les autres projets ayant des VM sur ce même ESX de nos 10 processeurs physiques. Cela représentait pour eux une charge importante de l’ESX.

Cependant, lorsque nous sommes passés à 50 processeurs, nous avons commencé à nous faire concurrence à nous-même. C’est à dire que nous occupions un volume de l’ESX suffisamment important pour ne plus pouvoir compter sur le foisonnement naturel des applications.

Ainsi, nous avons pu obtenir de très belles courbes où nous observions une saturation très nette de nos performances (ici la courbe bleu représente la vitesse de traitement des données alors que la courbe verte représente le nombre de cœurs utilisé ) :

VM-Ware saturation

Pour ce problème, toute solution est bonne à prendre dès qu’elle augmente le ration nombre de processeurs physiques réellement sollicités sur nombre de tâches en parallèle :

  • diminuer la contention théorique
  • répartir les VM sur différents ESX
  • réserver des machines virtuelles sur nos ESX et ne pas les utiliser
  • désactiver l’hyperthreading (en conservant le même calcul de contention : logique / virtuels)

6.4) Un outil pratique : la rampe

J’ouvre ici une parenthèse pour commenter l’outil ayant permis la génération du graphe ci-dessus. Il s’agit ni-plus ni moins que de notre LoadBalancer auquel nous avons apporté deux modifications :

  • le nombre de tâches qu’il s’autorise à lancer en parallèle est fixé par le temps (il s’agit de la rampe verte)
  • lorsqu’il termine la liste de tâches qu’on lui a confié, il recommence, de manière à ne jamais manquer de tâches

Nous avons beaucoup hésité à réaliser un tel outil, entre autre pour la raison qu’il était structurellement opposé aux choix que nous avions fait jusque là. En particulier notre application était basée sur le fait que ce sont les slaves qui s’enregistrent auprès du master et donc que leur nombre et leur répartition est entièrement dynamique.

Finalement nous avons opté pour la création d’une branche “brouillon” de notre application principale. Ainsi cette application de rampe n’est ni industrialisée ni maintenue.

Étant donné les énormes avancées de diagnostics que cet outil nous a permis de réaliser, je pense que si c’était à refaire, nous inclurions ce fonctionnement dans l’application dès la conception de celle-ci.

7) Autre dimensionnements

Comme nous l’avons dit précédemment, notre application est typiquement consommatrice de CPU (par opposition aux accès réseaux ou disque) : elle effectue des opérations de calcul lourdes sur de faibles volumes de données. Il ne nous a donc pas paru pertinent d’effectuer d’autres dimensionnements que ceux liés au processeurs.

Dans une des premières version, le LoadBalancer travaillait directement sur un disque dur réseau commun ou NAS (pour Network Attached Storage).

Etant donnée que la lecture des données d’entrée et l’écriture des données de sortie ne représente qu’un faible pourcentage du temps total de traitement, nous avions calculé que ce facteur ne serait pas limitant. Cette solution s’est maintenue un certain temps, mais le nombre de VM et la quantité de logs produits augmentant, le NAS est devenu une ressource limitante.

Nous sommes donc passé à un système où nous :

  • commençons par copier les données source sur le disque local (dans notre environnement VMWare il s’agit d’un SAN avec réseau fibre dédié)
  • effectuons les traitements
  • finissons par copier les données et les logs produits sur le NAS

Ce simple basculement suffit à rendre le facteur disque complètement négligeable.

A posteriori, il me semble évident que les logs à eux seuls étaient responsables de l’essentiel de la congestion. Et nous aurions sans doute pu nous permettre de ne déplacer qu’eux. Si toutefois il fallait prendre à nouveau la décision, je pense que nous prendrions la même étant donné qu’une donnée produite sans les logs associés à sa production n’a que peu de valeur.

8 ) Chronogrammes de “Suivi” des actions

Pour enrichir la liste des outils que nous avons créé et qui ont été très pratique, je voudrais mentionner le générateur de chronogrammes, c’est à dire l’outil qui fabrique ces graphes :

Serialisation

Idéalement, nous aurions pu nous interfacer avec une application de monitoring de type Jenkins, mais là encore le “vite développé” et “ne rien installer” a triomphé sur le long terme. Nous avons donc développé un petit (250 lignes) script en PERL qui parse les logs et génère un fichier au format svg.

Le gros avantage d’une telle solution est qu’elle est rapidement développée, et surtout qu’elle est facile à faire évoluer au fil de l’évolution des logs. A chaque fois que les logs change, on peut facilement adapter le script. Bien sur cet avantage vient au prix d’une faible maintenabilité : il est très souvent nécessaire d’adapter le script.

Quoi qu’il en soit : ce genre d’outil s’est avéré indispensable à la mise au point de notre application. Un bug dans un traitement se voir presque immédiatement sous cette forme, y compris pour les bugs que l’on n’a jamais rencontré. Si nous devions développer une telle application à nouveau, je pense que nous n’hésiterions pas à intégrer la génération de ce type de graphe aux objectifs des toutes premières versions.

Ci dessous plusieurs exemples d’erreurs :
Chronograms errors

9 ) Reprises sur erreur et verrous

La fragilité du développement décrit dans ce billet, en en particulier l’outrepassement de la GUI, implique qu’un certain nombre d’erreurs se produisent au cours de nos traitements. Ces erreurs sont compensées par un simple système de reprise : une tâche échouée est remise dans la queue du master avec une priorité moindre.
Une tâche échouée trois fois de suite est abandonnée.

Notons qu’une tâche est considérée échouée si on n’a pas la confirmation de son succès, y compris si l’on n’a pas eu non-plus de confirmation de sa réussite. Cette considération est importante dans la mesure où elle nous prive de la possibilité de gérer des tâches dont on ne sait pas vérifier le succès.

Lorsqu’une tâche échoue, elle peut blâmer une ressource (pas d’accès au fichier, disque absent, temps d’accès à la BDD trop long, etc.). L’ensemble des blâmes sont rapatriés sur le serveur, et celui-ci, s’il détecte un trop grand nombre de blâmes liés à une même ressource, peut générer un verrou sur cette ressource. Toute tâche qui nécessite l’utilisation de cette ressource ne peut alors plus être lancée jusqu’à ce que le verrou soit levé. En parallèle une alerte devrait (*) être envoyée à l’administrateur pour qu’il vérifie et/ou redémarre la ressource en question.

(*) Les alertes ne sont pas encore développées.

IV) Les problèmes spécifiques

Outre les problèmes d’outre-passage de la GUI et les problèmes de parallélisations, nous avons eu à diagnostiquer et résoudre un certain nombre de problème spécifiques à la conjonction de ces deux actions.

1) Les ressources partagées inattendues

1.1) Les mutex et évènements Windows

Parmi les choses que nous avons découvert à l’usage, il y a le fait que l’application monitorée utilise des Mutex et évènements Windows nommés. Ainsi, en lançant de multiples instances de cette application sur la même machine (à la fois en série et en parallèle), nous générions des interférences entre ces instances qui conduisaient à des temps de latence.

S’il nous était venu, avant de commencer le développement, l’idée de demander au fournisseur de l’application de nous renseigner sur l’existence de tels éléments, cela ne nous aurait pas aidé pour autant. En effet celui-ci a découvert cette existence en même temps que nous.

Parmi les outils qui nous ont permis de détecter ces interactions il y a les outils système ProcMon et ProcExp qui permettent de monitorer les différentes ressources et actions mobilisées par les différentes applications en cours d’exécution.
ProcExp

A ce problème nous n’avons en l’occurrence pas trouvé de solution. Aujourd’hui nous vivons avec. L’analyse des latences générées nous a permis de réorganiser nos traitements de manière à en tenir compte et à ne plus être pénalisé par ce phénomène. A ce jour, les seules limites qu’il induit sont :

  • l’impossibilité d’augmenter indéfiniment le nombre de traitements sur une même VM. La limite imposée étant de toute façon beaucoup plus haute que l’architecture choisie.
  • un coût en temps mesuré à une dizaine de seconde sur 10 minutes de temps de traitement (< 2%)

Ci-dessous : l’illustration du rapport qu’il existe entre les mutex et la limite du nombre d’instance utilisable en parallèle sur chaque VM :
Mutexes limit

1.2) L’affichage

Alors même que nos traitements n’affichaient rien à l’écran, il s’est avéré qu’ils réservaient quand même les ressources (OS et/ou hardware) d’affichage. Il s’ensuit que le lancement de certaines parties du traitement étaient fortement ralenties lorsqu’elles étaient déclenchées de façon synchrones.

Ce comportement a pu être isolé par observation des vitesses de traitement (mesurées en nombre de lignes de logs par minute) sur des traitements parfaitement identique lancés ou non en parallèle sur la même machine. Voici l’une de ces observations :
Graphical latencies

Une fois la zone de log posant problème isolée, notre connaissance du traitement a permis d’établir les particularités de cette zone, à savoir la création d’objets graphiques (en vue d’une utilisation ultérieure).

La correction à ce problème a été apportée par l’éditeur du logiciel. Aucune des options envisagées pour contourner le problème n’était de toute façon réellement satisfaisante. En particulier, la possibilité de démultiplier les VM (afin de n’installer qu’une unique instance de l’application par VM) avait un vrai coût en terme d’architecture (par exemple de nombre de cartes graphiques virtuelles sollicitées).

1.3) Le presse-papier

De façon fort étonnante, il s’est avéré que l’application monitorée vidait régulièrement le presse-papier de l’OS. Dans le cas d’une utilisation en parallèle, par de multiples applications sur la même machine, cette utilisation pouvait générer des concurrences et des latences.

Là encore la solution est venue de l’éditeur. Le diagnostic quant à lui a été obtenu en enrichissant les logs de l’application jusqu’à se rendre compte que des crashes apparaissaient dans cette zone.

2) Les ressources partagées attendues

2.1) Le serveur de licence

L’une des ressources partagées que nous avions anticipée est le serveur auquel chaque instance de l’application se connecte pour négocier une licence en début de traitement.
Nos premières estimations évaluaient le risque d’étranglement lié à ce serveur comme faible, le serveur répondant très facilement à une dizaine de demande en quelques secondes.

Toutefois, il s’est avéré à l’usage qu’un mécanisme de protection contre les attaques par dénis de service avait été implémenté dans ce serveur. Lorsque nos traitement demandaient “au même moment” plus de 20 licences (ce qui n’arrivait finalement pas spécialement souvent), le serveur se mettait à ignorer toute demande pendant quelques secondes.

Or le comportement par défaut du client était d’attendre une dizaine de minutes que le serveur réponde. Nous observions donc des initialisations de traitement de cette durée là, qui aboutissaient à des crashs.

Le diagnostic a finalement été réalisé par le fournisseur de l’application, de même que la correction.

2.2) les disques dur locaux (SAN) ?

L’autre ressource partagée que nous avions identifié sans la craindre était l’utilisation du disque dur. Un premier aménagement (détaillé plus haut), nous avait permis de passer d’un disque NAS à un disque SAN pour le traitement des logs.
A un moment de doute, alors que nous avions des difficultés à diagnostiquer d’autres problèmes sus mentionnés, nous avons eu un doute sur la capacité du SAN.
Dans la mesure où nous rapatriions et renvoyions les données/log/résultats sur le NAS en début et fin de traitement, nous nous n’avions en local que des fichiers temporaires. Nous avons donc décidé de mettre en place des RamDisks, pour ces fichiers.

S’il s’agissait d’une fausse piste (les derniers tests montrant des performances assez similaire en utilisant les RamDisks ou le SAN), il s’est avéré que les quelques % de gagnés nous permettaient à cette époque de passer en dessous d’une barrière bloquante dans un nombre important de cas.

A ce jour, nous travaillions encore sur RamDisk, il se peut que nous les abandonnions pour raisons de compatibilité avec le référentiel logiciel supporté par l’exploitant informatique.

V) Conclusion

Entre le début du projet et la rédaction de ce post, il se sera écoulé 18 mois. La taille de l’équipe a varié de 1 à 3 personnes, aucune n’étant affectée à temps complet sur cet outil. Si par moment nous avons douté de la rentabilité et parfois de la faisabilité de ce développement, il semble aujourd’hui tout à fait amorti.

Les excellents résultats obtenus encouragent aujourd’hui notre client à nous demander régulièrement d’intégrer de nouvelles tâches au traitement : extension du périmètre des données, nouveaux calculs et à nous confier de plus en plus de traitements.

Pour moi, il s’agit avant tout d’une expérience win-win, d’un exemple d’interaction positive avec le client. Notre proposition a été écoutée, entendue et nous avons eu le loisir de la mener à bien. Le client, en prenant le risque de nous faire confiance, s’est doté d’un outil aujourd’hui indispensable à la réalisation de ses objectifs.

Quant à nous, en nous faisant force de proposition et en nous investissant dans le projet, nous avons eu la chance de travailler sur un projet motivant mettant en jeu des complexités et des technologies choisies.

Posted in Moteurs de Calculs | Leave a comment

Agile Tour Toulouse 2013

Agile Tour Toulouse 2013

Agile Tour Toulouse 2013

Je me suis rendu pour la troisième fois à l’Agile Tour Toulouse avec toujours le même entrain. Le public y est un peu plus diversifié que dans les autres conférences auxquelles je suis habitué. 400 personnes étaient présentes à Diagora cette année, un petit peu moins que lors de l’édition précédente visiblement. Je vous encourage à aller voir mes précédents articles sur les éditions 2011 et 2012 de cette même conférence. J’ai essayé cette année de trouver un meilleur équilibre entre les présentations et les ateliers.

La Horde Agile

Pablo Pernot nous a rapidement plongés dans le bain, nous ramenant à nos racines de chasseurs-cueilleurs. Il a ainsi mis en avant ce qui faisait nos forces dans les temps anciens, revenant sur notre nature même.

On retrouve effectivement un certain nombre de notions communes : nos ancêtres étaient nomades, n’avaient pas besoin de s’appuyer sur des marqueurs chiffrés pour la chasse, se servaient de leur nombre et de leur endurance pour venir à bout par épuisement de leur proies.

Curieusement, ces troupes d’individus rassemblaient vraissemblablement aux alentours de 150 personnes, on retombe donc sur le nombre de Dunbar, qu’on retrouve un peu partout : dans le nombre d’amis moyen des gens sur FaceBook notamment. Il est communément admis que les membres d’un groupe de 7 ou 50 personnes ont un sentiment d’appartenance à un groupe ou à un département. Il est vivement conseillé aux entreprises de se découper en départements de 140 à 210 personnes, eux-même subdivisés en équipes de 7 ou 50 personnes (curieusement 50 est quasiment égal à 7* 7). Pour approfondir ce sujet.

Une autre notion abordée a été celle de l’over shadowing : quand on décrit quelque chose avec des mots, on a tendance à transformer un peu ce dont on parle. C’est par exemple le cas pour les témoignages. C’est à priori pour cela qu’on retrouve des peintures rupestres dans les grottes. La mémoire marche mieux avec des dessins et des écrits qu’uniquement avec des mots. Je passe rapidement sur la transmission des connaissances au coin du feu, sur l’apprentissage par le jeu (1, 2, 3, soleil)…

Pour clôre cette entrée en matière pour le moins intéressante, on pourrait résumer par le fait que nous sommes dans un monde complexe, fait d’inattendu et de désordre, et que c’est le terreau parfait pour l’innovation et l’évolution. Arrêtons de vouloir aller contre notre nature en se basant sur des indicateurs, laissons parler nos émotions et notre culture.

Les slides de la Horde Agile

La culture du Backlog

Le concept de cette présentation de Claude Aubry, était de présenter ce que Kanban pouvait apporter pour améliorer Scrum. La parallèle était cette fois fait sur la culture, voire même l’agriculture.

Le but était alors de pouvoir mieux connaître les stories en début de sprint, pouvoir injecter les changements plus rapidement qu’une itération de sprint et avoir une meilleure idée de l’avancement.

La fausse bonne idée : rajouter une colonne au tableau Scrum (à tester par exemple).

La vraie bonne idée : passer des colonnes à des bacs. L’idée est de limiter ici le stock.

On écrit les idées sur des cartes, on discute de celles-ci avec le Product Owner. On itère ainsi jusqu’à ce que la story soit prête. Voir les 3C de Jeff Patton : Card / Conversation / Confirmation.

Le concept peut être poussé jusqu’à la mise en place de 5 bacs :

  • Un bac à sable dans lequel on peut lancer les idées sans préjugé
  • Un bac de culture dans lequel on ordonne ces germes d’idées, on décompose les prioritaires qui seraient trop grosses pour des itérations, on détaille, précise ou même estime ces stories
  • Un bac de départ (starting blocks) qui contient les stories sélectionnées en début de sprint
  • Un bac de sprint pour les stories en cours
  • Un bac de récolte pour celles qui sont finies

En partant de ces principes, il devient nécessaire de faire une revue régulière de culture du backlog. On limite alors le nombre de tâches simultanées, en essaimant (swarming) les développeurs sur les stories (1 conteur qui a la responsabilité de la story et des butineurs qui l’assistent).

On peut alors limiter la taille du bac ce sprint, afin d’éviter d’avoir trop de stories en cours et non finies.

Il est aussi conseillé de mettre en place des alarmes sur une limite basse des bacs, poussant ainsi à les reremplir afin d’avoir toujours de quoi faire.

Afin d’aller encore plus loin, on peut aussi fluidifier la livraison des stories terminées au client en mettant en place du déploiement continu.

Les slides de la présentation

Table ronde : au delà de l’agilité, la culture

Je ne me hasarderai pas à essayer de reprendre, même en résumé tout ce qui a été dit sur le sujet. Cette session était animée par Emmanuel Gaillot, et Alexandre Boutin, Claude Aubry, Jean-François Jagodzinski, Laurent Morisseau et Yannick Ameur étaient présents pour donner leur avis.

En vrac, ils ont parlé de principes, de culture et de contre-culture, de rébellion, de rock&roll, de philosophie et de culture de l’entreprise. Mais aussi de savoir faire collectif, d’étiquette et de rituels d’équipe, du caractère des équipes, de s’améliorer, de placer l’humain au centre, de l’introduction du jeu…

Des questions ont ensuite été posées par l’assistance avec ou sans réponses des intervenants.

Durant toute la séance, une personne représentait graphiquement ce qui ressortait de la table ronde (honte à moi, je n’ai même pas pensé à immortaliser son oeuvre).

Une parenthèse plus philosophique très intéressante, dans un format difficile mais bien amené.

Une seule ressource citée cette fois : The Culture Game de Daniel Mezic.

Beer Game

J’apprécie particulièrement Alexandre Boutin en tant que présentateur/animateur. Encore une fois je n’ai pas été déçu. Le Beer Game est un jeu de plateau pas tout récent disponible gratuitement. Il ressemble fortement au Kanban Board Game que je vous avais présenté l’an dernier et permet de mettre en avant le même type de conclusions. On y joue par binômes de l’usine au consommateur (le seul à être seul), 9 personnes par table. Des packs de bière étaient promis aux gagnants. La coopération avec nos voisins nous a permis de plutôt bien nous classer. Au final nous nous sommes retrouvés à se partager les bières gagnées en discutant. Une bonne bouffée d’oxygène dans cette journée.

C’est en forgeant qu’on devient forgeron

Cette session était animée par Baptiste Mathus (notre JUG Leader actuel à Toulouse) et Michaël Pailloncy tous deux du Mipih où j’ai fait mes armes. Durant cet atelier, nous avons mis en place une forge logicielle quasiment complète. C’est une tâche que j’avais déjà effectuée sur notre plateforme de Toulouse et qui a aussi été effectuée sur Paris, mais je me suis dit qu’un rappel ne faisait jamais de mal.

Nous avons ainsi lancé jenkins, déployé une application Java dessus, avec des builds spécifiques en surveillant un repository Git. Chose que je n’avais pas encore faite de mon côté, nous avons continué et intégré Sonar pour faire de l’analyse de notre code.

La présentation, bien qu’un peu facile pour quelqu’un qui connaissait déjà le domaine, m’a semblé bien adaptée au public supposé de l’Agile Tour et permettait d’aborder un grand nombre de sujets sur l’intérêt des forges logicielles et de l’intégration continue. Vous pouvez trouver les sources et les instructions ici.

L’aventure d’un sportif de haut niveau vue au travers des grandes valeurs de l’agilité

Cette présentation était intéressante bien qu’un peu longue par moments. Il existe effectivement des notions communes, ainsi que des différences. Le parcours de Romain Mesnil (champion en saut à la perche pour ceux qui seraient complètement allergiques au sport), est pour le moins singulier. Il est désormais commercial pour une grande enseigne de services de couleur orange, a fait aussi du développement Java en entreprise en parallèle de ses préparations olympiques, à subi de lourds échecs et des problèmes de performance lors des olympiades. Et en bonus, pour ceux qui auraient vécu sur une autre planète et n’auraient pas vu ses spots de recherches de sponsors : sa recherche et son sponsor trouvé.

En complément, les liens vers des présentations auxquelles je n’ai pas assisté : Votre diplôme c’est vous et Kata Mölkky ainsi que la présentation sur le Software Craftsmanship d’Antoine Vernois (à visualiser avec la touche S pour voir les commentaires de la version speaker), celle sur le Lean Startup de Nicolas Deverge et le résultat d’Agile Smells.

Et enfin, les autres retours glanés ci et là : un retour à 4 (8?) mains d’ekito, les impressions de Claude Aubry et celui de Fabrice Aimetti.

Posted in Agile Tour, Agiles, Conferences, Divers, Methodologies, Scrum | 1 Comment

E-Learning

L’apprentissage en ligne est un phénomène relativement récent, mais qui explose depuis peu. Je m’y adonne depuis longtemps maintenant, en fait je crois bien l’avoir toujours fait, depuis mon entrée sur le marché du travail tout du moins. A l’époque je m’investissais beaucoup sur un site nommé javablackbelt, puis knowledgeblackbelt, mais qui a malheureusement été racheté depuis par un concurrent et été contraint de fermer.

Cette première expérience m’a clairement donné le virus et je n’arrête donc plus depuis. J’ai compilé tous les liens que j’ai trouvés durant ces quelques années et ai fini par en faire un Google doc, que j’ai partagé avec quelques amis. Autant que cela serve à d’autres, mais je n’étais toujours pas satisfait du taux de propagation de mes maigres connaissances à la matière.

La semaine dernière j’ai eu le plaisir de participer à un Code Retreat (le 3ème ou 4ème, je ne me rappelle jamais, je vous conseille mes articles sur le sujet si vous ne connaissez pas encore le terme) et le sujet a été remis sur la table lors de discussions entre participants. Nous avons collégialement décidé de monter un repository Git commun où chacun d’entre nous pourrait déposer ses bonnes adresses sur le sujet.

Ces informations sont désormais à la charge et sous l’égide du Software Craftsmanship Toulouse (SCT pour les intimes)  et accessibles gratuitement à l’adresse suivante : https://github.com/dojo-toulouse/apprendre

Je vous encourage très vivement à aller y jeter un coup d’oeil, et à contribuer si vous repérez de bonnes adresses manquantes!

Posted in Divers | Leave a comment

EclipseCon France 2013

L’EclipseCon France 2013 s’est déroulée les 5 et 6 juin 2013 à Toulouse. Voici les présentations les plus marquantes auxquelles j’ai pu assister.

Git & EGit beginner workshop

EGit est le « team provider » Eclipse pour travailler avec Git. Cet atelier était un tutoriel destiné aux débutants, pour ceux qui, comme moi, n’ont pas encore eu l’occasion de s’y frotter (tout en en ayant entendu beaucoup de bien…)

Alors, certes, un SCM distribué, c’est agréable : vous pouvez travailler (commit) dans votre coin et  publier plus tard vos travaux à vos coéquipiers. Mais il faut bien avouer que cela induit une certaine lourdeur. Il y a de nouvelles commandes à apprivoiser, en plus des classiques commit, update, merge : rebase, pull, push et j’en oublie certainement…

Actuellement utilisateur régulier de CVS et occasionnel de SVN, j’ai notamment apprécié une fonctionnalité de Egit : la « staging area », une sorte de « commit wizard ». Il s’agit en fait d’un espace temporaire dans lequel vous pouvez construire votre commit en y ajoutant et enlevant des fichiers, et en saisissant le commentaire (si souvent négligé et pourtant si utile !)

Remarque : CVS dans Eclipse propose une fonction à peu près similaire (et peut-être un peu plus complète) mais assez cachée : les « change sets ».

Mais bien sûr, l’immense avantage de Git, c’est la vue « Historique » qui présente un graphe complet (et pas juste une liste de commits triés par date). Reste à savoir à quoi ressemble ce graphe après quelques années…

Un petit reproche : quand on fusionne deux branches, en cas de conflits, le réflexe de EGit est de modifier le code source en incluant les marqueurs textuels du diff classique. J’aurais préféré une prévisualisation avec un éditeur graphique de différences (« two-way compare »). Remarque : cet éditeur peut être ouvert sur  le fichier source en conflit après la fusion pour aider la résolution.

Mon impression générale : si CVS proposait une solution simpliste au problème complexe du SCM, Git propose une solution plus complète mais aussi beaucoup plus complexe. L’intégration dans Eclipse est bien faite mais manque de fluidité dans son utilisation. Elle demande un investissement non négligeable.

Tycho: the mandatory tool to build your Eclipse based product

Tycho est une extension de Maven dédiée à la construction de produits Eclipse (OSGi, p2) : plugins, features, update sites, products, etc.

En plus de la construction d’artefacts, Tycho peut prendre en charge l’exécution de tests unitaires (y compris de l’interface graphique avec SWTBot comme démontré lors de cet atelier). Et tout cela pour toutes les plateformes que vous voulez : selon l’OS, l’architecture, la version Eclipse, etc.

Premier avantage : Tycho découvre les dépendances depuis les méta-données OSGi (plugins metadata, etc.) au lieu du pom.xml. Inutile donc de coder en double les dépendances.

Second avantage : Intégré dans Maven, vous bénéficiez de tout de ce qui vient naturellement avec (Jenkins, Jacoco, Sonar, etc.)

Quelques bémols tout de même : Ce produit est encore en incubation aujourd’hui. Certaines commandes maven sont à privilégier (mvn verify plutôt que mvn install, par exemple). Les dépôts de composants ne sont pas des dépôts Maven standard, mais des dépôts p2 (remarque : il existe des passerelles).

Software Quality: the Eclipse Way and Beyond

Le groupe de travail PolarSys a lancé une initiative visant à définir une modélisation de la qualité d’un projet logiciel typique du monde Eclipse. Cette modélisation est en cours d’élaboration et le processus d’assurance qualité recherché a pour objectif : d’être entièrement automatisé (mesure sans intervention humaine), transparent pour ses utilisateurs (lisible par un humain), utilisable à des fins d’amélioration de la qualité (et non pas pour mettre en concurrence les projets audités).

Trois domaines de qualité sont audités : le produit, le processus de développement et la communauté. Pour que l’automatisation soit complète, des métriques précises ont été choisies dans chaque domaine. Pour le produit, elles sont connues : lignes de code, pourcentage de commentaires, mauvaises pratiques, etc. Pour le processus de développement, on comptera les jalons, les revues, les demandes d’évolution, etc. Pour la communauté, ce sont les mailing lists qui sont audités (nombre de sujets abordés, nombre d’auteurs, délai pour obtenir une réponse, etc.).

Un projet bien ambitieux, donc, mais très intéressant.

Orion deployed: Orion goes from prototype to production

Orion est un « IDE allégé » en ligne, utilisable directement dans votre navigateur. On y trouve notamment : un éditeur texte avec coloration syntaxique, un navigateur de fichiers, une console (pour exécuter des commandes !), des fonctions de recherche, un éditeur de différences entre fichiers, l’intégration avec Git, le branding, etc. Attention tout de même : ce n’est pas Eclipse dans votre navigateur…

Le serveur est conçu pour être extensible : il est possible de développer des plugins qui vont venir compléter les fonctionnalités déjà présentes. Et tout cela en étant déployé sur d’autres serveurs physiques !

Quelques autres « fonctionnalités » transversales qui sont encore plus ou moins en travaux : accessibilité, globalisation (caractères unicode, langues RTL, etc.)

OSGi: Don’t let me be Misunderstood

OSGi est le framework sur lequel se base Eclipse pour gérer les plugins. Mais c’est un framework complexe. Très complexe, même. L’objet de cette présentation (pour débutants) était de montrer que cette complexité répond aux problématiques de modularité dans le monde Java. Eh oui, tout cela a une raison, et la voici explicitée en 7 points :

  • OSGi permet de spécifier l’environnement d’exécution de votre application (« quelle version de Java ? »).
  • OSGi permet de différencier artefacts et modules : mort aux JARs, vivent les bundles !
  • OSGi permet de restreindre la visibilité des packages dans un module en en publiant certains (car les mots-clés de Java ne suffisent pas).
  • OSGi permet de charger plusieurs versions différentes d’une même classe pour « éviter » les soucis d’intégration.
  • OSGi donne une sémantique aux numéros de versions pour pouvoir les exploiter et vérifier les dépendances entre modules.
  • OSGi gère le cycle de vie des bundles (de leur installation à leur désinstallation).
  • OSGi propose le pattern µServices pour régler son compte au couplage des modules.

Now that I’ve Got a Model – Where’s my Application?

Une démonstration impressionnante de la puissance du couple EMF+CDO. Grâce à EMF, vous pouviez déjà définir votre modèle et générer :

  • le code correspondant,
  • une interface graphique minimaliste pour manipuler votre modèle, l’enregistrer et le charger avec le format XMI.

Vous n’êtes pas impressionnés ? Qu’à cela ne tienne, EMF peut donner bien plus que cela !

Une fois complétée votre interface graphique à l’aide des divers assistants de PDE et WindowBuilder, vous pouvez remplacer la couche de persistance XMI par un serveur CDO qui vous offre notamment :

  • Un modèle partagé entre utilisateurs sur le réseau (TCP) ;
  • Un modèle persistant, enregistré dans une base de données ou ailleurs ;
  • Des mises à jour en temps réel des interfaces graphiques des clients ;
  • Des verrous sur les objets du modèle (verrous optimistes ou pessimistes, persistants ou non, et transférables d’un utilisateur à un autre) ;
  • Un langage de requêtage.

Dans l’avenir, CDO devra également offrir des mécanismes de migration du modèle persistant.

Cette présentation fut une bonne introduction à Live collaborative modeling goes industrial, feedback par Thales/Obeo du développement d’un atelier de modélisation collaborative utilisant notamment CDO. L’occasion de voir que CDO règle certains, mais pas tous les problèmes…

It’s all about feedback – code review as a great tool in the agile toolbox

SAP présentait ici son retour d’expérience sur la mise en œuvre de revues de code sur les projets agiles (Scrum) internes. En pointant notamment la différence entre pair programming et code review que certains considèrent redondants.

Si le pair programming permet le défrichage de nouveautés, la formation en favorisant la complémentarité des expériences, la revue de code améliore la lisibilité du code, profite à tout le monde puisqu’elle est publique et ouvre la porte aux solutions alternatives.

De plus, la revue de code étant asynchrone, elle peut être menée en parallèle avec d’autres actions et s’insère donc très bien dans les plannings. Évidemment, une partie de la revue de code peut être automatisée avec des outils de vérification du code (style, bad practises, etc.).

Gerrit est un outil de revue de code qui s’appuie sur Git et permet la revue de code changement par changement. Pour faciliter les choses, les changements doivent être les plus petit possibles, accompagnés d’un commentaire pertinent (expliquant le POURQUOI du changement et indiquant éventuellement le niveau de maturité du changement [POC, RFC, WIP]). Les commentaires de revue peuvent être catégorisés (style nit, optional, can be fixed later, unrelated change, etc.) et doivent proposer des alternatives quand c’est nécessaire.

Si tous les membres de toutes les équipes peuvent relire le code de tous les membres de toutes les équipes, il est tout de même utile d’inviter parfois certaines personnes à relire un changement qu’on vient de faire. Et bien sûr, si on attend des commentaires, on veillera à laisser aux autres le temps de relire le changement, en commençant autre chose, par exemple.

Si l’investissement est connu (1 heure par jour et par développeur), le retour sur investissement n’a, lui, pas été chiffré. Mais est-il chiffrable ? Il semble que tout le monde soit satisfait, et c’est plutôt bon signe…

Posted in Conferences, Eclipse, Eclipse Con, Java, Methodologies | Tagged , , , , , , , , , | Leave a comment

Développement d’une nouvelle application : le choix de JavaScript.

Suite à l’article de Vincent sur son retour du Devoxx et notamment sur ses interrogations “Du JavaScript propre ?” voici mon retour d’expérience sur le développement d’applications web riches dans le cadre d’un projet client.

Il y a encore quelques années il était très difficile voire impossible de développer des applications complexes sur un navigateur web. Le choix du client lourd s’imposait alors comme solution par défaut, faute d’alternative viable. JavaScript était alors considéré comme un langage peu performant aux fonctionnalités limitées. Les gens considéraient le code difficile à maintenir et à faire évoluer.

Aujourd’hui encore beaucoup de développeurs sont effrayés à l’idée de développer de grosses applications entièrement en JavaScript. Des frameworks comme GWT ou ZK ont alors pris beaucoup d’ampleur en permettant de faire des applications web sans toucher une ligne de JavaScript ou presque.

ZK fut d’ailleurs le framework de prédilection chez mon client pendant longtemps et nous continuons de l’utiliser sur certaines applications.

Mais l’avènement de l’HTML5 a amené avec lui la création d’un immense écosystème autour de JavaScript, avec entre autres de nombreuses bibliothèques et outils.

Saviez-vous par exemple que les principales applications Google (GMail, Google Maps, Google+ et bien d’autres) étaient écrites principalement en JavaScript ?

Dans cet article j’aimerai vous présenter les raisons qui nous conduisent à  à proposer des développements d’ applications JavaScript pour nos clients dans le cadre  de nouvelles applications.

  1. JavaScript : un langage orienté objet
    Le développement orienté objet en JavaScript diffère de la plupart des autres langages orientés objets car les objets ne sont pas des instances de classe, et l’héritage se fait par prototype. Vous trouverez beaucoup de littérature sur Internet à ce sujet, je ne rentrerai donc pas dans les détails ici, mais grâce à l’orienté objet, écrire un code propre, maintenable et réutilisable est tout à fait possible en JavaScript.
  2. Les bibliothèques
    Pour les applications sur lesquelles je travaille, nous nous appuyons principalement sur des bibliothèques reconnues qui ont fait leurs preuves comme JQuery et JQueryUI, mais il existe aujourd’hui des bibliothèques pour pratiquement tous les besoins. Je vous conseille d’ailleurs le site http://jster.net/ qui propose un catalogue assez complet de bibliothèques JavaScript.
    Il existe également des bibliothèques destinées au monde professionnel avec des licences commerciales payantes, comme le framework Kendo UI qui est l’équivalent de JQuery UI en beaucoup plus poussé.
  3. Les tests unitaires
    L’énorme avantage quand vous développez votre application en JavaScript, c’est la possibilité de tester unitairement les IHM beaucoup plus facilement, soit en utilisant des bibliothèques de tests unitaires (comme Jasmine) soit, comme nous le faisons, en développant des tests spécifiques par exemple en simulant les actions utilisateurs comme les clics de souris ou les saisies clavier.
  4. Les outils de débogage
    Il y a de nombreux outils de débogage JavaScript, les deux plus connus étant Firebug et les Chrome Dev Tools (ces derniers ayant ma préférence) intégrés à Google Chrome. On peut ainsi mettre facilement des points d’arrêts conditionnels, inspecter l’état des variables lors de l’exécution et même modifier le code JS à chaud sans avoir à recharger la page grâce à ces outils.
  5. Les outils de vérification et minification
    Quelques autres outils vraiment pratiques que nous utilisons sur le code JavaScript :

    • JSLint et JSHint : des outils qui permettent d’améliorer la qualité du code JS.
    • YUI Compressor : compresse le code JS et ajoute de l’obfuscation de code. S’intègre facilement à Maven pour être lancé automatiquement lors d’un build.
      Dans le même genre d’outil, mais en beaucoup plus poussé il y a le Google Closure Compiler.
  6. Les nouvelles possibilités offertes par l’HTML 5
    Si vous pouvez vous permettre d’oublier les vieilles versions d’IE vous aurez alors accès via JavaScript à une multitude de possibilités inédites grâce aux nouveautés introduites avec l’HTML 5. Pour n’en citer que quelques-unes :

    • Canvas. Pour faire du rendu 2D directement à l’écran. Voir par exemple la bibliothèque KinectJS pour avoir une idée de tout ce qu’on peut faire avec.
    • SVG : Cela permet, entre autres, de dessiner des graphiques, des diagrammes et autres courbes en vectoriel, et de rendre le tout interactif. La bibliothèque RaphaëlJS vous simplifiera le développement en vectoriel.
    • Local Storage. Permet de sauvegarder des informations sur le poste client de manière permanente. Pour aller plus loin avec la manipulation des données entièrement côté client, la nouvelle API IndexedDB permet d’avoir une base de données locale facilement manipulable.
    • WebGL : basé sur OpenGL ES 2.0, WebGL permet de faire de la 3D en utilisant la carte graphique. Supporté actuellement par tous les navigateurs récents sauf IE (mais a priori plus pour longtemps), WebGL est l’API de choix pour afficher des graphiques 3D temps réel ou faire des simulations 3D. Si vous avez déjà développé en utilisant OpenGL, vous serez à l’aise avec WebGL.

Avec les énormes optimisations effectuées par les navigateurs sur l’exécution du JavaScript depuis ces dernières années (la plupart compilent et optimisent le code en natif à la volée) il devient aujourd’hui possible de faire presque n’importe quel type d’application entièrement en JavaScript. Si on ajoute à cela l’impressionnant écosystème qui s’est formé autour de ce langage (bibliothèques, outils, documentations) le choix de développer un client léger en lieu et place d’un client lourd, prend désormais tout son sens.

Posted in HTML, Java, JavaScript | Tagged , | Leave a comment

Mon Devoxx France à moi

Autant le dire tout de suite, Devoxx France est un évènement pour le moins enrichissant. La soif de connaissance et l’envie de partager des participants y est palpable, et on y apprend certainement plus en deux ou trois jours qu’en de nombreuses heures de R&D personnelle. Venu de Toulouse pour l’occasion, je n’ai pas été déçu du voyage!

Une meilleure diffusion de la connaissance

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

What every Hipster should know about functionnal programming

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

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

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

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

Du JavaScript propre?

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

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

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

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

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

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

What I want in Java 9

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

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

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

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

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

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

Posted in Conferences, Devoxx France, JEE, Java | 1 Comment

Retour sur Devoxx France 2013

Le Devoxx 2013 France s’est déroulé du 27 au 29 mars 2013. Voici quelques conférences qui ont retenu mon attention, soit parce qu’elles peuvent m’aider au quotidien, soit parce qu’elles m’ont permis de découvrir des sujets que je connaissais mal comme le NoSql.

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

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

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

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

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

Blog de Tugdual Grall

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

Posted in Conferences, Devoxx France, Divers, Java | Leave a comment