Il y a un poil plus de monde pour cette seconde journée, certain participants ayant pris un passe pour mercredi et jeudi.

Cette seconde journée commence par une keynote de Ken Schwaber, inventeur, avec Jeff Sutherland de la méthode Scrum, puis enchaine sur les sessions, avant de finir sur les « Jazoon Rookies ». Les Jazoon rookies sont un format de conférences spécifique à Jazoon, où des intervenants qui ne sont pas encore des stars de la scène (Java) internationale, peuvent faire leurs premiers pas dans une conférence à caractère international.

Keynote d’ouverture de la seconde journée : Total Cost of Ownership, Ken Schwaber

A part la présentation de ce que présente scrum.org en terme de formation, certification, Ken Schwaber explique un principe et énonce une idée forte.

Scrum est très léger et est un « framework », au sens où il pratique le principe de Hollywood. En particulier, lors des itérations, il faut donner un sens à « done ». Il nous demande de nous interroger entre participants voisins (ce qui n’est pas évident quand ses voisins parlent uniquement allemand), pour savoir ce que l’on entend par « done », dans le cadre d’une itération de développement (sprint).

Puis il demande si les réponses que l’on a reçu comprennent :

• Les benchs de performances
• Les tests de robustesse (stabilité)
• Les tests de réponse immunologique (si vous savez ce que c’est, merci de mettre un commentaire)
• La vérification de la bonne intégration avec les six autres équipes (en supposant qu’il y ait six autres équipes)
• Tests d’intégration avec les incréments des six autres équipes, pour valider un incrément global
• Mise à jour des releases notes
• Internationalisation du produit dans les six locales des utilisateurs du produit
• Tests d’acceptance utilisateur
• Tests anti-regression
• Revue de code

La « stabilisation » est ce qu’il faut faire après les itérations pour avoir un produit fini. Si notre définition de « done » n’est pas rigoureusement définie, la stabilisation augmente après chaque itération de manière exponentielle (ou peu s’en faut).

Session technique : Unleash your processor(s), Vaclav Pech, JetBrains

Cette session très technique intéresse beaucoup de monde. La salle dans laquelle elle a lieu, qui n’est pas la grande salle, suffit à peine pour tous les participants.

Vaclav Pech est employé par JetBrains, mais est impliqué, ainsi que Dierk König (cf plus loin) dans l’équipe de développement de GPars, une librairie Groovy qui propose des abstractions de haut niveau pour programmer de manière parallèle en utilisant les patterns les plus modernes.

Vaclav commence par dire qu’il va nous faire peur. Je pensais qu’il allait nous sortir des horreurs comme on en rencontre que en programmation concurrente. Il nous a juste montré qu’avec un code très simple invoquant beaucoup de calculs, en ayant un quadri-processeur, double coeurs, notre programme n’utilise qu’un huitième de la ressource CPU disponible.

Selon lui, la plupart des programmes utilisant plusieurs coeurs le font par hasard.

Peut-on faire mieux ?

Il existe des patterns de conception modernes permettant de programmer du code essentiellement métier, en profitant du parallélisme.

Il y a une distinction entre parallélisme et concurrence :

• On parle de parallélisme quand il y a deux exécutions simultanées : il faut au moins deux processeurs, ou un processeur multi-coeur;
• On parle de concurrence quand il y a parallélisme ou émulation : pour le programmeur client, les problématiques sont semblables.

Patterns de concurrence

• Map/Filter/Reduce
• Fork/Join
• Actors
• Software Transactional Memory (STM)
• Invocations asynchrones

Les invocations asynchrones se font en utilisant, en Java, les Parallel*Array définis dans la spécification JSR166y. Comment ? Vous ne connaissez pas et ce n’est pas dans votre JDK ? En réalité c’est une API qui n’a pas été inclue dans le JDK 6, et donc a été sortie de la JSR166, pour être incluse dans le JDK7 avec JSR166y.
Le principe des ces invocations asynchrones est qu’elles sont bloquantes de manière lazy, c’est-à-dire qu’on manipule des références vers le résultats d’un calcul, mais tant qu’on utilise pas le résultat du calcul, on n’est pas bloqué (au sens verrou).

Les STM (Software transactional memory) sont à la manipulation d’objets en mémoire ce que la transaction JTA est à l’INSERT SQL (raccourcis opportun pour faire comme si j’avais vraiment compris). Il faut faire très attention quand on fait des choses transactionnelles dans un contexte de concurrence (et donc encore plus dans un contexte de parallélisme, si vous avez suivis). Par ailleurs, il n’y a rien de magique, l’usage des transactions, quelqu’en soient les objets pénalisent fortement les performances (création de logs, utilisation de verrous et synchronisation, scheduling …).

Je n’entrerais pas plus dans le détail, dans ce billet, pour vérifier la validité de mes notes, mais j’ai appris en vrac que :

• il existe des inter-blocages sympathiques (enfin, plus sympathiques que d’autres: ceux qui se reproduisent de manière déterministe) !
• les acteurs, n’ont pas leur propres threads, ils interagissent avec le provider de thread (pool ou plus complexe)
• la communication entre acteurs se fait par des messages immutables

Le présentateur a pris le soin de préciser que la session s’adressait à des développeurs Java, que la session de l’après-midi sur GPars serait plus focalisée sur Groovy, mais que les exemples de code serait en Groovy, en Scala ou en Clojure, parce que les exemples en Java ne tiennent pas sur un slide !!!

Indépendamment des futurs API disponibles dans Java7, il existe des frameworks pour disposer de telles API. Par exemple, Akka, très utilisé en Scala, est également utilisable en Java.

Session technique : Harnessing the Power of HTML 5 WebSocket to Create Scalable Real-Time Applications, Peter Lubbers, Kaazing

Le présentateur a fait parti du groupe d’experts qui ont établis la spécification des WebSockets au sein du W3C. Il est employé par la société Kaazing qui propose des solutions clients/serveurs pour utiliser les WebSockets.

Peter Lubbers commence par rappeler certains principes de HTTP, pour présenter pourquoi, pour certains usages, HTTP n’est pas adapté et les WebSockets permettent de résoudre un pain-point :

• HTTP a été conçu initialement pour transférer des documents (pas des données, pas des applications);
• HTTP est « half-duplex », c’est-à-dire que le flux de données est monodirectionnel à un moment donné;
• C’est compliqué de faire du temps réel, pour différentes raisons et limitations.

Quand on a pas de WebSockets, on utilise les techniques AJAX et Comet pour palier à ces limitation. Mais

• Cela ne résoud pas réellement la problématique du temps réel;
• Pour simuler du temps réel, on utilise souvent des techniques de polling ou de long-polling (COMET ou reverse AJAX, c’est-à-dire qu’on fait un ping régulièrement en AJAX)
• COMET est un hack (une requête reçue devrait avoir une réponse de manière synchrone), qui manque donc de spécifications et de standards.

Il résume « Use COMET to spell COMplExiTy », parce qu’il n’y a pas de socket nativement.

A propos de la technique du polling, qui consiste à pinger régulièrement le serveur, il parle de « temps réel approximatif », ce n’est qu’une simulation, et que trop de connections sont établies.

La technique du long polling consiste faire en sorte que le client envoie une requête HTTP, que le serveur réponde partiellement, sans fermer la réponse. Eventuellement, de temps à autre, il y a fermeture de la réponse puis émission d’une nouvelle requête, de manière à supporter les proxies qui ferment automatiquement les réponses au bout d’un certain time out. Cela fonctionne, mais il y a un overhead inutile de données dans les en-têtes de requête et de réponse, de plus c’est un hack (d’après la spécification, une requête HTTP attend une réponse synchrone).

Le streaming est encore plus efficace, mais parfois problématique. Il peut y avoir des complications avec les proxies et les firewalls. Les réponses doivent être flushées périodiquement. Il y a des problématiques de limitations dues au nombre de connexions maximale que le navigateur autorise pour un même domaine (et la navigation par onglets).

Il peut y avoir avec ces techniques, des overhead allant jusqu’à 2 kilo octets par requête HTTP.

Si on imagine comme cas d’utilisation 1000 clients (application de chat ou de jeu en ligne) qui ping toute les secondes (Polling), il y a une sur-utilisation d’un méga par seconde.

Kaazing a implémenté un serveur TCP pour la compatibilité avec les WebSockets HTML5. L’API des WebSocket fait partie de HTML5, spécifié par le W3C et le protocole WebSocket est spécifié par l’IETF.

• Ce sont des sockets plein texte, full-duplex
• Elles permettent une communication avec un host distant.
• Elles traversent les firewalls, proxies et routeurs de manière (à peu près) transparentes.
• Elles utilisent un port HTTP.

Il y a deux schémas de protocoles pour les WebSockets, à savoir ws et wss, le second pour la version sur TLS (WebSocket Secure). Il y a un handshake établi en HTTP. Pour établir une connexion WebSocket, le navigateur envoie une requête HTTP, avec un en-tête « Upgrade: WebSocket ».

Exemple:

Une fois l’upgrade obtenu, il peut y avoir des communications dans les deux sens. Le modèle programmatique, à ce moment devient celui des sockets asynchrones.

Dans les browser le supportant, on a une API Javascript, pour manipuler ces WebSockets:

Evidemment, cet exemple n’a aucun sens, on n’ouvre pas une socket pour envoyer un unique message et fermer la connexion quand on peut envoyer des requêtes HTTP.

Les navigateurs actuels supportant les WebSockets sont les suivants :

• Chrome 4.0+
• WebKit nightly builds
• Planned for Opera and Firefox

Il semblerait que ce ne soit pas dans la prochaine version de IE (parce qu’ils ne l’ont pas annoncé)

L’inspecteur natif de Chrome permet une inspection des WebSockets.

Un certain nombre de librairies permettent d’établir une dégradation gracieuse (gracefull degradation), par une émulation des WebSockets (entre autre la ‘classe’ Javascript WebSocket est créée) :

• Kaazing Websocjet gateway;
• Flash WebSocket Emulation: web-socket-js sur github

Parmi les usages envisageables on a:

• XMPP, Jabber;
• Stomp, AMQP;
• Protocole de jeux spécifiques (voire propriétaires);
• Binaires;
• Tout protocole au dessus de TCP;
• LE navigateur devient un citoyen de première classe au niveau des protocoles de communication.

Parmi les exemples en production, on a :

• des applications financière temps réel;
• un portage par Google de Quake II.

Les WebSockets peuvent ne pas bien passer les répartiteurs de charges, proxies et firewalls de niveau 7 (HTTP, applicatifs). Par contre, la version sur TLS passe sans problème. Il est donc possible d’utiliser wss pour être sûr de passer en environnement inconnu (cela ne me semble pas satisfaisant intellectuellement).

Il finit en donnant un exemple de site réel de poker en ligne, dont la réactivité est déjà satisfaisante, puis montre la version de Kaazing, (« Kaasino » ha! ha! ha!), dont la réactivité est effectivement impressionnante.

Session technique : GPars : Parallel programming concepts for the jvm in Groovy, Dierk Koenig

L’objectif de cette session est de présenter GPars, une API Groovy permettant d’utiliser la plupart des patterns dont il était question dans la première session.

Il a fait une démonstration pour les concepts suivants : Fork/Join, Map/Filter/Reduce, Dataflow et a montré le code sur des slides pour les Agents et les Actors.

En fonction de l’API utilisée, la coordination est :

• Pour le Fork/Join et le Map/Filter/Reduce: predefinie;
• Pour les Dataflow: implicite;
• pour les Agents: déléguée;
• Pour les Actors: explicite.

Les nouvelles API essaient de faire en sorte que la coordination ne puisse être erronée.

Le principe avec les Data Flow est que si ça marche en developpement (ou en test), ça marche en production (coordination implicite).

Il y a également une API pour les CSP (Communication Sequence Processing) et il devrait prochainement en avoir une pour les STM (Software Transaction in Memory).

Avec l’approche Map/Filter/Reduce, on a plus de contrôle sur l’ordonnancement qu’avec le Fork/Join.

Les Agents sont une façon de proteger les objets (pour assurer une contrainte de manière concurrente). Souvent une variable d’une instance d’un agent est appelée « guard ».

Le présentateur conclus que :

• GPars rend la programmation concurrente simple;
• Il faut apprendre les concepts;
• Groovy et Java sont prêts pour les nouveaux défis (multicoeurs, …)

Session technique : Cloud Computing with Scala and GridGain, Nikita Ivanov, GridGain

Avec la session suivante, on passe de Groovy à Scala. Le présentateur montre l’usage d’une API développée en Scala pour non seulement rédiger du code qui sera déployé sur le Cloud, mais également pour configurer les instances des noeuds de son cloud et pour déployer automatiquement son code sur les différents noeuds, pour faire du grid computing.

Le présentateur explique qu’ils ont choisit de faire l’API en Scala pour les raisons suivantes:

• Langage scalable
• Post-fonctionnel
• Performances équivalentes à Java
• Statiquement typé
• Pleinement compatible avec Java

Gridgain a étudié une série de language avant de choisir Scala. L’avantage le plus important de Scala à leurs yeux est que l’on peut ajouter des mots-clés TOUT EN RESTANT statiquement typé.

Il a dit plus ou moins que Martin Odersky avait créé Scala parce qu’on lui avait dit que ce ne serait pas possible de le faire.

Il a introduit également Scalar, un DSL de cloud computing Scala basé sur Gridgain.

A suivit une séance de codage en direct, dans lequel il créé une application de grid computing en quelques minutes, sans copier-coller, sans code pré-compilé ou pré-buildé, sans configuration spécifique. Dans un premier temps, il a utilisé juste GridGain, puis avec Scalar il a fait la même chose avec un mot clé additionnel qui simplifie encore la syntaxe (en gros une ligne de code en moins de 80 colonnes suffit pour une application de grid computing).

Session technique : How Java Powers Large Online Retail Sites, Robert Brazile ATG

Cette session n’était pas vraiment technique, au sens le plus strict. ATG est un des fournisseurs de solution de e-commerce les plus importants au monde. Ce sont également des early adopter de Java. En 1996, ils utilisaient le serveur d’application Dynamo (rien à voir avec la solution de persistance NoSQL d’Amazon).

La sessions concernait essentiellement les problématiques auxquelles ils ont été confrontés, des retours d’expérience, des chiffres que je n’ai pu noter de manière complète, donc je préfère ne pas énumérer. Je vais uniquement énumérer les tendances business et technologiques qu’ils suivent :
Business:

• Mobile
• Remarque: dans les pays émergents, le mobile est le seul vecteur de e-commerce
• Social networks
• Convergence of these and other channels
• Growing use in the developing world
• ease of use in the business user
• spawning of many smaller sites rather that changing big one

Technologiques:

• Virtualization/Cloud computing
• NoSQL
• Scripting (PHP, Ruby, Groovy, Scala, Clojure, Erlang, …)
• Framework (Rails, Grails, Lift, …)
• Multi-core, more concurency, STM

Jazoon Rookies

Il s’agissait de trois conférences réalisées par des conférenciers débutants, auxquels l’opportunité de faire une présentation auprès d’un auditoire international était offert.

La première conférence était une présentation de l’API OpenSocial. Le sujet est très à la mode, mais je ne suis pas sûr que cela valait le coup de faire une conférence. C’est un standard. On prend les spécifications et on sait implémenter.

La seconde portait sur la problématique du facteur humain et sa prise en compte dans les réalisations logicielles d’un point de vue sécurité. La forme de la conférence était originale, avec une sorte d’histoire qui mettait en parallèle des chevaliers … avec … j’ai oublié. Impossible de prendre des notes. La présentation était bien mise en scène, mais en tant qu’auditeur, on perd le fil. Même si j’ai compris le message final, j’ai perdu le cheminement de la présentation.

La troisième conférence voulait démontrer l’intérêt de l’outil Eclipse Memory Analyzer récemment disponible avec Eclipse. La présentation était essentiellement deux démo. Prévoir une démo dans une présentation est risqué. Quand c’est la première présentation, c’est vraiment courageux. De surcroit, l’infrastructure était défaillante (exceptionnel depuis deux jours à Jazoon – sauf pour le WIFI hier. Tiens, je vous ai dit qu’aujourd’hui c’était bon ?). Bref, il s’est débrouillé comme un chef, sauf qu’il a manqué quelques explications préalables à sa démo pour nous indiquer l’intérêt de sa deuxième démo. (en gros Eclipse Memory Analyzer analyze les fichiers dump.hprof et propose une vue qui permet assez facilement de déterminer les memory leaks et dans la seconde démo, il le faisait à distance sur un serveur de production, mais sous des hypothèses que je n’ai pas comprises).

Conclusion

Cette journée était beaucoup technique et intéressante (subjectivement) qu’hier, mais je commence à saturer. Je comprend certain compatriotes qui ont pris le chemin du retour ce soir. A demain pour de nouvelles aventures !

Si vous avez des commentaires, rendez-vous sur le forum