Paris Web 2013

Introduction

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.

Tags : #parisweb

Want to add something ? Feel free to get in touch on Twitter : @pixelastic