Best of Web 2017

Vous reprendrez bien de la techno web?

Paris est une ville bruyante, avec des métros qui ne fonctionnent pas, et des gens tristes. Mais c’est aussi une ville pleine de meetups web passionnants, avec certains centrés sur une technologie (React, Angular, Vue) ou plus généralistes (Human Talks, ParisJS, Paris API). Depuis 3 ans, ces meetups se réunissent une fois par an pour proposer le meilleur des présentations sur une journée. Ainsi est né Best of Web.

Avant de parler des présentations, j’aimerais juste rappeler ce qui fait la spécificité de Best of Web: tous les speakers sont des bénévoles, qui ont originellement fait leur présentation dans un meetup, et qui la refont aujourd’hui dans une grande salle, devant environ 500 personnes. Pas de pression. Cette journée est également très peu chère en comparaison des autres conférences, le billet plein tarif étant à 50€.

On a assez parlé des détails, passons aux présentations!

Keynote: Le développeur fullstack existe-t’il? (Thomas Guenoux)

Après un rappel des 2 premières révolutions industrielles, Thomas nous a expliqué que l’informatique était la troisième révolution industrielle, et qu’aujourd’hui l’algorithme fait foi, car c’est lui qui choisit les mises en avant sur Facebook, les recommandations pour le repas du midi, le chemin à prendre en voiture, etc etc.

En tant que développeur, nous passons beaucoup de temps à nous former sur des frameworks/technologies, à faire de la veille en lisant des articles dans le métro, à la pause de midi, le soir…

Mais cette technologie n’est qu’un outil, qui nous sert à créer des choses. Il nous faut penser plus loin que le code, prendre du recul. Nous sommes les artisans de cette révolution industrielle, et ce sont nos choix qui façonneront le monde de demain. Cette révolution préfigure la prochaine révolution industrielle, qui sera l’IA.

On va encore moins dormir.

Service-public.fr: Accessibilité et Agilité (Adrien Saunier)

L’accessibilité est souvent mise de côté aujourd’hui, et pourtant beaucoup de gens sont atteints de handicaps: problème physique qui empêche d’utiliser une souris, daltonisme, fatigue extrême, etc.

Il n’est pas très compliqué de rendre un site accessible, mais c’est encore plus simple si on s’y prend le plus tôt possible. Il ne faut pas que l’accessibilité soit un bonus, il faut que cette notion soit intégrée aux fonctionnalités à développer, et que ce soit un critère de qualité dans le livrable final. Corriger l’accessibilité a priori est une plaie, surtout si cela impose de changer de composant/recoder un bloc entier.

Quelques tips:

• La syntaxe HTML doit être valide
• Le titre des pages est important. Un utilisateur aveugle avec 5 onglets ‘Service public’ doit relire chaque page pour savoir quel est le contenu de la page. Alors qu’avec ‘Service public / Documents à fournir pour une demande de passeport’, il n’y a pas d’effort à faire.
• Le site doit être utilisable au clavier uniquement. Et là on se rend compte de l’utilité des skip-link.
• L’information ne doit pas être portée uniquement par la couleur. Un bouton rouge ou vert, pour un daltonien, c’est compliqué. Un texte ‘OK’ ou ‘KO’ est bien plus accessible

SOLID principles for Front-End Developers (Gregory Ruiz)

Une explication des principes SOLID appliqués en TypeScript. On retrouve vraiment les mêmes concepts qu’en Java, donc cette présentation était bien plus destinée aux développeurs front, et j’avoue n’avoir pas plus d’informations intéressantes à rajouter sur le sujet.

React Storybook (Marie-Laure Thuret)

React Storybook est un outil permettant d’écrire des stories descriptives pour visualiser tous les états voulus de son composant React. C’est très utile pour isoler techniquement un composant (Presentational component, qui ne dépend pas de Redux), et décrire tous les cas d’affichages possibles.

Avec quelques plugins (StoryShots pour les tests de rendu, à base de snapshots, Specs add-on pour ajouter des tests automatiques, avec ré-exécution à chaque rafraichissement), on peut obtenir une documentation à jour, vivante, et avec laquelle l’utilisateur peut jouer en temps réel, ce qui est génial si vous proposez une librairie de composants.

https://github.com/storybooks/storybook

Le même outil existe aussi pour Vue: https://github.com/vue-play/vue-play

La technique des Fab Four (Rémi Parmentier)

Faire des emails responsives, en 2017, est toujours une plaie. La plupart des clients ne supportent ni Flexbox, ni les media queries. Et là, c’est le drame. Et GMail a une liste blanche de propriétés CSS, et filtrera toutes les autres.

Rémi nous a présenté la technique qu’il a développée, et détaillée sur son site personnel.

En résumé, en utilisant min-width, max-width et width avec calc, il applique une width immensément grande si on est au-dessus d’un breakpoint défini, et donc le composant prendra la taille définie par max-width. Si on est sous ce breakpoint, width aura une valeur négative, et donc le composant appliquera sa min-width.

Elm + Web Components = ❤ (Kevin Lebrun)

Une présentation très basique d’Elm, avec l’exemple du compteur, visible sur le site d’Elm, pour ensuite partir sur une communication entre Elm et Javascript, à l’aide des ports.

Faire du bruit avec Pizzicato.js (Alejandro Mantecon Guillen)

L’API WebAudio est une API de très bas niveau, et nécessite donc beaucoup de code utilisateur pour pouvoir être concrètement utilisée.

Pizzicato est un framework qui a pour but d’aider à l’utilisation de cette API native, avec des effets préconfigurés, et des aides pour se brancher sur différentes entrées (fichier son, entrée USB, etc).

Avec une démo en live avec une guitare branchée sur le PC, et des effets WebAudio appliqués sur les sons de la guitare, c’était vraiment bluffant et super cool!

Faire cohabiter React et D3 (Christophe Rosset)

Il y a plusieurs façons de faire cohabiter React et D3:

• Dans React, on peut récupérer une référence au nœud DOM avec l’attribut ref, puis passer ce noeud DOM à D3, pour ensuite appliquer du D3 de façon classique
• Utiliser react-faux-dom pour créer un faux élément de DOM, et ensuite appliquer D3 dessus
• Refaire l’arborescence SVG en pure JSX, mais cela revient à refaire D3 en React. D’autres l’ont fait avant, comme Victory ou Recharts

Reverse engineering d’une API SOAP chiffrée (Kévin Raynel)

Kévin avait un problème: l’application qui pouvait lui permettre de récupérer ses fiches de paie ne fonctionnait que sous IE. Mais pas IE Edge. Un vieil IE.

En utilisant Charles, un décompilateur DotNet et hexdump, il a décompilé l’application Windows, analysé les requêtes réseaux, et fait un Man In The Middle entre le client et le serveur, pour arriver à une application finale lui permettant de récupérer ses notes de frais.

Créer une expérience WebVR sur toutes les plateformes (David Rousset)

Une présentation centrée sur Babylon.js, un moteur que David a créé il y a quelques temps. Débuté en Javascript, Babylon est maintenant développé en Typescript.

Plutôt que de tester le navigateur, il faut mieux tester si le navigateur supporte WebVR. Lorsqu’il est en mode WebVR, le navigateur tourne à 90FPS, pour éviter le motion sickness, et donc requestAnimationFrame est appelée en conséquence.

Pour gérer le déplacement, on peut utiliser un gamepad (Gamepad API!), mais déplacer la caméra virtuelle alors que le corps ne bouge physiquement pas est une très bonne solution pour se faire vomir, donc à éviter.

Les autres possibilités sont d’utiliser le regard, et de téléporter la caméra lorsqu’on fixe un point. Il est aussi possible d’utiliser les manettes pour viser un point, et téléporter l’utilisateur. L’important est de toujours mettre des indications visuelles pour montrer ce qui est utilisable.

Tour d’horizon des 3 grandes méthodologies CSS (Jonathan Verrecchia)

J’avais déjà vu cette présentation au meetup JS-Star chez JS-Republic, donc c’était une redite pour moi!

Le problème initial avec la CSS est son imprédictibilité. Une classe peut être surclassée par un style défini dans un autre fichier, mais avec un ciblage plus précis (‘.classe’ aura moins de priorité que ‘body .classe’). Cela ne permet pas de connaitre le style finale d’une page en regardant le code HTML.

Les 3 méthodologies pour résoudre ce problème sont:

• Une méthodologie de nommage (BEM, SUIT CSS, SMACSS). On évite au maximum le phénomène d’écrasement de règles CSS, avec des règles strictes sur le nommage de la CSS.
• CSS-in-HTML. On utilise une classe CSS pour définir une seule règle. Par exemple <div class='fl-r bgc-red m-b-20'> sera en float right, background red, et margin-bottom à 20px. Cela alourdit l’HTML, mais le problème d’écrasement de la CSS est évité. Les principaux frameworks sont Tachyons, Basscss, et Atomic CSS.
• CSS-in-JS. Le plus connu avec React. Cela permet d’isoler le style par composant, en déléguant à webpack la génération de classes CSS uniques à chaque fois.

Construire une “Raspberry Pi home alarm” en moins de 3 heures (Raphael Dubigny)

Raphael voulait se construire une alarme pour son appartement parisien vieux et peu sécurisé. A l’aide d’un Raspberry Pi, un module bluetooth, une caméra infrarouge, très peu de soudures et quelques APIs (Twilio, IFTTT, Google Drive), il a programmé une alarme qui prend des photos lorsqu’il y a du mouvement à la caméra, et qu’il n’est pas connecté au bluetooth local.

Il a ensuite amélioré son système en rajoutant une détection de vibration de la porte, une lumière qui s’allume automatiquement, une alarme sonore à 110db et du reactive programming.

Comment tirer le maximum de vos contributeurs (Vincent Voyer)

Dans un projet open source, la contribution d’utilisateurs extérieurs au projet est quelque chose d’essentiel pour s’assurer que le projet survive.

Pour voir plus de contributeurs, il faut leur simplifier la tâche au maximum:

• Un README clair, précis, qui permet de très vite comprendre le but du projet.
• Un template de bug report, pour guider le contributeur qui veut ouvrir un ticket. Eventuellement un JSFiddle prêt à l’emploi, pour permettre de reproduire facilement le bug.
• Communiquer clairement. Les intentions passent mal à l’écrit, il ne faut jamais supposer, toujours demander des clarifications.
• Aider les développeurs. Mettre un npm start qui fait le maximum possible, pour que le développeur n’ait aucun problème à corriger un bug.
• Pour les tests, fluidifier l’expérience au maximum. Mettre un npm test qui lance tous les tests.
• Mettre un outil de linting (Eslint, Tslint) et de formatage (Prettier). Le style ne doit pas être un problème, il faut encore une fois avoir le moins de travail manuel à faire.
• La documentation doit être claire, avec des exemples live si possible, pour permettre de facilement rentrer dans le projet.
• La pull request: Pour les projets graphiques, utiliser Netlify pour faire un déploiement automatique, afin de permettre au reviewer de facilement voir les impacts de la pull request. Sinon, bien évidemment, utiliser Travis CI pour tester automatiquement le code.
• La livraison. Il faut toujours livrer un changelog à jour, car les utilisateurs/développeurs utilisant votre produit veulent savoir ce qui change entre les versions. Des outils comme Conventional Changelog permettent de générer des changelog automatiquement à partir de l’historique Git.
• Distribuer le code, sur npm pour les projets Javascript, et sur JSDelivr comme CDN, pour permettre du prototypage rapide (il suffit d’inclure une balise script, sans besoin de créer un projet npm de test)

En conclusion: il faut toujours essayer de simplifier au maximum l’expérience des contributeurs, pour attirer le plus de gens possibles.

Conclusion

Un programme très complet cette année encore, avec beaucoup de sujets qui couvrent un très grand champ des technologies du web. Une organisation au top, sans aucun problème dans la journée. On se revoit l’année prochaine!

ET RENDEZ VOS PLACES QUAND VOUS N’ALLEZ PAS AUX MEETUPS!