La conférence avait lieu dans le grand amphi d'EPITA. Une centaine de personnes. Co-organisé par Etienne Folio et Quentin Raynaud. Organisé tous les 2e mercredis de chaque mois. Centré sur node, mais aussi du js front (Backbone, Ember, Angular, jQuery).
Bien démarrer avec express.js
Première présentation de 10mn sur Express. Surcouche de surcouches. Présentation rapide des convenient methods d'express, et de la batterie de app.set() à définir au début d'un projet express. Explication rapide des middlewares et des templating engines.
Globalement la conférence était plus une présentation ligne par ligne d'un boilerplate express. Assez confus et pas passionnant. Heureusement que FJA m'avait expliqué Express plus tôt dans la journée.
Gérer des processus NodeJS, améliorer leur performance et les monitor avec PM2
pm2 est un process manager en cli pour node qui permet de lancer son appli node sur chaque CPU de la machine hôte et agit comme load-balancer pour renvoyer les requêtes équitablement entre tous les CPU (il faut bien sur une appli stateless pour pouvoir en profiter).
Il permet aussi de relancer ses instances sans downtime. Une nouvelle instance est créée et accepte les nouvelles connections pendant que l'ancienne termine ses connections en cours avant de s'éteindre. Cela utilise le mode cluster de node, mais l'expose selon une API beaucoup plus simple à utiliser par le dev.
Les différentes instances peuvent communiquer par un systeme de pub/sub qui permet de broadcaster des events (mais le dev avoue ne pas avoir trouver de use case intéressant). Fourni avec un monitor en cli qui permet de voir la charge de chaque instance et de reload/restart/etc. Pense faire une version SaaS dans le futur.
Dernière présentation de Bruno Jouhier sur les génerateurs ES6. L'ayant déjà vu à ParisJS je n'y ai pas assisté, mais vous pouvez trouver les slides ici
C'est une librairie graphique qui fonctionne sous Mac, Windows et Linux pour créer des jeux vidéos en 2D simple. Elle peut créer des fenêtres avec une boucle de game play updatée à 60 images par seconde, afficher des images, jouer des sons et intercepter la souris et le clavier. Hyper simple à mettre en place, démo intéressante.
Gem pour activer le support des websockets dans rails. Nécessite un serveur basé sur EventMachine (thin dans l'exemple). Stable, testé sur centaine d'utilisateurs simultanés. Peut être déployé sur plusieurs serveurs synchronisés (utilise Redis pour ça). Démo rapide d'un pub/sub en quelques lignes en écoutant des events sur le serveur. Encore quelques limitations : bugs sur des edge cases, securité et partage des events, serveur ne capte pas les déconnections des clients, mais activement développé.
Présentation de divers gems en rapport avec Redis
redis-objects pour mapper directement des objets ruby dans Redis
redis-rb pour parler à Redis dans une syntaxe rubyiesque
redic pour parler à Redis dans une syntaxe redisesque
nest pour travailler avec des clés structurées (type “user:42:name”)
Heimanu
Présentation du site Heimanu qui utilise Discourse en interne pour proposer des discussions en temps réel entre ses membres. Ils se sont retrouvés bloqués par le système de permissions de Discourse qui ne convenait pas à leur appli, ils ont donc rajouté une surcouche à Discourse (elle aussi en rails + ember) pour régler leur problème. La conf était assez brouillon et très spécifique à leur usage. Il leur a quand même été demandé s'ils n'auraient pas mieux fait de faire à la main plutôt que de modifier Discourse. Réponse : Mauvaise estimation du temps nécessaire à la modif (6 mois plutôt que 4), mais Discourse propose tellement de choses que si c'était à refaire ils le referaient.
Cache Rails 4
Finalement, présentation du caching HTTP dans Rails 4. En fait, plutôt présentation du caching HTTP coté client tout court. Max-Age et ETag/Last-Modified.
Présentation des méthodes expires_in, fresh_when, is_fresh pour tester tout ça. Idée intéressante d'utiliser des ETag custom et de les intercepter coté Rails pour accélérer des traitements (sans pour autant cacher toute la page). Par exemple une clé Redis contenant les infos pertinentes.
Discussion sur l'intérêt de définir ces entêtes private (seul le client final cache la ressource) ou public (tous les proxies sur le chemin peuvent la cacher). Economie de requêtes sur le backend rails, mais moins la main sur l'invalidation du cache). (Pour info, cette page explique très bien les mécanismes de cache client)
Galaxy: async/await grâce aux générateurs "harmony"
Présentation de yield et des function star en javascript. Ce qui existe déjà en python et ruby. Et utilisation de streamline.js et galaxy.js pour l'implémenter.
Semble assez puissant et bien fourni, c'est un préprocesseur qui ajoute ces nouveaux mots-clés (mais qui sont déjà intégrés dans Chrome Canary et dans un Firefox).
L'idée est de réussir à combler le problème des pyramides de callbacks de nodejs pour rendre le code un peu plus simple à lire en lui donnant une allure de code synchrone. Apparemment tout cela intégre un systeme de traceback et pile d'erreur qui permet de remonter la pile des callbacks en donnant le contexte
ExoBrowser
Deuxième présentation sur ExoBrowser un side-project qui s'est transformé en browser complet. Il réutilise le travail fait par chromium en intégrant un thread nodejs à l'intérieur d'une WebView générée par Chromium. Toute l'UI est fabriquée manuellement en HTML/JS/CSS. Le thread node intégré écoute sur les events du navigateur (resize, load, cookie, search, etc).
Cela lui permet de faire de son navigateur exactement ce qu'il veut. L'idée de base étant d'avoir des onglets sous forme de pile plutot que d'onglets. De même, les listeners des cookies permet de pouvoir les stocker et centraliser pour avoir sa session qu'on peut récupérer d'un browser à un autre.
jQuery et TDD
Présentation de comment tester son code jQuery en console. En utilisant json-dom et nodejs pour simuler une page web et tester son code dessus. Le simple fait de ne pas avoir de rendu visuel sous les yeux les force à mieux organiser et présenter leur code.
La démo ne portait que sur du refactoring d'éléments assez simple mais permettait de montrer que oui, c'est possible, de faire du jQuery en TDD.
Le samedi, après les conférences Paris Web, c'est toujours les ateliers. Je conseille à tout le monde d'aller aux ateliers. Même si vous ne venez pas aux conférences, les ateliers sont toujours très instructifs et surtout, c'est vraiment pas cher.
Ce sont des cours moins théoriques et plus pratiques, par petits groupes, et avec une plus forte intéraction avec le speaker.
Apprendre à se servir des Chrome Dev Tools
Thomas Bassetto nous parle des fuites mémoires et de comment on peut les débusquer et les corriger avec les Chrome Dev Tools. Le principe même d'une fuite mémoire, c'est qu'elle n'apparait pas dès le début mais seulement quand on laisse tourner son application pendant un certain temps d'utilisation.
A la fois Chrome Canary et les Nightlies de Firefox proposent des outils de profiling très utiles pour les trouver. Les versions ne sont pas toujours stables, mais elles sont excellent pour débugguer.
Pour Chrome, il est conseillé de se créer un nouveau profil pour débugguer. Pour repartir comme ça sur une base clean, sans extensions, sans cache, sans historique, etc. Idem sous Firefox.
Safari sous Mac a longtemps était une copie-conforme de Chrome, mais aujourd'hui les deux sont bien différents et les outils de débugging de Safari sont très mauvais. À la place, il est conseillé sous Mac d'utliser WebKit.app.
Sous Windows 8.1, les outils de debug de IE11 sont très bon aussi. Si vous devez débugguer d'anciennes versions de IE, c'est une autre histoire...
Thomas nous présente ensuite quelques raccourcis bien utiles et pas forcément connus de l'outil. En sélectionnant un nœud et en appuyant sur h, on le masque, suppr le supprime du DOM (et on peut l'annuler avec Ctrl-Z). Il est aussi possible de déplacer des nœuds du DOM simplement en faisant un drag'n'drop.
Dans la colonne de droite, on peut aussi forcer les états :hover, :active et :focus. Il est possible d'incrémenter les unités CSS en appuyant sur Haut/Bas (en ajoutant Ctrl ou Maj on augmente aussi l'incrément).
Il nous a aussi parlé des fonctions avancées de logging comme console.group, console.groupEnd, console.time et console.timeEnd. Malheureusement, je ne me souviens plus ce qu'elles font...
Il existe de plus des tas d'extensions pour Chrome et Firefox qui ajoutent des fonctionnalités spécifiques pour certains frameworks, comme Ember, Angular, Knockout ou Backbone.
Avec les Chrome Workspaces, on peut même en partie remplacer son IDE. Il est possible de modifier le CSS directement depuis le browser, puis de voir les fichiers modifiés, avec le diff par rapport aux fichiers source. Chrome est même capable d'exporter les fichiers ainsi modifiés pour remplacer les fichiers existants. Ca ne marche par contre pas encore avec les préprocesseurs.
Ces outils proposent plein de petites choses pour rendre la vie du développeur plus facile. Ils ont des fonctionnalités de prettyprint du code (pour indenter correctement un fichier minifié par exemple). Parfois, ces options sont un peu cachées, mais elles existent. Ils proposent aussi bien souvent l'objet $ qui permet de faire des sélections CSS à la jQuery. Si jQuery est chargé alors il l'utilise, sinon il se rabat sur les méthodes natives.
Thomas nous a aussi montré des trucs plus puissants comme des breakpoints en CSS pour voir quand une propriété est modifiée, et par qui (feuille de style, script ?). Je ne me souviens plus de la manip, mais ça m'avait bluffé.
Finalement la dernière feature intéressante sont les possibilités de timeline. On peut voir en temps réel les reflow et les repaints. Ca permet de voir où l'affichage de l'UI prends du temps. A savoir que chaque browser possède ses propres routines pour l'affichage et que donc Firefox et Chrome ne ralentiront pas forcément sur les mêmes choses.
Il est possible de voir le fps général, et donc de détecter ce qui le fait baisser (peut-être un évenement un peu trop poussif bindé sur un onscroll ?). Il est possible de zoomer sur un moment de la timeline en le selectionnant pour aller voir plus profondément, et à partir de là remonter les stacktrace pour voir ce qui a appellé les redraw.
L'outil est vraiment super puissant et je ne me doutais pas qu'il permettait autant. Il est par contre assez complexe à prendre en main, car les fonctionnalités sont légions et parfois cachées.
Thomas a finalement terminé en nous donnant quelques astuces qu'il a apprise au fil de ses débugs. Déjà, le trick d'utiliser -webkit-transform:translateZ(0) sur une animation permet de la faire traiter par le gpu plutot que le cpu. Utiliser un background-fixed sur le body permet d'économiser des repaints. Désactiver les effets de survol quand on scroll est aussi une très bonne idée. Pour ça on peut ajouter par défaut une classe sur le body, qu'on supprime quand on scroll et on n'active les effets :hover que si cette classe est présente.
Finalement il nous a montré les Heap Snapshot de Chrome qui permettent de prendre un snapshot de la mémoire à un moment donné. Vu que ça prends absolument tout en compte il est parfois difficile d'y trouver ce qu'on cherche. Son astuce est de prendre un premier snapshot, puis de faire X fois la même action, qu'il suppose être la cause du problème, puis de reprendre un autre snapshot. Puis il compare les deux, et regarde dans le diffs ceux qui sont multiples de X. Par entropie il a trouvé que X = 7 était un bon chiffre, qui est assez grand pour sortir du lot et assez petit pour ne pas prendre trop de temps. Et surtout, c'est un nombre premier, donc on a moins de faux positifs.
Raphaël Goetter et Nicolas Hoffman nous parlent de frameworks CSS, en prenant comme exemples leurs propres créations. Ils n'étaient pas là pour vendre leur solutions. Ils étaient plutot là pour donner leur retour d'experience, pour qu'on puisse en profiter quand on fait nous-même nos frameworks.
Alors bien sur, on ne fait pas tous des frameworks CSS open-source que d'autres vont utiliser, mais on possède au moins un tas de classes qu'on réutilise d'un projet à un autre. POur faciler la réutilisation, il y a donc quelques bonnes pratiques à prendre en compte.
Déjà, découper ses classes pour les rendre le plus réutilisables possibles. Utiliser une nomenclature cohérente pour nommes les éléments d'interfaces. Toujours garder ses fallbacks pour vieux browsers proches du code de la feature initiale (pas dans une feuille de style supplémentaire). Utiliser normalize pour être sur de partir sur la même base à chaque fois.
Et surtout, une fois que votre nomenclature de nommage est statuée et cohérente, documentez-la et expliquez-là, donnez des exemples.
Il est parfois nécessaire d'aller à l'encontre des bonnes pratiques, comme d'utiliser le sélecteur universel * pour remettre un box-model par défaut, ou utiliser !important pour être sur de ne pas avoir une règle fondamentale écrasée. Bon, là on a le droit, c'est pas une rustine pour un cas particulier.
Finalement comme autres frameworks CSS, ils conseillent de tester Zurb Foundation.
Monitoring
Dernière conférence de la journée et absolument passionante. On a eu un retour d'expérience d'un ops du journal 20 minutes (à moins que ce ne soit Metro ? Je ne me souviens plus).
Il commence par nous dire qu'il est inutile de tout monitorer. Quand on tracke trop d'indicateurs et qu'on se mets trop d'alertes, on recoit plein d'emails et on finit par ne plus les lire et faire des règles de filtrage pour simplement les marquer comme lus.
De la même façon, il faut éviter de créer des dashboards avec des tas de valeurs affichées partout. Le cerveau humain ne process pas cette info aussi vite que si on avait simplement affiché des couleurs, pour voir d'un coup d'œil ce qui cloche.
Il nous a ensuite parlé des outils. Tout d'abord collectd qui collecte des tas d'infos sur le serveur où il tourne (process, RAM, hard drive, etc) et qui les envoie ensuite quelque part.
De l'autre coté, on a Graphite dont le job est d'afficher des données sous forme de graph. Il peut s'installer chez soi ou s'utiliser en SaaS avec Librato. Graphite ne contient pas d'intelligence, il prends des données dans le temps, sous forme de flux, les map et les reduce, garde un historique et les affiche. Les infos ne sont pas stockées telles qu'elles, elles sont compressées au fil du temps pour ne garder qu'un trend.
Graphite fonctionne sous forme de fenetres de temps (Jour, Heure, minutes, etc) sur lesquelles on génére des statistiques génériques. Seuls des valeurs numériques simples peuvent être sauvegardées. Le but est de voir l'évolution d'un "compteur" au fil du temps sur des fenetres plus ou moins grandes. Par défaut pour passer d'une fenetre de temps à une autre Graphite fait une moyenne, mais on peut le configurer pour faire un min, max ou une somme.
Tout ceci est exposé sous forme d'url pour obtenir les valeurs depuis l'exterieur.
Un autre outil à ajouter à sa ceinture est statsd qui permet de collecter des metrics plus personnalisés, applicatives. Cet outil prends des valeurs sous forme de jauge (% de RAM utilisé, jauge de vitesse, etc). Les metrics sont à prendre directement dans le code de l'application, et il existe des SDK pour à peu près tous les langages. L'idée c'est bien sur de lui faire ensuite envoyer ses informations à Graphite pour les tracker.
Graphite n'est pas très performant en cas d'envoie de beaucoup de données. Il est donc possible que des datas soient envoyées, mais ne soient jamais recues. Dans ce cas, on peut faire comme Etsy qui utilise du sampling. C'est à dire qu'ils n'envoient pas toutes leurs données, mais seulement un sur 10, et ils extrapolent ensuite dans Graphite.
Il semble aussi possible d'envoyer des données vers Graphite à partir de munin et awstat mais notre speaker ne l'a pas testé directement.
Ensuite vient logstash, un outil basé sur elasticsearch qui permet de recueillir les logs et les étudier. La bonne pratique est déjà de centraliser ses logs sur un même serveyr, ne pas les laisser pourir les serveurs sur lesquels ils sont créés. Surtout quand on scale, on détruit beaucoup de machines et on risque donc de perdre des logs. Pour ça, on peut utiliser syslogrc ou checksyslog.
Logstash permet de faire des requetes sous forme de regexp, ou de filtrer sur certaines url (pour savoir le nombre de connections à un panier d'achat par exemple). Pour peu que les urls du site soient bien ordonnées, ça permet de faire du tracking à peu de frais en utilisant les logs déjà générés par le serveur.
Un marqueur important à garder dans graphite est les dates des déploiement, de manière à les correler avec les pics possibles d'erreurs et de pouvoir ainsi facilement les isoler. Idéalement chaque commit devrait être présent sur la timeline. Il est important d'avoir des métriques visuelles rapides dès qu'on déploie, pour voir si on a pété quelque chose en production. En intégration ça permet aussi de pouvoir comparer les stats d'un commit sur un autre.
Il nous a aussi parlé de ab ou de thung (pas sur de l'orthographe) qui sont des outils pour tester un serveur, voir à quand il va s'effondrer. Descartes est un dashboard avec un peu plus de classe que le theme de base, pour Graphite.
La fin du talk était surtout l'occasion de lancer quelques noms d'apps qui peuvent aussi aider dans le monitoring, comme logly, logentries, papertrails ou spunk pour l'analyse de logs. sentry pour les logs front, capturer les exceptions, observer les valauers des variables. Il est nécessaire de le configurer abondamment pour l'utiliser en prod car lui demander de logguer toutes les erreurs risque d'en faire beaucoup trop.
Dans la veine de nagios, il nous conseillait riemann ou sensu.
Cette année, ParisWeb a lieu au Palais Brongnard, place de la Bourse. C'est un endroit magnifique, mais à en croire les organisateurs, ça reste un peu trop cher. Première et dernière fois dans ces lieux, donc.
La folle journée, ou les fourberies d'un projet
Très bonne keynote d'ouverture, pleine d'humour pour nous réveiller en ce début de journée à 9h45. STPo, Mariejulien et Florian Boudot nous font un sketch de tout ce qui peut mal tourner dans un projet web, et ainsi répondre à la grande question "Pourquoi les sites webs sont si dégueulasses ?".
Ils mettent en relief tous les travers de toutes les personnes impliquées dans la réalisation d'un site, depuis les besoins flous et impossibles à réaliser du marketing, les développeurs trop surs d'eux, les économies faites en prenant trois stagiaires à temps partiel sans recouvrement de leurs horaires et toutes les autres erreurs causées par l'incompétence ou la mauvaise foi.
A voir absolument en vidéo.
Em, cette unité meconnue
En CSS, on a plusieurs unités de mesure pour gérer la taille du texte, des marges, etc. On a les px pour faire du pixel-perfect, on a des pt, que personne n'utilise, on a des pourcentages surtout utilisés pour faire des colonnes, et finalement on a des em. Les em c'est bon, mangez en, ça permet de faire des tailles de texte relatives.
Sauf que ça a quand même le gros défaut d'être héréditaire, du coup, plus on imbrique nos éléments et nos em, plus les unités se multiplient. rem vient régler ce problème, permettant de faire des unités relatives par rapport à la taille du texte définie sur le body.
Du coup, même si l'utilisateur modifie ses paramètres de zoom, toutes les dimensions de la page s'adaptent. Il reste certains devices et certains navigateurs qui ne permettent pas de modifier la taille du texte, mais cela doit changer, et va changer. Avec la multiplicité des terminaux (mobile, télé, etc) et le vieillissement de la population, il est nécessaire que chacun puisse ajuster le rendu visuel à son matériel et à sa perception.
Alors il existe des pré-processeurs (LESS, SASS, Stylus) qui permettent des calculs pour avoir des tailles de texte basées sur la taille de base. Mais leur output final est en em (ou en pourcentage, mais ça revient au même) et ne règle pas le problème de l'imbrication de plusieurs modules qui indiquent chacun des em. Chris Coyier propose une solution qui consiste à utiliser rem dans le root d'un module, et des em à l'intérieur.
Bonnes pratiques d'API
Éric Daspet nous parle de bonnes pratiques à adopter si on doit concevoir une API.
Il commence par nous parler des dates, comme quoi il ne faut pas utiliser de date, même de timestamp, si on ne précise pas le fuseau horaire à prendre en compte.
Il préconise de prévoir la possibilité d'avoir plusieurs langues, mais ne précise pas comment le faire, dommage.
A propos de la pagination, il nous avertit que cela est difficile à maintenir. La collection que l'on souhaite récupérer peut avoir évoluée entre la requete de la page une et celle de la page deux. Il ne faut pas laisser à l'utilisateur la responsabilité de définir l'offset sur lequel il veut faire sa pagination. À la place, il faut que ce soit le back-end qui prévoie un mécanisme pour récupérer la suite de la liste, et que l'API fournisse le lien vers cette page. De toutes façons, un système de pagination est obligatoire sur une API, pour éviter de trop charger les serveurs en retournant absolument tout à chaque fois. Du coup, le système de pagination peut s'appuyer sur les mécanismes de cache qui sont mis en place.
L'API allant évoluer au fil du temps, il faut aussi penser à la versionner. Éric préconise d'ajouter un /v1 au début des urls. Il est comme ça techniquement possible de faire les urls de la /v2 rétro-compatibles avec la v1, même si dans les faits ça reste très difficile à faire.
Au niveau de la sécurité, il faut utiliser OAuth si on fait appel à une authentication tierce, sinon en attaque directe, un HTTP Basic est suffisant. Bien sur, tout ça doit être servi en HTTPS. Bien penser que si on expose un SDK, on ne doit pas pour autant permettre d'attaquer les urls sans https pour autant. Mieux vaut forcer les bonnes pratiques de sécurité.
Il ne faut pas oublier que les token d'API ne font pas office de sécurité, il permet juste d'identifier qui fait quel appel. Ca permet de bloquer un utilisateur, d'instaurer des quotas, et d'étudier les patterns d'utilisation.
On peut ensuite aller plus loin que les APIs traditionnelles et permettre de la découverte de l'API directement en tapant dessus. C'est le top du must de l'API (rien que ça), mais je ne connais pas d'API qui implemete ça correctement. Le minimum par contre est de faire des URI prédictibles, facilement testables, simplement avec un navigateur. Les gens vont bidouiller les urls de toutes façons, pour comprendre. On évite donc les surprises, on n'utilise que des minuscules, pas de caractères spéciaux, pas d'accents.
On fait des urls courtes, non pas en abbrégeant les noms des objets (ça, jamais !), mais en limitant le nombre de niveaux à 3 maximum. Il faut limiter de toutes façons le nombre d'entrées dans l'API. Si on peut accèder à un même objet par plusieurs entrées, c'est une mauvaise idée. Si un item enfant dépends de son parent, il doit aussi pouvoir être accéder directement depuis le root, par son identifiant.
Soyez reponsable, construisez votre API
Le titre de cette conférence portait un peu à confusion. Il n'était pas question d'API dans le même sens que le résumé précent. Notre speaker parlait des API dans le sens de l'interface externe qu'expose le code qu'on produit.
Aujourd'hui on utilise un paquet de librairies, qui exposent des API qu'on utilise dans nos projets. Ces API externes permettent d'enfouir la complexité et d'exposer seulement les parties utiles. L'intérieur peut donc être modularisé, et possèder des composants très légers.
En CSS par exemple, plutot que de définir à la fois les couleurs, le texte et la taille dans le même élément on peut utiliser plusieurs classes, qui s'occupent chacun d'un aspect et qu'on peut moduler pour les appliquer à plusieurs éléments. Au final, on peut même finir par utiliser un préprocesseur pour les compiler en une seule classe, tout en gardant la modularité de notre code.
C'est important de limiter son "empreinte carbone", de limiter ce qu'on expose à l'exterieur. En Javascript par exemple, ça implique de ne pas polluer le global scope, d'utiliser des fonctions auto-appellantes, de séparer le fonctions publiques des fonctions privées. Parfois, les utilisateurs vont demander à avoir accès à des fonctions internes de vos systèmes, et il faut alors les leur ouvrir. Mais il ne faut pas tout exposer dès le début, car sinon on s'expose à de gros soucis de rétrocompatibilité.
Quand on conçois une page web, ça veut dire faire des composants réutilisables, qui puissent être utilisés à différents endroits et modulaires sans casser la vue générale. Pour ça, il faut se baser sur les standards existants, les urls, le JSON, l'utf8, etc. Utiliser des verbes pour REST, des noms pour les URI.
Bon, en relisant mes notes je me rends compte que tout ça est assez confus. Je ne parviens pas à me souvenir exactement du propos de la conférence. Globalement c'était un récapitulatif des bonnes pratiques, un rappel sur l'utilisation des standards, sur la modularité des éléments, sur l'abstraction pour cacher la complexité, sur les endpoints des API pour laisser les utilisateurs s'approprier les éléments, sur éviter les frameworks monolithiques et privilégier les microilibrairies.
Je code donc je teste
La dernière présentation portait sur les tests, et sur leur utilité. Il existe principalement trois types de tests : Unitaires, Intégration et Fonctionnels.
Les tests unitaires se font en boite blanche. On connait l'implémentation du code, et les tests sont écrits par les développeurs. En Javascript, on utilise des frameworks comme Jasmine, Mocha ou Sinon pour ce genre de tests.
Les tests d'intégration quand à eux se placent à un niveau plus élévés. On s'assure que chaque composant du système s'intégre correctement avec les autres. En front, on utilise Karma et CasperJS par exemple. On scénarise des parcours utilisateur et on vérifie qu'ils fonctionnent.
Finalement les tests fonctionnels permettent de vérifier qu'un système fonctionne, du point de vue de l'utilisateur. On utilise alors Selenium ou Sikuli Script. J'avoue que je n'ai pas bien compris la différence entre tests fonctionnels et tests d'intégration.
On peut aussi faire des tests de validité, qui permettent de vérifier un code face à des bests practices ou des standards. On citera JSHint, YSlow, OpQuast ou le validateur du W3C par exemple.
Les tests de compatibilités, avec de soutils comme BrowserStack, qui permettent de vérifier que le comportement est le même sur tous les navigateurs. On y fait généralement des tests d'intégrations, les différences d'implémentation de code étant généralement minimes (et au pire, elles peuvent être testés avec des navigateurs différents configurés sous Karma).
Tout ces tests n'ont de la valeur que s'ils peuvent être executés rapidement. Il est primordial que la boucle de feedback entre le code et le résultat du test soit la plus courte possible. Des outils comme Grunt permettent d'automatiser énormément de ces tâches. Et Grunt peut facilement s'interfacer avec Git, pour par exemple forcer certaines tâches à chaque commit et/ou à chaque push. De même, on peut l'intégrer dans un Jenkins pour créer un environnement d'intégration continue.
Faire des tests, ça prends du temps. Ca prends du temps de les écrire, ça prends du temps de les maintenir. Le gain sur le long terme est à plusieurs ordres de grandeur de différencre par rapport à trouver le bug manuellement en production et le patcher dans l'urgence par contre. Néanmoins, l'apprentissage est long. Il faut apprendre à la fois le principe, la méthodologie, mais surtout appréhender les outils et frameworks.
Il faut aussi savoir garder les pieds sur terre et accepter qu'on ne pourra pas tout tester sur tous les projets. Les tests unitaires sont les plus simples à mettre en place, et apportent un réel gain dès que plusieurs développeurs travaillent sur la même fonctionnalités car ils permettent de se prémunir de la régression et font aussi office de documentation. Une bonne pratique quand on cherche à ajouter des tests durant le cours du projet est de toujours ajouter un test de non-regression à chaque bug corrigé.
Quand on est mieux rodé aux outils, on peut se mettre au TDD et ainsi écrire les tests et le code qui va avec en même temps, quand les informations sont encore fraiches dans la tête. Parfois, le TDD n'est pas adapté, et on code rapidement la feature, et on rajoute les tests le lendemain, ou plus tard. C'est moins bien, mais c'est déjà bien. Il vaut mieux un test imparfait aujourd'hui que pas de tests du tout.
Le Web après les mots de passe
Un rappel de bonnes pratiques sur la sécurité, et en particulier les mots de passe. Rien de transcendant, mais des bonnes pratiques, qu'il est toujours bon de rappeller.
Les processus de création de compte peuvent suivre plusieurs flows. Idéalement on demande à l'utilisateur de choisir son login. On peut alors simplement lui donner un mot de passe aléatoire et directement lui laisser accès au site web. On lui envoie en parallele un mail, dans lequel il trouvera un lien pour changer son pass (on peut même lui forcer cette étape la prochaine fois qu'il se connecte). Si jamais on demande directement le pass lors de l'inscription, on demande de taper une confirmation pour éviter les fautes de frappe.
Surtout, on ne stocke pas les mots de passe en clair dans la base de données. Si on veut envoyer un mail à l'utilisateur pour lui confirmer qu'il est bien inscrit, et lui rappeller ses identifiants, on le fait avec des mots de passe temporaires, comme dit au dessus, et on lui propose un moyen de les modifier.
On peut rajouter des captchas si on souhaite limiter les inscriptions automatiques de bots, mais on ne l'active que quand on détecte ce genre d'activité.
Il ne faut pas oublier qu'on doit se créer des compte sur une multitude de sites. La majorité des gens utilisent toujours les même mot de passe. D'après les études qu'on peut faire sur les fichiers leakés, seulement 40% des mots de passe sont uniques, et ceux les plus utilisés sont vraiment simples : 123456, azerty, etc. Seuls les technophiles font attention à leurs pass, les gens normaux utilisent toujours le même. Il faut éduquer les masses, leur apprendre des méthodes simples pour générer mentalement des mots de passes complexes et dynamiques. Les politiques de sécurités imposées par certaines sociétés ou certains sites nuisent plus à la sécurité qu'elles ne l'améliore. Il ne faut jamais limiter le nombre de caractères autorisés, et des règles trop strictes sur le nombre de majuscules/minuscules/nombres/caractères spéciaux risquent de limiter les variations.
Bref, on peut éduquer les utilisateurs et leur apprendre tout ça, et même qu'ils utilisent KeePass ou équivalent pour stocker leurs identifiants. Mais dans la vraie vie, on n'a pas accès à nos clients, et nos clients vont donc avoir des identifiants trop simples. Pour limiter les risques, on va donc toujours renvoyer les demandes de réinitialisation de mot de passe sur un canal secondaire (un sms par exemple).
Il ne faut pas oublier qu'on ne peut choisir que deux éléments entre Praticité, Sécurité et Coût dans l'équation de la sécurité informatique pour les grand public. Si possible, il vaut mieux laisser ces problématiques à un tiers extérieur dont c'est le travail. La sécurité, c'est un boulot à temps plein, bourré de cas particuliers. Si vous pouvez utiliser OAuth pour identifier vos utilisateurs et ainsi déléguer la gestion de leur identité et permission à une autorité extérieure, faites-le.
La rencontre entre hacktivisme et sociétés civiles, un enjeu pour les libertés numériques
Je n'ai pas pris de notes à cette conférence, mais je vous invite grandement à regarder la vidéo et à lire son livre.
Conclusion
Les notes de ces deux journées sont assez spartiates et inégales, je n'ai pas pris de notes à chaque fois. Et pour tout vous avouer, j'écris ce compte rendu près de 8 mois après l'évenement, ma mémoire n'étant plus très claire. Néanmoins, ParisWeb est toujours un évenement remarquable, à ne pas manquer. La première année que je suis venu, je me souviens m'être fait la réflexion que j'avais appris plus en 2 jours de conférences qu'en 6 mois de veille à lire des blogs. Aujourd'hui je continue d'y aller pour les rencontres et pour le bol d'air frais et de bonne humeur que ça apporte. On y croise des artisans passionés de leur métier et le niveau général de compétence est très haut.