C'est Valtech qui nous a fait l'honneur de nous héberger dans leurs magnifiques locaux. On a pu profiter des talks confortablement assis dans de superbes fauteuils de salle de cinéma. Ça a aussi été mon bizutage comme co-organisateur, à monter sur scène pour présenter les HumanTalks à ceux qui n'étaient encore jamais venus. Valtech, Mailjet et Breaz, les sponsors, ont rapidement fait une petite présentation, et les talks ont ensuite rapidement commencé.
Tests de performances
Claude Falguière nous a parlé de la difficulté à faire des tests de performances. Initialement, les tests de perfs étaient là pour s'assurer que la machine cible allait réussir à tenir la charge des requêtes qui allaient lui arriver dessus. Aujourd'hui, avec la puissance du Cloud, il suffit d'agrandir la machine en question pour régler les problèmes de perfs. Le but des tests aujourd'hui n'est plus de s'assurer que la machine tienne la charge, mais que la charge coûte moins cher.
Dans le joyeux monde des entreprises, il y a deux moyens de faire de la perf. Le premier, c'est de ne pas en faire : on fonce, on code, on déploie et ça plante, et après on essaie de patcher pour éviter les catastrophes. Ou alors, le problème est déjà arrivé par le passé et alors on a ancré dans le process qu'il fallait faire des tests de perf. Alors on coche la case sur la checklist avant de mettre en prod et ça nous donne un petit sentiment de sécurité.
Sauf que bien sur, les tests ne sont jamais réellement fait sur un environnement équivalent à celui de production, et donc le résultat n'a pas beaucoup de sens. Garbage in, garbage out.
Le vrai objectif final à avoir, à ne pas perdre de vue, c'est que tout doit fonctionner en prod. On vérifie bien sur en dev si ça fonctionne, car si ça foire en dev, ça va foirer aussi en prod, mais c'est pas parce que ça marche en dev que le travail est terminé.
On peut extrapoler les besoins de la prod à partir d'un petit subset de dev. On regarde les fuites mémoires, on regarde la consommation, et on peut extrapoler sur ce que ça va pouvoir tenir/combien ça va nous couter une fois scalé.
La prod doit être monitorée, on doit avoir des metrics sur ce qu'il se passe quand de vrais utilisateurs utilisent le système dans des conditions réelles. Et ces informations doivent être facilement accessibles, visibles et lisibles par tout le monde. Allez, on peut lacher le buzzword, il faut que ça soit devOps. Il faut que les devs qui ont codé la feature puissent voir son implication sur les ressources une fois en prod, voir la RAM utilisée, le nombre de connexions parallèles, les bottlenecks, etc. Ce n'est que comme ça qu'ils pourront améliorer leur soft pour améliorer les perfs.
C'est un travail régulier, un aller-retour entre le code bien couvé au chaud en dev, puis son exposition au monde extérieur et son amélioration. On peut rajouter quelques tests de performance automatiques, mais uniquement sur les metrics critiques (disponibilité, temps de réponse) et les tunnels critiques (paiement).
Mais les tests ne seront jamais assez, parce que la production est par définition imprévisible. Et la question n'est pas "Et si la prod plante ?" mais "Quand va la prod planter ?". L'infrastructure (et c'est aussi bien du point de vue technique qu'organisationnel) doit accepter l'échec, et apprendre de ses erreurs. Il faut quelque chose de flexible, qui scale, qui soit agile, qui puisse apprendre et trouver des solutions. Par exemple, prévoir une possibilité de faire du feature flipping des features les plus gourmandes permet de réguler la charge en offrant un service minimum degradé.
Il faut aussi penser à un mode dégradé. Que se passe-t'il si l'une des briques vient à tomber ? Est-ce qu'elle emporte tout avec elle, ou est-ce qu'on a un backup ? Par exemple prévoir un opérateur de paiement en ligne de backup au cas où le premier vienne à tomber permet de s'assurer que notre génération de revenus n'est pas intimement liée au bon vouloir d'un third party. Identifier les SPOFs et prévoir un backup.
Une bonne technique pour pouvoir tester une nouvelle feature et ses implications en terme de perfs sans pour autant la balancer directement dans le grand bain de la prod est d'opérer un Dark Launch. On créé en fait une copie de la prod, mais de manière cachée, qui contient la nouvelle feature. Et pour chaque requête qui arrive sur la prod, on la renvoie aussi sur la version dark. On peut voir comme ça si la version dark parvient à suivre la charge ou si elle s'écroule. Et si elle s'écroule, elle ne gêne pas les utilisateurs car elle leur est complétement cachée. Et cela nous génère tout un tas de logs et de datas qui vont nous permettre d'itérer encore sur la version dark avant de la sortir du coté visible.
Une autre technique similaire est de pousser les nouvelles features à de plus en plus d'utilisateurs, graduellement. Par exemple, une feature n'est activée que sur demande explicite des utilisateurs, sur une liste triée représentative ou pour un pourcentage aléatoire. La feature est techniquement en prod, déployée pour tout le monde, mais le feature flipping sélectif s'assure que tout le monde ne soit pas impacté directement.
Ces deux méthodes possèdent néanmoins un défaut, c'est sur la structure des données. Si une partie des utilisateurs ont accès à une feature et pas l'autre, il est probable que la structure de leurs données soit différente. Il faut donc bien s'assurer qu'on puisse faire cohabiter les deux.
Finalement on a aussi un peu parlé de la Simian Army de Netflix qui ressort dans toutes les présentations de ce genre. Elle leur permet de tuer aléatoirement des nœuds de leur infra en suivant le principe que "de toutes façons, la prod va péter, alors autant que ce soit nous qui le fassions".
Au final, encore une fois, pas de scaling sans devOps.
L'holacratie, travailler sans manager
Olivier Le Lan, coach agile de SOAT nous a fait un retour d'expérience sur le changement d'organisation qu'ils ont eu au sein de leur équipe de coachs agiles à SOAT. 4 coachs, managés par une personne. Puis un jour le manager s'en va, et les 4 coachs se demandent s'ils ont besoin d'un manager, ou s'ils peuvent se débrouiller seuls.
Le terme holacratie vient du grec holons, qui veut dire aussi bien l'entité constitutive, que le tout qu'elle constitue.
En suivant l'adage que "Le management, c'est bien trop important pour le laisser à une seule personne", ils ont trouvé une autre solution. Le management, c'est une technologie qui sépare les exécutants des pensants, et comme toute technologie, elle finit par être dépassée. L'agile de son coté remets en cause tout ça, incite les équipes à s'auto-organiser, à faire confiance à l'intelligence collective. Du coup, est-ce que le management est utile en mode agile ?
Il nous a parlé de Zappos qui a supprimé 1500 postes de managers pour les redistribuer à d'autres postes dans l'entreprise, et remis tout le monde au même niveau de hiérarchie.
Chez Soat ils se sont séparés en différents cercles, regroupés par affinités, par buts (cercles de coachs agile, cercles par projets, cercles par techno, etc). Chaque individu faisant partie de plusieurs cercles, et chaque cercle étant auto-organisé.
Le principe fondamental de l'holacratie est qu'on continue d'avoir un manager, mais ce n'est plus une personne, c'est un rôle, qui est tournant au sein des individus d'un même cercle. Chaque individu peut avoir plusieurs rôles (dans différents cercles) et plusieurs individus peuvent avoir le même rôle.
C'est pour le moment une expérimentation chez SOAT, qui porte ses fruits dans le cercle des coachs agiles. À eux 4 ils se sont répartis les rôles et les changent régulièrement (une réunion par mois où les rôles peuvent être changés), chacun est responsable d'être le lien privilégie avec les autres cercles de SOAT (comm', rh, etc).
Le point principal pour la création d'un cercle auto-géré comme cela c'est que tous les acteurs doivent être alignés sur le WHY de leur cercle ET sur le WHY de leur entreprise. Même si les objectifs de chacun sont légérement différents, le but n'est pas d'avoir un consensus de tous, mais un consentement de chacun. Il ne faut pas que tout le monde dise oui, il suffit que personne ne dise non.
Il y avait un sceptique dans la salle pour qui une telle organisation était utopique, et qui était rassuré de voir qu'on ne supprimait pas le management, mais qu'on supprimait juste le manager. La différence est que ce rôle de manager qui est dévolu à l'un des membres du cercle ne doit pas lui prendre plus de 10% de son temps, par opposition à un individu dont c'est le travail fulltime.
REX très intéressant au final, l'expérience semble très bien se passer à SOAT.
Ionic Framework
Loïc Knuchel nous a ensuite parlé d'un sujet plus tech, le framework Ionic. Mélange d'Angular et de Cordova, il permet de développer des applications hybrides assez facilement.
Loïc est un dev-front end et un entrepeneur, et il a plein d'idées. Et la plupart du temps, ces idées se décomposent sous forme d'appli mobile. Avec Ionic, il peut rapidement faire des protos pour les tester.
Ionic est livré avec une batterie de composants (packagés sous forme de directive Angular) pour la majorité des besoins de UI des applis d'aujourd'hui. C'est un peu le Bootstrap de la UI mobile web, avec des sliders, des listes, des boutons, des pull-to-refresh, des popovers, des onglets, etc.
Visuellement, les styles sont très orientés iOS mais une version Material est en cours. Ionic est aussi livré avec un petit outil en ligne de commande qui permet de générer un splashscreen, des icones, de gérer le livereload, d'inclure Crosswalk pour une execution plus rapide, et de tester les différentes vues Android/iOS directement dans le browser.
La version 1.0 vient de sortir officiellement, ce qui donne vraiment envie de tester le système pour des POCs rapides. Pour une petite idée d'appli qui reste dans les standards de UI actuels, et pour se concentrer uniquement sur le fonctionnel, ça semble un choix tout à fait sain. Je testerai sans doute sur un side project bientot.
Il n'y a pas de gestion native de l'offline, mais des plugins cordova (donc non-spécifiques à Ionic) permettent de l'ajouter.
Bien sur, ça reste du web mobile, avec de l'Angular, dans une WebView donc oui ça sera moins rapide que du natif, mais ça restera assez rapide pour qu'on ne s'en plaigne pas. Ça a aussi l'avantage de pouvoir se prendre en main plus facilement par des fronteux, et ça peut soit se packager sous forme d'app, soit directement accessible sous forme de site web (et dans ce cas, pas besoin d'approbation du store).
L'intrapreneuriat, qu'est-ce que c'est ?
Finalement, c'est Christopher Parola, co-fondateur d'elCurator qui vient nous parler d'intrapreneuriat. Ayant suivi un peu la vie d'elCurator à Octo, son talk a quand même répondu à quelques questions que je me posais sur cette structure (pourquoi ? qui possède quoi ?).
Il nous raconte un peu le début du projet, une idée qui avait été lancée à Octo, lui et Jérémy qui travaillent dessus sur leur temps perso, le partage au sein d'Octo. C'était un parfait bac à sable pour eux deux pour apprendre Rails et le Lean Startup. 2 ans plus tard, elCurator est une structure à part entière et eux deux en sont salariés.
Question financement, au début tout est payé de leur poche : nom de domaine, hébergement. En tournant sur Heroku, ils limitent énormément les coûts. Plus tard, ils seront hébérgés dans les locaux d'Octo.
Pourquoi avoir fait la bascule au bout de 2 ans ? Pour eux, c'est parce qu'ils commençaient à avoir des clients, et l'envie de travailler sur le projet à temps plein, mais cela peut-être fait plus tôt, voire dès le début. L'intrapreneuriat est encore quelque chose d'assez vague, il y a très peu de littérature sur le sujet et peu d'exemples, donc il n'y a pas vraiment une seule façon de faire, c'est en fonction du projet, des sociétés et des gens.
C'est d'autant plus flagrant au niveau de la structure juridique. Il n'y a aucune règle particulière, aucun statut spécial, tout est encore une fois à faire en bonne intelligence avec l'entreprise. Dans le cas d'elCurator, ils ont monté une SAS, et se sont répartis les parts. La question de la propriété intellectuelle du produit est par contre une question plus complexe à résoudre, surtout dans le cas d'elCurator où une partie a été créé sur du temps perso et une autre sur du temps de salarié Octo. Son conseil: statuer sur ce point le plus tôt possible.
Le même conseil est donné quand à la répartition des parts. Plus la société est créée tard, et donc plus la répartition des parts à lieu tardivement, plus les négociations sont complexes. Une fois que le projet est parti, que du monde a travaillé dessus, qu'il rapporte déjà de l'argent, il est plus dur de discuter séparation des parts. Bien sur, il ne faut pas non plus commencer à se séparer les parts alors que rien n'a été créé, on risque de tomber dans le syndrome du groupe de rock d'adolescents qui splitte avant d'avoir écrit la moindre chanson car ils ne sont pas d'accord sur comment séparer leurs futurs millions.
Dans le cas d'elCurator, la séparation a été effectuée équitablement entre les deux associés et Octo, puis Octo a abondé pour racheter des parts, un peu comme une levée de fonds.
Pour l'entreprise, incuber une société lui permet d'innover dans un domaine qui n'est pas son domaine premier, lui permet de se diversifier, et de ne pas perdre des collaborateurs qui seraient sinon partis faire leur projet ailleurs. Pour les créateurs, l'avantage majeur est la sécurité. En restant incubé chez Octo, ils continuaient de garder leur salaire pendant 2 ans, tout en bénéficiant de locaux, d'un écosystème et d'un carnet d'adresse.
La différence majeure entre un intrapreneur et un entrepreneur se situe ici. L'entrepreneur se moque des risques, il croit fermement à son idée et est prêt à vivre de peu, de travailler beaucoup, pour monter son idée.
Finalement une question de l'assistance qui m'a semblé assez folle, sur une rumeur qui court sur Octo. D'après la personne qui posait la question, Octo donnerait environ 20% de temps à chaque employé pour travailler sur des projets perso (à la Google), mais si jamais ces projets sont rentables, tout les bénéfices vont dans la poche d'Octo. Pour être plutôt bien placé pour le savoir, je peux dire que cette rumeur n'est vraie ni dans ses fondements ni dans ses conclusions.
Conclusion
Super session, comme d'habitude. 4 talks très intéressants et des discussions qui ont duré jusque tard dans la nuit après coup. Du technique, de l'orga, des retours d'expérience, un très bon mélange !
Première fois que je mets les pieds dans un meetup Meteor. Je n'ai jamais touché à la techno et ne l'ai suivie que de loin. Mais comme l'invité d'honneur de ce meetup est mon pote Sacha, j'y suis allé par curiosité.
Criteo a hébergé le meetup, dans une salle très spacieuse. Bon, c'était en sous-sol et on n'avait pas d'accès Wifi, mais ils se sont carrément rattrapé sur le buffet (Sushis + pizzas pour nourrir un régiment). Comme d'habitude, Criteo fait son speech de recrutement bien rodé : "on est gros, on paye bien, on a toutes les stacks dans notre SI, il suffit juste que vous soyiez assez bon pour nous rejoindre".
Pour en revenir aux meetups Meteor, ça fait deux ans qu'ils existent, mais de manière assez organique, sans véritablement de date fixe, ni de format spécifique. À partir de ce meetup, ils deviendront réguliers, tous les 3e mardis de chaque mois (choisi de manière à ne pas se mettre le même soir que d'autres meetups déjà existants). Ce soir, le format était de 4 présentations, suivi d'un buffet, puis de discussions par groupe. Au final, après avoir mangé, les discussions ont continué, mais de manière très informelle, et c'était pas plus mal.
Meteor + Docker
La première présentation était d'un side projet qui permet de piloter des instances Docker depuis une UI web. La motivation était de ne pas avoir besoin de taper des lignes de commande longues pour spawner des instances, et de pouvoir voir sur un dashboard l'état de ces instances.
Visuellement ça ressemble à un site classique en Bootstrap, avec la liste des images disponibles, possibilité de les spawner en un clic ou de configurer un peu les valeurs par défaut (port, working directory, etc).
Par derrière, Docker exposant une API REST avec un endpoint streamant le flux des events, Meteor se pluggue juste dessus et transmets ces events dans une base mongoDB. La base représente donc à tout moment l'état actuel des instances. Ces états sont alors renvoyés en temps réel aux différents clients.
Ça signifie que même les instances lancées/tuées depuis une autre source que l'UI web sont quand même visualisables dans la UI.
La facilité avec laquelle on peut plugguer un flux d'event dans du web temps réel sur X clients était assez impressionante, même si je ne suis pas bien sur du use-case d'un tel projet.
Telescope
La seconde présentation était celle de Sacha. Il présentait Telescope, le projet open-source sur lequel il travaille depuis 2 ans, et qui lui a servi de base/exemple pour le livre Discover Meteor.
Telescope est destiné à créer un clone de HackerNews. Une liste de threads, sur lesquels les gens peuvent voter et laisser des commentaires. Mais surtout, il est extensible pour que chacun se l'approprie et puisse rajouter de nouvelles fonctionnalités.
Il nous a fait un tour d'horizons des différentes versions de Telescope disponibles en production. Déjà crater.io, qui rassemble la communauté meteor en restant très proche du telescope original.
thedrop.club de son coté utilise telescope pour la musique. Chacun peut poster une musique de soundcloud, tout le monde peut voter, et le site se transforme alors en immense playlist qu'on peut jouer depuis son browser.
On a codebuddies où chacun peut proposer une room hangout pour discuter d'un problème de code. On réserve sa place, puis on se retrouve à l'heure donnée pour discuter. On continue une version proche de thedrop, mais pour les beatbox en video (j'ai pas retrouvé le lien par contre).
Et finalement, un seconde création de Sacha, crunchhunt qui agrége tous les posts de TechCrunch et les classe par nombre de share, avec un aperçu. Pour ça il utilise une fonction native de meteor qui parse un flux RSS, il rajoute un coup de kimonolabs par dessus pour APIfier les pages de TechChrunch pour en ressortir le nombre de shares et génère un thumbnail avec l'API d'embedly.
Au final, on voit que Telescope peut être utilisé pour créer rapidement des sites sur le même modèle, et ça peut être un très bon exemple pour apprendre à structurer son code Meteor.
Finalement, la session de question réponse à porté sur les plugins intéressants à utiliser. simpleschema apporte le principe de Model (le M de MVC) et les validations qui vont avec. autoform permet de générer automatiquement des formulaires de CRUD pour ces schemas.
Je retiendrais que Meteor est très au point pour ce qui est de la gestion du cache. Comme le code client et serveur est mélangé, dès qu'on pousse une modification sur le serveur, tous les clients la reçoivent instantanément. Par contre, vu que tout est basé sur des websockets, le scaling de ce genre d'appli n'est pas évident, mais ce n'est pas un soucis propre qu'à Méteor. De même, il subit les mêmes problèmes que n'importe quelle appli SPA : pas de server-side rendering, donc il faut que tout le JS soit chargé coté client avant que quoique ce soit ne soit affiché, et défaut de SEO.
Startups d'État
Matti Schneider nous a ensuite parlé de son travail en Meteor au sein des startups d'état. En particulier, il nous a parlé de comment il a pu développer en 5 jours une appli Meteor de simplification de gestion des fiches de banc.
Vous ne savez pas ce que sont les fiches de banc ? Et bien moi non plus je n'en avais aucune idée. Si j'ai bien tout retenu (parce que c'était quand même pas la procédure la plus simple), ce sont les fiches qui servent à tenir le compte des amendements sur une loi. Celles-ci se retrouvent imprimées en plusieurs exemplaires (selon un formalisme sans doute hérite de Napoléon) et rangé dans des classeurs.
Quand une loi possède des milliers d'amendements (parce que nos députés n'ont pas envie qu'elle passe trop vite), il faut des salles entières pour stocker les classeurs en questions, et garder l'ordre chronologique des amendements devient une tache titanesque qui demande énormément de travail manuel.
Matti a donc rapidement développé un POC en se basant sur une API de l'Assemblée Nationale qui permet de récupérer la liste des amendements (dans un format XML non documenté quand même sinon ça serait trop facile). Et à partir de là, c'est juste une question de skill Meteor pour présenter cela dans une belle UI qui permet à chaque cabinet de député de lister les amendements et indiquer un résumé en quelques lignes et si le député doit voter pour ou contre.
Bref, une belle simplification !
Libreboard
Une autre démo technique en Meteor hyper impressionnante. Celle-ci n'est rien de moins que la réimplémentation open-source en Meteor de Trello. Exactement les mêmes features que Trello (même plus, avec l'i18n), mais libre et installable chez soi.
Bon, vu qu'ils ont quand même piqué la CSS de Trello ils ont du enlever le projet de GitHub, mais il est quand même dispo sur leur git perso.
Franchement, impossible de voir la différence avec l'original, c'est vraiment du beau boulot.
Tuniliv
Finalement, une demo de tuniliv, un site Tunisien permettant de faire de la livraison entre particuliers. L'un passe une annonce comme quoi il souhaite envoyer un objet (taille Small, Medium, Large) de telle ville vers telle ville. Un autre peut accepter l'offre et se faire rémunerer pour ça.
La démo a été faite avec deux browsers ouverts ensemble pour montrer les interactions entre les deux, ça marche plutôt bien. Le site n'a pas encore réussi à terminer complétement une transaction entre deux personnes, mais en même temps il n'est pas en production depuis longtemps.
12 édition de ParisHacker. J'étais allé aux premières éditions il y a quelques années, où on discutait des top topics d'HackerNews, où chacun pouvait présenter quelque chose en 5-10mn, où des questions étaient posées à la cantonnade.
Tout ce coté s'est un peu perdu, et j'ai plus l'impression d'aller à un meetup de devs (globalement experimentés), voir quelques présentations sur des sujets divers, mais sans forcément de fil conducteur.
Bref, cette fois-ci, c'était chez Tektos, un incubateur du coté de Marcadet-Poissonniers. Ils incubent des startups assez longtemps (ils en ont une avec 40 employés), et semblent se spécialiser surtout dans les startups tournées vers un marché anglophone.
On a eu le droit à une petite panne de courant dans la salle du meetup qui nous a obligé à nous déplacer dans une autre salle avant que les talks ne commencent réellement.
Hosting large audience websites with Varnish
Maxime Kurkdjian d'Oxalide nous a parlé de leur business d'infogérance des gros sites de presse français. Le début de la conférence était en anglais (ce qui est d'usage aux ParisHacker), mais Maxime avait beaucoup de contenu à nous faire passer et la barrière de la langue l'obligeait à limiter les informations qu'il souhaitait faire passer. On a donc décidé de revenir en français pour la fin de la conférence, et c'était du coup beaucoup plus riche.
Oxalide s'occupe des sites de 20 minutes, l'Express, le parisien ou encore Radio France. Leur cœur de métier est l'amélioration des perfs et la tenue de charge dans les métiers des médias et de la presse.
Ce sont des sites qui possèdent beaucoup de contenu, avec de nouvelles pages ajoutées chaque jour. En cas d'actualité intense, les serveurs sont très demandés, et les pages mises à jour régulièrement. Les articles les plus récents sont beaucoup plus demandés que les articles anciens. Il faut donc réussir à faire scaler tout cela, idéalement sans avoir à changer le parc informatique existant, mais juste en rajoutant le bon système de cache devant.
Le 7 Janvier, les attentats de Charlie Hebdo générent un nombre record de pages vues sur leurs services. 56.000 requêtes / seconde en moyenne, pour plus de 157 millions de visites dans le mois. C'est la plus grande affluence qu'ils aient jamais eu a gérer.
Le challenge d'Oxalide, c'est de réussir à gérer de gros traffic, sur des sites qui ne sont pas forcément bien optimisés pour de la perf. Il lui a été posé la question en fin de session "Si j'ai un site avec 500 millions de requêtes par jour, ça me couterait combien chez vous ?". Il a répondu qu'il ne pouvait pas donner de chiffres aussi facilement, parce que cela dépends pour environ 80% de la dette technique du site qui est derrière. La techno n'a ici aucune importance, c'est vraiment la dette technique et les améliorations sur les serveurs d'origine qui vont être un facteur limitant.
Bref, revenons à Oxalide. Même s'ils peuvent mettre des tas de choses dans le cloud, spawner de nouvelles machines en cas d'affluence, tout n'est pas si rose. Le cloud nous fait croire que nous avons des ressources illimitées à notre service, mais cela n'est pas complétement vrai. Tout simplement parce que notre portefeuille, lui, n'est pas illimité. Il va donc falloir être efficace avec les machines qu'on a.
Continuous improvement
La première étape, c'est de se mettre des objectifs. Nous avons besoin de réponses quantifiables à des questions simples. Quel doit être le temps de réponse maximum autorisé ?, quelle charge doit être tenue sans avoir à dégrader l'UX ?, à quelle vitesse le site doit réagir à des pics de charge ?, quel est le response time autorisé en cas d'affluence ?, etc.
On track toutes ces infos dans des dashboards qui nous donnent l'évolution à court terme, et à long terme. Les seuils doivent être fixés par la direction de l'entreprise. C'est elle qui sait, en fonction de son business model, ce qu'il vaut mieux privilégier.
Réussir à tenir face à une montée en charge, c'est comme jouer à un tower defense. On doit protéger ses ressources les plus chères et les plus fragiles de la horde de connexions qui vont arriver. Nos back-end PHP et nos DB mysql font parti de ces assets à protéger.
On mets donc un cache Varnish devant. Il va absorber 90% des requêtes directement. Ensuite, derrière le Varnish on rajoute quelques autres protections pour réduire l'impact des requêtes qui sont passées : APC, memcache, query cache.
Avec un Varnish bien configuré, on peut multiplier la capacité d'un site par un facteur de 100, et réduire le temps de réponse par un facteur de 10. Comme effet bonus, avec un temps de chargement plus rapide, on améliore aussi l'UX finale.
L'idée est d'avoir un taux de caching de 90% et de tendre vers un 100%.
Varnish en détail
La perfection, ce n'est pas quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à enlever.
Cette citation de St-Exupery est parfaite dans le domaine de l'optimisation de montée en charge. On veut que chaque élément qui se trouve sur la zone de défense entre les clients et nos serveurs finaux soient le plus rapide possible, et pour ça, il faut qu'il soit le plus léger possible.
Oxalide préconise d'avoir deux lignes de Varnish. La première, la plus proche des clients est la plus stupide possible. Elle sert de cache HTTP simple. Elle peut contenir des dizaines de serveurs Varnish si nécessaire. La deuxième, juste derrière, fait des choses un peu plus intelligentes. Elle active la compression gzip, gère la validation des assets, etc.
En faisant ainsi la première ligne réponds très vite, et si une requête fait un cache miss, elle va taper la seconde, qui est aussi bien rapide, sans avoir à taper les serveurs d'origine. Cette topologie permet aussi de facilement spawner des Varnish en première ligne, qui peuvent être dans le cloud, et donc les décommissioner rapidement une fois la charge terminée. À noter que quand on ajoute un nouveau Varnish dans un pool, il commence avec un cold cache, et va donc devoir requêter l'origine pour se former son cache. Encore une fois, en ayant un deuxième niveau de Varnish, il ne requête pas directement l'origine.
Attention toutefois au domino effect. Il faut faire attention à la consommation de chacune des machines d'un pool de serveurs Varnish. Si on a deux machines et que les deux sont environ à 50% de leur capacité, si l'une tombe, l'autre va se manger toute la charge de la première, et dépasser ses 100% de capacité et tomber aussi. Il faut toujours avoir suffisamment de machine dans un pool pour que même si une machine tombe, la charge sur les autres ne dépasse jamais 50%.
Hardware
Quand on doit gérer du très fort traffic, le commodity hardware ne suffit pas. On veut des éléments qui répondent vite, et qui ne fassent que ça. Il faut donc choisir son hardware en fonction, et Oxalide continue de monter des serveurs physiques "comme avant", pour éviter la couche de virtualisation qui prends du temps, et être au plus près du barebone.
Plusieurs optimisations peuvent se faire directement au niveau du BIOS, et la configuration out of the box des machines du commerce ne fonctionne jamais pour un besoin spécifique de grosse charge.
Le simple fait de changer la taille de la congestion window TCP permet des gains de perfs de 30% sur le réseau.
DevOps
Si on veut gérer un énorme traffic, il faut savoir qu'on va se planter plusieurs fois avant d'y arriver. Pour ça, il ne faut pas avoir peur de l'échec, et apprendre de ses erreurs. Il faut aussi une culture de devOps. S'il y a séparation entre les équipes de dev et les équipes de prod, aucune optimisation ne peut être fait.
Les ops fournissent aux devs des dashboard pour qu'ils puissent suivre l'évolution des différentes mises en prod, des pics de charge actuels, des fichiers les plus sollicités, des bottlenecks dans le code, etc (avec Kibana. Comme ça les devs peuvent aider sur ces points, trouver des solutions et avoir un vrai retour sur l'implication de leur code sur leurs utilisateurs.
Encore une fois, le travail des dev, leur disponibilité, leur implication a beaucoup plus d'importance dans la réussite de la montée en charge que l'installation du Varnish devant. Pour Oxalide, 80% de la reussite ou non de la montée en charge vient du code de l'appli et de sa dette technique. Varnish peut aider, mais pas faire des miracles.
Questions
Viennent ensuite plusieurs questions diverses.
Est-ce que Varnish peut être utilisé à l'intérieur d'un SI, entre deux apps qui communiquent par API ? Oui, sans problème.
Est-ce que Varnish peut aider à cache une API en SaaS où chaque requête est dynamique et dépends du user authentifié ? Oui, à partir du moment où deux requêtes identiques donnent un résultat identique, Varnish peut aider. Si deux fois la même requête donne un résultat dynamique différent, alors non.
Exemple donné de MediaPart qui a multiplié par 5 son nombre d'inscrits après l'affaire Cahuzac. Ils n'ont pas changé leur infra, juste tweaké un peu plus leur Varnish.
Est-ce que Varnish est aussi intéressant pour un site d'e-commerce que pour des sites de presse ? Oui, sur un site d'e-commerce, 99% du site sera en cache dans Varnish, seul le panier et le tunnel de paiement tapera sur l'origine.
On a ensuite eu la droit à un Skype avec Pierre-Rudolf Gerlach, co-fondateur et CTO de Qleek. Qleek est à mi-chemin entre le software et le hardware, le dématérialisé et le physique.
C'est un petit bout de bois de forme hexagonale qui contient une puce RFID dans laquelle on peut stocker n'importe quelle musique, film, playlist, image. Il suffit ensuite de la poser sur un lecteur tout aussi sympa (en bois, de forme douce) pour jouer l'élément en question sur la télé.
Ça permet d'avoir un support physique aux œuvres qu'on aime, sans avoir à démultiplier les formats.
Pierre est un ex-Joshfire, donc habitué des meetups des ParisHackers. Il a aussi bossé sur le Nabaztag donc tout ceci ne lui est pas étranger.
Ils sont trois sur ce projet et après avoir été incubé à Numa (ex-Camping), ils sont maintenant à Bolt, un incubateur hardware à Boston. Le Camping a pu les aider sur le début, sur la partie entrepreneuriat, un peu sur le software, mais n'avait pas d'appui sur le coté hardware.
Leur système fonctionne, ils peuvent en produire, mais ils ne peuvent pas encore en produire en masse et l'incubateur en question va les aider à faire ça. Ils y testent de nouveaux matériaux (liège, plastique, verre), testent leur produit à des températures extrêmes, sous l'eau, sous une forte pression, pour tester ses limites.
Coté software, c'est en grande partie du web, je crois que le backend est en node mais pas sur. Coté hardware on a du RFID, du BLE, de l'ARM et de l'Android. Tout ça dans un mélange de bois, métal, aimants, avec une impression d'image sur le bois pour les personnaliser.
Il existe apparemment plusieurs accelérateurs hardware. Il y a Haxlr8r à Shenzen ou encore Highway 1 à San Franciso. Le leur, Bolt, a incumé iRobot (créateur du Roomba ou encore Pebble. Il est en plein centre-ville de Boston.
La difficulté qu'ils rencontrent actuellement est sur la packaging. Il faut que celui-ci puisse mettre le produit en valeur et expliquer en moins de 2s ce qu'il fait. Il faut aussi beaucoup travailler sur le speech d'explication du produit, et sur le nom à lui donner.
Tous les participants travaillent sur le même problème par équipe de 2 à 4. Google leur fournit un fichier d'input, et un problème à résoudre. Les équipes doivent fournir un fichier d'output et une note leur est automatiquement discernée en fonction de l'output. L'année dernière par exemple, ils avaient un fichier représentant les rues de Paris et ils devaient calculer l'itinéraire optimal pour qu'une Google Car les quadrillent.
Les inscriptions se terminent le 8. Je ne pense pas participer. Je m'étais inscrit l'année dernière mais je m'étais fais recaler dès l'inscription car ils avaient trop d'affluence. Cette année ils donnent un test préparatoire à faire le soir comme épreuvre de pré-sélection.
Au final, passer des épreuves éliminatoires, pour ensuite tous être en compétition pour résoudre un problème de Google me tente pas du tout. Je préfère les hackathons open bar, où tout le monde construit des choses différentes, innovantes, ensemble et pour le fun.
Vendredi soir avait lieu au théatre du Rond-Point une conférence de Kyan et Navo sur leur processus créatif lors de la conception de la série Bref. J'avais déjà eu la chance d'écouter cette conférence il y a quelques mois, mais la voir en live cette fois-ci m'a donné envie de partager un compte-rendu des conseils qui y étaient donnés.
Leurs conseils viennent de leur expérience dans la création d'une série courte comique, mais la trés grande majorité des conseils peuvent s'appliquer à n'importe quel acte de création, depuis l'écriture d'un roman à la fondation d'une startup.
Vous avez quelque chose à dire
Le premier conseil pour se lancer est de ne pas croire qu'on n'a rien d'intéressant à dire ou à offrir. On était une centaine dans la salle à assister à la même conférence, néanmoins si on avait du chacun écrire sur un papier notre expérience, on aurait tous raconté quelque chose de différent. Un même événement peut être raconté de manières complétement différentes et aucune n'est plus légitime qu'une autre.
Just do it.
Au delà du slogan de Nike, cet adage est l'un des plus importants pour moi. C'est bien beau d'avoir des idées, mais sans leur réalisation, l'idée ne vaut rien. J'ai rencontré beaucoup d'entrepreneurs qui étaient persuadés d'avoir l'idée du siècle et qui avaient juste besoin d'un développeur pour la réaliser.
C'est pas comme ça que ça marche. C'est extrémement simple d'avoir des idées. Tout le monde a des idées, et c'est même très probable que d'autres personnes aient exactement les mêmes idées que vous. Mais imaginer un concept ou un produit dans sa tête c'est trop facile. Tout le monde peut être un génie dans sa propre tête. C'est quand on sort son idée dans le monde réel que la véritable aventure commence.
Parce qu'une fois qu'on la sort dans le monde extérieur, qu'on la confronte à d'autres personnes, à un marché, on risque de se prendre des murs, on risque de se planter. Notre si belle idée n'est finalement peut-être pas viable. Mais sans cette étape, on ne l'aurait jamais su. Il est donc indispensable de faire des choses, de passer son idée de simple concept à une réalisation concrète.
Des gens qui ont des idées il doit y en avoir approximativement 7 milliards sur Terre. Des gens qui réalisent quelque chose à partir de ces idées, il y en a déjà beaucoup moins, et ceux qui parviennent au bout de leur réalisation sont vraiment très peu.
Faites des choses, tentez, essayez, plantez-vous. Si vous ne vous plantez pas, c'est que vous n'avez pas innové. Si vous réussissez du premier coup, c'est que votre idée n'a rien de révolutionnaire.
Dumpez
Adeptes du GTD ou de Anki, vous devez connaitre ce principe. Dumpez. Ne laissez pas votre esprit être encombré de trop de choses. Vous avez une idée, notez là dans un carnet, envoyez-vous un mail, mettez là sur Evernote. Vous ne pourrez sans doute rien en faire aujourd'hui, mais au moins vous l'avez notée et un jour viendra où vous pourrez vous en resservir.
Kyan donne l'exemple du carnet dans lequel il note le nom des acteurs qu'il a aimé voir au théatre. Navo écrit sur son blog depuis des années des tas de pensées. En quand ils ont du réaliser Bref, ils ont acceléré leur casting grâce au carnet de Kyan, et ont pu transformer des notes de blog en épisodes.
Lors de l'écriture de Bref, ils ont balancé en vrac toutes les vannes, tous les trucs drôles qu'ils avaient en tête et dans leurs carnets. Ensuite, ils les ont regroupés sous des thèmes communs, qui ont ensuite donné lieu aux épisodes. Ils appellent cette technique des "jouets et des chambres". J'utilise quelque chose de très similaire quand j'écris mes scènarios de jeu de rôle et ça permet d'avoir une matière première très facilement.
N'ayez pas peur de montrer ce que vous faites
Je vois beaucoup d'entrepreneurs qui ne veulent pas parler de leurs idées de peur de se les faire voler. Encore une fois, les idées ne valent rien sans leur réalisation. Mais surtout, en empechant l'idée se se faire connaitre ils empechent complétement leur projet d'aboutir.
Peut-être allez-vous vous faire voler votre idée. Et alors ? Des idées vous en aurez d'autres, non ? Je l'espère pour vous en tout cas. Si vous pensez que vous n'avez eu qu'une seule bonne idée de toute votre vie, laissez moi vous dire qu'il y a peu de chance que cette idée soit bonne.
Les gens qui ont des bonnes idées les ont par dizaines. Ce sont des poules aux œufs d'or. Ils pourront continuer d'en avoir, même si on leur en vole une. Alors que les voleurs sont incapables d'avoir des idées. En vous volant votre idée, le voleur vous a rendu service. Vous savez que c'est un voleur maintenant, et vous ne lui ferez plus confiance et vous ne vous ferez pas voler votre prochaine idée qui est encore mieux.
De toutes façons, vous y gagnerez plus à vous faire voler une idée et la voir grandir dans le monde réel, même si vous n'y participez pas, plutot que de ne rien produire du tout.
Encore une fois, tout le monde a des idées, mais peu de personnes sont capables de les réaliser. C'est pas grave de se faire piquer des idées, c'est pas ça qui manque. Et on ne peut pas vous voler votre capacité de réalisation, c'est ça qui compte.
J'ai beaucoup aimé le petit dialogue imagé entre Kyan et Navo sur ce sujet :
— Oh, j'ai une super idée.
— Ah ouais, c'est quoi ?
— Nan, je peux pas te le dire, tu va me la voler.
— Ah. Ben viens, je te présente quelqu'un.
— Nan, nan. Il va me voler mon idée lui aussi.
— Comme tu veux...
— C'était qui d'ailleurs ?
— Le succès.
Ayez de la chance
Ce conseil parait idiot, mais c'est l'un des conseils les plus importants pour réussir. Personne ne parvient à créer quelque chose de neuf sans avoir de la chance. Mais surtout la chance, ça se provoque.
Navo aime à raconter l'histoire de cet homme très croyant qui jour après jour, pendant des années, prie Dieu pour lui demander de le faire gagner au loto. Si bien qu'après des années Dieu lui apparait et lui dit : "Écoute, je veux bien te faire gagner au loto. Mais s'il te plait, joue."
Beaucoup de gens pensent que la chance arrive comme ça, sans raison. Qu'un jour un producteur ou un investisseur va venir frapper à votre porte alors que vous êtes chez vous en slip en train de réfléchir à votre idée et vous proposer beaucoup d'argent pour enfin la réaliser.
Non.
Ça ne marche pas comme ça. Avant de pouvoir récolter de la chance, il faut savoir semer du risque. La chance, ça se provoque. Il faut tenter des choses, se faire voir, rencontrer du monde, partager, montrer ce qu'on fait. Le talent et la créativité ne font pas tout, la chance a aussi une part énorme à jouer.
Il faut savoir accepter la chance, la respecter, et la provoquer.
Créez votre famille
Même quand vous faites quelque chose de chiant, faites-le bien. Si vous travaillez un jour avec quelqu'un et que vous faites un sale boulot, il s'en souviendra et le jour où il aura besoin de quelqu'un pour monter son projet, vous pouvez être sur que ce n'est pas vous qu'il appelera.
Encore une fois, le plus important c'est pas l'idée, c'est l'équipe qui va la réaliser. Il y a des gens avec qui on a travaillé, on a apprécié leur travail autant que leur personne, on sait qu'on les rappellera pour travailler à nouveau avec eux dans le futur. On sait qu'on peut leur faire confiance, on sait comment ils travaillent, on est dans une ambiance de bienveillance.
Vous ne savez jamais si le petit boulot que vous êtes en train de faire aujourd'hui ne vous permettra pas de faire quelque chose de bien plus grand plus tard, simplement parce qu'on se souvient de vous comme quelqu'un qui bosse bien.
Ne laissez pas l'argent vous brider
Et bizarrement quand je dis ça, je ne pense pas au manque d'argent, mais au surplus d'argent. À un moment, votre projet fonctionnera. Vous gagnerez des sous avec et se posera la question de quoi faire avec ces montants.
Vous vous souviendrez du moment où vous avez commencé, où vous avez réussi à faire beaucoup avec peu de moyens. Maintenant on vous offre un chèque avec plein de zeros pour continuer. Il pourrait être tentant de se dire "Bon, je vais faire juste 90% de ce que j'avais prévu, ce qui est déjà bien, et garder les 10% restant pour ma poche".
Non.
Il faut que vous fassiez 110% de ce que vous aviez prévu. Mettez vous en galère, allez plus loin encore. Ce n'est que le début. Vous serez riche plus tard. Là vous avez encore beaucoup à apprendre, beaucoup à prouver, il ne faut pas s'arreter maintenant. En faisant ainsi, vous vous donnerez à fond et irez encore plus loin.
Le plus mauvais conseil qu'on puisse vous donner quand vous monter votre projet viens bien souvent de vos proches. Ils voient que votre idée fonctionne et vous disent "T'es payé combien ? Fais attention à ne pas te faire avoir".
Worst advice ever.
Après ça vous allez avoir un petit démon dans un coin de votre tête qui va venir vous emmerder à chaque fois que vous aller pondre une nouvelle idée. Vous allez brider votre créativité en vous disant "Non, je mérite mieux que ça", "Ça, je le garde pour moi". On s'en fout de combien vous êtes payé, vous faites ce que vous rêvez de faire, ne laissez pas une hypothétique somme d'argent vous brider avant même d'avoir commencé.
Ils sont nombreux les groupes de rock fondés par des gamsin de 15 ans qui splittent avant même d'avoir écrit leur première chanson car ils se voient déjà en haut de l'affiche et s'engueulent pour savoir comment partager les gains de leur hit idéalisé. Ne soyez pas ces gamins. Faites.
La contrainte peut être libératrice
Parfois une contrainte, un impondérable va vous forcer à revoir vos plans. Ce que vous aviez prévu de faire ne peut pas être fait comme prévu. Vous avez alors deux choix : annuler ou trouver une solution.
Et c'est bien souvent quand on a des contraintes fortes qu'on parvient à trouver des solutions créatives que nous n'aurions autrement jamais imaginées. Et ces solutions peuvent bien souvent être aussi utilisées dans des situations normales, là où la contrainte n'existe pas, pour rendre le process encore plus agréable, rapide, utile.
Ne vous découragez pas face à une contrainte, il y a forcément une solution, et bien souvent elle vous ferez explorer quelque chose d'inédit.
Qu'est-ce qu'un gars plus fort que moi ferai ?
Quand vous avez réussi à faire ce que vous vouliez, que vous pensez en avoir fini, demandez-vous "Qu'est-ce qu'un gars plus fort que moi ferai à ma place ?". En essayant de vous mettre dans la peau de quelqu'un plus fort que vous, vous parviendrez à être plus fort que vous même.
Ça parait bizarre comme conseil, mais essayez, vous verrez.
Bien souvent, vous allez rencontrer des gens dans des métiers annexes au votre avec qui vous devez intéragir qui vont vous dire "Nope, désolé, c'est pas possible.". Bien souvent, en creusant un peu, vous comprendrez que ce n'est pas pour eux que la tache est impossible, mais parce qu'ils pensent que quelqu'un d'autre, un peu plus loin dans la chaine ne voudra pas.
Si vous commencez à entendre des choses comme "Non mais c'est même pas la peine d'essayer, ils voudront jamais", "Ça fait 15 ans que je fais ce métier, je peux te dire qu'ils ne voudront pas.". Répondez simplement "Viens, on essaye.", "Viens, on essaye" jusqu'à ce qu'il accepte effectivement d'essayer.
Et vous serez surpris du nombre de fois où finalement il n'y avait pas de réel obstacle sur la voie, juste des gens qui pensent que des gens pensent qu'il va y avoir des obstacles et donc bloquent dès le début.
Et ça n'arrive pas qu'aux autres. Faites attention à la petite voix dans votre tête qui dit "Non, ils voudront pas, c'est pas la peine que je demande" aussi.
Consensus
Quand on monte un projet à plusieurs, il est fondamental que les idées mises en place plaisent à tout le monde. Si vous devez batailler pour convaincre l'autre que votre idée est bonne, changez d'idée. N'oubliez pas que vous êtes des poules aux œufs d'or. Bien souvent il existe une autre idée qui satisfait tout le monde pile entre la votre et celle de votre associé.
Si jamais on vous impose une idée et que le projet ne fonctionne pas, vous serez tenté de dire "Ouais mais je le savais, j'en voulais pas de ça moi.". Et au contraire si c'est votre idée qui est acceptée et que le projet fonctionne, vous aller penser "Je le savais, mes idées sont vraiment meilleures". Et les rancunes et les dissenssions vont commencer à partir de là.
Trouvez une idée avec laquelle vous soyez tous d'accord, que vous puissiez tous défendre et porter. Si votre idée ne convient pas, pas de soucis, trouvez-en une autre et gardez votre idée pour un autre projet.
Attention aux détails
Octroyez-vous le pouvoir de tout maitriser, toute la chaine, jusqu'au bout. Même si vous avez fait le gros du travail, faites attention aux petits détails, tout le temps, partout.
Kyan raconte une anecdote très vraie d'un magicien américain qui vient faire un spectacle en France. Il répète son tour depuis des années, il est parfaitement au point, il s'est beaucoup investi dedans, il a même divorcé à cause de ça. Il est capable de faire téléporter une petite fille depuis un bout de la scène vers l'autre.
Et au moment de monter sur scène, le présentateur l'annonce avec :
Mesdames et messieurs, un tonnerre d'applaudissement pour Maurice et ses jumelles !
Comme quoi, il faut faire attention à tous les détails jusqu'au bout.
Conclusion
Ce sont pour moi des conseils extrémement précieux. Certains s'appliquent particulièrement à un processus créatif, mais d'autres possèdent vraiment une portée bien plus générale.
J'espère que vous aurez tiré quelque chose de cet article comme moi j'ai tiré quelque chose de ces conseils.
Meetup angular, organisé par le bon coin. J'avais un peu arreté d'aller aux meetups angular (trop peu de contenu), mais là le programme annonçait un REX sur comment mélanger React et Angular, du coup, j'étais curieux.
Le bon coin, derrière leurs airs de sites des années 80 mis en ligne dans un garage possède en fait de formidables bureaux en plein Paris. Le premier site date de 2006 et est Norvégien, puis la France a été la première filiale en 2007 avant que le système ne s'implante dans plus de 35 pays.
La technologie sous-jacente est un moteur custom codé en C nommé blocket et réutilisé par toutes les filliales (qui peuvent donc faire des mises à jour de leur moteur facilement) avec quelques petites différences culturelles pour chaque pays.
D'un seul dev au départ, ils sont maintenant 250 dans la boite avec un objectif à 350 pour la fin de l'année. Le bon coin, c'est des chiffres de consultations extraordinaires. 90 millions de pages vues par mois, essentiellement des résultats de recherche, donc sans possibilité de mise en cache.
Ils parviennent quand même à un startRender moyen de 0.7s. 6e site le plus visité de France, 700.000 nouvelles annonces chaque jour, 2 datacenters de 400 serveurs. En terme de charge, c'est du très lourd, leur conso normale correspondant aux pics de charge de ce qu'on connait habituellement.
Au dela du cœur de l'appli, il y a toutes les applications de gestion (modération, monitoring, etc) qui sont développés dans des tas de langages différents. Il y en a pour tous les gouts : PostgreSQL, Python, Ruby, Go, Shell, PHP, des apps natives, du big data, de l'hadoop, du capybara.
Ah, et la question qu'on se pose tous. Non, le compte @TopBonCoin n'est pas officiel, le bon coin ne faisant actuellement aucune publicité ou community management.
Bon, assez parlé de l'hôte, place aux talks.
React et Angular
Julien Bouquillon, alias @revolunet viens nous faire un retour d'expérience sur l'intégration de React dans Angular. Il a entendu beaucoup de bien de React et a voulu voir si ça se plugguait facilement.
Ça fait deux ans qu'il fait de l'Angular, sur du mobile et sur du desktop et le problème récurrent pour lui, ce sont les perfs. Essentiellement sur mobile d'ailleurs. Les problèmes de perf sont les mêmes sur les deux plateformes, mais les desktop étant plus puissants, il faut vraiment de grosses apps pour ressentir les ralentissement.
Vu que React mets en avant sa rapidité, il a décidé de troquer les directives d'Angular par des composants React pour voir la différence. Pour lui le reste d'Angular est très bon. On gagne en productivité et en réusabilité, le framework fournit plein de choses de base et tout ça se teste facilement. Globalement, super framework... sauf pour les perfs.
What's wrong with Angular ?
Parce que le gros problème d'Angular se trouve dans le data-binding, bête et méchant. C'est le coté magique qui nous attire au début dans le framework, mais c'est aussi le goulot de performances. Quand on inclue une variable dans un template pour qu'elle soit bindée, l'algo simpliste d'Angular va simplement ré-évaluer chaque variable à chaque événement de l'utilisateur. C'est à dire au clic, au scroll, au touch, au keypress. Voire même sur des events qui ne viennent pas du user, comme le retour d'une requete HTTP.
Et ce, même si les éléments en questions sont en dehors du viewport, ou qu'ils n'ont aucun rapport avec l'élément actuellement modifié. Bête et méchant on vous dit.
Bon, sur une appli desktop, on voit pas trop le problème, ça va super vite. Mais sur mobile, on peut commencer à percevoir la lenteur, voir à la subir. À chaque interaction, la totalité du DOM est réevalué, c'est pas rien. C'est vraiment du dirty checking.
Si on veut fournir un expérience smooth, il nous faut viser du 60 fps, ce qui corresponds à 16ms pour un refresh. 16ms pour un refresh de tout le DOM, c'est pas énorme.
Malheureusement, Angular ne nous donne pas beaucoup de points d'actions pour pouvoir influencer ou améliorer ce rendering, le processus fait plus ou moins partie intégrante du core du méchanisme.
La version 1.3 a fait de grosses améliorations à ce sujet, d'au moins 50% de gain. Elle introduit aussi le principe des bind-once, et des filters stateful, qui peuvent n'être executés qu'une seule fois pour chaque valeur passée. On peut aussi éviter de mettre des méthodes à évaluer dans les templates mais simplement des variables, utiliser la syntax track by des ng-repeat et toujours essayer de mettre ses event handler sur les éléments les plus hauts.
Malheureusement, il reste le cas des keypress. Si j'ai un input, la totalité de mon DOM est réévalué pour chaque touche que va taper mon utilisateur.
Et React ?
React de son coté fonctionne avec un système intermédiaire entre ses data et le DOM, il y intercale un concept qui lui est propre : le virtual DOM. Les modifications de data influent directement sur le vDOM (qui n'est pas rendu directement), et seulement le diff entre le DOM actuel et le vDOM sont reportés dans le DOM. Ça marche très bien, et du coup seul ce qui a changé est modifié.
React intègre aussi par défaut un système d'event delegation intelligent. Plutôt que d'ajouter des handler sur plusieurs éléments, il ajoute un handler général sur la page et renvoie l'event au bon élément cliqué. On arrete comme ça de dupliquer les handlers.
Et surtout, React est explicite. Plus de magie. Chaque composant possède sa méthode render qui va retourner du HTML. On peut comme ça tester unitairement le rendu, mais surtout chaque composant est isolé et ses données ne fuitent plus vers l'extérieur. Seul le contenu du composant est modifié, sans que cela n'induise un rechargement de la totalité du DOM de la page.
Sans compter que React s'intègre parfaitement dans l'écosystem npm et browserify.
Benchmarks
Il nous a fait une démo d'un même composant codé une fois en Angular et une fois en React pour voir la différence de perfs. C'était un tableau de 100 éléments et de 5-6 colonnes. En cochant la première colonne de chaque ligne, on pouvait "barrer" l'élément.
En React comme en Angular, le chargement initial du composant prends environ autant de temps. Pas de gain à attendre de ce coté là. Par contre, si on coche une ligne du tableau Angular, les 1000 éléments sont ré-évalués alors que si on coche celle de React, seule la ligne cliquée est modifiée.
Là où c'est pire, c'est qu'en ajoutant un champ d'input au dessus du tableau Angular, chaque keypress ré-évaluait la totalité du tableau. Et pire que tout, on a ajouté un bouton qui ne faisait rien (pas de ng-click, rien). Et bien cliquer dessus rechargeait encore tout le DOM Angular.
Je crois que toute la beauté de React peut se résumer dans la phrase suivante de Julien :
En React, un bouton qui ne fait rien, ne fait rien.
Bon, et mon React il va rentrer dans mon Angular ?
Oui. Il est tout à fait possible de mettre un composant React au beau milieu d'une appli Angular. Il va vivre sa vie en isolation, sans générer de reflow Angular, et sans se modifier quand Angular se modifie.
Par contre si on veut l'introduire dans notre cycle Angular normal, il faut le wrapper lui-même dans une directive. Par contre, à partir du code de la directive, on entre dans un mode explicit > implicit où on va définir des callbacks à notre composant qu'il sera chargé d'appeller quand il voudra communiquer son état vers l'extérieur, et on ajoutera aussi des méthodes au composant pour pouvoir lui passer de nouvelles data depuis Angular.
C'est un peu plus de plomberie, mais on est alors certain qu'il ne se mettra pas à jour sans raison, et il pourra agir en isolation complète.
Il existe un projet, ngReact qui défini justement ce type de directive, mais ils vont trop loin et ajoutent des watchers automatiques pour passer les infos d'Angular vers React et vice-versa, ce qui nous fait revenir au problème de dirty checking du départ.
Conclusion
React peut s'intégrer correctement dans Angular et vivre sa vie correctement en profitant de manière isolée de ses avantages. La plomberie reste un peu manuelle, mais permet une belle isolation. Néanmoins, la philosophie de l'un et de l'autre étant tellement différentes, je ne suis pas sur qu'on tire vraiment le meilleur des deux mondes.
KillrChat
Duy Hai Doan, tech évangéliste chez Datastax nous a parlé d'un pet project de chat à base d'Angular, Spring Boot et Cassandra. C'est cool, il est payé pour faire des meetups et présenter Cassandra, du coup avec trois technos cools comme ça il peut réutiliser le même talk :)
L'idée de faire une appli de chat vient de sa frustration de faire des ateliers pour faire découvrir Cassandra et que les élèves ne repartent qu'avec un énième "Hello World" qui ne sert pas à grand chose. Là, il a une vraie appli qui touche à toutes les couches.
Et surtout, elle peut profiter des possibilités de scaling de Cassandra. En gros, quand le nombre de user se mets à grossir, il suffit d'augmenter le nombre de nœuds sur lesquels les données sont stockées dans Cassandra. Cassandra s'occupe de répartir les nouvelles données uniformément sur chaque nœud de manière à ce qu'aucun ne soit particulièrement submergé. Pour plus d'infos sur le fonctionne de Cassandra, je vous invite à relire mon compte-rendu du meetup nodejs paris.
Le chat qu'il a développé communique avec le back-end Spring Boot en websocket, avec SockJS. Entre les deux, il suffit de mettre un broker qui sait scaler (RabbitMQ, ZeroMQ, Kafka) qui implémente un simple système de pub/sub et front et back peuvent communiquer sans soucis, même avec une forte charge.
Et Angular dans tout ça ?
Duy Hai vient surtout du monde Java, le front c'est pas forcément son domaine. Mais il a kiffé Angular, il s'y est bien retrouvé. Il a aussi apprécié le fait qu'il y ait des outils pour se plugguer facilement avec Bootstrap (car comme il le dit lui-même, si on lui laisse le design d'un site ça sera horrible, avec bootstrap au moins c'est pas trop moche).
Il a quand même très rapidement implémenté des tas de bonnes pratiques en Angular (je ne sais pas si ce sont des bonnes pratiques issues de Java ou non). Par exemple, toute sa logique est distribuéed dans des services stateless, ses controllers se chargeant simplement d'un rôle de passe-plat.
Par contre, comme beaucoup, il s'est fait avoir par les $resources. Déjà, selon qu'on utilise les ressources avec des méthodes d'instances ou des méthodes de classe, ce n'est pas la même type d'objet qui est retourné et le chaining des promises en devient d'autant plus complexe (sans parler des promises angular qui ont leurs propres quirks).
Ce qu'il regrette dans Angular c'est qu'il faille une bonne connaissance de Javascript pour comprendre réellement ce qu'il se passe sous le capot. Heureusement pour lui, il a découvert angular-from-scratch qui se propose de recoder les mécaniques principales d'Angular depuis rien pour bien assimiler petit à petit chacun des concepts.
Globalement une présentation assez chouette, un REX avec des technos sympas.
Bon, je vais la faire assez vite pour le coup. Typescript est une surcouche à Javascript, un peu comme Coffeescript, qui compile en Javascript. Le truc qu'apporte Typescript, c'est un typage fort des variables.
On peut désormais définir le type de chacun de nos arguments de fonctions et définir des interfaces de classe. Et si jamais le compilateur s'aperçoit qu'on essaie de faire rentrer des ronds dans des carrés, il nous balance une exception et il compile pas.
On peut aussi définir "facilement" des variables privées et publiques et même génerer automatiquement des getters et des setters. Ouais, ouais, comme un vrai javaiste.
Bon, à part ça y a des linters et ça génère des sourcemaps.
J'ai vraiment beaucoup de mal à voir l'intéret du truc, mais j'imagine que ça va encore plus plaire aux javaistes qui se mettent au front.
Buffet
Et comme souvent, le buffet qui suit les talks est toujours l'occasion de discuter et de rencontrer des gens très intéressants. Hésitez pas à venir taper la discut' si vous êtes dans un meetup la prochaine fois.
La version 1.0 vient de sortir officiellement, ce qui donne vraiment envie de tester le système pour des POCs rapides. Pour une petite idée d'appli qui reste dans les standards de UI actuels, et pour se concentrer uniquement sur le fonctionnel, ça semble un choix tout à fait sain. Je testerai sans doute sur un side project bientot.
