J'ai eu la chance de participer à la formation "Réussir ses présentation PPT" à Octo. N'ayant jamais touché à PowerPoint et étant sous Linux, j'ai un peu galéré à installer une version de Windows Trial, et une version Office Trial pour pouvoir avoir PowerPoint le jour J.
Il s'est avéré que la formation portait plus sur les présentation en règle générale, sur les messages à faire passer et comment les passer que sur l'outil en lui-même.
La formation était orientée sur la création de présentations dans un contexte professionnel, à destination de nos clients finaux. Dans cette optique, on considère que l'on utilise le même support pour la présentation, en personne, devant eux, que celui qu'on leur enverra par mail et qu'ils pourront relire ensuite.
Partant de là, il est important de proposer deux niveaux de lecture. Chaque slide doit porter un message, et on peut suivre la suite des messages, et donc le message global rien qu'en lisant les titres de chaque slide. Ensuite, si on veut avoir plus de détail, on peut aller le chercher dans la slide en question, et si vraiment on veut creuser très profondément, on peut rajouter des annexes qui explicitent certains points.
Les slides doivent être auto-portants, notre présence ne doit pas être requise pour comprendre le gros du message. Notre auditoire possède une capacité de concentration limitée, il faut donc lui faciliter la lecture et la compréhension de chacun des messages. Si un message est trop complexe, on le découpe en deux slides.
Même si l'auditeur décroche quelques secondes, pour cause d'un moment d'inatention, il faut que la slide puisse lui rappeller en un coup d'œil où on en est dans le déroulé. Ce n'est pas grave si notre auditoire décroche par moment, c'est normal. Mais il faut lui laisser la possibilité de suivre la présentation à son rythme et de pouvoir décrocher et raccrocher quand il le souhaite.
Dans la même optique, il ne faut pas jouer sur le suspens, en annoncant petit à petit notre message, et en présentant la conclusion seulement à la fin. Il faut être direct, et présenter la solution dès le début. Ca s'applique tout aussi bien dans la présentation dans son ensemble que pour chaque slide prise séparement. On présent dès le début la conclusion de notre étude, ce que l'on pense qu'il faille faire, etc. Et ensuite, le reste de la présentation permet de démontrer, de prouver, de corroborer ce que l'on a annoncé dès le début. Il ne faut pas que l'auditeur ai à attendre la fin pour comprendre le message, sinon il va décrocher.
C'est pour cela qu'il faut porter grande attention aux titres, et faire en sorte qu'ils ne soient pas creux. Il faut oublier les titres de genre "Contexte", "Constat", "Nos préconisations". Il faut que chaque texte transmette une prise de position, une description. Par exemple "Un contexte difficile", "Un constat en demie-teinte", "Former les développeurs pour plus de flexibilité".
On a aussi vu, par la pratique, à quel point notre cerveau humain percoit les formes et les images beaucoup plus rapidement que le texte. Il faut donc faire attention aux éléments que l'on utilise pour illustrer nos propos, faire attention qu'ils ne phagocytent pas le message que l'on souhaite faire passer. Une image ne doit être incorporée que si elle ajoute réellement de la valeur, de l'illustration au message à passer. Une image qui donne un exemple est très parlante, notre cerveau s'en rappellera bien, mais une image "pour faire joli", va trop attirer le regard et le détourner du propos initial.
On n'est pas là pour raconter une histoire, pour parler de soi ou pour divertir. On est là pour démontrer une thèse, pour montrer ce que l'on pense, et le démontrer ensuite. Notre message doit être clairement explicité, avec une slide par idée. On montre dès le début la conclusion, et on explicite seulement ensuite. On évite les titres creux, il faut qu'ils transpirent une conviction, une croyance. Les phrases doivent être simples, deux virgules maximum. Si la phrase est trop longue, alors l'idée est trop complexe. Pour rester factuel et uniforme essaie de garder tous les verbes à l'infinitif, sans les conjuguer. Au pire, on mets au présent. On évite les verbes trop génériques (faire, dire, être, avoir), on remplace par de synonymes plus précis. Et on ne doit pas avoir peur du blanc, du vide, il ne faut pas chercher à remplir la slide à tout prix. Par contre, ce que l'on mets doit être aéré, aligné, et cohérent.
Si on doit faire une liste, on fait attention à la cohérence (liste de noms, de verbes, etc), et on mets en avant (en gras par exemple), les idées principales de chaque ligne. Si on a choisi le gras pour la mise en avant, on s'y tient, on n'utilise pas de la couleur ou de l'italique sur une autre slide. Dans la même idée, on limite le nombre de couleurs utilisées à 3, ou 4 au grand maximum. Une seule police maximum.
Une fois sa slide terminée, on vérifie sa checklist pour être sûr de n'avoir rien oublié : - Deux niveaux de lecture. L'idée principale dans le titre, plus de détail dans la slide. Je dois pouvoir suivre le plan général juste avec les titres. - Qu'est-ce que je veux dire ? Quel est mon message ? Quels sont les élements chocs, convaincants ? - Est-ce que je suis obligé de dire tout ça ? Est-ce que je peux en enlever ? Ou au contraire, est-ce que je n'ai pas oublié un élément primordial ? - D'abord la conclusion, ensuite la démonstration. - Est-ce que mes données, mes sources, mes graphes sont bien à jour ? Attention aux copié-collé d'anciennes présentations dépassées. - Est-ce que mes visuels servent vraiment mon propos. C'est eux qu'on va voir en premier, est-ce que c'est vraiment ça que je veux ou est-ce que c'est superflu ?
Enfin, si vous ne savez pas comment faire le plan général de votre présentation, il y a plusieurs idées assez classiques : - FSVOM: Les Faits, ce que l'on Sent, ce que l'on Veut, les Obstacles et les Moyens - Diagnostic : Le problème, la possible solution, les conséquences et la décision finale. - SOSRA: Situation, Observation, Sentiment, Réflexion, Action - PPL : Principes, Portée, Limites
Et finalement un dernier conseil. Si après tout ces conseils vous avez bien taillé dans le lard de votre présentation et enlevé tout le superflu pour ne garder que l'essentiel et que votre message est bien clair, mais que malgré tout tout semble aussi important et capital, il faut encore prioriser. Si tout est important, en fait rien n'est important. Il va falloir prioriser, et prendre une décision, une conviction qu'on doit pouvoir démontrer dans la présentation.
Mardi dernier avait lieu les HumanTalks. Cette fois-ci c'était dans les locaux de So@t, et c'était sur le thème des jeux vidéos.
Au menu, on a eu 5 présentations :
Board Game Arena, un site communautaire pour jouer à des jeux de plateau en temps réel, et explication de la stack technique derrière (Jetty, Apache, PHP, long-polling)
Overview de ce qu'est la gamification, et comment ça marche.
Présentation de Gosu, une librairie Ruby pour faire des jeux vidéos en 2D très facilement.
Les Agile Games, et en quoi jouer stimule des parties spéciales du cerveau et peut aider à l'innovation, le cohésion de groupe et l'empathie.
Et finalement, retour d'expérience d'un game designer de chez Quantic Dream, et comment se passe les cycles de développement d'un AAA vu de l'intérieur.
BoardGameArena
Gregory Isabelli (@boardgamearena), nous parle de Board Game Arena, un site où il est possible de jouer en temps réel avec d'autres joueurs à des jeux de plateaux.
Le tout est (bizarrement) codé en PHP, avec un Apache devant, et des connections avec le serveur en long-polling. Derrière ces choix étranges, il faut savoir que le site a déjà près de 6 ans d'existence si je me souviens bien, et que c'était pas un si mauvais choix de stack à l'époque.
Le paradigme classique du web (le client initialise une requete, le serveur l'attrape et réponds) n'est pas possible pour faire du temps réel, vu qu'il faut que le serveur puisse notifier ses clients quand une nouvelle action se passe (classiquement, quand un autre joueur à fini son tour).
Il utilisent donc un serveur jetty devant leur apache pour gérer le long-polling. Pour ceux qui ne sont pas familiers avec la technique, le long-polling consiste à ce que le serveur prenne le plus de temps possible pour répondre (mais sans timeout). Le client envoie une requete, et si le serveur n'a rien à répondre, il maintient la requete ouverte. Si jamais il est notifié d'un event en interne, il ferme la requete en envoyant le résultat de cet event, et le client renvoie aussitot une nouvelle requete. Si jamais il n'y a pas eu d'event, le serveur renvoie quand même une réponse pour éviter le timeout, et le client relance une requete.
Comment ça se passe par derrière en PHP ? Et bien, quand un joueur A envoie ses ordres, le serveur s'occupe de calculer le nouvel état du plateau de jeu. Il notifie ensuite le serveur jetty avec le nouvel état, et celui-ci ferme toutes les requetes ouvertes de tous les joueurs avec ces nouvelles informations (qui en ouvrent à nouveau de nouvelles automatiquement).
Sur boardgamearena, ils ont en moyenne 1000 joueurs connectés tous les soirs, et leur unique serveur jetty tient tout à fait la charge. Néanmoins, ils savent que s'ils doivent scaler pour accueillir plus de joueurs, il leur suffit de rajouter de nouveaux serveurs jetty (environ 1 pour 20.000 joueurs) et de modifier le PHP pour qu'il notifie plusieurs jetty à la place d'un seul.
Étant moi-même grand joueur de jeux de plateaux, j'ai beaucoup aimé ce site, que je ne connaissais pas. Ils proposent aussi un mode "studio", dispo directement dans le navigateur pour coder ses propres jeux.
La Gamification, qu'est-ce que c'est ?
David Grezinger, développeur chez Xebia, qui nous avait déjà fait une présentation sur les MOOCS à un précédent HumanTalks, nous a cette fois parlé de la Gamification (sujet qu'il a appris grâce à Coursera).
Il nous a d'abord parlé du but de la gamification, qui peut être d'attirer des utilisateurs sur une plateforme, ou de favoriser le travail en équipe. Pour cela on utilise une mécanique de points, de badges, de barres de progressions, qui peut être plus ou moins subtile. Foursquare est un exemple de Gamification assumée et très flagrante, idem pour les badges sur CodeSchool. Les barres de progression quand on rempli son profil sur LinkedIn par exemple en est un autre exemple. StackOverflow finalement est un exemple un peu plus subtil.
Mais il ne suffit pas de rajouter des points ou de badges pour avoir une gamification réussie. Le but est de réussir à recréer des mécanismes qui nous paraissent ludiques, amusants, et qui incitent, sans qu'on le remarque, à faire des tâches qui nous auraient sinon semblées rébarbatives. Il existe des applications de fitness qui poussent la gamification très loin, en simulant un mode envahi de zombis, en faisant appel à un savant mélange de carte google maps et à l'imagination de l'utilisateur pour le forcer à courir d'un point à l'autre de sa ville pour "éviter les zombis".
Il a fini par faire un parallele avec World of Warcraft, où pour réussir à battre l'un des boss les plus difficiles du jeu, il fallait à une époque réussir à regrouper une équipe de 40 joueurs différents, avec des classe de personnages (et donc des roles) complétement différents. Réussir à la coordonner, plusieurs fois par semaine, pendant des mois, échec après échec, pour finalement réussir à battre ce satané Ragnaros. Essayez donc de faire la même chose en entreprise, coordonner 40 personnes, à distance, avec des compétences et des égos complétement différents, pour atteindre un but commun, échec après échec.
Ceci n'est qu'un résumé de son talk qui était lui-même un résumé du cours de Kevin Werbach sur Coursera, donc si vous voulez creuser le sujet, je vous invite à aller directement à la source.
Faire des jeux en Ruby avec Gosu
Matthieu Segret, co-fondateur des HumanCoders nous a fait une présentation sur Ruby, et plus particulièrement Gosu. Gosu en Ruby est simplement une interface qui se bind sur une library en C qui permet de créer facilement des jeux 2D.
C'est cross-platform, ça permet de générer une fenetre dans l'OS, avec un background, des sprites, et une boucle de jeu qui écoute les événements clavier.
Lors de ses formations d'initiation à Ruby, c'est cette library qu'il utilise pour apprendre Ruby a des débutants, parce que le feedback visuel est instantané et le code est facile à lire et à écrire.
Je ne vais pas trop m'étendre dessus, vu qu'il l'avait déjà présenté à un parisRB, il vous suffira de retrouver le compte-rendu initial.
Agile Games
Talk présenté par un formateur agile de So@t dont j'ai malheureusement oublié le nom. Il nous a parlé du jeu comme mécanisme d'amélioration, d'innovation et d'estimation.
Jouer permet de manipuler des concepts de manière plus forte que de simplement les lire ou les écouter, cela permet de se les approprier avec plus de force, d'en devenir utilisateur et non plus seulement spectateur. Cela permet aussi de créer des liens entre des personnes, une synergie, une empathie qui n'est pas forcément créée naturellement dans un contexte d'équipe traditionnel.
Selon lui, on retient plus facilement une leçon quand elle est liée à une émotion forte, et comme il ne peut pas taper sur ses élèves, il préfère les rendre contents, par le jeu.
D'un point de vue purement neurologique, ce ne sont pas les mêmes zones du cerveau qui sont sollicités quand on réfléchit à un problème que quand on manipule physiquement des objets. On peut ainsi faire sortir des idées qui ne seraient pas venues si on s'était simplement limité à réfléchir au sujet. C'est simplement humain.
Il a ensuite donné plusieurs exemples de jeux agile qu'il utilise. La product box, qui consiste à essayer de construire la "boite" de notre produit si celui-ci pouvait simplement être vendu en supermarché et que l'acheter suffisait à résoudre les problèmes qu'il est censé résoudre. On réfléchit donc à mettre en avant ce à quoi le produit doit servir. Le cadrer dans un exemple concret auquel on est habitué, peut permettre de plus facilement s'approprier l'exercice. Cela permet aussi de discuter sur ce qu'il est nécessaire de mettre en avant sur le produit, et de potentiellement voire les différences de perception entre les personnes sur ce qui est important. La place sur la boite étant limitée, on doit se concentrer sur le plus important.
Il a ensuite présenté des estimation games. Partant du principe que c'est aux développeur d'estimer eux-même la durée de leur charge de travail et non pas à leur boss, que l'intelligence collective permettrait un meilleur chiffrage que l'estimation individuelle. Il nous a donc présenté le planning poker, rajoutant que l'esprit humain est facilement capable de faire des comparaison (machin est plus grand que bidule) que de donner des chiffres exacts (machin mesure 1m82). La suite de Fibonnacci est donc parfaitement adaptée pour ça.
Il a ensuite donné l'url du site tastycupcakes.com pour trouver des idées de jeux agiles, et a annoncé qu'ils avaient développés en interne à So@t un Kaizen Game, permettant d'aider l'amélioration continue, et qu'ils le présenteraient à un meetup prochainement.
Bonnes idées, même si je pense qu'on utilise un peu les mêmes techniques à Octo, je n'en ai jamais utilisé personnellement, et j'ai aimé avoir des arguments (neurologiques) sur en quoi c'est intéressant, et que ce n'est pas simplement parce que c'est plus fun.
La création d'un AAA
Alexis Moroz nous parle de son parcours de game designer dans plusieurs boites de jeu vidéo français. Il a surtout parlé de son travail sur Heavy Rain, chez Quantic Dream vu que c'est là qu'il a passé le plus de temps.
Quantic a 17 ans d'existence, et 5 jeux produits. Ils sont spécialisés dans les "Interactive Drama", un genre qu'ils ont inventés, genre de films interactifs, avec beaucoup d'émotion, mais que beaucoup de gens qualifient comme "n'étant pas des jeux".
La production d'un jeu AAA comme Heavy Rain a couté environ $20 millions de dollar, plus environ $30 millions de marketing. Au final, le jeu aura rapporté $113 millions. Aux dires d'Alexis, Heavy Rain n'était pas vraiment un "triple A", mais plutot un "2.5 A", car depuis des jeux comme les Assassin's Creed ou GTA ont complétement réhaussé le budget nécessaire à la conception des jeux. On dépasse aujourd'hui les budgets des blockbusters de cinéma.
Le rythme de développement d'un jeu de ce genre est très différent de ce à quoi nous sommes normalement habitué dans les projets informatiques. Tout est drivé par les milestones : pré-alpha, alpha, pré-beta, beta, release candidate et gold. Les dates de ces milestones sont fixées à l'avance et coincident avec des événements majeurs du milieu (E3, TGS, etc). Il n'est donc pas possible de les déplacer, une version du jeu doit être sortie à cette date, quoiqu'il arrive.
En plus de cela, les budgets pour les jeux étant colossaux, Quantic ne peut pas investir sur ses propres fonds. C'est donc le travail de l'éditeur, dans leur cas, Sony. Ils passent un contrat avec Sony, où Sony s'engage à payer leurs dépenses (locaux, salaires, etc) jusqu'à la prochaine milestone, et eux s'engagent à un certain nombre de features qui doivent apparaitre dans cette milestone. S'ils ne remplissent pas leur part du contrat, alors Sony ne remplit pas la sienne non plus. C'est à dire qu'ils ne sont pas payés, et que donc des jeux peuvent ne jamais voir le jour si une des milestone n'a pas été atteinte.
Il n'est pas possible de négocier sur les délais comme on l'a vu, et très difficile de négocier sur le périmètre, Quantic s'engageant sur celui-ci au début. Néanmoins, Alexis nous avoue que généralement on triche sur les specifications. Si on a dit qu'un niveau entier doit etre jouable, ou que tous les personnages doivent être texturés pour une étape donné, on ne fait quand même que le minimum pour ce qui n'est pas indispensable. Niveau vide à part pour l'intrigue principale, textures de basse qualité pour les endroits éloignés, etc.
Du coup, si ni les délais ni le périmètre ne peuvent bouger, qu'advient-il de la qualité ? Et bien c'est là que tout est subjectifs. Chez Quantic, les jeux jouant beaucoup sur l'émotion, les tests des niveaux sont effectués par des humains, qui jouent et rejouent, et des playtesteurs externes. Il n'ont que très peu de tests automatisés, voire pas du tout. Ils ont de grandes sessions de QA, mais faites par des humains (un chèque cadeau de 100€ contre 3-4h de test d'un niveau).
Quantic, et Ubisoft, et finalement pas mal des grosses boites de jeu sont connues pour avoir des rythmes de développement effrenés quand les dates de milestone approchent, surtout quand la dernière arrive. Ils savent qu'après la date finale, ils ne pourront plus rajouter de contenu sur leur jeu, et ils y ont travaillé des années, par passion, ils ont envie qu'il soit parfait. Et comme ils sont aussi généralement en retard des milestones précédentes pour avoir grapillé sur les specs, ils ont beaucoup de travail à faire à la fin. Ces periodes de burn sont très durs, et il est fréquent que des démissions arrivent à la pelle après ces périodes, qui en dégoutent plus d'un de travailler dans ce milieu.
Les salaires ne sont pas mirobolants non plus, les boites jouant beaucoup sur le fait que "mais tu viens faire ta passion, travailler dans le jeu vidéo c'est pas donné à tout le monde, si tu ne veux pas de ce poste, je vais en trouver facilement d'autres, tu devrais être content."
Ce qu'il est intéressant de noter sur la composition des équipes, c'est qu'il y a autant de développeurs (une vingtaine chez Quantic en tout cas) pour la conception du moteur de jeu en lui même que pour la conception des outils internes (outils pour importer les textures, gérer les modèles 3D, gérer le motion capture, etc).
Finalement dernière point intéressant pour revenir sur les différentes milestones, c'est que généralement les deux premières (pre-alpha, alpha) contiennent surtout des artworks et pas de phase de jeu, puis vient la "vertical slice", qui est censé donner une vue d'ensemble d'un niveau du jeu. Avec la musique, les effets, le scénar, le moteur 3D, etc. Bref, toutes les couches du jeu sont présentes, mais sur une durée limitée. Ce genre de production peut difficilement être réutilisée dans le projet final, et c'est donc finalement du temps "perdu" en développement, mais gagné pour le coté marketing.
Cette fois-ci, c'était chez Meetic, qui ont de chouettes locaux en plein Paris, mais on peut passer devant sans s'en rendre compte vu que ce n'est pas marqué sur la façade.
Améliorer les performances de ses applications Angular
Jonathan Meiss, ancien collègue Octo désormais chez Meetic, nous présentait toute une liste d'astuces pour améliorer les performances d'une appli Angular. Globalement c'était des choses assez basiques et connues.
On a pas mal parlé de ngRepeat qui est là que généralement les problèmes de perf se font sentir. Déjà il est éviden que la page va être moins performante si on doit afficher 1000 élement que si on n'en affiche que 10. Du coup, il peut être intéressant de faire appel à limitTo pour paginer les résultats. Une autre solution est de tirer parti de l'infinite scroll qui permet de ne charger des éléments que quand ils vont apparaitre dans le viewport. Il conseille la library ng-infinite-scroll pour ça.
Toujours sur les ngRepeat, il faut bien sur éviter de faire des boucles sur des résultats de fonctions (ie pas de ng-repeat="item in filteredList()") car cela force à recalculer le contenu de filteredList à chaque digest cycle. Mieux vaut soit utiliser des filter dans la vue, soit itérer sur une variable du scope.
Dernier conseil sur ngRepeat; angular génère un id unique à chaque élement sur lequel il itère pour les différencier. Si on le laisse faire il utilise les clés interne de l'objet pour générer son id. Si on sait qu'une de nos clés (id par exemple) est unique dans la liste, autant lui spécifier avec track by pour lui simplifier son calcul et lui éviter d'ajouter des éléments inutiles au DOM.
On est ensuite passé sur le two-way binding qui est l'élément qui nous a fait rêver au début d'angular, mais qui reste un processus couteux. A partir de 2000 watchers, les performances commencent à en patir. Si on sait qu'on ne fait qu'afficher sans avoir besoin de modifier des données, on peut ajouter bo-text="user.name" sur l'élément sur lequel on itère pour qu'angular ne crée pas de two-way binding.
Il nous a fait un petit retour sur ngIf et ngShow et les cas d'usages pour chacun. ngIf ne va ajouter des éléments dans le DOM que si la condition est vraie, il ne faut donc pas l'utiliser si la condition change souvent, au risque de créer trop de rendering au browser. Au contraire, si le contenu affiché dans l'élément nécessite un processing intense, il vaut mieux le mettre dans un ngIf plutot qu'un ngShow. ngShow quand à lui est utile si on veut "cacher" des éléments dans le DOM pour les afficher plus tard rapidement.
Bien sur, il conseille d'activer le cache:true sur les ressources, et $q.all quand possible pour parallelliser les requetes aux API. Idem pour définir des resolve dans son router (à noter que si une seule des resolve fail, alors le controlleur cible ne sera pas instancier. Il peut donc être intéressant de ne définir qu'un seul resolve, qui englobe une promise custom avec $q.all et retourner un unique object avec des clés undefined si les sous-promises failent, et gérer les fallbacks dans le controlleur).
Finalement, il ne faut pas oublier que la performance ne se calcule pas en ms réelles, mais en perception utilisateur. Il peut donc parfois être intéressant d'utiliser des résolve pour afficher à l'user une page avec toutes les données, mais parfois de les afficher au fur et à mesure. A noter qu'en dessous de 100ms le cerveau humain considère une action comme immédiate. On peut donc afficher un spinner à l'utilisateur pour lui indiquer qu'une action est en cours, mais ne l'afficher que si le traitement prends plus de 100ms pour lui éviter un flicker inutile. Si on veut aller au bout des best practices, on peut commencer à afficher des placeholders pendant le chargement pour lui montrer que quelque chose se passe. Il est important aussi de lui laisser accès à des fonctions de base (sidebar, menu) pour lui permettre de naviguer si la navigation prends trop de temps (plutot que de se retrouver sur une page freezée et qu'il soit obligé de quitter la page).
Finalement John a fini par un troll en disant que si vraiment vous voulez des pages réactives qui se chargent vite, utilisez React.
SVG
Présentation molle et avec des soucis techniques. Au final on a juste (re)appris que SVG c'était cool parce que c'était vectoriel et donc ça scale aux résolutions. Mais surtout c'est du XML dans le DOM, donc ça se scripte en Angular très facilement et ça se style en CSS. Et on peut faire des formes complexes à base de suite de points pour faire par exemple une carte de france des régions.
Voila, voila.
Le talk était fait par un statisticien qui était passionné (et passionant) quand il parlait des données, mais semblait découvrir en Angular ce qui pour moi faisait partie des bases. Au final, d'un point de vue technique je n'ai rien appris, et d'un point de vue des données en elle-même, cela semblait certes le passioner, mais n'ayant pas la même fougue pour les nombres, ça m'est juste passé au dessus de la tête.
Première édition de dotScale, petit frère des dotConférences. Encore une fois, ça avait lieu dans un endroit magnifique, qu'est le théatre de Paris. La salle était loin d'être complétement remplie, ce qui permet à chacun de s'installer où il le souhaite. Et c'est tant mieux, car comme souvent dans ce genre de théatre, toutes les places ne sont pas égales. Et pour peu que vous ayiez envie d'être installé confortablement et de prendre des notes sur votre laptop, ça devient compliqué.
Néanmoins, j'ai pu me trouver une place dans l'une des loges VIP sur la gauche de la scène, ce qui me donnait une vue parfaite et plongeante sur les présentations.
Retour d'expérience sur healthcare.gov
Robert Kennedy, employé Google, nous a fait le deuxième retour d'expérience de la conférence. Il est allé aidé le projet healthcare.gov, dont vous avez sans doute déjà tous entendu les déboires. Je ne connaissais pas le détail technique de pourquoi ça s'était cassé la gueule, et c'était intéressant d'avoir ce retour de cette horror story vue de l'intérieur.
Le projet complet de réforme du système de santé repose sur le bon fonctionnement du site web. Le fait que le site soit dans les choux pour une durée indeterminée dès le jour de son lancement à fait les unes des journaux.
Globalement le site était dispo, il pouvait recevoir du traffic, mais il était complétement instable. Plusieurs éléments de son archit étaient des SPOF et il n'était pas conçu pour scaler aisement.
Au moment où notre gars est intervenu, ils avaient une nouvelle deadline, quelques mois plus tard, où le site allait devoir ouvrir, à plus de monde encore, et donc faire face à un afflux encore plus important.
La majorité des problèmes ne venaient pas réellement de mauvais choix techniques, mais plus de problèmes humains. Le projet avait été splitté en une douzaine de modules différents commandés à autant d'agences différentes. Chacune faisait son affaire dans son coin, avec des niveau de qualité différents, mais surtout personne n'était en charge de faire fonctionner les modules ensemble. L'idée était que si chacun faisait correctement son travail, alors tous les bouts allaient magiquement s'emboiter à la fin. Comment dire ? non.
Ils n'avaient pas non plus de monitoring centralisé des modules. Certains avaient fait leurs propres outils (en console, en web view, sous forme d'export régulier) mais la plupart n'avait absolument aucune idée de si leur système était up ou down à part en vérifiant manuellement. L'une des premières choses qu'ils ont mis en place a été d'aggréger en une vue simplifie les infos les plus importantes qu'ils avaient : nombre de requetes, % d'erreurs et consommation CPU. Ils l'ont enrichi au fur et à mesure avec les datas qu'ils arrivaient à récupérer des différents modules.
A chaque fois que le site était down, il leur fallait quand même aller voir chaque responsable un par un en leur demandant si leur partie était bien opérationnelle.
D'un point de vue archi, leur infra n'est pas trop déconnante. Un frontal web qui tape vers un gateway qui s'occupe de l'authentication, et si ok renvoie vers la couche métier. Celle-ci s'occupe d'aggréger des résultats de service de plein d'API d'autres ministères et organismes pour calculer ce à quoi l'internaute à droit. Le processus métier étant long et complexe, dans certains cas les internautes doivent le faire en plusieurs fois, le temps que leur demande soit manuellement traitée. Il faut donc sauvegarder dans un coin l'état de leur demande pour qu'ils puissent y retourner plus tard. Ils stockent donc tout ça dans une DB en xml.
Apparemment, ils avaient un système de cache mal configuré là dedans qui créait dans certains cas plus de requetes qu'il n'en absorbait. Rajoutons à cela qu'ils ont eu besoin de stocker des fichiers, beaucoup de fichiers, ils ont donc commandé des serveurs pour ça, et les X modules se sont mis à écrire dessus jusqu'à remplir le serveur. Ils en ont donc rachetés de nouveaux, et rebelote. Au final, ils avaient 19 serveurs de stockage de fichiers où les X modules qui constituent l'application écrivaient leurs infos. Chacun de ces 19 serveurs était un SPOF car il contenait potentiellement des infos nécessaires à tous les modules... Rajoutons à cela que si l'un deux plante, ils n'ont aucune procédure automatique pour les ramener à la vie (et bien sur aucune redondance), du coup il fallait manuellement se connecter sur les machines pour remonter le filesystem manuellement. Et bizarrement, on ne pouvait pas remonter les machines dans n'importe quel ordre, il fallait forcément les remonter dans un certain ordre, sans que l'on sache pourquoi, mais au moins on connait l'ordre... ça faisait un peu vaudou...
Ensuite, l'une des histoires les plus intéressantes de toute la conf est celle du jour où ils ont pu voir sur leurs outils que toutes les requetes entrantes retournaient des erreurs, et que la latence moyenne avait baissée de 200ms à 10ms. Comme ils n'avaient toujours pas d'outils vraiment précis pour isoler le problème, ils ont déduit qu'il y avait un soucis avec la DB (la DB est généralement la partie qui cause la plus grande latence, si celle-ci droppe à 0, ça veut dire qu'elle n'est sans doute plus sollicitée).
Comme d'hab, il font manuellement le tour de tout le monde pour leur demander si leur système est up. Les gars de la DB s'apercoivent que depuis 10h30 le matin, toutes leurs requetes en DB leur retournent une permission denied error.
J'ai oublié de le dire précédemment, mais pour faciliter encore les choses, les différentes agences sont réparties à 3 endroits des USA différents, et ont une pieuvre de conf-call allumée en permanence pour discuter. Voyant l'erreur, ils demandent donc aux deux autres permanences s'ils ont modifié quelque chose à 10h30 ce jour là. Silence. Non, non, personne n'a rien changé.
En fait, il y a bien un développeur qui a changé les droits d'accès de l'user principal en vu d'un processus de batch qui allait arriver, mais au lieu de mettre à jour les anciens droits, il a simplement écrasé les anciens par les nouveaux, rendant l'accès initial à la base impossible. Plutot que de dire "Oui c'est moi, j'ai du me tromper, venez m'aider à régler", il a préféré ne rien dire en esperant que ça passe inaperçu et qu'on ne sache pas que c'était lui. Manque de bol, ils ont réussi à retrouver que c'était lui et... ils l'ont viré.
Et c'est là toute la différence de culture entre, par exemple, Google et la cellule du gouvernement en charge de mettre en place le site. A Google, on aurait dit "Mince, je crois que j'ai fait une connerie, le site est en rade, que quelqu'un qui maitrise vienne vite m'aider". Là, ils savent que s'ils se font chopper à faire une erreur, ils se font virer. Au final, plus personne ne veut prendre d'initiative car dans le cas où ils se trompent, ils ont tout à y perdre.
Notre speaker disait que lui il avait le beau role, vu qu'il venait de l'exterieur pour aider, même s'il se plantait, au pire il retournait travailler à Google et eux restaient avec leur problème, ca n'avait pas la même pression que sur les autres. Au final, tout le monde était donc incité à ne rien faire, par peur des représailles en cas d'échec. Alors que dans l'équipe, il y avait des gens très compétents, qui savaient très bien comment faire, mais qui ne voulaient pas prendre le risque.
Au final ils se retrouvaient donc dans une situation où ils viraient les gens les plus compétents parce qu'ils se trompaient parfois, et gardaient des gens qui ne faisaient rien de peur de se tromper. Si déjà ce genre de comportement est en vigueur dans la société en situation normale, il est exacerbé en situation de stress comme c'était le cas ici. Si les devs n'ont pas la liberté d'essayer, de se tromper, et de demander de l'aide, alors le jour où il se passe vraiment quelque chose de grave, tout le monde est démuni parce que personne ne veut prendre de risques. Et finalement, qui est-ce qui passe pour un incompétent aux yeux du monde ? La société/ministère, pas les développeurs internes.
Cette histoire est celle qui m'a le plus marquée parce que c'est celle qu'on retrouve (à plus petite échelle) bien trop souvent. Le fiasco qu'à été healthcare.gov et l'ampleur que ça a pris dans les médias sont de bons exemples pour expliquer les dérives qu'impliquent de telles cultures.
La suite du talk était un ensemble d'autres WTF sur le projet. C'est toujours bon à prendre, donc je le rajoute ici :
Ils avaient par exemple l'un de leur module qui avait bien un système de reporting de ses erreurs mais, il y a avait en fait toujours des erreurs, si bien que plus de la moitié des composants étaient toujours au rouge. Mais bon, le parcours critique semblait quand même fonctionner donc on oubliait un peu les indicateurs et le rouge devenait normal. Sauf le jour où il y a vraiment eu un problème, il est passé inapercu dans la masse. Impossible de se logguer en ssh sur les machines, un des serveurs était passé en read-only, plus aucune écriture dans la DB n'était possible. Ils n'ont jamais compris d'où le bug venait, et ils ont pris du temps à le remarquer, et encore plus à le corriger.
Ils avaient aussi eu des soucis de configuration de leur Load Balancer qui envoyait la moitié des requetes dans le warp, vers des IP qui n'existaient pas.
Globalement pourquoi ce projet a tourné à la catastrophe ? Parce que personne n'avait de vision générale de tous les éléments, personne n'était là pour les faire fonctionner ensemble, chacun faisait sa partie dans son coin en se disant que "si je suis les specs, il ne peut rien m'arriver de mal".
Ils ont mis en prod directement le jour de la sortie, sans faire de pre-prod avant. Le grand saut directement. Bien sur ça a planté, et s'en est suivi une grande période de stress pour toute l'équipe. Déjà qu'il était difficile de faire les choses correctement en période normale, c'était encore plus dur en stress. L'inaction était récompensée, car si on cassait quelque chose, on se faisait virer, mieux valait ne rien faire. Chaque équipe était dans son silo, sans partager ni ses informations sur son module, ni les responsabilités. Le management les incitait même à cela, pour qu'ils se concentrent sur leur sujet, sans se laisser distraire par les autres. Ils faisaient aussi bien trop confiance aux produits "tout fait". Après tout, il suffit d'aller acheter une DB au magasin Oracle et de la poser dans l'archi et tout marche, non ?
Bon, le point positif, c'est qu'ils ont quand même beaucoup appris de cette expérience et qu'ils vont changer leur culture de l'IT pour la suite, pour ne pas avoir de second épisode comme celui-ci.
Scaling One Direction
Entre plusieurs talks de présentation d'outils extraordinaire, on a eu le droit à un petit REX très intéressant.
L'histoire est ici celle de l'équipe en charge de réaliser l'infra qui devait supporter live stream video du concert de 7h des One Direction. Un boys band est un très bon exemple des problèmatiques de scaling : il y a des millions de fans à travers le monde qui vont tous faire la même chose en même temps en fonction de ce que fait le groupe sur scène.
Ici la problèmatique n'était pas vraiment le streaming live de 7h de vidéo à plusieurs dizaines de millions de personnes à travers le monde. C'est pas quelque chose de facile, mais ça a déjà été fait avant.
Non, la difficulté vient d'autre part. Pendant le concert étaient diffusées, toutes les 10 minutes, des questions sur le groupe, auxquelles les fans devaient répondre avec l'appli mobile dédiée. En terme de pic de charge ça veut dire que pendant 9 minutes il ne se passe rien, puis en 1 minutes l'infra doit absorber des dizaines de millions de hits concentrés. Puis silence radio à nouveau pendant 9 minutes. Et nouveau pic. Et ça, pendant 7h.
Après chaque question, des stats étaient affichées en temps réel sur scène, avec le pays où les fans avaient le mieux répondu aux questions, et à la fin du concert, LE fan absolu, celui qui avait répondu bon à toutes les questions depuis le début, et le plus vite possible avait son nom affiché sur écran géant et droit à un petit mot du groupe. La classe.
Bon, et comment on fait l'infra pour ça ? Déjà on estime ce qu'on pense recevoir comme hits. On se prends une marge basse et une marge haute, et on calcule les machines qu'il va nous falloir pour absorber ça. Ensuite on calcule combien ça coute, et là on s'évanouie parce que c'est énorme. Mais comme on a ces 9 minutes d'inactivité, on sait qu'on peut diminuer la facture par 10 si seulement on ne commissionne des machines que durant les tranches où on en a besoin.
Citation très importante à ce moment : "Scaling is as much getting bigger and bigger than getting smaller and smaller in a short period of time".
Ensuite, deuxième étape pour savoir sur quelle stack partir, ils sont allé voir le métier pour savoir exactement les métrics dont ils allaient avoir besoin. Il a fallu convaincre la BI (mais avec la simulation de la facture c'était pas dur), que garder toutes les données (nom, prénom, age, etc) de tous les participants c'était inutile, et qu'on n'en avait besoin que pour le top 10 à afficher à la fin. Ensuite, on n'a pas besoin de savoir exactement qui a répondu quoi, on a juste besoin de savoir combien de personnes ont répondu juste ou faux à une question, leur tranche d'age (séparée en 3) et leur pays.
Sachant cela, les archi ont laissé tombé les bases SQL et sont partis sur du memcache. L'event étant un oneshot, il n'y a pas d'intéret à garder les données après coup, donc une base inmemory est adaptée. Les écritures sont rapides et simple, mais on est limité à une structure clé/valeur.
Ils ont alors commencé à trouver la meilleure manière de nommer leurs clées pour répondre à ce besoin spécifique. La logique de nommage étape par étape est la suivante :
Comme il ne leur faut que le nombre de bonnes et mauvaises réponses à chaque question, ils ont créés des clés nommées q1wrong, q1right, q2wrong, q2right pour stocker les bonnes/mauvaises réponses aux questions 1 et 2.
Bon, ça faisait quand même beaucoup d'écritures en séquence sur la même clé, du coup ils ont opéré un sharding manuel. Ils généraient un nombre random entre 1 et 100 qu'ils suffixaient à la clés : q1wrong42, q2right67, etc. Ainsi, les écritures étaient un peu réparties et ce n'était pas toujours la même plage mémoire qui trinquait.
Ensuite ils devaient gérer la tranche d'age de l'utilisateur (séparée en 3 buckets possibles), ils l'ont donc rajouté dans la clé : q1age2wrong66, q2age3right01.
Il doivent aussi connaitre les scores par pays, et là ca se complique. Certains pays sont largement plus représentés que d'autres, donc ajouter simplement le nom du pays à la clé ferait encore trop d'écriture sur les mêmes clés. Ils ont donc défini les pays qu'ils pensaient être les plus représentés ('uk', 'us', 'unknown'). Et si le pays de l'appelant est dans cette liste, il rajoutent un nouveau sharding numérique entre 1 et 15. Si c'est un autre pays (donc moins représenté), il ne font un sharding que sur 1 à 3.
Au final, leur archi-one shot a tenue. On ne sait pas exactement combien de memcache répliqués étaient utilisées mais je doute que tout tienne sur un seul (ou peut-etre que si ?).
Après l'évenement, ils sont donc allé feter ça au bar pour la soirée et la facture des boissons était plus élévée que leur facture de cloud. Ce qui est un bon indicateur de réussite de scaling !
Consul
Mitchell Hashimoto, le créateur de Vagrant nous a parlé de son dernier projet : Consul.
Consul cherche à régler le problème de la découverte et de la configuration de machines dans un réseau. Pour pouvoir gérer son infra au mieux, on a besoin de savoir où se trouvent (ip) les différents serveurs, s'ils sont up ou down, et comment ils sont configurés. On doit aussi pouvoir en ajouter ou en enlever au système et que les autres soient au courant. Généralement pour cela on utilise un serveur centralisé qu'on peut interroger pour répondre à ces questions mais que se passe-t'il quand ce serveur là est down ?
Consul permet de répondre à toutes ces questions par un système distribué et hautement disponible. Il n'a pas pu nous dire pourquoi et comment Consul était si hautement disponible, parce que sinon il allait en parler pendant des heures, mais nous a juste indiqué que c'est la priorité numero 1 : que les infos soient toujours dispos même si des noeuds tombent. Chaque serveur fait tourner en local une instance du système, donc même s'il est coupé du réseau, il possède quand même un cache des infos et il se resynchronise avec le reste dès que la connection revient.
Chacunes de ces instances distribuées expose une API dispo en curl/dig qui permet de récupérer l'ip d'une machine à partir de son nom (ou vice-versa). L'API permet aussi de savoir si la machine est up (par défaut il ne retourne que des services ups, mais on peut taper sur un autre endpoint pour avoir la totalité des services). Avec quelques simples appels curl on peut aussi récupérer la config de telle ou telle machine.
Comme je disais plus haut, le mode de fonctionnement est local par défaut (chaque machine possède les infos de la totalité du réseau) mais se synchronise en cas de changement. Un (ou plusieurs) datacenters peuvent être identifiés comme maitre de la donnée, où les autres se tournent pour avoir des infos plus fraiches.
Et bien sur, il existe une console web pour voir tous les noeuds, leur dispo et leur config, mais aussi un outil en ligne de commande pour intéragir avec eux.
Connaissant la qualité de Vagrant, Consul a l'air très prometteur.
Flynn
Jeff Lindsay nous a présenté un truc assez flou où à la fin de la présentation on ne savait pas si le projet dont il parlait existait réellement ou non. Il faut dire que les speakers avaient comme consigne de ne pas faire de conférences commerciales, donc parfois c'était assez flou.
Bref, Jeff Lindsay a un CV assez impressionant d'ops chez Digital Ocean, dotCloud, la NASA, et Twilio.
L'histoire qu'il nous raconte est celle d'une société qui commence son proto et l'héberge sur heroku. Tout est facile, en quelques clics on choisit ce qu'on installe et tout est disponible directement.
Mais quand la société grandit et qu'elle a besoin de scaler, elle va vite atteindre les limites d'heroku. Avec de la chance, toute la stack technique dont elle a besoin est fournie par heroku, mais si jamais ce n'est pas le cas elle est obligée de tout migrer sur une nouvelle infra, et de rattraper un gros retard from scratch en réecrivant tout sous Chef ou Puppet.
Et ça arrive souvent. Les serveurs évoluent, les besoin techniques aussi, on a besoin d'ajouter de nouveaux noeuds, ou de splitter des noeuds existants, ou de merge plusieurs noeuds ensemble. Il faut mettre une API en frontal, rajouter des load balancers, du cache, des master/slaves, etc. Sans parler des serveurs annexes qui gravitent autour : le repo git, le master chef, l'outil de bug report, le jenkins, etc. Forcément, au bout d'un moment on va avoir plein de machines un peu partout.
Et si on n'avait plus besoin de machines finalement ? Et si tout ce qui nous intéressait c'était les services qui tournent dessus ?
Flynn, l'outil développé par le monsieur essaie d'abstraire la notion de serveurs pour se concentrer sur les modules qui tournent dessus. A base de containers dockers un peu partout, il fourni un outil pour développer son propre heroku-like privé. La notion même de host disparait, et tout ce qui nous intéresse sont les process.
C'était une idée vachement intéressante et qui fait voir les choses sous un autre angle, mais le projet n'est qu'à l'état d'embryon actuellement.
Après la pause déjeuner, on a eu le droit à une sessions de lightning talks.
Le premier nous a parlé de son projet Nephorider qui permet de dresser une carte graphique des différentes machines d'un cloud : qui est relié à quoi, avec quelle ip, etc. Ils fonctionnent avec plusieurs providers, mais essentiellement Amazon, Rackspace et Google Compute Engine. Son talk parlait surtout des différentes API que ces trois fournisseurs exposent pour obtenir les infos nécessaires à la conception de son graph.
Chez AWS, il faut une cinquantaine de requetes, pour questionner toutes les régions, toutes les zones et aggréger toutes les infos. Chez Rackspace, on se limite à une vingtaine. Chez Google il en faut 3-4 parce que leur API permet de sélectionner les clés que l'on désire, et permet d'aggréger plusieurs requetes en une seule, et de les chainer avec un seul appel. Ca c'est de l'API !
Peter Szilagyi, le suivant nous a parlé de son projet Iris. J'ai eu un peu de mal à suivre exactement de quoi il retournait mais de ce que je comprends c'est un projet de messaging au sein d'une infra, de manière à faire communiquer des nodes ou groupes de nodes de même nature les uns avec les autres. Ca peut aussi bien être du broadcast générique que du pub/sub que du classique request/reply ou du stream d'un node à un autre. C'est resté assez flou.
Finalmeent Steeve Morin (@steeve) nous a parlé de boot2docker, qui utilise un kernel linux le plus petit possible, juste suffisant pour lancer docker et qui permet ainsi d'avoir une instance docker complete (kernel, OS, docker) pour seulement 53mo, et qui se lance la première fois en 3s, téléchargement de l'iso inclus. Vu que la stack initiale est read-only, on peut même booter depuis une clé USB. Un projet intéressant.
openZFS
Premier talk d'un haut niveau technique par Matt Ahrens, j'ai un instant eu peur que toutes les confs soient de cet acabit, mais c'était plutot l'exception.
Il nous parle des filesystems en général et d'openZFS en particulier. Comme dans pas mal de systèmes, il y a toujours un tryptique où on ne peut choisir que deux points parmis trois et pour les filesystems le choix se porte entre rapide, sûr et bon marché. Il nous parle d'un problème courant dans les datacenters où certains disques d'une baie sont moins performants que d'autres, et qu'on a beau les remplacer par des neufs, c'est toujours celui qui est à la même place qui souffre. Comme c'est du matériel mine de rien assez fragile, il suffit qu'il y ait des vibrations à cet endroit dans la pièce (à hauteur de voix parce qu'on est obligé de crier dans un datacenter à cause du bruit) et la tete de lecture se décale et crée des incohérence dans les données écrites sur le disque.
Généralement ces incohérences sont corrigées par le software qui va lire le disque, mais openZFS prends un autre partie en gérant ce genre de problèmes au niveau hardware. Les données sont écrites à plusieurs endroits dans le filesystem afin d'assurer une redondance et donc une meilleure intégrité des données. Ils font aussi des checksums de ce qu'ils écrivent afin de s'assurer de l'intégrité de la donnée. Un serveur qui utilise openZFS peut bien crasher d'un coup, les données sont assurées d'être écrites correctement, les disques ne peuvent pas se retrouver dans des états instables qui nécessittent de passer un coup de fsck.
openZSF est fait pour tourner sur du commodity hardware, des tas de disques bons marchés sur lesquels on replique la donnée et on se moque si l'un est plus lent que les autres ou non, il suffira alors de le changer si nécessaire, et on ne perdre pas l'intégrité de notre donnée.
Aujourd'hui, pour le même prix on peut avoir une capacité de stockage un million de fois supérieur à ce qu'on avait il y a 20 ans. Ce n'est donc pas intéressant de faire travailler du software pour régler des soucis d'incohérence et d'intégrité de donnée, il vaut mieux assurer ce travail au plus près du hardware pour avoir le moins de transit de donnée.
Note: Comme je disais en intro, ce talk était très technique, donc désolé si j'ai compris des trucs de travers, les experts pourront corriger.
Will PHP be hype again ?
Fabien Potencier (@fabpot), de Symfony nous a parlé de PHP. Il a commencé par évacuer les trolls d'entrée de jeu en disant que lui aussi, même s'il fait du PHP tous les jours, il n'aime pas le langage. Mais qu'il aime PHP pour la plateforme que c'est. Grand écosystème, facile de contribuer, server-side language qui a été pensé dans une optique de web dès le début et une pltéhore de frameworks disponibles (WordPress, Drupal, Joomla, Magento entre autres).
Le problème majeur de PHP est qu'il n'a jamais été pensé pour scaler. Toute nouvelle requete doit repasser par tout un cycle de traitement et de recompilation. Sur Symfony, ils essaient de déplacer certaines éléments de logique qui étaient initialement réexecutés à chaque requete, pour les déplacer à l'initialisation de PHP, histoire de gagner en performance. Ils se heurtent à pas mal de soucis inhérents à la conception initiale de PHP, comme par exemple le fait qu'une seule requete ne puisse être traitée en entrée à chaque fois et qu'une seule réponse ne puisse être retournée (ie. echo renvoie direct dans le corps de la réponse).
Bref, il est confiant que PHP puisse redevenir hype à nouveau ("après tout, c'est bien arrivé à Javascript"), grâce à la communauté qu'il a déjà derrière lui.
SaltStack
Thomas S. Hatch nous a parlé de nos infrastructures. On a plein de machines, déployées à travers le monde, qui communiquent les unes avec les autres. Pour réussir à scaler correctement, il faut aller vite; le scaling est essentiellement une question de vitesse. Et bien sur, chaque infra est différente et il n'y a pas de formule magique qui marche dans tous les cas.
Il y a donc différentes manières de considérer ses machines. Certains les voient comme des animaux domestiques, à qui on demande d'effectuer des taches, et qui reviennent avec le résultat. D'autres les chouchoutent comme des pierres précieuses, en les configurant aux petits oignons, mais de manière tellement précise qu'on n'ose plus y toucher de peur de briser quelque chose. De plus les voient aussi comme du bétail, un gros troupeau sans intelligence individuelle mais qui réagit à des ordre de déploiement supérieurs.
Mais la solution évoquée par le speaker est de les voir comme une armée de minions. On peut les diriger, leur donner des ordres, et compter sur eux pour faire ce qui est juste à un moment donnée pour arriver au but indiqué.
L'automatisation passe essentiellement par la communication entre les entités. Et vu la taille des architectures dont on parle, cette communication ne peut être qu'asynchrone, on ne peut pas attendre d'avoir la réponse aux questions qu'on a posées avant de passer à la suite. Si on rajoute à cela que tout ces systèmes ne parlent pas la même langue (différents protocoles, différentes implémentation, différents OS), il est impératif de trouver une manière de normaliser la communication.
Il a ensuite rapidement évoqué SaltStack, son produit qui serait une solution proposée à ce problème (http://www.saltstack.com/). Pour lui la solution passe par une modularisation (separation of concerns) des composants, et une abstraction par couche (pour simplifier chaque partie au maximum), mais surtout l'architecture doit être data-driven et non pas language-driven. Toute la configuration de qui parle avec qui pourquoi doit se trouver dans des fichiers de confs et pas dans des scripts d'un langage ou d'un autre. Ca permet de ne pas être bloqué avec un outil et de ne pas pouvoir en changer (un gars de WikiMedia dans une autre conf évoquait justement qu'ils restaient sur un vieil outil à cause des 20.000 lignes de code de déploiement qu'ils avaient dessus à cause du coup de migration).
Au final, il a peu parlé de sa solution et je ne sais pas trop ce qu'elle fait mais son analyse était intéressante.
And let's not forget Security
Alison Gianotto, alias @snipeyhead nous a fait un tour d'horizon et une piqure de rappel sur la sécurité informatique. C'est sujet récurrent dans à peu près toutes les conférences où je vais, mais c'est aussi un sujet tellement vaster qu'un peu d'évangélisation ne fait jamais de mal.
Elle a commencé par énoncer deux principes qu'il faut garder en tête à chaque fois que l'on tente de se protéger. Tout d'abord il est impossible d'anticiper tous les risques. Et deuxièmement, il est futile d'essayer de mitiger tous les risques. Sur ce premier constat pessimiste, on enchaine en se mettant dans la peau du hacker et de pourquoi il fait ça ?
Généralement c'est pour du profit, pour voler ou revendre des informations personnelles, des numéros de carte bleue, des informations secrètes. Ca peut aussi être tout simplement pour le fun, ou pour de l'hacktivisme. Parfois c'est par vengeance, ou pour de l'espionnage industriel. Il ne faut pas oublier tout le blackhat SEO (compromettre des sites pour faire monter son propre google juice).
Nos infrastructures sont aujourd'hui bien plus grandes qu'il y a 10 ans. Les infiltrations sont sans doute aussi nombreuses en proportion, mais la quantité de donnée volée est bien bien supérieure. On a eu plusieurs mega-breaches ces dernières années (ie. 10+ millions d'identitées récupéréres) : Adobe, PSN, etc.
Alors on essaie de se protéger, mais souvent ce qui semble une bonne idée de l'extérieur amène en fait plus de risques qu'initialement. C'est par exemple le cas de forcer ses utilisateurs à utiliser des mots de passes résistants en les forçant à suivre des règles drastiques (des chiffres, des lettres, des caracteres spéciaux, et devoir le changer régulièrement). Au final, le pass est tellement difficile à retenir que les utilisateurs vont le noter sur un post-it, et incrémenteront un numero tous les 3 mois.
Nos archis couvrent une telle surface que les intrusions peuvent venir de bien plus d'endroits qu'avant. Monitorer tout cela et se protéger devient très difficile. Sans compter qu'on fait face à une force de frappe qui est virtuellement illimitée : réseau de machines infectées qui peuvent bruteforcer ou DDOS. Ca coute beaucoup plus cher à une boite de se protéger de ces intrusions que cela ne coute à un attaquant (on peut louer des serveurs dans le cloud à la force de frappe énorme pour peu de sous).
Mais continuons à être pessimistes : les hackers ne sont pas nos seuls ennemis dans cette battaille. Nous sommes nous-même bien souvent la première faille du système. Nos systèmes devraient suivre le principe de CIA (rien à voir avec l'agence), c'est à dire : Confidentiality, Integrity and Availability.
Confidentiality signifie que l'accès aux données sensibles doit être limitée. 2 factor authentication, et destruction des anciennes données régulièrement. L'Integrity assure que l'information que l'on récupère est correcte et qu'elle n'a pas été modifiée. Et finalement Availability pour assurer que les personnes qui ont l'accès peuvent accéder à leurs infos à tout moment.
Elle a fini par quelques conseils génériques et une checklist de 20 items à faire tout de suite si ce n'est pas déjà fait. Tout d'abord, il faut étudier tous les composants de notre infra, et pour chacun étudier les chances qu'il puisse être la cible d'une attaque, et l'impact si jamais il venait à être compromis. Ensuite, il faut bien évidemment avoir un monitoring, comme toujours, de toutes les requetes et des comportements étranges. Et finalement, il faut lister tous les appels que l'ont fait vers des third party (API externes, progiciels, etc) pour identifier l'impact si l'un d'eux vient à tomber ou devient compromis.
Finalement, la vingtaine d'items à faire au plus vite :
Faire participer sa team à un jeu de CTR (Capture the Flag). Ce sont des jeux organisés en ligne où le but est de réussir à s'introduire dans des serveurs spécialements prévus à cet effet, mais utilisant des failles communes dans beaucoup de systèmes. C'est en se mettant à la place de l'attaquant qu'on voit toutes les informations intéressantes que l'on peut laisser derrière nous dans notre dev qui sont autant de levier pour assister une intrusion. Elle donne l'exemple typique de laisser le mode debug activé en prod, qui souvent laisse une stacktrace par défaut, et parfois même affiche les lignes de code incriminées : révélant au grand jour les login/password de la DB.
Ce conseil est rarement appliqué, mais est pour elle primordial : il faut mettre la sécurité sur la table dès le début du projet et ne jamais l'oublier. Ne jamais se dire que cela viendra dans un second temps, plus tard, comme une couche de vernis à appliquer sur un projet terminé. C'est quelque chose qui se passe à tous les étages et qui doit être gardé dans un coin de la tête de tous les acteurs du projet.
Liste toutes les potentielles cibles d'attaque exterieure : les frontaux publics, les bases de données, etc. Y attribuer une valeur de criticité s'ils tombent et une valeur de confiance qu'ils peuvent résister.
Avoir identifié à l'avance les conséquences du fail des third parties sur lesquels on se repose. Que faire si cette brique disparait du système, si on ne peut pas leur faire confiance. Est-ce que tout est bloqué, ou est-ce qu'on a un fallback en mode dégradé ?
Très important ! Faites confiance à votre instinct. Si quelque chose vous parait étrange, il y a de fortes chances que ce ne soit pas normal.
Gardez les systèmes le plus simples possibles. S'ils sont déjà complexes à comprendre en situation normale, une situation irrégulière d'intrusion risque de passer inaperçue.
Augmenter la transparence. Ne développez pas de système en boite noire, partagez la connaissance du fonctionnement de chaque outil au sein de l'équipe. Plus il est connu comment les choses fonctionnent, moins on risque de créer des failles par ignorance.
Automatisez tout. L'erreur est humaine, et les taches répétitives doivent êtres automatisées, ici aussi pour éviter d'insérer une faille par inadvertance.
Logguez presque tout. En gros, il faut tout logguer pour pouvoir déceler des comportements suspects, mais il ne faut jamais logguer les informations critiques comme les mots de passe ou les numeros de carte de crédit ou de sécurité sociale.
Utiliser le principe du least privilege par défaut : bloquez l'accès à tout le monde sauf à une whiteliste plutot que d'ouvrir tout et ne blacklister que certains points d'entrée/utilisateurs.
Ne gardez que l'information dont vous avez réellement besoin. Inutile de remplir des To de logs qui n'ont aucune valeur pour vous mais pourraient en avoir pour un attaquant.
Utilisez du two-factor authentication. C'est très simple à faire et il y a plein d'APIs disponibles pour aujourd'hui.
Prévoyez un plan de recovery en cas de crash, ou en cas de suspiscion d'intrusion, mais surtout TESTEZ LE !
Préparez toute la paperasse légale, faites les bonnes dépositions auprès des bons organismes pour indiquer le type de données que vous stockez, pourquoi et pour combien de temps. C'est long et laborieux, mais le jour où vous serez au grand jour pour une faille, ça limitera les dégats sur votre image.
Si vous utilisez un framework, utilisez ses mécanismes de validation/sanitization des inputs, ne développez pas les votre.
Faites faire des tests d'intrusions de l'intérieur, avec la connaissance du système, mais aussi de l'extérieur, sans connaissance du système, pour avoir deux points de vue différents.
Faites attention aux alerts. Si vous avez des erreurs régulières sur votre monitoring mais arretez d'y prêter attention, vous ne remarquerez pas l'erreur importante le jour où elle aura de la valeur.
Et le plus important : devenez un ambassadeur de la sécurité passionné, pour en parler à vos utilisateurs et à votre équipe.
HumanTalks chez Adobe, dans leurs magnifiques locaux. La "sécurité" à l'entrée était un peu longue à passer du coup les talks ont pris pas mal de temps à se lancer, et le manque de pizza pour combler nos estomacs à la fin s'est bien fait sentir.
Néanmoins les présentations étaient globalement très intéressantes.
Cache Manifest
Présentation trollesque sur cache manifest. Le speaker annoncait que les systèmes de cache natifs des browsers et des serveurs (ie. les entetes de cache HTTP) n'étaient pas assez robustes et que le cache manifest était donc la solution pour parfaitement avoir la main sur ce qui était caché et ce qui ne l'était pas. Il est même allé plus loin en parlant des développeurs qui désactivent automatiquement le cache avec les outils de dev de Firefox et de Chrome et qui mettaient ses serveurs à genoux en démultipliant les requetes et que le cache manifest encore une fois était la solution à ces problèmes.
La suite de son talk annoncait que le cache manifest avait même un effet bonus qui permettait le travail online, et que c'était facile de détecter si le browser était offline ou non avec navigator.onLine...
Mouais.
Je ne suis pas du tout convaincu par ces arguments, les mécanismes de cache HTTP du browser et du serveur sont parfaitement adaptés à mon gout une fois qu'on comprends bien l'utilité de chaque header. Idem pour navigator.onLine qui a un comportement tellement différent selon les navigateurs que cela le rends inutilisable.
Finalement la conférence était plus un pretexte à troller Windows, IE, Flash et compagnie plutot que d'apporter des arguments interessants pour l'utilisation du cache. Le plus frappant était surtout que j'avais vu deux conférences à la QCon (Steve Souder et un mec de Hoodie, qui sont quand même des pointures) dire à peu près tout le contraire : que le cache est une bonne idée dans la théorie mais que l'implémentation rends la chose très fragile -propos confirmés par deux collègues d'Octo qui y ont touché de près-.
Git Deliver
git deliver est un ensemble de scripts git et bash qui permettent de faire des déploiements facilement directement depuis git.
L'idée est d'utiliser les remotes de git pour y pusher du code. Plutot que de faire un git push, on fait un git deliver en spécifiant la remote et le sha/tag/branch que l'on souhaite pusher.
Le système se charge ensuite de mettre le working directory dans un dossier accessible et propose tout un tas de hooks pour effectuer différentes actions après le push, avant de mettre dans le working directory, à la fin, etc. Comme par exemple passez un validateur de code, lancer un process de build, jouer les tests, mettre à jour une config, etc. Si un de ces scripts retourne une erreur, le déploiement n'est pas effectué.
Il garde un historique de n déploiement précédents, et la possibilité de faire des rollback facilement.
C'est au final assez proche d'un outil comme Capistrano, mais son avantage est qu'il n'a besoin que de git et bash pour tourner, donc extremement facile à mettre en place.
C'est parfaitement adapté pour des technos comme PHP qui peuvent s'executer direct depuis le working directory, ou un site purement front. Pour d'autres technos ça demande un peu de tweaks des scripts de trigger (mais ils sont fait pour ça). Si jamais l'archi nécessite des déploiements sur plus d'un serveur, ça devient rapidement moins adapté.
La vie d'un manager
Un ancien développeur nous a raconté son parcours à travers plusieurs boites de différentes tailles, et comment il est passé de dev à manager et ce que c'est que d'être manager.
Globalement, son image c'est qu'on a le cul entre deux chaises. D'un coté des devs qui veulent s'éclater sur des technos interessantes et de l'autre des boss qui veulent rentabiliser leurs applis sur des technos plus anciennes. Le role du manager est de réussir à comprendre les envie des deux, les langues des deux, et les faire se comprendre.
La qualité la plus importante pour lui est d'instaurer la confiance, notamment au travers des 03 qui doivent être honnetes (pas de manipulation), confidentiels (ce qui se dit dans un O3 reste dans l'O3) et dans lesquels le manager doit réellement écouter.
Son conseil principal quand on est un dev et qu'on devient manager par la force des choses, c'est de commencer par NE RIEN FAIRE. Le travers des jeunes managers est de vouloir organiser trop de choses et devenir donc trop rigides.
Son devoir est aussi de cadrer les développeurs : booster celui qui est paresseux, challenger celui qui est trop confiant, donner confiance à celui qui est trop timide, et calmer celui qui est trop casse-cou.
A coté de ça, il lui faut présenter le travail de l'équipe aux boss, dans des termes qu'ils comprennent, et parfois sur des trucs très simples (la liste d'acronymes sans fin et de termes barbares qu'on emploie tous les jours). Il donnait l'anecdote du chef de projet qui avait un jour conseillé que "si les développeurs se mettaient à un par poste plutot qu'à binomer, ils iraient deux fois plus vite...".
Sinon un dernier truc assez vrai mais que je n'avais pas remarqué, c'est qu'on a une certaine réputation d'enfants gatés : on travaille dans un milieu où il est facile de trouver du travail, en plus on fait un métier peu fatiguant (rester assis devant un écran, c'est pas bien crevant), on a du matériel haut de gamme et on se plaint encore de pas avoir les dernières version. Et en plus, on fait nos autistes à travailler avec notre casque sur les oreilles. Tout ça donne une mauvaise image pour qui ne connait pas le métier, il faut donc faire attention à ne pas alimenter les clichés.
Il a finalement terminé en disant que le management, c'était basé essentiellement sur des ficelles de manipulation ("comme toutes les relations humaines"), savoir qui est influent, ce qui l'intéresse, ce qui le touche, ce qui l'embete, ce qui lui plait, etc, de manière à créer une cohésion de groupe qui ne se serait pas forcément créée d'elle-même.
Les nouveaux outils Adobe pour les Web Designers
La dernière conf', vu qu'on était chez Adobe, était sur les prochains produits et évolutions de produit Adobe. Présenté par @mchaize qui bosse là bas et qui a pu nous donner une vision honnete de ce qu'il se passe chez Adobe.
D'abord, c'est des améliorations dans la prochaine version de Photoshop. Photoshop est un logiciel vieux, au lourd passif de codebase legacy, qui n'était pas du tout destiné à faire du design web mais qui a du évoluer au fil des ans. Ils font ce qu'ils peuvent pour aider le travail des webdesigners et webdeveloper.
Et deux nouvelles features très interssantes : la première étant d'avoir des objets liés entre plusieurs .psd et .ai. On peut importer un fichier vectoriel .ai dans un .psd et quand le modifie, celui le mets automatiquement à jour dans le .psd (du moment que 'toshop peut accèder au fichier sur le disque). Ainsi, plusieurs designers peuvent travailler sur le même projet du moment qu'il est découpé en plusieurs fichiers.
Deuxième feature, carrément plus intéressante pour un webdev comme moi : Il suffit désormais de nommer ses calques avec des noms de fichiers pour qu'ils soient automatiquement exportés. Par exemple, un calque banner.jpg sera exporté automatiquement dans le même dossier que le psd, et mis à jour automatiquement dès qu'il est modifié dans le psd. Plus de galère pour retrouver le ou les calques à exporter à chaque modif du psd. On peut même spécifier la compression et/ou la qualité (ie. une version à 200% pour retina, une à 100% sinon). Ca accepte du jpg, gif, png et svg.
Dernière amélioration, c'est le Project Parfait, un site internet d'Adobe où on peut uploader un psd et le voir en live dans son browser. On peut alors survoler les éléments pour voir directement leurs dimensions et leur positionnement sur la page. On a la liste des couleurs utilisées avec leur code hexa. Selectionner un élément de texte nous donne automatiquement les règles CSS associées (font, size, color, shadow, etc). Sélectionner deux éléments indique leur espacement, etc. Bref, un gain de temps sur toutes les fonctionnalités qu'on doit faire et refaire quand on doit intégrer un psd en CSS/HTML. Et le super effet kisscool bonus c'est que ça permet de faire directement sauter aux yeux les incohérences des designs ("pourquoi la marge est de 6px ici et de 4px là ?", "Pourquoi y a 12 gris différents et 6 polices ?").
J'ai aussi appris que photoshop possédait une API pour le piloter en headless avec plein de plugins dispos.