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".
Ce mois-ci, les HumanTalks étaient chez Deezer, dans leur belle grande salle du rez-de-chaussée. Un beau frigo rempli nous fait de l'œil, le buffet va être bien, Deezer a tout prévu.
La soirée s'est plutôt bien passée, malgré les quelques fails. Déjà, un des speakers n'est pas venu, alors qu'il avait confirmé encore la veille et n'a pas jugé utile de prévenir. L'un des trois autres speakers l'a alors remplacé au pied levé, mais sa présentation, trop commerciale, n'était pas très convaincante.
Du coup, toutes nos pizzas sont aussi arrivées avec un peu de retard et il a fallu attendre un peu avant de pouvoir manger. Le tout dans une salle bas de plafond, avec une clim qui marche mal. Oh, et on a eu le rétroprojecteur qui s'est mis à faire grève durant l'introduction aussi. Mais sisi, je vous assure, c'était bien.
Github Awards, découvrez votre ranking
Vincent Daubry, co-fondateur de Yooboox et développer Ruby/iOS nous parle d'un petit side project qu'il a récemment mis au point et qui a assez fait parler de lui.
Il avait vu il y a quelques temps une présentation de Sacha, qui parlait des side-projects, et que ceux-ci devaient rester simples, prendre peu de temps et surtout être fun.
Du coup, de son coté il s'est donné 2 semaines, en bossant le soir et le week-end pour terminer son projet. 2 semaines c'est assez long pour pouvoir construire quelque chose, et assez court pour ne pas se lasser.
Son projet, nommé GitHub Awards permet de "noter" les différentes personnes inscrites sur GitHub pour voir qui est le plus gros commiteur sur telle ou telle techno selon différentes zones géographiques. C'est tout con, et ça le faisait marrer, ce qui est largement suffisant pour un side-project.
Pour faire ça il a commencé à récupérer la liste de tous les users de GitHub et leur localisation. Puis, il a récupéré l'ensemble des repos, leur nombre de stars et les langages associés. Il y a ensuite un petit travail pour recoder les coordonnées de location en quelque chose de plus exploitable par son système et ensuite il faut mettre au point une petit formule de ranking de tout ce beau monde.
Bon, l'avantage c'est que GitHub ouvre une API qui permet de récupérer toute ces infos sans avoir besoin de crawler les pages manuellement. Le problème c'est que la masse de données est énorme et GitHub ne permet que 5000 appels par heure par clé d'API. Néanmoins, GitHub propose une version "bulk" de son API qui expose moins d'informations mais permets d'en récupérer plus d'un coup.
Heureusement, il existe à coté le projet GitHub Archive qui indexe depuis 2011 l'ensemble des activités sur tous les repos de GitHub. C'est à dire les commentaires, les PR, les clones, etc. Tout ceci représente beaucoup de données mais est requêtable avec Google Big Query et l'ensemble du dataset, bien que conséquent, peut être monté en mémoire avec Redis.
Du coup, après le coté technique, Vincent à souhaité tester le coté commercial. Il a posté sur HackerNews, a été featuré sur ProductHunt et a ainsi réussi à atteindre les 200 millions de visiteurs (ce qui représente quand même 15% des utilisateurs de GitHub). Ce qui est impressionnant c'est que son site web est un simple Rails (protégé par un bon système de cache) et qu'il a bien tenu la charge.
Sa conclusion, que je partage, c'est qu'il ne faut pas laisser trainer ses side-projects. Il faut les sortir du placard rapidement, pour qu'ils ne prennent pas la poussière, et se donner un temps limité pour éviter cet effet d'abandon.
Licences open-sources
Le second talk, je l'attendais avec impatience. Mickael Andrieu souhaitais nous parler de licences Open-Source et des différences entres elles, ce qui est un sujet bien obscur pour moi.
Malheureusement, je n'en sors pas avec beaucoup plus d'informations qu'avant. Je ne me risquerai pas à faire un résumé du talk car je dois bien avouer que je n'ai rien compris aux explications.
J'ai bien compris qu'il y avait une forte différence entre Libre et Open-Source, mais je suis toujours aussi incapable de l'expliquer précisément, et je ne sais toujours pas expliquer la différence une MIT, GPL et Creative Commons.
Ah si, j'ai noté qu'il avait créé un site, www.choisirunelicence.com qui doit expliquer tout ça en détail.
B.A.-BA du scraping
Alexandre Gindre, ex collègue d'Octo nous a ensuite parlé de web scraping. Il a tout présenté dans des beaux slides brandés Octo mais il a bien précisé que ce dont il allait nous parlait n'était pas fait dans le cadre d'Octo. En effet, certaines parties du scraping sont assez floues vis-à-vis de la légalité.
Déjà, il faut bien faire la différence entre le scraping et le crawling. Le crawling va récupérer la totalité d'un site externe pour l'indexer tel quel de son coté (ce que fait Google typiquement). Le scraping de son coté va "uniquement" extraire certaines infos du site.
L'archi nécessaire pour faire du scraping est assez simple mais est à peu de choses près toujours la même. Dans un premier temps on va requêter le site cible, si possible caché derrière un proxy, et on va en extraire les données intéressantes. On va ensuite stocker ces données chez nous et les présenter dans une nouvelle UI, avec de nouvelles features.
Alors, est-ce que c'est bien légal ? C'est là que c'est flou. Normalement, d'après la loi du droit d'auteur sur les bases de données, ce qui est sur un site appartient à son auteur. Mais en même temps, si ces données sont accessibles publiquement, il peut être admis qu'on puisse les utiliser. La jurisprudence vient rajouter un part de complexité dans l'équation aussi. Opodo avait scrapé les pages de Ryanair, et Ryanair avait alors porté plainte, mais Opodo a fini par gagner le procès car Ryanair n'a pas pu prouver que le scraping leur avait porté préjudice, bien au contraire.
Par contre, si jamais le site cible indique clairement qu'il ne faut pas le scraper, alors il ne vaut mieux pas s'y frotter. C'est par exemple le cas de societe.com. Quand à savoir si une telle indication a réellement une force légale, c'est moins sur.
Ce qui est sur par contre c'est que même si le scraping en lui-même n'est pas interdit, il faut faire attention aux méthodes utilisées. Si on tape dessus comme un bourrin et qu'on mets en péril la stabilité de la plateforme, on risque d'être apparenté à un DDoS, ce qui est cette fois tout à fait répréhensible et relève du pénal.
On connait Opodo comme site de scraping qui agrège les données de plusieurs sources, mais il en existe plein d'autres. Il y a PriceWiki qui scrape le prix d'objets de la vie courante de différents pays afin de comparer le prix de la vie. Rapportive qui mets en commun les informations de LinkedIn, les photos et les adresses mails d'une personne. GetHuman qui scrape les sites webs pour en extraire les adresses mails des gens à contacter.
Si vous voulez le faire vous-même, il existe quelques outils en SaaS qui peuvent vous mâcher une grosse partie du boulot. Kimonolabs qui en quelques clics vous transforme n'importe quelle page en une API. Import.io qui vous propose un GUI pour vous permettre de scraper n'importe quoi, s'occupe de vous masquer derrière un proxy et vous prévient en cas de mise à jour.
En un peu plus manuel, il y a Scrapy et ScrapingHub pour la version SaaS qui vous permet d'héberger vous même le scraper, de gérer la fréquence de mise à jour et le pool d'ip à utiliser.
Si vous voulez le faire à la main, la combo Tor, Squid et Polipo permet de facilement anonymiser ses connections. Après pour parser le HTML et en extraire les infos intéressantes il y a Nokogiri en lib Ruby, mais celle-ci ne gère pas toute la logique de connexion, gestion des erreurs HTTP, etc. C'est juste une lib de parsing HTML, donc il vous faut obtenir le fichier initial.
Il a fini par quelques conseils de sioux pour éviter de trop se faire remarquer. Hidemyass pour changer son ip facilement. Envoyer de simples requêtes curl en HEAD pour checker si la page a été mise à jour ou non. Regarder les flux RSS qui sont une source énorme d'infos sur les pages du site. Regarder les robots.txt et les sitemaps, et envoyer un faux header pour se faire passer pour Google Bots ouvre aussi pas mal de portes.
Un talk super intéressant, pour une discipline que nous avons tous déjà du pratiquer au moins une fois, mais qui est toujours aussi casse-gueule et manuelle.
BackBee
Et donc, le dernier talk, au pied levé par Mickael (qui nous avait déjà présenté les licences libres un peu avant). Il nous a parlé de BackBee, le CMS "orienté gestion de contenu" (?) qu'il développe, fondé sur Symfony et Doctrine.
Encore une fois, j'ai pas réussi à vraiment comprendre ce qu'il faisait. Je me souviens qu'il y a de la config en yaml, un client js en front distinct du back, un système de templating, une API Rest, la possibilité de faire de l'edit in place mais très honnêtement je serai bien incapable de dire ce que ça fait réellement.
Conclusion
Au final, une soirée sympa mais malgré tout placée sous le signe du fail.
Pour la session d'Avril, les HumanTalks avaient lieu chez Meetic. Meetic en a profité pour nous faire une petite présentation de l'historique de la boite. Ils sont aujourd'hui dans la position de la startup qui a grandit très vite, qui a racheté plusieurs autres boites et qui se retrouve très rapidement avec un legacy et un SI complexe. Ils sont aujourd'hui dans une phase de simplification, à base d'architecture REST, d'industrialisation, de TDD, de BDD, un peu de Docker dans un coin, et plein de choses intéressantes.
Ils sortent aussi progressivement du travail avec les prestataires qui ont anciennement développé leurs applications pour les internaliser aujourd'hui, et redonner un coup de jeune à leur présence en web mobile, puis sur le desktop. Ils ont des concurrents beaucoup plus hypes avec Tinder et Happn et veulent rester à la page.
Après cette petite entrée en matière et après la présentation des HumanTalks, on est partis sur les talks.
L'UX n'est pas là où vous le pensez
On commence par le talk le moins technique de la soirée, plutôt porté sur l'UX pour débutants. Christophe Michel, d'Arolla nous raconte une petite histoire de toilettes d'une grande banque française noire et rouge.
Les toilettes sont un lieu exclusivement utilitaire, on y va parce qu'on a besoin d'y aller, et on n'y va que pour une seule chose. C'est donc un très bon endroit pour s'entrainer à faire de l'ergonomie.
Malheureusement, les toilettes dont il nous parle semblent avoir été fait en dépit du bon sens. Les portes ne peuvent pas s'ouvrir complètement car elles tapent contre la céramique des toilettes, obligeant les gens à se contorsionner pour entrer ou sortir. Les pictogrammes sur les portes censés indiquer si ce sont des toilettes homme ou femme sont peu clairs, et il a fallu rajouter une indication au marqueur pour réussir à faire la différence. Une fois toutes ces épreuves terminées, on doit encore se battre avec les lavabos dont la vasque hyper-profonde se voit affublée de robinets qui coulent au ras des bords et d'une sèche-main "automatique" qui ne se mets jamais en marche.
Bref, tout cette introduction permettait de mettre en valeur le fait que les personnes ayant construit ces lieux ne se sont jamais mis dans la peau des utilisateurs. Tout cela sent bon le cahier des charges suivi à la lettre, sans réfléchir à l'utilisation réelle des personnes finales.
Et cela fait un bon parallèle avec le développement des applications. Bien souvent, quand on développe et qu'on reste focus sur les fonctionnalités à ajouter, on ne pense pas à l'utilisateur final. On va mettre des menus déroulants de 125 entrées pour choisir un pays même si 99% de nos utilisateurs seront en France. Et déjà ça, c'est mieux que de demander aux users d'entrer eux-mêmes l'id du pays dans un champ libre...
On utilise aussi des messages de confirmation cryptiques, du genre "Êtes-vous sur de ne pas vouloir annuler votre action ? Oui. Non. Annuler". Dans ces cas là, un messages reformulé et surtout des boutons plus explicites permettent de lever les ambigüités.
Finalement, le talk mettant en garde les développeurs sur la facilité que l'on peut avoir à choisir la solution techniquement la plus simple, et celle que l'on sait utiliser avec notre background, mais qui n'est généralement pas la plus évidente pour l'utilisateur final.
Je regrette un peu que le talk n'est pas donné plus de pistes d'améliorations (faut-il intégrer un ergonome à part entière dans l'équipe, si oui à quel moment ? Au début, tout le long, à la fin ? Ou bien est-ce un travail qui doit être dilué dans toute l'équipe). Je reste un peu sur ma faim, mais c'est une piqure de rappel bienvenue.
Dans les commentaires de la page meetup, Christophe a donné pas mal d'idées de lecture pour creuser plus profondément :
On a ensuite enchainé sur le talk de Jean-Christophe Honde de Meetic, qui travaille justement dans l'équipe de refonte de l'appli mobile. Full disclosure: je viens de passer les 6 derniers mois dans cette équipe, donc le sujet m'étais très familier.
JC a orienté son talk non pas sur les spécificités de la refonte Meetic mais sur le choix de la technologie pour le faire. Ils sont partis sur famous, un framework d'animations JavaScript dont la promesse est de délivrer des performances aussi bonnes sur tous les devices, même les plus vieillissants.
Il explique comment et pourquoi ils ont fait ce choix. Pour lui, une technologie est viable en entreprise si elle corresponds aux trois critères suivantes : le code est testable, la communauté est active, et elle apporte quelque chose d'innovant.
Il est inutile de rappeler pourquoi les tests sont exceptionnellement importants (réduit le cout de devs, évite les non-régressions, fait office de documentation, etc), et on va surtout parler des deux suivants. Une communauté active permet de s'assurer que la techno sera maintenue pendant plusieurs années, et le coté innovant permet à la société qui l'utilise d'avoir un avantage face à ses concurrents.
L'appli n'est pas entièrement bâtie sur famous, il y a aussi un socle en Angular, mais là n'était pas le sujet du talk donc on est passé vite les classiques reproches qui lui sont fait.
Pour JC, la promesse de famous est de réussir là où HTML5 a échoué. C'est à dire que les specs CSS3 promettent monts et merveilles en terme d'animation, mais le support est encore fragmentaire, parfois inexistant ou beaucoup trop lent sur de vieux devices. Famous quand à lui se pose comme une couche JavaScript sur les propriétés CSS 3D Transform. Ces propriétés utilisent la puissance du GPU des devices de manière à utiliser au maximum les possibilités du téléphone, et l'abstraction Famous permet de simplifier leur écriture.
Et ça marche. Famous utilise en partie le DOM HTML classique, mais place tout ses éléments en position:absolute dans un viewport de taille fixe et les anime en CSS. Des tas de démos du framework permettent de s'en rendre compte, tout s'anime dans tous les sens, comme cette table périodique des éléments en 3D.
Sauf que ce que Famous ne fait pas, ce sont les éléments de UI. La librairie ne fournit pas, ou très peu, d'éléments permettant de créer un UI facilement (comme peut le faire Ionic par exemple). Il faut donc récréer soi-même toute cette partie. Au final, on résout effectivement le problème de performance, mais au prix d'un plus long développement pour refaire ce que HTML nous offrait nativement (un peu comme Flipboard et leur surutilisation du canvas.
Si on rajoute à cela que Famous et Angular on des cycles de digest différents et qu'il faut réussir à synchroniser les deux, on rajoute une complexité supplémentaire.
Au final, des dires mêmes de JC, Famous ça marche, mais c'est compliqué. Il faut vraiment vouloir se plonger dedans et avoir un vrai besoin de perfs pour que cela vaille le coup. C'est couteux, mais c'est aujourd'hui d'après lui le seul moyen sur le marché.
Au final, j'en ressors en me disant que c'est une techno puissante, mais que j'utiliserais plutôt pour des animations 3D et pas pour de la UI (à moins d'avoir un vrai prérequis de support de vieux devices comme Meetic).
Son talk était fait comme un cours didactique où on commençait avec un code dont les responsabilités étaient très couplées. Une méthode instanciait un nouvel objet avant de le manipuler, ce qui rendait le tout difficilement testable (car difficile à mocker).
Elle a petit à petit transformé le code en inversant les concerns, et en ajoutant Google Guice dans l'histoire. À noter que l'exemple était évidemment donné en Java (Google Guice étant un framework d'injection de dépendance pour Java), et n'ayant jamais fait de Java, j'ai décroché en cours de route. Malheureusement, ses slides avaient peu de contraste de couleur et environ la moitié de la salle ne pouvait pas lire ses exemples.
J'ai quand même réussi à comprendre qu'une force de Guice était de permettre d'insérer des annotations au dessus de ses méthodes pour indiquer comment l'injection de dépendance devait se faire, ce qui permettait de garder un code simple mais explicite.
Au final, j'ai apprécié la démarche de refacto pas à pas (cela m'a fait penser à un chapitre de Practical Object-Oriented Design in Ruby de Sandi Metz où elle explique aussi par l'exemple comment inverser les contrôles.
Vim, il y a encore des gens qui codent avec ça en 2015 ?
J'ai ensuite donné la dernière présentation, sur vim, mon éditeur de tous les jours. Il est assez difficile de faire un récapitulatif de ce qu'est vim et surtout de donner envie d'essayer en 10mn, mais j'ai réussi à aborder la majorité des sujets qui me semblaient importants.
Vous pouvez trouver les slides ici, mais j'ai avant tout parlé du fait que pour nous autres développeurs, notre éditeur de code est notre outil le plus important. On passe des heures devant jour après jour et année après année, il faut donc que cet outil nous fasse gagner du temps et que ce soit un plaisir de l'utiliser. C'est notre éditeur qui doit se plier à nous et non pas l'inverse.
Je n'ai pas souhaité lancer un troll entre vim, emacs, IntelliJ, Sublime et tous les bons éditeurs qui existent, j'ai simplement parlé de celui que j'utilise et de pourquoi je l'apprécie.
Les avantages principaux de vim découlent tous du fait que c'est un éditeur en mode console. Une fois qu'on a lancé vim, on reste dans sa console et on fait tout au clavier. Vim est pensé comme ça, du coup, tout est pensé pour être fait sans souris, et cela va beaucoup plus vite une fois qu'on connait les touches. Ça permet aussi d'éviter de se faire mal aux avant-bras à force d'aller chercher sa souris sur la table et de se cogner le bras sur le rebords de la table, jour après jour, de manière répétées, pendant des années.
Vim fonctionne en deux modes principaux : le mode normal et le mode insert. Le mode insert est celui que tous les autres éditeurs appellent le mode normal: on appuie sur une touche, cette lettre s'affiche à l'écran. Pour vim en mode normal, quand on appuie sur une suite de touches, notre code en est modifié. On peut se déplacer comme ça dans le fichier, déplacer des lignes ou des mots, changer des arguments, faire des copié-collé.
Pour la petite histoire, j'avais assisté à un ParisJS il y a quelques années où Ryan Dahl, le créateur de nodejs était venu présenter son bébé. Il avait fait une séance de live coding avec vim et j'avais été bien plus ébahi par vim que par nodejs à l'époque. Le code semblait se créer sous mes yeux sans que je comprenne comment il avait fait. Et c'est une force de vim que je retrouve aujourd'hui, maintenant que je connais les commandes principales. La barrière entre le moment où j'ai une idée dans la tête et celle où mon code est modifié pour refléter cette idée est de plus en plus courte, ce qui me permets de rester in the zone.
J'ai finalement terminé en donnant plusieurs exemples de ce en quoi vim était customisable : macros, plugins, remapping de touches, appel à la ligne de commande, etc.
L'exercice était difficile, mais plusieurs personnes m'ont ensuite dit avoir envie d'essayer, je suis donc satisfait :). Si vous voulez jeter un œil à ma config vim, c'est par ici que ça se passe.
Conclusion
Meetic nous a ensuite régalé avec d'excellents bagels et cookies (quantités telles qu'on avait encore de quoi manger le lendemain midi) et les discussions/trolls ont pu continuer sereinement dans la cafétéria.
Le mois prochain, les HumanTalks se passent chez Deezer, venez nombreux !
