QCon London 2014 – Journal de Bord – Day 1

5 Mars 2014, 08:30, banlieue de Londres :
Il est temps de se mettre en route et d’affronter le froid et la grisaille matinale pour se rendre à la conférence. Légèrement en retard, je décide qu’il vaut mieux prendre le petit déjeuner là-bas…
09:10 : finalement, pour le petit déjeuner c’est raté il ne reste plus rien. Les anglais sont matinaux et ponctuels, tant pis on va passer directement à la keynote… vite vite ça a déjà commencé!

Keynote – Life, the Universe and Everything

par Damian Conway
Damian entreprend une présentation du fameux jeu de la vie et son implémentation en Perl. Il va nous embarquer dans un voyage galactique, nous apprendre à programmer en Klingon, qui comme chacun sait est un langage fonctionnel en Reverse Polish Notation
Le KlingonScript est un langage au ton très directif (oui Damian le parle apparemment couramment). Ainsi il y a 12 manières d’écrire la commande kill.
Damian lie ensuite cela avec les lois de la thermodynamique et le démon de Maxwell, duquel il va faire une simulation en utilisant le jeu de la vie comme plate-forme. Il poussera le vice en écrivant le tout en Klingon 🙂
Conclusion : les automates cellulaires sont étonamment bons en tant que plate-forme de calcul, la vie permet de simuler de tout, en klingon.

Talk 1 – How to work as a startup when you’re not a startup

par George Richmond
George travaille pour Sky, un fournisseur de câble britannique et donc une très grosse boîte. Il nous fait un rappel des principes du Lean Management, et nous explique que bien qu’il travaille sur des parties moins visibles de l’entreprise (et moins “glamour”), la FAQ des boîtiers satellites et le call-center virtuel, il est malgré tout content. En effet, il a la chance d’avoir intégré une équipe utilisant ces principes de la Lean Startup dans leur travail quotidien.
Par exemple, il nous explique comment ils ont pu améliorer la satisfaction client et réduire les nombres d’appels à la hotline à propos des problématiques de signal satellite en
– automatisant les tests (selenium + cucumber)
– automatisant la validation de screenshot pour le rendu visuel
– testant avec des utilisateurs réels (A/B testing), par exemple le libellé d’un bouton oui/non sur la question “est-ce que cette procédure vous a permi de corriger le problème?” : +35% de clics avec un simple “non” par opposition à “non, voir l’étape suivante” car les gens voulaient savoir quelle était cette fameuse étape suivante).
Un talk intéressant sur l’aspect Lean et des retours d’expérience. Il manquait juste peut-être des informations sur comment le management a été convaincu / a proposé ce genre d’approches.

Talk 2 – Fault tolerance made easy

par Uwe Friedrichsen
Uwe souhaite nous présenter des cas d’études et des patterns pour facilement apporter de la tolérance à la panne dans notre système.
Ce qui importe, c’est la production. Pour cela il nous faut de la disponibilité, et donc de la tolérance à la panne.
Le premier exemple qu’il prendra est celui du serveur web qui ne répond plus. En investigant on s’aperçoit que le serveur d’application est bloqué, et en descendant d’un niveau que la base est lockée parce qu’un batch est tombé en erreur pendant la nuit.
Les patterns qu’il propose pour ce genre de cas sont assez simples : timeouts, coupe-circuit, fail fast (avec une vérification par exemple de l’état de plusieurs coupe-circuits avant de consommer des services de manière coûteuse).
La deuxième étude de cas qu’il propose est le site victive de son succès, ralenti fortement lorsque l’on veut l’utiliser, et qui fini par planter au pire moment (timetout de session par exemple, au moment de valider l’achat d’un panier qu’on a eu bien du mal à constituer).
Les 2 derniers patterns associés à cette étude sont jeter la charge excessive et le deferrable work : si on s’apprête à surcharger un serveur avec la combinaison de la charge utilisateur et des traitements en tâche de fond, peut-être n’exécuter que la partie du batch qui permettra de rester sous une limite convenable et bloquer le reste de celui-ci (tout en exécutant à chaque cycle de réestimation de la charge au moins un minimum de travail pour éviter un blocage total).

Talk 3 – Is it a car? Is it a computer? No! It’s a raspberry-pi java carputer!

par Simon Ritter
Simon nous présente un projet plus personnel et matériel, assemblé autour du Raspberry Pi, d’un accéléromètre, d’un écran tactile et de la plate-forme JavaFX.
Il nous présente succintement les protocoles électroniques de communication en bus présents sur les voitures modernes, et comment on peut extraire de ceux-ci des informations pertinentes pour un conducteur souhaitant mieux connaître son véhicule et améliorer sa conduite.
L’interface est volontairement simplifiée au maximum, et tire parti des capacités d’affichage de graphes de JavaFX ainsi que sa gestion du multitouch pour s’adapter à une utilisant en cours de conduite.
Il termine par une vidéo de démonstration, ainsi qu’une démonstration “live”, malheureusement peu visibles depuis le fond de la salle.

Repas

C’est l’heure d’une pause un peu plus conséquente, afin de manger. L’organisation est vraiment sympathique à cette QCon et le lieu gigantesque.
Une salle pour le service du repas est prévue à 5 des 6 étages du centre de conférence, avec des codes couleurs sur les badges pour mieux répartir les convives. Au menu pour moi, curry de poulet et lentilles, plutôt pas mal comme buffet chaud!

Talk 4 – Blooming marvelous! Why probably is sometimes better than definitely

On réattaque fort, car dans cette présentation, on nous parle de filtres de bloom, de hashing et des applications de ceux-ci dans des cas concrets.
Cette structure probabiliste permet de gagner en efficacité au niveau mémoire et performance par rapport au bon vieux HashSet pour répondre à la question de l’appartenance ensembliste. Cependant, on perd en précision puisque la structure peut induire des faux positifs (mais jamais de faux négatifs, si elle répond que X n’est pas dans l’ensemble, il n’y est à 100% pas).
L’exemple fil rouge est celui d’un système de surveillance du traffic dans le quartier de Westminster, permettant de savoir si une caméra du secteur a vu passer la plaque d’immatriculation N au cours des dernières 24h.
Des applications sur le terrain du Bloom Filter se retrouvent dans beaucoup de bases de données, dont Cassandra et HBase, dans des systèmes de join de tables moins coûteux, dans la détection de boucles en routage réseau, ainsi que la détection d’URL malicieuses dans Chrome…
Une bonne partie du talk détaillera les probabilités so
us-jacentes et les leviers pour faire du tuning et choisir le bon compromis taille/% de faux positifs.

Talk 5 – Almost everything you “know” about regular expressions is wrong

par damian conway
Damian nous acceuille à nouveau en Klingon : “Bonjour à tous!” (enfin ça se traduit plus litéralement en “Que voulez-vous, humains?!”).
Les expressions ne sont pas si compliquées que ça, mais il faut les voir comme un langage de programmation, code et sous-routines, et comprendre leur modèle d’exécution.
Damian nous décris alors les 6 familles de langage d’expression régulières, comment elles sont exécutées sur leur propre machine virtuelle (en théorie une machine à états finis), et commence à décortiquer une expression simple.
Sa méthode est assez parlante, puisqu’il déroule d’abord des graphes servant à l’analyse et fait ensuite la comparaison avec du code java “équivalent”.
Il met en avant que les expressions régulières vont par nature avoir tendance à trouver le match le plus court et venant en 1er dans la chaîne.
Il soulève ensuite que le principal problème des expressions régulières c’est que les espaces sont des commandes. On ne peut donc pas “aérer” le code comme on le ferait dans d’autres langages de programmation. Astuce : dans les dérivés de la famille PCRE, le flag (?x) permet de passer en mode étendu et de considérer les espaces et commentaires comme non-significatifs.
Damian termine par expliquer les boucl
es en regex, qui combinent en quelque sorte le for (boucle itérative) et le while (boucle conditionnelle). L’autre différence majeure avec ce à quoi on a l’habitude, c’est que dans les regex lors d’une itération, soit on match et on termine, soit on n’arrive pas à matcher et on reviens en arrière, on rembobine la boucle et on repart un caractère plus loin dans la chaîne analysée.
Damian est un speaker très intéressant, drôle et dynamique. Sans conteste la meilleure intervention de la journée.

Talk 6 – Impossible Programs

par tom stuart
Tom va nous convaincre, avec des exemples en ruby, que les programmes ne peuvent pas tout faire. Il existe une famille de systèmes dits “universels”, qui peuvent toujours simuler un autre système universel (en écrivant un interpréteur pour un autre langage par exemple), y compris eux-même.
Il ajoute ensuite que les programmes sont de la donnée, et qu’il peuvent donc servir de donnée d’entrée à d’autres programmes… Et encore une fois à eux-même.
Cela conduit à l’existence des boucles infinies, qui sont la seule “solution” aux paradoxes logiques introduits par cette capacité de s’utiliser comme donnée d’entrée.
Tom nous parle ensuite du “halting problem”, est-il possible d’écrire un programme qui décide si un autre programme contient ou non des boucles infinies. Ce problème reste non résolu depuis 250 ans.
On peut y voir comme conséquence qu’il est par exemple impossible d’écrire des tests automatiques, le théorème de Rice dit que “toute propriété intéressante du comportement d’un programme est indécidable”.
Comment pouvons-nous nous en sortir?
– timeouts (mais conduit à des approximations, des faux positifs)
– poser plusieurs questions plus petites mais décidables, et qui apportent des éléments de réponse/preuve à la plus grande question (tests unitaires)
– poser des questions décidables en étant conservatif (conservative) : par exemple un compilateur qui cherche du code non-atteignable va considérer que le code est atteignable et donc gardé si il n’arrive pas à décider.
– convertir vers des approximations plus simples bien qu’approximatives et poser des questions à propos du programme plus simple (exemple : systèmes de typage).

Fin du jour 1

Et voilà, la première journée est terminée. Une expérience très intéressante, avec une organisation impressionnante et efficace et un très bon niveau général des interventions.