Aujourd'hui, je reviens du premier jour des conférences ParisWeb 2015, qui avaient lieu au Beffroi de Montrouge. ParisWeb c'est 3 jours de conférences, j'y vais presque tous les ans et je me suis rendu compte que même si j'avais pris des notes à la session de l'année dernière, je n'avais jamais pris le temps de remettre mes notes au propre pour poster sur ce blog.
Pour éviter que cela se reproduise cette année, j'ai décidé d'écrire mon résumé dès la fin de la journée. C'est à chaud, pas forcément bien construit, mais le voici:
Internet et libertés: pour un engagement des acteurs du numérique
La conférence d'ouverture commence directement par la Quadrature du Net, représentée par Adrienne Charmet. Adrienne nous rappelle que même si notre métier est de travailler dans le milieu du web, une grosse partie de notre vie privée se passe aussi sur le Web. Et même si on pouvait encore croire il y a quelques années qu'on pouvait faire du Web sans s'intéresser à la politique qui tourne autour, ce n'est aujourd'hui plus possible.
Il semble que le monde politique ne comprenne pas le milieu qu'il tente de légiférer, il essaie de calquer des modèles qui marchaient ailleurs sur le modèle international décentralisé qu'est le net. Les aberrations que sont les lois et leur absurdité nous saute au yeux (quand on nous dit qu'on va utiliser une adresse IP pour identifier une personne... Ça nous parait tellement gros et stupide et débile et absurde qu'on ne relève pas, et pourtant...), mais des lois, qui vont réellement influer sur notre existence et celle de nos enfants sont fondées sur ces incompréhensions.
Adrienne nous fait donc un rapide récapitulatif des 4 grosses lois qui touchent au numérique de l'histoire de France récente. Elle appuie sur le fait que nous sommes encore assez gentils aujourd'hui, à nous élever publiquement sur nos sites persos en changeant le fond en noir où en écrivant à quel point nous ne sommes pas d'accord avec ces projets de loi (ce qui est déjà pas mal), mais que nous pouvons aller plus loin.
Si on passe rapidement sur les 4 lois en question on a d'abord la Loi Renseignement, qui à la suite des évènements de Charlie Hebdo, légalise et élargit les pratiques des agences de renseignement. Ces pratiques vont bien trop loin, et il n'est pas possible d'accepter tout et n'importe quoi sous prétexte de lutte contre le terrorisme. Même si la loi est passée, elle est passée en douleur, et ce qui était présenté comme une loi de sécurité, est finalement devenue une loi de liberté publique.
Là encore, la vision du développeur que je suis, quand on me parle de surveillance de masse de la population, on a beau me dire que la surveillance sera effectuée en masse, sans ciblage, et uniquement sur les metadatas, au lieu de me rassurer ça m'inquiète encore plus. Il suffit qu'on dise "metadata" et "algorithme" à un politique et tout à coup ça parait moins dangereux. Que la surveillance soit effectuée par une machine codée par un humain ou par un humain directement, la seule différence c'est la puissance de calcul, qui est des ordres de grandeur plus importante par la machine.
L'argument évident du "si j'ai rien à me reprocher ça ne me pose pas de problème" m'énerve toujours autant. Déjà le simple fait de savoir que tu es surveillé va te faire agir différemment. Ce n'est pas parce que tu n'as rien à te reprocher que tu souhaites étaler ta vie privée, celle de ta femme et celle de tes enfants à n'importe qui. Et toutes les victimes des dictatures, elles non plus elles n'avaient rien à se reprocher, et pourtant c'était tellement plus facile quand on pouvait savoir ce qu'elles disaient à tout moment.
Bref, les arguments généralement évoqués pour faire changer les politique d'avis ont rarement à voir avec ces considérations humaines. Généralement on parle de profits perdus, de compétitivité du pays qui baisse, etc. On prends l'exemple des USA où les GAFA ont fait pression contre le gouvernement pour qu'il se rétracte de SOPA, arguant que si les citoyens savent qu'ils sont épiés, ils auront moins confiance, et que s'ils ont moins confiance ils achèteront moins. En France on argue que surveiller les communications va faire fuir les business qui se basent eux aussi sur la confiance. Ces arguments, aussi véridiques soient ils me dérangent toujours autant comme n'étant pas le vrai fond.
La prochaine bataille sera sans doute sur le chiffrement, qui est attaqué avec le sophisme idiot comme quoi le chiffrement est utilisé par les méchants, alors il faut interdire le chiffrement. Ça empêchera pas les bad guys d'utiliser du chiffrement, mais ça supprimera simplement l'anonymat.
On enchaine donc sur la neutralité du net, sur le principe fondamental de ne pas filtrer les paquets en fonction de leur type ou leur provenance. Envoyer du texte, des vidéos ou des mails fait appel aux même couches sous-jacentes, leur prix ne doit pas être différent. Et surtout, personne ne doit être en mesure de pouvoir payer plus cher pour avoir un accès privilégié.
S'ensuit le classique débat sur le modèle publicitaire en ligne. Celui qui dit que c'est mal de bloquer les publicités parce que c'est le seul moyen qu'ont les créateurs de site de gagner leur vie et qu'en faisant ainsi on les vole. Non, non et non. Je n'ai pas envie qu'un site vienne vomir sur mon écran ses publicités qui clignotent et font de la musique, m'empêchent de lire mon contenu, me piquent de la data sur mon forfait, ralentissent mes pages et vont sniffer mon parcours. Tout ça sans m'avoir à aucun moment demandé mon avis. Donc non, tes pubs tu te les mets où je pense et ne viens pas me faire la morale, merci.
C'est extrêmement intrusif, à la fois sur la partie visible de l'iceberg (une pub qui clignote et vient gêner ma lecture), mais aussi sur toute la partie qu'on ne voit pas et sur toutes les informations que le tracker récupère. La législation européenne qui demande qu'on prévienne quand un cookie est mis me fait bien rire quand on voit tout ce que les régies pubs enregistrent dans des formats bien plus difficile à supprimer que des cookies, sans qu'on ne leur demande rien.
BREF. Le but de la conférence d'Adrienne était de faire réagir, et là dessus je peux dire qu'elle a réussi, je pensais pas écrire autant sur le sujet. Elle nous incite à parler de ces sujets autour de nous, à notre famille, nos amis, nos collègues, poster des articles, montrer que c'est une préoccupation importante, pour que cela devienne une cause politique.
Dev front à mach 1 au quotidien
On continue avec une conférence ultra-rapide de Christophe Porteneuve (comme d'hab). C'était la suite du talk DevAvengers qu'il avait déjà fait à ParisJS, en version à peine updatée.
Je vous invite à lire le CR que j'avais fait sur le sujet car le fond est le même. Christophe nous incite à perdre le moins de temps possible, à profiter des outils qui sont là pour nous faciliter la vie.
À commencer par le browser, dans lequel on peut faire du live edit du CSS, JS et HTML et qui nous propose une completion dynamique de ce qui est chargé au runtime. Le tout marche même en mobile avec un simple câble USB. Ça marche même avec les fichiers minifiés/compilés du moment qu'on fournit les sourcemaps, et on peut même lier les fichiers chargés avec un workspace sur notre disque pour que les changements faits en live soient changés aussi sur disque. Bref, bonheur.
Les DevTools proposent des tas de fonctions comme ça qui ne sont pas forcément très connues, mais qu'on peut apprendre sur codeschool, youtube ou sur html5rocks. Il nous conseille aussi d'utiliser les DevTools dédiés à nos frameworks (React, Angular, Ember ou Redux.
Il nous montre ensuite BrowserSync qui utilise des websockets pour faire du hot-reload de CSS/JS/HTML et même de synchroniser browsers ensemble. Niveau build, lui qui chantait les louanges de Brunch il n'y a pas si longtemps s'est récemment converti à Webpack, cumulé à jspm. J'ai pas encore bien cerné ce que ces deux outils faisaient, il va falloir que je me penche dessus. Par dessus (ou à coté, en dessous, j'ai pas suivi) il propose de rajouter SystemJS qui permet de charger n'importe quel type de module (AMD, CommonJS, Global ou ES6) de manière compatible.
Les deux derniers slides sont allés très vite, j'ai pas eu le temps de tout noter, dommage c'était ceux qui m'intéressaient le plus. J'ai eu le temps de noter qu'il conseillait Chai, Sinon, Mocha pour les tests et BabelJS pour tester de l'ES6 dès maintenant. Ça tombe bien, c'est déjà ce que j'utilise.
CSS Grid Layout
On a ensuite enchainé sur une conférence technique sur le CSS Grid layout et sur cette spec qui n'est aujourd'hui accessible qu'en mode experimental dans Chrome. En quelques mots, l'idée est de pouvoir définir notre layout directement dans le CSS sans avoir besoin de gérer un markup à base de rows et de cols.
Ça va donc plus loin que les vieux float et leur hacks, les table (en HTML ou en CSS) ou même les flexbox. L'idée est de passer un display: grid à un parent, et ensuite tout un nouveau monde de grid-template-columns et grid-template-rows s'ouvre à nous sur les enfants.
La syntaxe est assez complexe et j'ai décroché de l'explication à plusieurs moments. C'est le genre de choses que j'ai envie de tester par moi-même plutôt que d'écouter en conférence. Tous les exemples qu'elle citait sont de toutes façons disponibles sur http://gridbyexample.com.
Au final j'en retiens qu'il y une toute nouvelle terminologie à apprendre pour ce système, mais qu'il permet de définir facilement un layout, même en RWD. Et il permet de définir combien de cells, en hauteur comme en largeur, chaque partie de notre layout doit prendre. On peut même positionner plusieurs cellules au même endroit et joueur sur leur ordre de stack avec zindex. On peut même faire de l'ASCII art pour dessiner notre layout, et une nouvelle unité de mesure, le fr, fait son apparition.
Ça semble extrêmement puissant, j'ai hâte que cela soit mieux supporté pour commencer à tester. C'est un grand pas dans la bonne direction. On s'affranchit des hacks de CSS pour avoir un vrai système de layouting, sans devoir noyer son markup sous un tas de classes pour gérer le RWD.
RGAA 3
Aurélien Levy de Temesis nous a ensuite fait un récapitulatif de ce que la norme RGAA 3 implique. Pour rappel, RGAA signifie Référentiel Général d'Accessibilité pour les Administrations.
N'ayant jamais du l'implémenter sur aucun site, les changement par rapport à la version précédente ne m'ont pas passionné.
OpenID Connect
François Petitit nous a ensuite parlé de FranceConnect et de son implémentation du protocole OpenID Connect. La présentation était très claire, mais on voit bien comment FranceConnect se place au centre d'une interaction où il est à la fois fournisseur d'identité et fournisseur de données.
L'exemple donné était le jeune parent qui souhaite faire une demande à la CAF pour son enfant. La CAF a besoin de son identité et de quelques infos supplémentaires pour faire les papiers. Deux organismes possèdent ces infos: les impôts ou AMELI. L'utilisateur peut choisir de s'identifier avec un de ces deux services, il rentre ses login/pass sur l'un ou l'autre et il est ensuite redirigé vers le site de la CAF avec tous les champs déjà remplis.
En arrière plan, FranceConnect s'est identifié auprès des impôts, a redirigé l'utilisateur, effectué un échange de tokens et récupéré les infos demandés. Ça parait super simple et j'ai hâte que cela arrive plus fortement dans nos administrations.
Webperf 2.0
En début d'aprem, Stéphane Rios de Fasterize nous a fait un état des lieux de la Webperf aujourd'hui. Je m'attendais à apprendre pas mal de choses et j'ai été plutôt déçu. Rien de bien neuf sous le soleil, surtout qu'on avait déjà eu une conférence sur le sujet l'année dernière qui disait à peu près la même chose.
Je sais bien que les bonnes pratiques Webperf ne changent pas tous les ans, et heureusement, mais je m'attendais à en ressortir avec plus d'éléments. On a commencé par voir pas mal de graphiques pour voir pourquoi la webperf c'était bien, puis on a attaqué les points pratiques.
J'ai pas été tout à fait d'accord avec tous les points soulevés d'ailleurs. Dire que la concaténation de CSS est contre-productive car il a un client qui a inliné l'ensemble de ses fonts en base64 dans un fichier, ou qui a atteint la limite des sélecteurs CSS de IE9, c'est se tromper de bataille. La concaténation de CSS est pour moi une bonne chose, à condition qu'on ne mette pas n'importe quoi dedans comme dans cet exemple.
J'ai pas réussi à suivre l'argument qu'il avait contre le lazyloading, comme quoi cela cassait le parseur HTML spéculatif, ni pourquoi mettre les js en bas de page ou minifier ses assets était inutile.
Ensuite on est parti sur quelques techniques de sioux pour charger des fonts en évitant le FOUT (à base de loadCSS), de mettre le CSS du critical path en inline dans le head ou encore de jouer avec les pre-fetch.
Un petit rappel rapide que HTTP2 ça va être mieux dans l'absolu, mais qu'on n'y est pas encore et que ça va casser toutes les bonnes pratiques qu'on connaissait (qui deviendront sans doute même contre-productives).
Point intéressant sur webp, qui est un format d'image supérieur à jpg, mais qui nécessite un lecteur spécial hors browser si les utilisateurs veulent sauvegarder l'image pour la voir plus tard. Coté compression, mozjpeg et lossygif sont toujours les meilleurs.
J'attendais peut-être un peu trop de cette conférence, mais je n'ai pas appris grand chose de neuf. Comme toujours il n'y a pas de silver bullet, plein de choses fonctionnent bien, mais même les bonnes pratiques les plus éprouvées méritent d'être testées en condition réelles sur chaque projet pour voir ce qui est vraiment pertinent.
Creating a culture of code quality
David West de Pinterest nous a ensuite parlé de code de qualité. Sortant d'un an et demi d'Octo, je suis assez familier avec le sujet. Là encore, je n'ai pas appris grand chose, si ce n'est des arguments intéressants pour convaincre d'autres personnes des bienfaits du code de qualité.
Tout d'abord sa définition de la qualité avec laquelle je suis tout à fait raccord:
Quality is pride of workmanship
Quand le code est de qualité, on lui fait confiance, et quand on fait confiance au code on peut le modifier facilement et le faire évoluer rapidement.
Chez Pinterest, ils ont des linters et des tests partout. Ils peuvent refactorer sans crainte et sont même allé plus loin en écrivant un script qui modifie automatiquement leur ancienne codebase en React, et en s'assurant que tout marche bien car les linters et les tests passent toujours!
Il nous a parlé de flow, qui est un type checker statique. Je ne connaissais pas et je vais me pencher là dessus, ça me semble très intéressant. Coté CSS il nous parle de csslint qui permet de checker les propriétés inconnues (souvent dues à des fautes de frappe), les sélecteur vides (sans doute du à un refacto), les propriétés connues pour causer des soucis de perf ou d'accessibilité ou tout simplement pour faire respecter les conventions.
Coté Javascript, ils utilisent eslint et Jest qui utilise le virtual DOM de React et qui du coup leur permet de faire des tests qui vont encore plus vite.
REX Styleguide
On a ensuite eu une présentation du chef de projet front de la refonte du site Relais & Chateaux sur l'importance du styleguide dans une équipe.
Ce document (sous forme HTML/CSS/JS) permet de partager au sein de l'équipe, et avec le client le langage visuel du projet. Il évolue dans le temps et sert à la fois de référentiel et de documentation.
Pour ce projet, ils ont suivi le principe de l'Atomic Design et le document présente donc les différents atomes, leurs groupements en molécules et des exemples d'organismes et de templates.
Il fournit des exemples de code HTML avec le rendu à coté ainsi qu'une liste exhaustive des couleurs et des fonts utilisées, avec un nom unique pour chacune et une représentation de celle-ci. Cela permet à toute l'équipe de parler le même langage.
Êtes-vous au top ?
Et la conférence WTF de ParisWeb, celle qui ne parle pas de Web mais qui en reste extrêmement intéressant quand même. Ici, Nattacha Hennocq d'Orange, nous explique comment rentrer dans un mode de pensée qui favorise la créativité.
On peut par exemple faire des side projects à coté, pour tester des choses nouvelles, mais bien souvent on ne termine pas les side projects commencés. On peut faire des choses plus simples chaque jour par contre, comme essayer d'écrire de la main gauche si on est droitier ou chercher à apprendre quelque chose de nouveau mentalement ou physiquement.
Cela peut être aussi simple que se forcer à se souvenir d'une réunion, qui a dit quoi. Ou compter les mots quand on lit, dessiner les réunions, bref faire des choses pas très compliquées mais qu'on ne fait pas, bien qu'elles soient à notre portée.
On peut se forcer à penser à des scénarios absurdes, écrire des listes de choses sur un sujet précis, faire une mind-map de n'importe quoi, se donner quelques minutes pour dessiner 30 symboles différents dans des cercles, cartographier un problème complexe qui ne comporte pas forcément de solution, mais juste se forcer à trouver des liens et des imbrications.
Beaucoup plus dur c'est faire attention à nos biais cognitifs, qui par définitions nous sont inconscients. Les deux plus flagrants sont celui qui nous fait penser que ce qui me ressemble est mieux, ou que les effets néfastes d'un changement surpassent ses effets positifs.
Ne pas hésiter à montrer son travail, à le partager, à en discuter. Avoir conscience de soi, de ce que l'on fait, de ce que l'on va faire, même dans les quelques secondes suivantes.
J'ai bien aimé l'idée et le coté décalé du reste des autres conférences de la journée.
Hybride
La dernière conférence de la journée a été une des très bonnes surprises. Un bon overview de ce qu'est le web hybride aujourd'hui, les différentes technos et leurs différences. Je me souviens avoir vu un talk à la TakeOffConf qui faisait un état des lieux des bases de données NoSQL général dans le même genre et c'est vraiment un type de talk que j'affectionne beaucoup.
L'histoire du monde hybride a commencé avec Phonegap, qui s'est ensuite fait racheter par Adobe. Puis Facebook a annoncé que le HTML5 était mort et qu'ils partaient en tout natif.
En fait, le soucis du HTML5, c'est qu'il n'existait pas de SDK pour faire des applis mobiles, alors que ceux-ci sont bien présents en iOS et Android. Pour un développeur hybride, il faut partir de rien.
Il y aujourd'hui pas mal de frameworks pour aider à faire ça, avec des méthodes très différentes. D'un coté on a les applications hybrides à base de webview avec HTML/CSS/JS et de l'autre on a celles qui ne font que du JS qui pilote des composants natifs (comme ReactNative). Cette deuxième version est encore assez jeune donc peu stable encore mais prometteuse car elle a l'avantage de ne pas demander de recompilation de l'app.
Coté Webview, il nous a parlé rapidement de Famous, qui est un moteur de rendu à base de CSS Transform3D. Il n'y a aucun élément de UI avec, c'est plutôt réservé à des applications événementielles. On a sinon Onsen UI, qui est le "Bootstrap du mobile".
Mais surtout on a Ionic, qui est un mix entre Angular, Gulp, Sass et Cordova (pour packager le tout en une application standalone). Le projet parvient à lever des millions, est bien suivi, avec une doc bien complète, une communauté active et un écosystème de tooling complet. Il propose même des thèmes qui s'adaptent au device sur lequel ils tournent (iOS ou Android).
Ionic ne supporte que iOS6+ et Android 4.1+, mais avec les dernières versions d'Android il profite de la mise à jour automatique de Chrome. Pour accéder aux fonctionnalités natives des téléphones, il propose son propre système de plugin (qui nécessite de coder la fonctionnalité en iOS ou en Android, et ensuite d'y déléguer l'appel depuis l'appli Ionic).
Aujourd'hui, Ionic est le clair vainqueur du monde de l'hybride, mais si un autre système voyait le jour en remplaçant la couche Angular par du React, il lui prendrait sans doute sa place.
Conclusion
Au final je ressors mitigé de cette première journée de ParisWeb. Je me souviens de mon premier ParisWeb en 2006, où j'avais appris plus en deux jours de confs qu'en 6 mois de veille technologique. Je suis revenu chaque année depuis (sauf en 2012, où je vivais en Nouvelle-Zélande). Je m'étais déjà fait la réflexion l'année dernière, mais c'est encore plus flagrant cette année : je n'ai pas le sentiment d'avoir appris grand chose cette année.
Sans doute parce que j'ai plus d'expérience et que du coup je prends plus mon pied en nouvelles découvertes dans des confs comme dotScale, qui touche quelque chose d'encore neuf pour moi.
Je pense que je ne suis plus forcément la cible de ParisWeb, ou que j'ai mal choisi mes conférences aujourd'hui mais entre celles que j'avais déjà vu et celles qui ne m'ont rien appris, j'ai plus autant cette magie de l'événement qui reste en moi après la fin de la journée.
Mais il reste deux jours d'événement, et j'ai quand même pas l'intention de les rater :)
Note: For this post, I'll try to write in English. I'm now working in an english-speaking company and I'm already writing emails in English to give feedback on the HumanTalks sessions. I'm not used to write such lengthy posts in English, though. Hopefully I'll get better at it the more I do it.
This session occurred at Prestashop new office. Right near the Gare St-Lazare in Paris, the office was brand new and really nice. For those that don't know, Prestashop is the "Wordpress of e-commerce". They did a quick recruiting speech at the start of the meetup, and they are looking for devops and front-end devs.
OpenID Connect
The first talk was from my former coworker and mentor, François Petitit from Octo. He talked about the France Connect initiative, pushed by the French government to have some kind of state platform where all administrations could exchange data in a uniformed way.
This ultimate goal is, as a citizen, that you do not have to fill the same form asking for your name, address and social security number every time you apply to a state service. Also, this will remove the burden of having to provide all the necessary papers to an administration. With the France Connect initiative, your profile will be centralized and shared between all the state instances and they could securely get documents from one another.
François worked on the main bricks of implementation and on one of the first real-life implementations. France Connect wraps several identity providers and identity clients. Each brick can be either provider or client.
This mean that one brick could act as a provider of identity, responding to requests of other bricks with data about a citizen. It could also act as a client, asking data about a citizen to other bricks of the network.
The application on which François worked was both, so he had to implement both sides. The protocol used behind the scenes is OpenId Connect which is already used by Google, Microsoft or Paypal. This must not be confused with OpenId.
OpenId was the ancestor, but it has now be deprecated and OpenId Connect is the new standard, which is based on OAuth 2. The OpenId group is an official group that can certify libraries and implementations of the protocol.
The OpenId Connect norm was finalized in 2014, with already some implementations in production. When you sign-in with Google on any site, this is using OpenId Connect. The spec defines ways to normalize the way sessions across several sites are handled, as well as how multi-identities on one site should be treated.
François told us about the real-life scenario they were implementing. Let's imagine you want to apply for a scholarship from you city website. Here, we are dealing with three actors. You, as the main user. The city, through its website. And an identity provider (to tell the city who you are).
You start by navigating to your city website. It asks for identification. You can choose which site can give your identification from a list (it could be the social security, or the tax department). You're then redirected to the website you choose. You login there and you're automatically redirected back to the initial website (the city one), with all your information already filled in. The needed data was send by the social security/tax department you logged to.
OpenId connect defines a set of standard to define a person, what fields should be used. This makes exchange between different providers easier.
The current landscape of OpenId is full of libraries, used by big names and most of them are officially certified. You need about 3 days of work to be able to consume information from a provider. To become yourself a provider this can take a bit longer. From their experience, what took the most time was not the implementation it self, but being able to get access to the data in the first place.
Nevertheless, it is important to note that the OpenId specs are very large and some areas are not clear or you can do the same thing in very different ways. This results in various client/provider implementation handling thing so differently that they are not really compatible in the end.
Make your business SPOF-less
The second talk was from Alex Centar, one of the founders of Jumboweb, a French web agency of 4 people. They mostly do web and mobile custom applications. Their company is growing, which makes them have less and less time. They decided to start working remotely and gave us some feedback on how to make it go smoothly, even when something goes wrong.
They realized that they had a lot of SPOFs in the way they did things. When you start looking for SPOFs, you find a lot of them. The A/C can be a SPOF during summer. Internet access and electricity certainly are. And each of the 4 members of the company are SPOFs also if they disappear.
They started to count how many projects would fail if one team member had an accident? 1, 2, 10? And would it put the whole company down? They had to find a way to limit that.
First of all, they added fallbacks to the tools they often use. Having a fixed telephone line in case the mobile one stops working. Backup all their work from their laptop machines to a decentralized server automatically, in another location.
Then, they put all the passwords in a Keepass file, shared in their Dropbox. They gave access to the Calendar and Financial information to everybody. Any tool one of them was using was also opened so anyone could use it, even if they did not need it at the time. This includes TODO lists, bug trackers, Evernote, Slack. The goal was that everybody had access to the same information.
Then, they started sharing their work. They wanted to do more than simply working together, they wanted to be able to have each of them able to work on all projects easily.
They do systematic peer programming, so that the code of one project is not in only one person head, but at least in two. They do code review on everything, at first with only the two developers involved, then with all the team. That way, everybody works on every projects, and when a critical bugfix is required, people at least know where to start. But still, they keep only one privileged interlocutor for each project when speaking with their customers. They kept that because it is better for the customer to always have the same person they are talking to.
They found that this was providing the best quality of their work. Everyone is able to work from anywhere, everybody learns, seniors can teach juniors and no project is ever stalled.
But our jobs requires that we do a lot of technology watch to keep us afloat in this ever-changing world of web development. So, to be sure that all of them had enough time to read and learn while keeping the company running they created a kind of reward system.
Each worked day earn employees "free time" that can be used for technology watch without pressure. They did the math and know the minimum number of worked hours that will keep their company running. Anyone has a counter of free time available and you're encouraged to use it. I must admit I did not completely understood the algorithm used here, but they did an open-source webapp to keep track of all the time spend on work and gained (they use the Freckle API to keep track of time).
They decided that the goal of their company was the well-being of the 4 of them. More time for family, more time for personal stuff, while still earning enough money to live with enough comfort. They get payed by the hour, they know what the budget for a project is, so they can easily know when they're making a profit and when they're not.
Mobile development recap
The next talk was the story of David Wursteisen that wanted to create a native app. He followed the advice from John Carmak (the creator of DOOM), who said that it is easier to launch application on small platforms, because you have less options and less things to consider.
So David started creating it own game on an Android device, but he soon discovered than creating a game is much more difficult than he initially thought. You need to be good on a large set of skills.
So he started working on a simple app instead. He wanted an app that automatically set its phone to vibration mode when he was at work, maximum volume when at home, and silence mode at any other moment.
He first downloaded an existing app that did the same thing, to see if the idea was actually useful. The test was positive, but the app he tested had much more features than he really needed. So he started working on its own app, with only one feature, but one he needed.
Before coding anything, he started testing the UI with slides. He showed it to several people, but nobody could understand how it worked. He tried with icons instead of text labels, people reacted better. Then he did a quick paper mockup and tested it on a few friends. He managed to simplify the UI still a bit more.
So he started coding. At first he followed the Google tutorials and guidelines, but he found them to be overwhelmingly complex and finally used tools he already knew : IntelliJ and Java. He lost a bit of time understanding how to register its app on the Play Store, but finally it was released.
He then discovered than debugging an app in the wild is hard. When the app crashes on one of your user's phone, you have no way to access the stacktrace to debug (unless the user clicks on "Send the crash report". But nobody does that). He had to release a new version that included a crash reporter built-in.
The app was working quite well, he now had to find a price to sell it. He chose 0.79€. Now, it was time to make discovering of the app in the Play Store easier. At first it was quite hard to find the app (it is named Georing, but the Play Store suggested Goering instead. Not very helpful). He tried the good old method of contacting (online) newspaper to talk about its app, but none never replied.
He increased the price. 0.79€ seemed to cheap, so he thought that by increasing it, it would show that the app was of good quality. It actually did not change anything on its number of download. He finally decided to put it completely free (and here an important note, it is not possible to revert this choice. Once an app is set as free, there is no way to set a price for it later, so be careful when making that choice).
This change actually paid off (no pun intended), as he got 15 new downloads! He then tried to make it more known by using Twitter, talking about it in meetups, to his friends and family. He considered adding ads inside the app at one point, but finally decided not to.
In the end, I really liked this talk because it shown the whole journey of someone who never created a native app to one that is available on the store. He did not spend too much time on the technical side but much more on all the questions you have to ask yourself when doing this kind of thing.
This was a very honest explanation, and I liked the posture he chose regarding price, ads, iterations and the MVP process.
Tails
Last talk was by Jean Baylon, and about the Tails Linux distribution.
The goal of the distribution is to be anonymous when going on the Internet. It lets journalists pass through the multiple layers of censorship. It actually is part of the base tech package of Reporters Without Borders and was also approved by Snowden.
Their are currently about 11k users (and one can wonder how we can get this number if the goal is actually to stay anonymous, maybe number of downloads?) and there are about 20 developers committing on the project on a regular basis. It got part of its funding from other projects in the field, like TOR, Debian or the Freedom of Press Foundation.
Tails should be used when you are doing something out of the ordinary. And it is not enough to protection your anonymity. If you use Tails to buy something on Amazon with your credit card and have it delivered at your place, it won't help.
What it does is having TOR and Firefox installed and configured by default. It also has an encrypted pidgin and automatically spoof the MAC address. It is loaded with aircrack ng to check the current wifi security and reliability and also contains a bitcoin wallet.
You can run it from a USB key, without installing anything, with absolutely everything loaded in memory. It means that it won't even leave a file on the file system. Its UI can mimic common windows UI in case you have to load it from a public cyberspace. You can even use a virtual keyboard that would bypass any hardware key logger that might be present in the keyboard.
Nice and interesting project, whose internal tools are now more and more common practice in the more popular distributions.
I'll just finish on a small note. The simple fact that you searched for it on Google would put you on some kind of list somewhere in the NSA files. And coming to a meetup that talked about it as well. And maybe just even reading this blog post.
Conclusion
Nice and varied talks as usual, honest feedback about projects people actually did. That's why I like the HumanTalks so much.
Pour le mois de Juin, c'est Viadeo qui a pu nous accueillir. On avait 120 personnes inscrites, mais on était dans les faits plus proches d'environ 90 sur place. Viadeo nous a accueillis dans leur cantine et on a pu ensuite se régaler de ce que leurs cuistots nous avaient préparés.
Une session formidable, avec 4 talks passionnants pour contrebalancer la session du mois précédent qui m'avait un peu laissé sur ma faim. Cette fois on a parlé de RAML, de sociologie, d'UX et d'école de développement.
Ce CR comporte des annotations directement par Sylvain qui m'a soumis une Pull Request. Si vous aussi vous avez des corrections ou des points à apporter, je vous invite à faire de même, c'est grandement apprécié.
RAML
Yves Pasteur nous a parlé de RAML, un format pour spécifier ces APIs. Le formalisme du langage permet ensuite d'automatiquement générer la documentation qui va avec et pourquoi pas de la tester automatiquement.
On le sait tous, le gros problème de la documentation c'est qu'elle n'est jamais à jour avec le code. Tout simplement parce que c'est une tâche pénible et qu'on la néglige bien souvent. Ici, RAML se situe dans la même lignée que les annotations, en permettant de spécifier son API en même temps qu'on la documente. Spec et doc ne font qu'un.
RAML en terme de syntaxe, c'est du YAML, et ça veut aussi dire Restful API Model Language. En gros, on peut définir plusieurs versions de notre API, et pour chacune d'elle spécifier son url, ainsi que les endpoints possibles. On peut bien sûr faire une hiérarchie de endpoints qui reflètent la hiérarchie de nos url, et pour chacun des niveaux indiqués une petite description ainsi que les paramètres attendus.
Tout ceci sera alors utilisé pour générer automatiquement la documentation à la manière d'un Swagger. Pour chacun des endpoints on peut bien sûr spécifier des actions différentes selon le verbe utilisé, ainsi que la liste des paramètres attendus (qu'ils viennent de l'url, d'une query string, d'un body ou même de headers).
Pour chacun de ces paramètres, on peut spécifier le type attendu, s'il est obligatoire ou non, et faire de même pour le type de réponse attendue ainsi que le code retour. On peut aussi bien sûr spécifier des exemples pour chacun d'eux. Pour ne pas écrire des fichiers trop énormes ont peut bien sûr utiliser des templates et inclure des fichiers.
Tout ceci permet de définir notre API dans un format standardisé. Il existe des parseurs de RAML dans plusieurs langages et déjà quelques outils qui en tirent partie (génération de docs, tests d'intégration, voire génération d'un CRUD simple).
Il y a plusieurs projets collaboratifs pour définir la spec RAML de certaines API bien connues comme Facebook, Twitter ou GitHub. Il n'est pas encore possible de détecter automatiquement quand une de ces API a ajouté de nouveaux endpoints grâce à RAML, mais on peut déjà tester si certains retours ont changé ou si certains endpoints ont disparu.
Je ne connaissais pas du tout RAML mais je préfère largement ce formalisme de spec d'API que de faire un gros fichier doc, car c'est parsable et qu'on peut donc à terme le tester et générer la doc qui va avec.
Sociologie appliquée aux développeurs
Sous ce titre assez étrange, c'est Sylvain Abélard qui nous a fait un talk ultra-touffu sur une douzaine de théorèmes et effets sociologiques qu'on est forcément amenés à croiser dans le monde professionnel.
Beaucoup d'humour et passionnant, je vous recommande chaudement de regarder le talk mais surtout d'aller lire davantage d'informations sur chacun de ces effets.
Sylvain est développeur, mais quand sa boîte a commencé à grossir et qu'il a dû embaucher d'autres développeurs il s'est retrouvé à aussi devoir les manager. Mais lui il code, il ne sait pas forcément comment gérer des humains. Du coup, il a fait comme pour tout nouveau framework qu'il ne connaît pas : il a lu la doc. Et c'est donc après en avoir appris un peu plus sur la manière dont fonctionne le cerveau humain et particulièrement dans un contexte d'équipe qu'il nous a fait cette liste, NdSAb: pour vous et votre chef[^why_socio].
On a tous déjà remarqué[^other_talks] que plus une boîte grossit et plus on a l'impression que les gens vont dans des directions différentes, que tout le monde pense avoir (ou pas d'ailleurs) l'intérêt de la boîte à cœur, mais que pour autant tout le monde n'est pas aligné. Et le pire c'est que la majorité du temps, ce n'est même pas de la méchanceté, encore moins de l'incompétence, juste des raisons différentes que chacun ne peut ou ne veut pas forcément exprimer.
Pour mieux comprendre tout ça, Sylvain a donc posé des mots et nommé une douzaine d'effets, principes et théorèmes.
Celui-ci est simple, et on le croise tous autour de nous. C'est tout simplement que le principe même de hiérarchie et de promotion fait que des gens incompétents se retrouvent à des postes hauts placés.
Comment ça se fait ? Tout simplement parce que quand on est bon à ce qu'on fait, on obtient une promotion pour accéder à une position plus importante NdSAb: ou pas[^careertips]. Au début on n'est pas très bon dans cette fonction, parce qu'on y débute, mais on finit par apprendre. Alors on monte encore d'un échelon, et encore d'un. Mais à un moment, on finit par ne plus monter, parce qu'on a atteint le maximum de ce qu'on était capable de faire _NdSAb: je crois que tout le monde peut progresser, attention au "fixed-mindset"[^fixedgrowthmindsets]
Sauf qu'on n'est jamais rétrogradé. On ne redescend jamais (disons très rarement)[^stepping_down] au poste précédent, celui où on bon. Cela signifie qu'au bout d'un moment, chacun se retrouve en poste à un poste où il n'est pas bon.
Du coup, il faut être plus conciliant avec les "incompétents". Ils ne sont peut-être pas bons à ce qu'ils font en ce moment, mais s'ils sont là c'est parce qu'ils étaient très bons à autre chose avant.
... Ou que VOUS ne voyez pas à quoi ils sont compétents car VOUS êtes incompétent ! C'est à dire que vous êtes sujet au...
Celui-ci, je l'adore. J'ai découvert la sensation il y a quelques années mais je ne savais pas qu'il avait un nom (et c'est d'ailleurs Sylvain qui m'avait filé le lien vers plus d'explication).
Cet effet explique simplement que celui qui sait sait qu'il ne sait pas, alors que celui qui ne sait pas ne sait pas qu'il ne sait pas. En d'autres termes, si vous êtes compétent dans un domaine, vous savez juger vos limites, vous savez ce que vous savez faire, vous savez ce que vous ne savez pas faire, vous voyez la réelle étendue du problème. Alors que celui qui est incompétent sera incapable de juger la réelle difficulté d'une tâche. Parce qu'il ne s'y connaît pas vraiment, il ne verra pas ce qu'elle implique réellement et elle lui paraîtra simple car il ne verra pas toute la complexité cachée que vous pouvez voir.
C'est malheureusement pour ça que les incompétents paraissent sûrs d'eux[^dumb_sure] mais que les gens compétents paraissent douter.
Le nom vient d'une usine de Chicago dans laquelle on a voulu étudier la productivité des ouvriers.
Attention, l'anecdote ci-dessous est inexacte. Lisez la page Wikipedia pour en savoir plus. Je laisse cependant cette version car elle est simple, amusante, que c'est celle de la vidéo, et qu'elle montre bien que Sylvain s'est fait avoir par un Woozle Effect :D
Un psychologue a cherché à savoir si le degré de luminosité de la pièce où ceux-ci travaillaient avait un impact sur leur productivité.
Du coup, il a essayé d'augmenter la lumière pendant une semaine pour voir. Et il s'est avéré que oui, les ouvriers produisaient plus. Du coup, la semaine suivante il a encore monté encore plus la lumière et la productivité s'est encore accrue. Alors il a tenté de la pousser au maximum, au point de les éblouir et oui, ça a encore mieux marché.
Du coup, il s'est douté que quelque chose ne tournait pas rond dans son expérience alors il a essayé de baisser la luminosité, en dessous du seuil initial et là encore la productivité était meilleure. Complètement surpris, il a remis la lumière à son état initial et là encore, productivité améliorée.
Il n'y comprenait alors plus rien. Jusqu'à ce qu'il réalise que le changement de lumière n'avait aucun impact sur la productivité de ses employés. C'était tout un tas d'autres facteurs : avoir son patron qui surveille, avoir une mesure à atteindre, changer les conditions du bureau, etc qui influençait leur travail.
Le Hawthorne effect indique juste qu'en modifiant quelques éléments, aussi subtils que changer son bureau de sens ou travailler dans un nouveau lieu donne de nouvelles idées, change les habitudes et permet de travailler différemment, bien souvent avec un effet bénéfique.
Celui-là est moins connu. On le retrouve quand on pose une question à quelqu'un mais qu'on à l'impression qu'il répond à coté. On demande de l'aide à quelqu'un pour résoudre le problème X, mais lui nous donne la solution pour résoudre le problème Y parce que de son expérience, la cause du problème X est bien souvent Y, alors il souhaite nous faire gagner du temps.
Sauf qu'en n'expliquant pas le processus, on à l'impression que l'autre ne comprend pas notre problème, ou s'en fout, et ne nous aide pas. Et c'est d'ailleurs tout à fait vrai, on n'aide pas quelqu'un en lui donnant la solution à un problème qu'il n'a pas.
Cet effet est assez simple et indique que parfois, regarder par dessus l'épaule de quelqu'un quand il fait une tâche peut avoir un effet bénéfique, parfois cela peut avoir un effet néfaste. En effet, quand une tâche est simple, on procrastine, on glande un peu à la faire, du coup si on est surveillé, on est moins dispersé. Au contraire, si la tâche est complexe, surveiller quelqu'un va simplement le ralentir, voir l'empêcher complètement de la réaliser.
Le mieux est simplement de demander de temps en temps où l'autre en est, mais pas trop souvent.
Sous ce nom compliqué se cache simplement l'effet de lourdeur hiérarchique. Plus un groupe est gros, moins il est efficace car il faut gérer, en plus de la tache à exécuter, l'overhead de la coordination du groupe. De plus, avec le grossissement d'un groupe arrive aussi la dilution de la responsabilité.
Quand on est seul, si quelque chose ne marche pas, c'est forcément qu'on a merdé. Même quand on est que 2 ou 3, on ne peut rebalancer la faute sur les autres tout le temps. Par contre quand on commence à être nombreux, si quelque chose foire, c'est jamais directement de notre faute, c'est un peu la faute de tout le monde, du coup c'est la faute de personne. Et puis même si c'était de votre faute, il y a peu de chance qu'on puisse remonter jusqu'à vous.
Ce genre d'ambiance plombe complètement la motivation, car de la même manière que vous ne pouvez pas être blâmé, vous ne pouvez pas non plus être récompensé. Si ce n'est la faute de personne quand ça foire, ce n'est grâce à personne non plus quand ça réussit.
Les grands groupes aiment aussi les process, les cadres, les règles. On arrive facilement et paradoxalement à de gros problèmes ou inadéquations ne résultant que de l'application de petites étapes qui, prises individuellement, ne montrent aucun souci en elle-mêmes. Sans réel coupable, ils peuvent aussi perdurer d'autant plus longtemps.
Pour contrer ça, laissez de la liberté à chacun, limitez la hiérarchie au maximum (3 couches MAX).
Woozle effect
Le principe de la rumeur. Comment les rumeurs et les légendes urbaines se forment. Comment à force de répéter et d'entendre tout le temps les mêmes fausses informations on fini par les assimiler comme des vérités et les répandre nous-mêmes.
Vérifiez vos sources, attention aux "untel à dit ça", méfiez-vous des vérités générales, entendre souvent la même chose ne veut pas dire que c'est vrai (ex: la pub)...
Ou comme dit dans HPMOR (Harry Potter et les Méthodes de la Rationalité) :
"Que croyons-nous et pourquoi le croyons-nous ?"
"L'absence de preuve n'est pas une preuve d'absence."
Si quelqu'un dans votre équipe est très compétent et qu'il est capable de faire un certain nombre de tâches plus rapidement que n'importe qui d'autre, il y a de fortes chances que vous alliez toujours le voir pour faire ces tâches.
Dans un premier temps, cette personne, exposée à davantage de problèmes et de solutions, deviendra une "Superstar".
Mais dans une version plus perverse, cette personne finit par ne plus avoir le temps de faire ses autres tâches, voire si vous êtes plusieurs à aller le voir, il n'a même plus le temps de faire son travail du tout. Alors que pendant ce temps tout le reste de l'équipe, on ne lui demande rien.
Dans ce cas, il faut faire faire monter en compétence et déléguer. Machin est peut-être plus rapide, mais si vous l'étouffez à toujours venir le voir, il finira par partir. Laissez Machin déléguer et apprendre aux autres, qui seront certes moins rapides mais qui peuvent être plusieurs à exécuter ces tâches en parallèle et vous désengorgez les process.
La solution n'est pas de virer ceux qui sont trop lents, et de ne garder que des experts d'un domaine. À la place il faut faire monter tout le monde en compétence sur tous les sujets, pour avoir une équipe pluri-disciplinaire.
C'est aussi plus facile pour gérer les maladies et les congés :)
Celui-là, je le connaissais pas ! L'histoire veut qu'un groupe de pêcheurs en haute mer revenait régulièrement au port avec de grosses cargaisons de sardines. Mais après un si long voyage, leurs sardines n'étaient plus forcément très fraîches. Et les sardines peu fraîches se vendaient moins cher que les sardines fraîches.
Pourtant, il y avait toujours un bateau qui avait des sardines plus fraîches. Son secret était qu'il gardait avec ses sardines un poisson-chat, prédateur des sardies, ce qui les tenait en mouvement.
L'émulation d'avoir un plus gros poisson avec elles, la compétition pour ne pas se faire manger les forçaient à rester alertes. Dans le monde du travail, cela ne signifie pas de mettre un tueur sanguinaire au sein de votre open-space pour motiver tout le monde. Non, l'idée est de mettre un "maestro", quelqu'un de plus balaise dans l'équipe pour créer une émulation encore une fois faire monter en compétence le reste de l'équipe autour de lui.
"Bidule qui est d'habitude toujours sympa, là il s'est vraiment comporté comme un salaud".
"Machin qui est d'habitude très con, là il a dit un truc super intelligent".
Ces deux phrases sont des exemples de l'attribution error. Méfiez-vous des phrases qui contiennent toujours ou jamais. Personne n'est toujours comme-ci ou jamais comme-ça. Vous avez sans doute mis une étiquette sur une personne par rapport à la manière dont elle s'est comportée la première fois que vous l'avez rencontrée et vous avez continué à la voir de cette façon par la suite.
Oubliez vos a priori, regardez ce que font les gens maintenant, pas par rapport à ce qu'ils ont fait avant. Et surtout, ne jugez pas hâtivement, et essayez de déchiffrer le contexte avant de parler.
Pas l'effet Bonaldi, mais celui qui dit que quand on montre aux autres comment faire, ils apprennent mieux que quand on leur dit comment faire. Surtout si la tâche est chiante, il vaut mieux la faire une première fois avec la personne qui va devoir la faire ensuite pour lui montrer et que ce ne soit pas toujours les mêmes qui fassent les tâches rébarbatives.
Celui-ci je ne suis pas sur que Sylvain n'ai pas inventé le nom NdSAb : non pas du tout ^^. C'est le fait que les managers qui ne sont pas habitués à travailler avec des développeurs puissent s'offusquer du fait que nous travaillions avec notre casque rivé sur les oreilles, éloigné du monde extérieur.
On fait ça pour pouvoir se concentrer, pour contrôler l'environnement dans lequel on travaille, mais pour quelqu'un qui ne le sait pas, cela nous fait passer pour des asociaux qui n'aiment pas les gens.
À nous d'expliquer et de faire comprendre pourquoi nous souhaitons "reprendre le contrôle".
Conclusion
Finalement, un talk passionnant, je vous invite à regarder et partager cette vidéo.
De l'UX dans mon équipe Agile
Antoine Pezé, Octo Technology, a ensuite parlé du rôle de l'UX designer dans une équipe agile.
Il a commence par rappeler que le rôle de l'UX designer n'est pas de dispenser une checklist de bonnes pratiques aux développeurs car une telle liste n'existe pas. Il faut à la place se mettre dans la peau des utilisateurs et créer un outil qui réponde aux besoins de ces utilisateurs. Si ça ne réponds pas à leurs besoins, c'est alors un échec.
Dans son ancien poste, il passait une majorité de son temps à créer des maquettes qu'il livrait ensuite à un prestataire qui aller les intégrer pendant deux mois, puis le site allait être mis en ligne. Sa part dans le projet s'arrêtait donc très tôt.
Maintenant chez Octo son rôle est beaucoup plus important sur toute la durée de vie du projet. Dans un projet agile il y a beaucoup de monde, avec différents rôles, mais ce qui est important, ce ne sont pas les gens, mais les flèches entre les gens (j'ai beaucoup aimé cette phrase). L'UX designer va discuter avec les développeurs, échanger avec eux et eux vont faire de même. Ainsi l'UX designer va quand même pouvoir évangéliser un peu les développeurs à l'ergonomie, et de son coté il va apprendre sous quel format les développeurs préfèrent obtenir leurs livrables.
Dans un projet agile, l'UX designer est celui qui prends de l'avance, qui ouvre les pistes. Il a une itération d'avance et va aider le PO à prendre des décisions en fonctions des retours des utilisateurs sur le terrain. L'UX designer va régulièrement sur le terrain, pour rencontrer les utilisateurs et pouvoir intégrer leurs retours dès les premières itérations, et continuer de le faire régulièrement tout au long du projet.
Il donne l'exemple de la dernière appli sur laquelle il a travaillé, destinée aux conducteurs de camion-citerne. C'est donc quelque chose de très spécifique et on ne peut en comprendre tout le détail qu'en allant sur place, sur le terrain.
Il a donc là bas appris très rapidement que les téléphones étaient interdits dans le dépôt (c'est bête, c'est là où l'appli devait être utilisée), mais que le mode avion était toléré. Du coup, l'équipe a pu prendre en compte dès le début la création d'un mode offline et ne pas découvrir cette informations à la dernière minute.
Idem, la boîte avait pour idée de créer un fil de news dans l'application pour les employés, mais après retour sur le terrain, cela n'intéresse personne. Du coup, la feature est mise de coté et l'équipe peut utiliser son temps pour faire des choses plus utiles.
Le travail de l'UX designer quand il n'est pas sur le terrain avec les utilisateurs est aussi sur le terrain avec les développeurs dans ce qu'il appelle des war rooms. Là, ils se retrouvent cote à cote pendant quelques heures pour améliorer l'intégration à coup de quickfix et de feedbacks. On change des détails comme la couleur, le contraste, la taille, etc. Bien plus rapide de le faire avec l'UX designer à coté pour valider que de devoir envoyer les informations par mail.
Cette manière de travailler permet d'avoir des retours des utilisateurs non pas à la toute fin du projet, mais dès le début, à chaque étape. Mettre son projet, incomplet dans les mains d'un utilisateur c'est un peu comme mettre ses trippes sur la table (j'ai bien aimé celle-là aussi), se confronter au réel, aux vrais utilisateurs, de voir comment les gens vont utiliser le soft pour de vrai.
C'est d'ailleurs très difficile de regarder quelqu'un se servir de son programme et de galérer, de ne pas aller l'aider. Mais il faut le faire, voir comment ils trouvent des chemins détournés, comment certaines choses qui nous semblent évidentes passent inaperçues.
Et allez pour la fin, il avait beau nous dire qu'il n'y avait pas de checklist d'UI, il a quand même donné le lien de goodui.org.
Wild Code School
Et pour le dernier talk c'est Romain Cœur qui nous a parlé de l'école d'informatique qu'il a fondée. La Wild Code School est spéciale car elle se trouve à La Loupe, un petit bled à la campagne à 1h30 de Paris entre Chartres et le Mans.
L'école vient de fêter sa première promo en Avril dernier et la prochaine va débuter en Septembre. Elle propose une formation courte et intense (6 mois) au développement web. C'est ambitieux (6 mois c'est court), mais elle est destinée à des gens ambitieux aussi bien dans les profs que dans les élèves.
Romain nous a parlé un peu de son parcours. Ingénieur, il a fait 5 ans d'études dans lesquelles il a appris plein de choses. Puis dans le milieu professionnel il s'est rendu compte qu'il y avait globalement les ingénieurs qui sortaient de grandes écoles et les autodidactes qui sortaient de nulle part, avec très peu entre les deux. Il a aussi remarqué que toutes les écoles sont globalement localisées à Paris alors que techniquement, le développement web ça peut se pratiquer en remote sans avoir besoin d'être à Paris.
La première promo de l'école était la promo bêta et a ouvert ses portes à des personnes de tout age (de 19 à 43 ans) et de tout horizon (serveur chez mac do, assistante de direction, boulanger, menuisier, etc).
La formation est entièrement centrée sur la pratique, les élèves ont des projets à réaliser dès la deuxième semaine. Ils n'ont presque pas de cours mais très souvent des ateliers pratiques. En lieu et place des examens, ils ont des hackathons avec des projets à rendre. Ils ont des ateliers organisés par des professionnels de tous poils qui viennent leur parler autant d'Agile que de communication corporelle ou d'API.
Ils ont aussi peu de professeurs, qui sont essentiellement des formateurs plus que des enseignants. Ils ne sont pas là pour délivrer la connaissance aux élèves, mais pour les accompagner dans leur formation et assurer la cohésion de l'équipe. Un point important sur lequel il a appuyé était la dédramatisation de l'échec. On est là pour apprendre, il est normal qu'on ne sache pas au début, mais en faisant on finit par comprendre et dans le doute tout le monde est dispo pour répondre aux questions.
Les élèves sont aussi très rapidement mis dans le bain car les différents projets qu'ils ont à rendre sont des projets réels, qui partiront en production pour les différentes entreprises de la région, et son facturés. Cela a un multiple effet positif. D'une part les élèves voient qu'ils travaillent sur quelque chose de concret, qui sera utilisé. Ils peuvent parler autour d'eux de ce qu'ils font car les entreprises sont connues dans la régions. Et le maire de La Loupe est très content d'avoir un pôle comme cela qui se développe.
Romain nous a ensuite mis en avant quelques temps forts de la première promo. Eux aussi découvrent ce que c'est que de monter une école, et de devoir gérer un groupe aux ages et ambitions différentes.
La différence d'age extrême entre certains élèves a parfois conduit à des mots un peu fort, mais il faut apprendre à certains à chacun à s'exprimer d'une manière qui ne blesse pas dans un contexte professionnel, et à d'autres à accepter qu'une plus jeune génération ait d'autres opinions.
Tous les élèves n'avaient pas la même motivation. Certains sont venus pour essayer mais se sont rendu compte rapidement que ce n'était pas pour eux, d'autres se sont découverts une passions ou encore certains étaient sous pression car cette formation était leur dernière chance de reconversion. Là dedans, il faut réussir à garder le flow et l'harmonie de l'équipe.
Les formateurs se sont aussi rendu compte d'avoir fait une grosse erreur quand ils ont organisé un examen noté. Plusieurs de leurs élèves étaient dégoutés du système scolaire classique et ont vu la notation d'un examen comme une sanction et leur note comme une attaque personnelle. Il a fallu travailler avec eux pour leur montrer que la note est juste le reflet des éléments qu'il faut améliorer. Mais ils ont quand même laissé tombé les notes pour la suite.
À l'issue de la première promo, 70% de leurs élèves ont trouvé un stage, un CDD ou un CDI. La formation délivre surtout les bases et la distillation de la curiosité. Les élèves sortent de là avec une envie d'apprendre et une forte capacité d'adaptation. Les bases de l'algo sont encore fragiles et ils sont plus portés sur la pratique que sur la théorie.
Pour les prochaines promos ils vont tenter d'améliorer ce coté là. Ils vont aussi avoir une sélection à l'entrée un peu plus fine, pour voir la motivation des gens. Beaucoup se disent que l'informatique ça peut être intéressant mais ne se rendent pas compte de ce que signifie réellement coder. Pour ça, ils font une première sélection sous forme de MOOC et ateliers pratiques pour essayer d'exposer aux gens où ils vont mettre les pieds.
La première formation était entièrement gratuite, car projet pilote. La deuxième est officiellement payante (6000€), mais avec les bourses données par la région, la ville, les entreprises et l'école elle-même (sur les projets facturés) ils garderont l'entrée gratuite pour les étudiants modestes.
Comme je le disais plus haut, le maire est très heureux de cette initiative et aide l'école, en fournissant par exemple un internat pour les élèves. Cela favorise l'emploi dans sa région et il souhaite fonder une pépinière d'entreprises sur place.
Romain est resté volontairement évasif sur les technos enseignées car celle-ci lui semblent secondaire face à la capacité d'apprentissage et d'adaptation que ses élèves acquièrent. Néanmoins ils commencent par du HTML et du CSS et choisissent ensuite pour la suite de la formation s'ils veulent faire du PHP, Ruby ou Node (il y a même des élèves qui ont choisi de faire du Meteor). Les élèves sont aussi force de proposition et certains ont proposés de tester PhoneGap alors ils l'ont ajouté au cursus.
Une bien belle école, où on apprends les fondamentaux avant de se lancer dans le monde du travail, tout en ayant aussi acquis la curiosité qui fait qu'on continue d'apprendre régulièrement.
Conclusion
Encore une bien belle session. Merci à Viadeo de nous avoir accueilli, on eu le droit là à 4 talks passionnants.
[^why_socio]: le but de l'auteur est de vous donner les armes soit en tant que (jeune ou moins jeune) manager, soit en tant que dev pour avoir les mots et les faits qui permettront d'expliquer à votre manager vos demandes pour améliorer vos conditions de travail.
[^career_tips]: mais c'est un autre débat -- ceux qui pourraient en parler exigeront soit beaucoup d'argent (c'est légitime vu les k€ que tu peux gagner, mais ça reste vous qui prenez les risques), soit de couper la caméra.
[^fixedgrowthmindsets]: Note de Sylvain Abélard : le "fixed mindset" dit que "vous avez un niveau d'intelligence fini, certains sont bêtes et d'autres plus ou moins intelligents. Le "growth mindset" dit que quel que soit le problème, on peut y arriver en travaillant davantage. Le Fixed Mindset donne des gens qui progressent peu et pour l'avoir vécu je le trouve dangereux et nocif. Il est la raison de mes talks Hack your Brain, Hack your motivation et Dark Side Pour en savoir plus : https://en.wikipedia.org/wiki/Mindset#Fixedmindsetandgrowthmindset
[^stepping_down]: hormis licenciement (difficile en France), changement de travail, mobilité interne... En tout cas changer de job tout court requiert de l'énergie et peu apprécient, surtout pour un poste moins "prestigieux socialement" ou à salaire moindre. Ceux qui savent bien négocier iront d'autant plus vite soit dans un poste très important où ils sont très incompétents (sans que cela ne se voie) soit dans un poste où ils maximisent leur propre bonheur, lequel est souvent défini par Autonomy, Mastery and Purpose (Autonomie, Maîtrise, Objectif / Vision).
[^dumb_sure]: Ajoutez à cela l'effet classique qu'en réunion comme dans tout contexte social, il est facile pour un extraverti d'imposer son point de vue ; que beaucoup de développeurs sont introvertis, et vous avez un mix explosif. En tant que "celui qui fait", il est alors de votre devoir d'améliorer vos skills sociaux en entreprise et lors des réunions !
Pour la deuxième année consécutive, je suis allé faire un tour à dotScale. Toujours au même endroit, au Théâtre de Paris, dans une belle salle de théâtre (même si il y faisait un peu chaud dans l'aprem). Ça fait plaisir de voir autant de gens réunis pour parler scalabilité (si seulement autant de personnes venaient parler CSS...).
Il y avait en tout environ 750 personnes, et comme à son habitude l'organisation était au top, les buffets bien remplis et très bons. Comme à son habitude, dotScale n'émets pas de wifi dans la salle de conférences pour que les gens se concentrent sur les talks (on nous incite même à ne pas utiliser nos laptops, mais j'ai bravé l'interdit pour prendre les notes qui m'ont permis d'écrire cet article).
Je suis resté un peu sur ma faim en milieu de journée quand la conférence s'est mise à devenir un dotNoSQL plutôt qu'un dotScale, mais les derniers talks sont revenus sur la bonne piste donc j'en sors finalement content.
Automatic Unattended Reboots
Le premier talk de la journée, de Matt Bostock de gov.uk commence directement à nous parler de reboots automatiques. Matt travaille donc pour le gouvernement du Royaume Uni et l'availability des différents sites de ministères et ambassades. Ils ont environ 12 millions de visiteurs uniques par semaine, à toute heure du jour et la nuit (voyageurs, expatriés à l'autre bout du globe qui utilisent les sites des ambassades).
Bien souvent quand on fait une mise à jour, il est nécessaire de faire un reboot. Parfois, un simple restart des services qui vont bien suffit, mais c'est pas toujours évident à faire. D'une part c'est un peu plus manuel qu'un bon vieux reboot, et parfois ça ne suffit même pas (comme quand on mets à jour des lib ssl -heartbleed, anyone ?-).
Du coup, rebooter manuellement tout ses serveurs de sa batterie, ça va bien deux minutes, mais il y a de bons moyens de rendre ça moins pénible. Ubuntu, qu'ils utilisent, est configuré pour mettre automatiquement à jour les paquets qui contiennent des updates de sécurité (cron qui check toutes les demi-heures de minuit à 9h du matin).
Comme je le disais plus haut, c'est déjà pas mal, mais parfois il faut faire un reboot après ça. Dans ce cas, il est possible de spécifier un Unattended-Upgrade::Automatice-reboot "true" pour que le serveur reboot dans la foulée. Il faut par contre faire attention à ce que tous les serveurs ne rebootent pas en même temps, en décalant légèrement le moment où les cron tournent entre plusieurs machines.
Ils ont donc mis au point un système automatique pour s'assurer que tous les reboots se fassent correctement.
Leur script bash tourne toutes les minutes, de minuit à 9h. Il check si /var/run/boot-required existe (ce fichier est ajouté par Ubuntu lorsqu'une update nécessite un reboot, c'est ce fichier qui est la cause du message qu'on voit parfois quand on se loggue sur un serveur qui a besoin d'être rebooté).
Si c'est le cas, il check un flag dans Puppet qui indique si cette machine a le droit de se rebooter seule. Certaines machines nécessitent un reboot manuel, et dans ce cas la config Puppet s'assure du feature flipping. Ils sont en train de modifier tout leurs serveurs pour qu'ils soient tous capables de se rebooter, mais comme ils n'en sont pas encore là, la feature peut être désactivée au cas par cas.
Ils requêtent ensuite Icinga (un fork de Nagios qui expose un endpoint en json avec l'état actuel de santé des machines) pour voir si le cluster sur lequel tourne le serveur est en bonne santé. S'il y a un trop grand nombre d'erreurs critiques en ce moment sur le serveur, on ne reboot pas, bien trop dangereux.
Ils requêtent ensuite etcd qui, d'après ce que j'ai compris, leur permet de d'obtenir un mutex distribué pour savoir si ce serveur peut reboot. Si le lock est dispo, le serveur le prends, sinon le script s'arrête et recommencera dans 1mn, au prochain passage du cron.
Au reboot, le serveur release son lock et les autres serveurs du pool peuvent alors le récupérer pour faire la même danse et se rebooter aussi.
Bien sur, avant de tester tout ça en production, ils ont testé dans leur environnement de staging, qui est une copie conforme de l'env de prod et qui reçoit une copie en miroir de toutes les requêtes que la prod reçoit aussi. Ils ont laissé tourné comme ça pendant plusieurs semaines, pour s'assurer que tout fonctionnait bien avant de déployer en prod une fois confiants.
Finalement, leur système marche bien et ils en sont très content. Depuis ils l'ont un peu amélioré, en passant le cron à 5mn plutôt que 1. 1mn était trop court et les serveurs n'avaient pas le temps de redémarrer correctement. 5mn leur laisse plus d'espace et est encore assez court pour que tous les serveurs puissent reboot avant 9h. Ils ont aussi réécrit une partie du parsing du json (anciennement en regexp) par du Ruby.
Scaling Humans
Le deuxième talk était de David Mytton, de Server Density. David nous a expliqué comment ils gèrent les astreintes chez Server Density.
Comme tous les bons ops, il commence par rappeler que quelque soit les précautions qui sont prises, il y aura toujours des moment de downtime, qui passent au travers des protections automatiques mises en place et doivent être gérées par des humains.
Et ces humains doivent être d'astreinte, joignables et prêts à intervenir au plus vite. Pour cela, il utilisent un système de rotation primary/secondary. Les primary sont prévenus en premier et doivent être dispo pour répondre en quelques minutes, se logguer sur les serveurs, commencer à comprendre d'où vient l'erreur et pouvoir passer ces informations à la seconde équipe qui n'arrive qu'au bout de 30mn si jamais le problème est toujours en production.
Tous les ops d'astreinte ont le droit à une journée off après un call d'astreinte, pour se reposer et pouvoir reprendre le travail en forme sans avoir eu une nuit blanche entre les deux.
Plus un système devient complexe et moins il a de chance de tenir dans la tête d'une seule personne. Et même si c'est le cas, cette personne ne sera peut-être pas toujours là, ou ne sera pas dispo pour cette urgence. Il est donc indispensable que l'infra soit documentée, ainsi que les erreurs communes. Cette documentation doit être searchable facilement et rapidement et surtout, elle ne doit pas être hébergée sur les mêmes machines que celles qui risquent de planter (mettre la doc sur Google Docs est donc une bonne idée).
La doc doit comprendre la liste des personnes à contacter pour les différents problèmes, que ce soit des développeur en interne, des responsable de la relation client, ou des contacts chez les différents prestataires. Les différents codes d'accès aux différents outils doivent aussi être facilement accessible pour ne pas se retrouver refoulé à l'entrée parce qu'on n'a pas le bon mot de passe du support ou pas la bonne clé ssh quand les serveurs sont en train de bruler.
Dans le même ordre d'idée, il faut s'assurer que le canal de communication principal (HipChat par exemple) n'utilise pas la même architecture que celle qui est susceptible de planter (AWS par exemple). Les moyens de communications doivent aussi être redondés.
Avant de se lancer tête baissée dans la résolution du problème il y a déjà 3 points qui doivent être respectés. Tout d'abord, et avant tout, de manière primordiale, ouvrir la checklist et vérifier de bien tout faire, dans l'ordre. Si une erreur survient le lundi matin alors qu'on est en pleine forme, c'est pas un soucis, mais si jamais on doit sauver le monde à trois heures du matin après une soirée arrosée au réveillon, on n'aura pas les idées très claires et suivre la checklist nous assurera de ne rien oublier et de le faire dans l'ordre.
Ensuite, on se connecte sur une war room dédiée. Celle-ci est destinée uniquement aux ops en train d'investiguer le problème, on n'y discute pas, on n'y partage que des infos qui font avancer l'investigation.
On loggue ensuite l'erreur dans un JIRA ou autre tracker et on balance l'url dans la room. Comme ça, on a une seule référence de l'erreur, avec un numéro unique et tout le monde peut bien parler de la même chose. On y poste les différentes commandes qui ont été exécutées, les pistes, etc de manière à ce qu'une nouvelle personne qui arrive sur le problème puisse voir en une seule fois les symptômes et ce qui a été tenté. Elle permettra aussi de se pencher sur un post-mortem ensuite.
Et seulement après la checklist, la war room et l'issue JIRA se mets on à investiguer réellement les causes. Comme je le disais, si on tente des commandes, si on fait des reboots des serveurs, on le note dans l'issue.
On prévient aussi nos utilisateurs aussi souvent qu'on le peut de l'avancée de nos investigations, ce qu'on suppose, ce dont on est sur, ce qu'on va faire et un ETA si on en a un. Il n'y a rien de pire qu'avoir son site down et de n'avoir pour seule information qu'une page de status mise à jour il y a plus de 4h qui dit "on s'en occupe".
Il est aussi utile d'avoir toute l'équipe dispo à portée de main. Tout le monde ne peut pas vraiment aider en même temps, mais de savoir que si besoin on peut aller voir la personne en charge de telle ou telle partie d'où le bug a pu provenir et qu'elle sera dispo là tout de suite pour aider à corriger, c'est un gros plus.
Et une fois que la catastrophe est endiguée, on laisse couler quelques jours pour se reposer, pour répondre aux clients, et on se retrouve pour faire un post-mortem. On raconte ce qu'il s'est passé, les causes, les conséquences, les solutions, et ce qu'on peut faire pour que cela ne se reproduise plus.
On peut ensuite poster ça publiquement sur le blog de la société. Selon l'affinité technique du public on peut rentrer plus ou moins dans les détails, mais au moins on le fait en interne au reste de l'équipe. Etsy, Heroku, Amazon et plein d'autres font ça régulièrement: ce qu'il s'est passé, pourquoi, ce qu'ils ont essayé, ce qui a marché, ce qui n'a pas marché et les solutions pour la suite.
Un bon guide de savoir-vivre de l'astreinte, concentré sur le coté humain, sur la communication, savoir expliquer ce qu'il se passe, pas mal de bonnes idées.
Worst and best in time series data
Paul Dix, d'InfluxDB nous a ensuite parlé de time series et des challenges que leur stockage comportait pour des bases de données classiques.
Déjà, un petit rappel sur ce qu'on appelle une time series. Un exemple concret et parlant sont des lignes de log par exemple. C'est un ensemble de données (url, host, temps de réponse, etc) lié à un timestamp. Ces données arrivent les unes après les autres à un serveur. Elles peuvent arriver de manière régulière (toutes les X minutes) ou de manière irrégulière (en réponse à des événements).
Réussir à modéliser ce genre de données dans une base de donnée (NoSQL ou relationnelle) classique est très compliqué. Mais si on s'intéresse aux spécificités de ce genre de data, on se rends compte qu'elles ont des propriétés très spéciales dont on peut tirer parti.
Tout d'abord, elles ont un nombre d'écritures très importants. Les logs arrivent tout le temps, sans jamais s'arrêter. Plus on veut tracker de metrics, plus on va recevoir de logs. Elles ont aussi besoin de pas mal de lectures, vu que les utilisateurs vont avoir besoin de voir les metrics enregistrées, générer des graphs, voir les évolutions sur plusieurs minutes, heures, jours, semaines, mois.
Si on stocke l'ensemble des logs qu'on reçoit, on se retrouve en plus avec des quantités de données astronomiques et plus de place pour les stocker et encore moins pour réussir à faire des queries performantes sur un tel dataset.
Mais si on y regarde de plus près, on se rends compte que notre donnée perds de son intérêt au fil du temps. Les logs de l'instant présent sont plus importants que ceux d'il y a deux ans. Et on peut se permettre d'effectuer un map/reduce sur nos anciennes datas pour ne garder que les metrics agrégées extraites de nos milliers de logs sans en garder le détail précis.
On remarque aussi que les time series ne font jamais d'update de donnée existante. On ne va jamais modifier un log existant, on va juste en ajouter des nouveaux, et en plus on va toujours les ajouter récemment. Cette particularité est très importante parce que cela veut dire qu'on peut se permettre de supprimer de gros chunks de données dans le passé sans gêner la consistency de ce qu'on a dans le présent.
Le simple fait de ne pas faire d'update de donnée signifie qu'on ne peut pas avoir deux ordres qui demandent de modifier la même donnée de deux manières différentes et qui nous demanderaient de savoir lequel des deux est arrivé en premier. On n'a pas ce problème, on se contente d'ajouter les logs comme ils viennent. On peut donc facilement faire de gros calculs sur des blocs entiers de donnée ancienne en ayant la certitude qu'un ordre ne va venir ajouter ou modifier un de nos items pendant qu'on fait notre calcul.
Et même dans le cas où notre base est distribuée sur plusieurs serveurs et que pour une raison ou une autre un des serveurs n'a pas reçu l'ensemble des ordres d'écriture, il nous est facile de reconstituer le set manquant en faisant la différence avec ce que les autres ont reçu.
Au final, le talk était un très bon moyen de mettre en évidence les spécificités des time series et de ce qu'elles impliquent en terme de type de base de données. Même si son nom n'a jamais été cité de tout le talk, j'imagine qu'InfluxDB doit résoudre l'ensemble des problèmes évoqués.
Borg
John Wilkes, de Google, nous a parlé de Borg, l'outil utilisé chez Google qui permet de faire de la parallélisation de tâches sur de multiples machines/cœurs/threads/whatever.
Honnêtement, je ne sais pas si c'était la chaleur ou le fait que le speaker parlait vite, et de manière assez monocorde mais j'ai piqué du nez à plusieurs reprises durant le talk et n'ai pas vraiment grand chose à vous raconter sur celui-ci !
Lightning Talks
Après la pause déjeuner, on est repartis pour une petite série de lightning talks. C'est une super idée qui permet de digérer tranquillement sans s'assoupir devant une longue conférence qui demande de faire travailler des méninges qui sont en général à ce moment en train de sortir de leur torpeur.
Doclipser
Le premier talk était sur un projet assez bizarre, de faire tourner Docker sous Eclipse. De ce que j'ai compris, ça permet d'ajouter de la coloration syntaxique et un vérificateur de syntaxe aux Dockerfile, ainsi que de lancer des images en quelques clics depuis son IDE.
J'avoue que ça m'a pas paru plus facile à utiliser que de taper docker run whatever, mais ça doit être parce qu'Eclipse ne m'a jamais paru facile.
Your system is distributed
Sam Bessalah (que je croise souvent en meetup et avec qui j'échange juste quelques mots), m'a particulièrement surpris avec un sujet super intéressant sur la place des recherches académiques au sein des différents projets open-source.
Il trouve que bien des projets mentent bien souvent par omission, en considérant que le réseau est fiable, que la latence n'existe pas, que nous avons une bande passante illimitée, etc.
Ces complexités existent, il ne faut pas fermer les yeux en se convainquant qu'il n'y a pas de problèmes, il faut penser un système qui les englobe et qui sait les gérer. De la même manière, réussir à mettre au point un algo de consensus dans un système distribué n'est pas quelque chose de simple.
Et c'est tellement peu simple qu'il existe des recherches sur le sujet, des papiers de plusieurs centaines de pages qui expliquent mathématiquement les problèmes et leurs différentes solutions. Mais bien souvent, tout cela passe au dessus de la tête des développeurs qui trouvent ça trop compliqué et recodent leur propre version.
Il ne faut pas avoir peur des recherches déjà effectuées, au contraire, il faut continuer à bâtir sur les épaules des géants qui nous ont précédés, il ne faut pas cantonner ces recherches au monde de la théorie et notre code à celui de la pratique, les deux ne font partie que d'un seul et même monde.
Good point, j'ai beaucoup apprécié. Même si je suis bien incapable de comprendre le moindre papier mathématique, je ne me risquerai pas à recoder un algo de consensus distribué.
Leader Election with Cassandra
Matthieu Nantern de Xebia nous a ensuite lu un texte explicatif sur Cassandra et la manière dont le Leader est choisi dans un cluster. Le talk n'apportait rien de plus que l'article, et était même plus difficile à suivre.
Convergent Replicated Data Types
Dan Brown nous a quand à lui parlé de la Joconde, de Jesus-Christ et de Léonard de Vinci. Ah non, pardon, il nous a surtout rappelé qu'il était impossible de différencier un échec d'une lenteur, si on ne définit pas un timeout maximum.
Consistency and Candy Crush
Neha Narula, dont la bio sur le site se limitait à "she has a PhD and she's from Google" a quand à elle entamé le premier talk de l'après-midi, sur la cohérence dans une base de donnée et ce que ça implique.
Ce talk était un de plus à nous parler du CAP Theorem, et un de plus à plus parler de database que ce que je m'attendais à trouver sous le terme de scaling.
On commence par un petit récapitulatif de ce qu'ACID veut dire.
Le A est pour atomic, soit un ordre s'est exécuté, soit il ne s'est pas exécuté. "Do. Or do not. There is no try" comme dirait l'autre.
Le C est justement pour cette Cohérence (Consistency), c'est à dire que le résultat est correct, selon des règles que nous avons nous même définies.
I pour Isolation, les différentes transactions sont indépendantes et n'interfèrent pas les unes avec les autres.
Et finalement, le D pour Durable, c'est à dire qu'on peut reconstruire la DB même après un crash. C'est la lettre qu'on oublie généralement.
Elle nous explique aussi ce qu'on entends sous le terme de serializability, c'est à dire la capacité d'exécuter un ensemble d'ordres comme si on les exécutaient les uns après les autres. Attention, ça ne veut pas dire que c'est comme ça que ça se passe à l'intérieur, ça veut juste dire que le résultat est le même si on exécute une transaction serialisable que si on exécute les ordres qui la compose les uns après les autres.
Dans l'esprit du codeur, c'est plus simple de se représenter une transaction serialisable, car on n'a alors pas besoin de penser à tous les problèmes d'enchevêtrement des ordres.
Il y a donc, dans le monde des DB, plusieurs modèles de cohérence. On a d'abord l'eventual consistency qui dit simplement que si on n'a arrête d'avoir de nouvelles updates, alors, au bout d'un moment, tout nos nœuds auront la même data. La difficulté avec ce genre de modèle c'est déjà que la notion de temps est assez floue et que ce n'est pas évident de savoir exactement quel est le dernier ordre, et aussi qu'en général les updates ne s'arrêtent jamais réellement.
De l'autre coté, on a la strict consistency. Les ordres sont exécutés dans l'ordre où ils sont envoyés, de manière linéaire. Eventual et Strict sont deux extrêmes d'un spectre avec des tas de variations entre les deux.
Finalement, le take away de sa conférence est que l'eventual consistency c'est compliqué à gérer et que bien souvent ça amène plus de problèmes que ça n'en résout. En tout cas, elle conseille de commencer ses développement avec une cohérence stricte. Et seulement quand cela crée des goulots d'étranglement tenter de les contourner (et l'eventual consistency peut être une solution mais pas forcément la seule).
Au final il faut être bien conscient des avantages et des inconvénients des DB qu'on utilise. Il faut savoir ce qu'on gagne, savoir ce qu'on perds, et ne pas laisser le système de base de donnée faire ce choix pour nous.
Internet as a giant computer
Un talk un peu meta pour la suite, cette fois-ci avec Ben Firshman. Il nous rappelle qu'aujourd'hui on a arrêté de vouloir avoir des serveurs de plus en plus gros, au contraire on cherche à en avoir de plus en plus petits, mais de plus en plus nombreux et de plus en plus éparpillés sur le globe.
Et même ces serveurs qu'on possède, on les splitte en machines virtuelles qu'on va elle-même splitter en containers. On a encore besoin physiquement d'avoir une machine sur laquelle faire tourner tout ça, mais on a tellement de couche de virtualisation entre temps qu'au final on s'en fiche un peu.
Tout parvient à tourner sur tout et chaque container a embarqué avec lui la totalité des langages et librairies dont il a besoin, de manière complètement isolée. On peut faire tourner des écosystèmes complètement différents sur la même machine sans que cela ne pose de soucis, et sans même forcément le savoir.
Tout ce qu'on demande au serveur, c'est de savoir gérer l'orchestration de tout ça, et d'être en mesure de tuer ou de spawner des containers très rapidement. Et quand il faut aujourd'hui moins d'une seconde pour lancer un container avec une stack complète et le tuer aussi rapidement, on peut faire des trucs très impressionnants.
On peut paralléliser des dockers, pour lancer un maximum de tâches en parallèle, de manière à ce que le temps final d'exécution de la tâche soit égale à la durée de la tache la plus longue. Pour lancer ses tests c'est parfait, une test suite complète qui tourne en quelques secondes, c'est un pas de géant.
Bien sur, on peut déjà faire ça offline, sur son laptop facilement, en forkant des process pour les avoir qui tournent en parallèle. Mais on peut aller plus loin et imaginer que plutôt que de forker un process on envoie une requête POST à un swarm de serveurs en ligne et que eux bootent des centaines d'instances docker en parallèle et nous retournent notre résultat computé très rapidement.
En faisant ainsi, on pourrait utiliser notre réseau de serveur comme un super computer à la puissance quasi-illimitée. Des outils comme Compose, Kubernetes et Mesos sont déjà sur cette voie. Ce n'est plus qu'une question de temps.
postgreSQL
Simon Riggs, développeur sur PostgreSQL depuis plus de 12 ans, nous a fait un récapitulatif de cette base de données qui a une réputation d'ancien, mais qui est bien plus moderne que ce qu'on peut croire.
Il commence par nous rappeler la bénédiction qu'a été l'arrivée du langage SQL dans le milieu des bases de données. Avant SQL, chaque DB avait sa propre syntaxe et les compétences d'une technologie à une autre étaient difficilement transférables. De plus, chaque query devait être manuellement optimisée par les développeurs.
Au fil des années, on a ajouté de nouvelles manières de représenter nos données dans nos bases, pour s'adapter aux nouvelles demandes. Relationnel, schemaless, multidimensionnel, relationnel imbriqué, etc. Différentes représentations pour différents types de données. Rester enfermé dans un seul type de représentation parce que notre DB ne peut faire que ce type est une erreur. C'est le type de donnée qu'on possède qui définit la manière dont on va la représenter et qui entraine le choix de la DB, pas l'inverse.
Et une DB doit idéalement être en mesure de représenter différentes types de données, de différentes manières, selon les use-cases. Elle doit être flexible, et on ne devrait pas avoir à tordre notre donnée pour la faire rentrer dans les cases attendues par notre DB. Si tel est le cas, il faut changer de DB (au moins partiellement).
Il a été pas mal reproché à postgreSQL de ne pas avoir réussi à suivre l'évolution du marché et les innovations shinys de tous les concurrents NoSQL. Postgre s'est surtout concentré sur ses utilisateurs principaux, ceux qui représentent 99% de leurs utilisateurs et qui sont de plus petites structures qui n'ont pas besoin d'avoir de la redondance forte.
Néanmoins, dans les dernières versions, postgre a quand même sorti quelques features très intéressantes, comme la capacité de stocker du JSON en JSONB. C'est à dire un format compressé tout en gardant la capacité d'indexer son contenu et de faire des queries dessus directement.
Ils ont aussi ajouté des limites de timeout sur les queries qui peuvent prendre beaucoup de temps. Par exemple, calculer la moyenne sur des millions de records va prendre beaucoup de temps, mais avec postgre on peut spécifier qu'on veut que la requête ne prenne pas plus que X secondes. Dans ce cas, postgre va prendre un sample de la donnée qu'il sait avoir le temps de processer en moins de X secondes pour retourner les bonnes infos. Bien sur, plus on laisse un long timeout, plus on aura des données précises, mais c'est là le développeur qui fait le choix de sacrifier de la pertinence contre de la performance.
Il a aussi fait le tour de pas mal de fonctionnalités de postgre dans le même genre qui permettent au développeur de choisir lui-même, requête après requête, les tradeoff qu'il souhaite faire en terme de consistency ou performance. Le choix se fait sur chaque requête, pas au global sur le choix de la techno.
Au final, moi qui n'ai jamais utilisé postgre, j'ai découvert une base de donnée bien solide qui semble capable de faire bien plus que ce qu'elle peut laisser présager.
Jepsen
Kyle Kingsbury, le destructeur de base de données, dont les posts de blog peuvent changer la perception de technos était sur scène à dotScale. Il travaille aujourd'hui à Stripe.
J'ai pris très peu de notes à cette conférence, car près de 120 slides en 20 minutes, je me suis surtout concentré sur le propos.
Il nous a fait un récapitulatif rapide de ce qu'il avait dit dans ses derniers articles de blog. Comme quoi MongoDB perdait des quantités incroyables de données dans certains, et que ElasticSearch pouvait aussi perdre pas mal d'infos dans certains cas de partition réseau.
Depuis la parution de ses articles, les deux technos ont émis des bug fix et mis à jour leur doc, mais il semblerait que MongoDB continue de mentir ouvertement et de nier ses pertes de données sur son site, alors qu'ElasticSearch a mis en place une page d'explications très détaillée sur ce qui fonctionne et ce qui ne fonctionne pas.
Il a rapidement aussi présenté Jepsen, l'outil qu'il utilise pour pousser toutes ces bases de données dans leurs derniers retranchement.
Cloudflare
On a ensuite enchainé sur un talk passionnant de John Graham-Cumming (de Cloudflare) et de leur problématique de gestion des logs. Cloudflare est un système de CDN en frontal devant de nombreux sites à fort trafic, qui s'occupe de détecter les potentielles attaques (DDoS) et de les bloquer.
Ils logguent l'intégralité des logs d'accès et les envoient dans un datacenter "secret" pour les stocker et les analyser. Ça fait quand même 400To par jour (compressé) soit environ 4 million par seconde.
Avec autant d'information, leur plus grande tâche est de réussir à faire la distinction entre le signal et le bruit. C'est d'autant plus important qu'ils doivent être en mesure de détecter une attaque en temps réel, et pas 4h plus tard. Ils présentent aussi sur le dashboard de leurs utilisateurs le % de hit miss, la bande passante utilisée, les origines de requêtes.
Au final, l'astuce n'est bien sur pas de logguer absolument tout, mais d'extraire de chaque log les metrics qui seront répertoriées sur le dashboard. D'attendre aussi d'en avoir assez et de tout envoyer en batch, régulièrement. Selon leur criticité, certaines informations sont envoyées plus régulièrement que d'autres.
La majorité de leur outils internes sont écrits en go. Les serveurs frontaux sont des nginx avec un module LuaJIT pour filtrer les requêtes à logguer. Les Nginx ont un ensemble de règles qui étudient des patterns dans les requêtes pour détecter telle ou telle intrusion et en extraire les infos importantes. Un même serveur nginx va servir de reverse proxy devant plusieurs sites web, et donc il doit aussi être en mesure de loader la configuration de différents utilisateurs (car tous ne souhaitent pas logguer les mêmes informations).
Cet nginx va donc dropper les requêtes qui n'intéressent pas l'utilisateur et passer les autres à un de leurs outils en Go qui la ensuite les compresser (lz4) et les envoyer en batch à leur datacenter sur un flux de streaming ouvert en permanence vers un Kafka.
Sur ce flux, la donnée est compressée avec Cap'n proto, qui permet justement de compresser la donnée pour l'envoyer facilement on the wire. D'après leurs benchmarks, c'est 20% plus rapide que CJSON, qui est déjà bien optimisé. Avec ce format, ils peuvent quand même facilement enlever ou supprimer des attributes sans pénalité.
Une fois arrivé coté Kafka, celui-ci va dépiler les infos au fur et à mesure qu'elles arrivent, et cela de manière parallélisable. Si jamais leur Kafka a du mal à ingérer un afflux massif de données, ils peuvent facilement scaler en en ajoutant de nouveaux au pool, et en les enlevant ensuite. Et même dans le pire des cas, si les Kafkas tombent, la queue continue d'être sauvegardée et pourra être rejouée et rattraper son retard ensuite (max 24h).
Les données sont alors agrégées et alimentent une base postgreSQL qui sera directement requêtée pour générer le dashboard des utilisateurs. Ici, ils utilisent aussi CitusDB qui permet de gérer ses instances postgreSQL comme des shards et d'envoyer une même requête qui sera exécutées sur plusieurs datacenters en même temps et qui retournera l'union des retours.
Ils utilisent aussi du Redis, mais je ne me souviens plus exactement à quel endroit, je pense que c'est pour la gestion du cache.
Pour réussir à gérer toute cette stack, ils se sont fait fabriquer des serveurs sur mesure par Quanta. Ils ont besoin de pouvoir ingérer 15Go/s et de stocker 12To pour leur analytics.
Une belle plongée dans l'infra d'un géant du web avec une infra originale pour des problématiques aussi originales.
Disque
Salvatore Sanfilippo, alias @antirez, le créateur de Redis nous a parlé de Disque, un système de message queuing sur la même architecture que Redis.
Il s'est mis à écrire un système de message queue car beaucoup de personnes utilisaient Redis pour ça, bien qu'il n'ait pas été pensé pour ce use-case. Il a donc décidé de prendre Redis, d'enlever tout ce qui en fait Redis, et de faire message queue system avec.
En gros on garde le squelette, la syntaxe, les protocoles, les helpers de Redis, mais on n'en fait plus un key/value store. Ici encore, tout reste en mémoire et la persistance est en option.
Un message queue system doit gérer un type de données très particulières, ce qui le rends plus facile à développer qu'une DB qui peut accueillir n'importe quel type de données. Le but premier dans Disque est de pouvoir faire un système d'exécution de job complètement asynchrone.
On a donc un producer, qui peut envoyer des messages (ou jobs) à une queue. La queue réponds dès qu'elle a reçu le message, mais n'exécute pas le job tout de suite. Elle l'exécutera quand elle pourra.
N'importe quel type de message peut être envoyé: une image, un json, un format propriétaire, ça n'a pas d'importance car c'est transféré comme du binaire.
Disque peut processer plusieurs queues en même temps, il suffit d'indiquer sur quelle queue on veut envoyer son message quand on exécute ADDJOB. On peut ensuite aussi récupérer la liste des jobs en attente sur une ou plusieurs queues avec GETJOB.
On a donc d'un coté un producer qui envoie des ADDJOB et de l'autre un listener qui va poller Disque régulièrement avec des GETJOB. Le listener va ensuite effectuer le job en question, et quand il a fini, il renvoie un ACKJOB à Disque avec l'id du job pour dire que celui-ci est exécuté, ce qui va le supprimer de la queue.
Du coup, il est tout à fait possible qu'un même job soit lu par plusieurs listeners si jamais plusieurs listeners le pollent le temps qu'il soit exécuté. C'est voulu, et cela permet de faire plusieurs services qui vont chacun avoir une tache à faire sur un même job.
Néanmoins, il est aussi possible de définir un TTL quand on envoie un ADDJOB pour indiquer la durée de vie du job. Si au bout du timeout il n'a toujours pas reçu de ACK, on le supprime quand même de la queue.
Disque est donc très simple, il fait ce sur quoi il s'engage (une simple pile de job qu'on peut push et pull). Par contre, il a des limitations clairement définies: l'ordre de traitement des jobs n'est pas assuré. Disque fait ça en mode best effort seulement.
Dans les prochaines features, il prévoit d'ajouter en plus du ACK un NACK pour dire que le job a été traité, mais a foiré. Dans le même ordre d'idée, il va ajouter de meilleurs options de debug et d'introspection. Pour le moment, Disque est encore techniquement dans une version instable mais déjà utilisée en production par quelques boites.
Your infrastructure is not a unique snowflake, and that's ok
Dernier talk de la journée, et celui qui m'a paru le plus intéressant, par Jeremy Edberg. C'est pour moi le talk a montrer à toute personne qui fait de l'IT aujourd'hui. C'est un excellent récapitulatif de ce qu'est l'état de l'art en 2015 quand on doit gérer un site/app online de taille respectable.
Il commence par introduire son sujet en nous parlant de l'overhead qu'une boite produit automatiquement, c'est à dire tout ce que font ses employés qui n'apporte pas réellement de valeur directe à l'entreprise. C'est bien souvent du temps perdu dans des process manuels.
J'ai eu un peu de mal à suivre la logique de son plan au début, ça semblait assez décousu, mais c'est devenu plus clair dans la seconde partie.
On se pose pas mal de questions dans la mise en place d'une infra, et dans son administration. La difficulté n'est pas de trouver les réponses à ces questions, mais de savoir poser les bonnes.
Par exemple, après un incident, on ne cherche pas à savoir qui est à blâmer pour un problème, mais à comprendre ce qui a pu mal tourner. Ainsi, on évite que ça se reproduise, plutôt que de faire peur aux gens et les empêcher de prendre des initiatives.
Une autre question qui revient fréquemment, c'est le "Build or Buy?". Il y a sans doute un outil déjà existant qui fait 90% de ce qu'on veut faire, mais qui va être difficile à utiliser pour les 10% restants. Ou alors on peut subir le Not Invented Here syndrome et faire ce qui nous convient parfaitement (parce qu'on aime bâtir des choses), qui fera exactement les 10% qui nous manquent, mais nous demandera de maintenir des tas de edge cases dans les 90% restant.
Idem, doit-on bâtir un monolithe ou des microservices. Les microservices permettent d'éviter les SPOF et de scaler plus facilement, mais un monolithe est quand même beaucoup plus facile et rapide à bâtir. La majorité des gros services aujourd'hui ont commencé par du monolithique avant de bouger petit à petit vers des microservices: Netflix, AirBnB, Pinterest, etc.
Car quand on part sur des microservices, le plus difficile ce n'est pas de bâtir les services, c'est de bâtir la plateforme sur laquelle ils se trouvent, qui leur permet de communiquer entre eux. Il faut savoir arrêter de développer la plateforme quand elle est "good enough" pour soi. Il n'y a que les providers de services en SaaS qui doivent continuer à améliorer constamment leur plateforme pour en faire un élément différenciant. Quand c'est pour un usage uniquement interne, inutile d'en faire trop.
Et en plus, vous et vos concurrents bâtissez à peu près le même type d'infra, ce qui est un gaspillage monstrueux car cela prends du temps et n'ajoute pas forcément grand chose comme valeur à votre core business. Chacun le refait parce que personne n'a trouvé quelque chose sur le marché qui corresponde à son besoin. Il y a bien Netflix qui mets à dispo en open-source pas mal de leurs projets, mais ça reste quand même très centré sur Netflix et difficilement utilisable dans un autre contexte.
Pour lui, une société qui se monte aujourd'hui doit commencer par sélectionner un des cloud providers existants (Google, Azure, Amazon et bâtir la première version de son infra dessus. Partir sur du hardware en 2015 quand on se lance est une énorme erreur, un gaspillage de temps et d'argent. Attention toutefois, le cloud est nimbé d'une aura médiatique qui semblent le rendre complètement magique. La vérité est entre les deux, tout n'est pas aussi rose, mais ces avantages sont indéniables.
Une fois qu'on a cette base d'infra, on va y poser dessus différents microservices qui vont s'occuper de différentes parties de notre système. Ils ne sont pas tous forcément visibles par nos utilisateurs, mais ils sont tous indispensables à la bonne marche du système. On parle ici de l'intégration continue, du logging, des metrics, de la gestion du trafic, de la découverte des ressources, des tests, de la sécurité et du stockage de nos données.
CI
Pour l'intégration continue on a le choix. Jenkins, TravisCI, TeamCity, CircleCI. Ils font tous à peu près la même chose, le choix de l'un ou de l'autre ne doit être drivé que par quelques questions: Est-ce qu'il peuvent être entièrement automatisés ? Est-ce qu'ils me produisent des objets directement utilisables ? Est-ce que je peux faire un déploiement en un clic ? Si un de ces système réponds Oui aux trois questions, ne vous posez pas plus de questions.
Logs
Les logs sont une grosse question. Il prennent rapidement beaucoup de place si on garde tout, et deviennent rapidement très difficile à exploiter. Pour détecter les problèmes sur le système, il est bien généralement inutile de les stocker éternellement. Il est plus intéressant de les étudier en temps réel que d'aller fouiller dans un gros historique.
À la rigueur on commence à les garder quand on détecte une erreur, mais jamais avant. Inutile de logguer tous les logs de succès, ce qui nous intéresse ce sont les logs d'erreur et surtout leur augmentation. On en extrait des metrics, mais on ne garde pas les logs raws.
Metrics
Justement, continuons sur les metrics. Au delà des metrics techniques récupérées par nos logs, on a aussi besoin de metrics de satisfaction humaine.
Le speaker nous donne un exemple sur le formulaire de recherche de Reddit. Ils avaient remarqué que leur recherche n'était pas géniale. Ils ont donc rajouté un formulaire de satisfaction ("Est-ce que vous avez trouvé ce que vous cherchiez. Oui / Non") avant de faire des modifs. Ça leur a permis de voir qu'elle était satisfaisante pour 70% des utilisateurs.
Ils ont ensuite commencé à changer le système, et ont laissé le formulaire trois mois après avoir tout remplacé, pour voir l'évolution. Ils s'en sortent avec une satisfaction de 90% à la fin. Et ce n'est qu'au bout de ces trois mois qu'ils annoncent officiellement sur le blog avoir tout remplacé.
Ils ont bien fait de ne pas prévenir en cours d'expérience qu'ils apportaient des modifications car les utilisateurs étaient alors persuadés que la modification avait été faite récemment, pas il y a trois mois. Les prévenir que la recherche allait changer aurait influencé leur choix et la satisfaction aurait été faussée.
Bref, mesurez avant, mesurez après, et seulement comme ça vous pourrez connaitre les impacts d'une modification.
Trafic
Le trafic entre chacun de vos services est très important. Si chaque service peut tout à fait fonctionner indépendamment, ce qui fait que votre infra fonctionne réellement ce sont les échanges entre chaque partie. Il vous faut des outils simples (comme des cartes mises à jour en temps réel) qui vous permettent de voir par où passe le trafic et où il peut être bloqué.
Il peut y avoir des centaines de raisons pour lesquelles le trafic entre deux parties de votre réseau peut être bloqué. Cela ne doit pas devenir un SPOF, mais vous devez être en mesure de rediriger ce trafic par d'autres endroits si nécessaire. Certes, ce sera moins rapide que de passer par la ligne directe initialement prévue, mais ça sera une infinité de fois mieux que de ne pas avoir de trafic du tout.
En plus de le voir, il vous faut aussi des outils qui peuvent rerouter le trafic bloqué par des routes accessibles, et si possible automatiquement, sinon au moins facilement.
Oh, et dernier conseil. Ne développez pas votre propre système de load-balancer, il y a tellement plus de subtilités que ce que vous pouvez imaginer. Utilisez HAProxy.
Service discovery
Bon, c'est bien cool tout ça. On a une carte de nos ressources, des lignes entre chaque service, la possibilité de rerouter le service en cas de problème, mais on fait comment pour mettre cette carte à jour quand de nouveaux serveurs arrivent ou disparaissent ?
Malheureusement, là dessus, il y a encore du boulot à faire. Les DNS restent la solution de facto pour tester si un service réponds, mais c'est encore assez pourri, du fait du cache (TTL) engendré par le protocole, qui n'est jamais réellement suivi à la lettre.
Zookeeper est une solution à ce problème, mais reste encore un SPOF. Netflix a mis au point une version open-source, nommée Eureka, qui est censé aider à la résolution de ce problème. Mais même de l'aveu du gars de Netflix, ça reste encore moyen, et surtout encore une fois très lié au use-case de Netflix.
Néanmoins, il nous laisse quelques petits tips sur la distribution des items au sein d'un shard. Si on a 3 serveurs pour stocker l'ensemble de nos objets, on peut hasher chaque objet en un ID unique et faire ensuite un modulo 3 sur ce hash pour savoir sur quel serveur le stocker. En faisant ainsi, on a réparti équitablement notre charge sur les 3 serveurs.
Malheureusement, cette approche est un peu naïve, car quand on va ajouter un nouveau serveur au pool et qu'on va devoir faire cette fois un modulo 4, on va devoir déplacer tous les items. Et il n'y a rien de plus couteux que de déplacer des items dans un shard. Non, à la place il vaut mieux utiliser un algo de consistent hashing qui distribue les éléments sur une horloge à 360°. Pour 3 serveurs, cela nous découpe notre cadran en tiers et si on ajoute un 4e serveur, on va avoir un quadrant découpé en 4 quarts. Seuls les éléments qui se trouvent aux bordures auront besoin d'être déplacés.
Test automatisés
Il ne faut pas se leurrer, tout va forcément péter à un moment ou à un autre. La devise chez Netflix est you don't know if you're ready to production unless you break it yourself, intentionnaly and repeatidly.
On est tous d'accord pour dire que faire des backups c'est bien, mais seulement si on vérifie qu'on est capable de les lire ensuite, sinon c'est complètement inutile. Pour la production c'est pareil, faire des fallbacks et éviter les SPOFS c'est bien, mais seulement si on pète la prod régulièrement pour vérifier.
On en revient donc comme souvent à la superbe idée des Chaos Monkeys. On casse des bouts de l'infra, régulièrement, de manière aléatoire, pour voir comment elle résiste, et on consolide là où on détecte des faiblesses.
Leur famille simiesque aime casser des choses à différents niveaux. Le Chaos Monkey va simplement tuer aléatoirement des instances en production. Cela permet de détecter les machins qui ont trop de responsabilités et sans qui le système ne peut même pas tourner en mode dégradé.
On passe ensuite au Chaos Gorilla qui va détruire des zones entières. Cela permet de tester les fallbacks des requêtes, vérifier que les nodes de rechange peuvent assurer la nouvelle charge qui leur arrive dessus et que les backups sont fonctionnels.
Au stade suprême, on a le Chaos Kong qui va détruire des régions entières, ce qui a pour effet de rediriger tout le trafic d'une zone vers une autre. Cela permet de vérifier que les load balancer fonctionnent bien, que le monitoring est capable de détecter les instances mortes et que tout passe bien au rouge sur les dashboard de monitoring. Ils le lancent automatiquement toutes les semaines, et cela passe globalement inaperçu.
Et enfin, un cousin éloigné de cette famille de singes, on a le Latency Monkey qui est encore plus vicieux. Il ne tue pas des instances ou des zones, il se contente juste de leur ajouter de la latence. Car c'est finalement assez facile de détecter un serveur mort, c'est bien plus dur d'établir un diagnostic quand il est lent de temps en temps. Définir qu'un serveur est mort dépends juste du destinataire (s'il ne réponds pas, il est mort), mais définir qu'un serveur est lent dépends à la fois du destinataire mais aussi de l'expediteur (on doit s'attendre à des temps de réponses plus longs quand deux serveurs sont géographiquement éloignés).
Security
La sécurité doit se trouver à deux niveaux primordiaux. Déjà, une sécurité au niveau applicatif. Les serveurs frontaux ne doivent pas exposer de failles de sécurité, le personnel doit être formé aux techniques de social engineering, etc. Mais même si (quand) quelqu'un parvient à s'introduire sur le réseau, il ne doit pas avoir un accès open-bar à tout ce qui traine. Chaque serveur ne doit avoir que des accès limités aux autres serveurs, limités par ce dont il a réellement besoin pour la bonne marche de son système.
Ici encore, le grand conseil est de ne pas développer ses propres systèmes de sécurité. La sécurité c'est un travail d'expert, c'est extrêmement complexe et un système de sécu mal pensé est plus dangereux que pas de système de sécu du tout.
Data
Il finit finalement assez rapidement sur la question du stockage des données. Il faut évidemment plusieurs versions de sa donnée, à la fois pour des backups, mais aussi des instances chaudes qui peuvent reprendre la main quand l'instance principale vient à lâcher. Pour se prémunir d'autres soucis typiquement humains et naturels, il faut aussi stocker sa donnée physiquement dans plusieurs datacenters, à des endroits différents du globe.
Conclusion
Au final, cette dernière présentation conclu à merveille ce dotScale 2015. Même si on y a trop parlé de base de données à mon gout, les quelques derniers REX donnent à réfléchir et permettent de voir les problèmes auxquels d'autres grosses boites sont confrontés et les solutions créatives qu'on est alors obligé de trouver.
Les infra des Géants du Web ont cette particularité d'être toutes complètement différentes car adaptées à des use-cases diamétralement opposés, tout en gardant un socle commun éprouvé durement de multiples fois qui devient maintenant juste du bon sens.
Bref, dotScale c'est pas cher et c'est bon. Si vous êtes sur Paris, mangez en et venez voir comment ça se passe dans les coulisses des grands acteurs du Web.
Le dernier meetupParisHacker avait lieu, une fois de plus, à Tektos. Il y avait une centaine d'inscrits sur meetup, mais on était au final à peine une vingtaine, sans doute la faute à la veille d'un week-end prolongé. En tout cas, c'était dommage.
On a eu le droit à trois talks, entrecoupés de pause pour prendre des bières et du fromage. D'abord, Vincent nous a parlé des challenges rencontrés à Algolia pour avoir un réseau distribué, ensuite Laurent nous a parlé de Couchbase Mobile et Emmanuel de Diffbot.
Challenges of Distributed Search Network
Déjà, je dois dire que bossant avec Vincent, j'avais déjà vu son talk quelques heures plus tôt. Du coup, j'étais un peu moins assidu pour prendre des notes, je vais quand même tenter d'en retranscrire le plus important.
Vincent travaille donc à Algolia, et même s'il travaille essentiellement sur les aspectsfront-end d'Algolia, il nous a quand même donné une idée plus générale de ce qu'il se passe sur un service en SaaS comme Algolia.
Sa présentation était en trois parties, d'abord une explication de ce qu'implique de faire de la recherche sur le net, ensuite ce que propose Algolia et finalement quelques tips et REX.
Search Engine ≠ Database
Déjà, la recherche sur le net, on n'y fait plus réellement attention, mais on passe la majorité de notre temps à faire des recherches sur Google pour trouver ce qu'on recherche. On commence quasiment toutes nos sessions de browsing par une session de recherche, mais il s'empêche que les algos et l'infrastructure qui tournent derrière sont très complexes.
On remarque aussi que bien souvent, la pertinence des résultats de recherches de Google est bien supérieure à la pertinence des résultats au sein même d'un site, si bien qu'on en vient à faire quelque chose de complètement absurde mais qui marche très bien : rechercher sur Google pour trouver quelque chose dans un site en particulier. Mais on reviendra là dessus plus tard, quand on parlera d'Algolia précisément.
Bon, déjà éliminons quelques misconceptions. Un moteur de recherche n'est pas une base de données. Dans une base de données, on fait des tas d'opérations (INSERT, UPDATE, DELETE, SELECT, etc) et on a un langage de query qui permet d'exprimer des demandes complexes.
Par contre, dès qu'on veut faire une recherche full text, on se retrouve avec des opérations couteuses, comme le LIKE %FOO% qui, en plus de devoir scanner l'ensemble des items, ne sait pas gérer les typos ou les pluriels.
Par contre, dans un moteur de recherche, on ne doit s'occuper que d'un seul type d'opération : la recherche. Pas besoin de langage aussi complexe que du SQL, on se concentre sur une seule opération et on l'optimise pour le use-case le plus commun : la recherche full text.
Indexing and Querying
Gérer un moteur de recherche nécessite deux parties. D'abord on indexe, ensuite on recherche. L'indexation consiste à enregistrer les documents de manière optimisée pour le search. Quand ensuite vient la recherche, en plus de retourner l'ensemble des documents qui correspondent aux termes envoyés, on doit aussi les classer par pertinence.
L'indexation peut se vulgariser assez facilement. Pour chacun des documents à indexer on liste les mots qui le composent, puis on fait une liste inversée de ces mots. Ainsi, on a une structure simple clé/valeur qui pour chaque clé (mot) comprends une liste de valeurs (les documents qui contiennent ce mot). Un peu comme un sommaire à la fin d'un livre de cuisine qui va pour la ligne tomate, indiquer toutes les pages de recettes qui utilisent des tomates. Et les résultats de recherche pour foo bar sont donc simplement l'intersection des résultats de recherche de foo et de bar.
Ça, c'est pour la partie théorique et simplifiée. En vérité, la structure qui contient cette relation terme/document est bien plus compliquée pour gérer les pluriels, les synonymes et les fautes de frappe, mais l'idée sous-jacente reste la même.
Algolia
Maintenant qu'on a vu un peu de théorie pour démystifier la recherche, voyons ce que propose Algolia. Algolia se pose comme un Google à l'intérieur de notre application. Plutôt que d'aller chercher dans un index de pages web, Algolia permet d'aller chercher dans un index de données qui nous sont propres (users, produits, vidéos, whatever). La force d'Algolia réside avant tout dans la vitesse d'exécution.
Le temps entre la pression de la touche par l'utilisateur et l'affichage des résultats sur son écran ne dépasse pas les 50ms (latence réseau comprise). Cette vitesse permet de faire des UI qui affichent les résultats directement quand l'utilisateur tape une nouvelle lettre de son clavier plutôt que d'attendre de devoir lui faire recharger une nouvelle page de résultats. Je ne parle même pas de la manière dont tout cela aide le cerveau humain en lui suggérant des éléments plutôt qu'en le faisant travailler à se souvenir de ce qu'il veut taper.
Bref, on a eu une belle démonstration d'Algolia sur HackerNews (spéciale dédicace à ParisHacker). Vincent nous a ensuite parlé du réseau distribué d'Algolia dans 12 datacenters dans le monde et nous a ensuite parlé des trois piliers de la performance qu'Algolia s'efforce d'optimiser : Software, Hardware et Network.
Pour le software, il faut savoir que la première version du moteur d'Algolia était fait sous forme de SDK embarqué dans des applications mobiles. Il fallait donc réussir à tirer profit au maximum des capacités de la machine pour pouvoir créer une expérience de search ultra rapide. On parle là de micro optimisation à la milliseconde. Le code a continué depuis d'évoluer et de s'améliorer et est aujourd'hui inclus directement sous forme de code natif dans les nginx des serveurs Algolia.
Coté Hardware, les serveurs tournent sur du matériel custom, dont les processeurs, la RAM et les SSD sont sélectionnés avec soins. Plusieurs tweaks sont appliqués directement sur le kernel pour avoir aussi les meilleurs rendus, et ce n'est pas le genre de chose qu'on peu faire sur des machines classiques.
Finalement, le gros des pertes de performances venant du réseau, Algolia a misé au maximum sur un réseau distribué de manière à pouvoir être au plus proche des utilisateurs. On a beau faire toutes les optimisation que l'ont peut, il arrive un moment où on ne peut pas faire transiter l'information plus vite que la vitesse de la lumière, donc le seul moyen est de se rapprocher au maximum de l'utilisateur final. En plus de la proximité géographique, il faut faire attention au peering que possèdent les opérateurs où on mets ses serveurs.
Pro Tips
Finalement, Vincent nous a fait part de 10 tips qu'Algolia a appris en mettant au point son infra et qu'ils partagent.
Déjà, il n'existe pas un provider unique et magique qui est présent dans tous les pays du monde avec un formidable débit. AWS c'est cool, mais il n'est pas présent en Inde, en Afrique et dans une bonne partie de l'Asie. Il faut donc utiliser aussi d'autres providers, et dans ce cas il faut essayer d'en avoir le moins possible pour ne pas compliquer les transactions. Aussi, il faut s'attendre à quelques surprises au niveau de la douane, ce n'est pas toujours facile de faire livrer des serveurs dans certains pays et alors il faut attendre plusieurs mois...
Vient ensuite la question du prix. Avec plusieurs providers, la même infra ne coûte pas le même prix dans plusieurs pays. Parfois il n'est pas possible d'avoir la même infra, certains serveurs n'étant pas disponibles, ou alors la tarification est différente. Dans ces cas là, est-ce qu'il faut reporter cette complexité dans la tarification faite à l'utilisateur ou ne proposer qu'un prix unique à l'utilisateur ? Algolia a choisir de masquer toute cette complexité, proposant le même prix à tout le monde.
Proposant une réplication dans 12 datacenters, Algolia a du se pencher sur un système de réplication. Comment faire discuter tout ces datacenters et rendre la recherche distribuée ? La solution la plus simple est souvent la meilleure. Chaque datacenter possède une copie de la donnée et est composé de trois machines. Une de ces machines est un master, sur lequel peuvent se faire les écritures, et les deux autres des slaves qui ne font que de la lecture.
Ensuite, on parle de DNS. Déjà la petite anecdote c'est qu'un .io sera plus lent qu'un .com ou .net. Ayant voulu se la jouer cool, comme toutes les startups, Algolia est initialement parti sur un .io, mais ce TLD étant beaucoup plus récent, il n'y a que 6 serveurs qui font foi pour la résolution de ce TLD alors que .com et .net en ont beaucoup plus.
Algolia utilise la résolution DNS pour sélectionner le datacenter le plus proche de l'utilisateur. Pour cela, il faut un fournisseur qui accepte la geo ip et l'edns. Mais surtout, la résolution DNS est un gros SPOF. Les SDK implémentent donc un mécanisme de fallback si jamais la résolution DNS principale fail, ils vont utiliser un deuxième fournisseur.
Pour s'assurer que tout ceci tourne correctement, Algolia utilise de simples sondes. Ce sont de petits serveurs peu consommateurs, éparpillés dans le monde, qui vont pinguer et exécuter quelques opérations classiques 24/24. Ils envoient leurs données à un master qui affiche l'état du réseau en temps réel sur status.algolia.com.
La fin du talk a été agrémentée de questions et de quelques bières, puis on est passés aux deux autres présentations.
Aujourd'hui, on est habitué à avoir une connexion à peu près tout le temps. Mais quand elle se dégrade, ou pire, quand on n'a plus de connexion du tout, on se retrouve avec une application qui au mieux est lente et frustrante, au pire ne fonctionne pas du tout et est donc encore plus frustrante.
Si on regarde les raisons pour lesquelles les gens laissent de mauvais ratings aux applications sur les stores, c'est globalement parce que les apps crashent ou sont lentes.
Le problème majeur derrière ça que CouchBase Mobile cherche à résoudre est l'endroit où les données sont stockées. Évidemment, si les données sont stockées sur un serveur distant et qu'on n'a pas de connexion pour y accéder, l'application ne peut pas fonctionner.
Par contre, si on inverse le paradigme et qu'on considère que la source principale de la donnée se trouve directement sur le téléphone de l'utilisateur, alors les applications peuvent travailler en mode offline tout le temps. L'offline devient le mode par défaut et la synchronisation avec un serveur distant devient une opération secondaire, quand la connexion revient.
J'avais déjà vu d'autres personnes attaquer ce problème, comme hood.ie ou PouchDB. Là, Couchbase Mobile nous promets une libraire simple à utiliser, rapide, basée sur du json schemaless et qui prends peut de mémoire. Elle fonctionne sous forme d'évènements et se charge de la synchronisation automatiquement.
Son store est un store de type document, avec un système de clé/valeur versionnées (permettant de gérer les conflits entre plusieurs versions, et laissant à l'utilisateur le soin de gérer manuellement les conflits qui ne peuvent pas être réglés automatiquement).
La suite de la présentation était une démo à base de live coding, mais j'ai complètement décroché.
The Web as a structured database
Ensuite, Emmanuel Charon de Diffbot nous a parlé de leur outil de scraping à base de reconnaissance visuelle.
Leur outil fait du scraping de pages web, mais il ne va pas regarder le code HTML sous-jacent, ni même faire de la reconnaissance d'image, il va à la place simuler un cerveau humain à qui on donne une image, et il va en extraire les informations importantes.
Diffbot est capable d'analyser n'importe quelle page web et d'en ressortir une représentation en JSON en analysant le contenu. Il peut en sortir les commentaires, les images, les tags associés (qu'il déduit depuis le texte, même s'ils ne sont pas directement taggués comme tels). Il fait un peu d'analyse de sentiment (positif/négatif) bien que cette partie ne soit pas encore assez au point pour qu'ils la mettent trop en avant.
Le but de Diffbot est de pouvoir permettre de faire des queries de manière humaines, comme "toutes les chaussures qui ont des commentaires qui les disent confortables" ou "toutes les mentions de untel dans les deux dernières semaines".
