ConFoo 2019

Les 13, 14 et 15 mars 2019 a eu lieu à Montréal la conférence annuelle ConFoo à laquelle Zenika a participé en tant que sponsor avec des conférences présentées par Anna Filina et Aurélien Loyer. Au programme de ces trois jours : accessibilité web, architecture logicielle, performances web, communication,… C’est l’occasion d’avoir un condensé des nouvelles technologies, méthodologies et pratiques tout en ayant des retours d’expérience de personnes qui les ont mises en application.

Et c’est parti pour l’édition de #ConFoo #ZenikaMontréal #Teamdefeu #Zenika #codinglife #Developer #Darthmaul pic.twitter.com/XeEUtL5RPx

— St-Jean Micheline (@StJeanMichelin1) 13 mars 2019

Jour 1

Ask 10x Better Questions for More Effective Communication by Garth Henson

Pour son introduction Garth Henson nous lance cette interrogation:  “What are questions ?”
Le but de cette forme de communication est de récolter des informations et donc pour apprendre. Malgré le fait que cela soit un exercice pratiqué depuis le plus jeune âge, le constat est fait que dans le milieu professionnel, les questions ne sont pas toujours bien construites et cela amène des suppositions entres interlocuteurs et dans certains cas, brise la communication.
Comment poser une bonne question ? Cela repose sur trois règles :

• Le contexte
• L’utilité
• La précision

Outre le fait d’optimiser nos questions, il faut aussi éviter d’utiliser les questions rhétoriques, tendancieuses et négatives et bannir les mauvaises habitudes comme les questions acerbes, c’est cette mauvaise communication qui crée des tensions dans les équipes.
La construction de bonnes questions s’applique aussi lors d’un entretien que ce soit pour un nouvel emploi ou pour une mission. Il est nécessaire de poser des questions précises qui nous donneront le maximum d’informations sur le contexte, le rôle, les technologies en un temps très court:
Quel est le but des questions lors d’une entrevue technique ?
Quel est le niveau du poste ?
Quelles sont les principales responsabilités ?
Avec qui le candidat va-t-il travailler ?
Quel est le niveau de communication requis pour le poste ?

ARIA, HTML5 et la synthèse vocale by Rodolphe Rimele

Le cofondateur de AlsaCreations nous présente un résumé sur l’accessibilité numérique.
Selon l’OMS (Organisation Mondiale de la Santé) plus d’un milliard de personnes vivent avec une certaine forme de handicap, soit, 15% de la population mondiale. Or il y a aussi des handicaps temporaires dus à un accident ou au contexte, donc cela peut concerner tout le monde à un moment précis de notre vie.
Les principaux outils d’accessibilités numériques, à savoir, les liseuses d’écrans sont aptes à retranscrire par synthèse vocal, un site web ou une application, les plus connus sont JAWS, NVDA et VoiceOver.
L’accessibilité est supportée par tous les navigateurs, bien que certaines liseuses fonctionnent mieux avec des navigateurs précis, exemple : VoiceOver avec Safari.
Pour aider ces outils à pouvoir décrire correctement l’arbre d’accessibilité créée par les navigateurs, il faut avant tout, RESPECTER LA SÉMANTIQUE HTML.
Or avec les évolutions et comportements introduits avec JavaScript, comme les animations et les événements le HTML ne suffit plus pour permettre à tous les utilisateurs de naviguer convenablement, c’est ainsi que rentre en jeu ARIA qui définit des rôles et des propriétés à rajouter sur les balises HTML afin de pouvoir identifier et parfois enlever des comportements qui ne sont pas utiles pour une navigation assistée par une liseuse.
Certaines pratiques sont à proscrire comme, de redéfinir les rôles des balises existantes, <nav role=”navigation”> par exemple alors qu’en revanche on peut utiliser des attributs aria pour cacher les images ou pictogramme grâce à aria-hidden.
Pour les ajouts dynamiques dans le DOM, la propriété aria-live permet de notifier le changement à la liseuse et de continuer la lecture ou bien de couper la lecture en cours pour directement lire le nouveau contenu.

The first contact by Andreas Heigl

Le rôle du premier formulaire auquel un utilisateur va faire face est crucial, tout ce qui est avant celui-ci n’est que de la publicité. Or beaucoup de formulaires demandent énormément d’informations non nécessaires et dans un format non adapté.
Les noms

• Est-il vraiment nécessaire d’avoir deux champs séparés pour le nom et prénom ?
• Pourquoi ?

Suivant la culture les noms des personnes sont totalement différents et n’ont pas forcément un prénom et un nom, pour pallier à ce problème : utiliser un seul champ “Nom” en UTF8 et avec une limite de caractères assez grande.
L’adresse courriel

• Pourquoi demander deux fois l’adresse courriel ?

De toute façon la plupart des processus de création de comptes demandent une confirmation par courriel ensuite, permettez tout de même l’erreur en ajoutant un bouton pour renvoyer le courriel de vérification et un autre pour changer l’adresse renseigné.
Les dates
En ce qui concerne les dates, il faut indiquer précisément le format attendu ou alors proposer directement un sélecteur de date ce qui reste l’option la plus simple pour les utilisateurs.
Si vous demandez la date d’anniversaire pour les utilisateurs, faites le pour un objectif précis et si c’est le cas, communiquez le et rendez le optionnel, par exemple indiquez si vous allez envoyer un code promotionnel a cette date, il faut surtout éviter de l’utiliser pour vérifier l’âge des internautes pour des raisons évidentes… Si vous avez besoin juste d’un élément pour un aspect juridique mettez juste une case à cocher “Je suis majeur” si cela suffit par rapport aux lois.
Les champs requis
Les messages d’erreurs est l’une des choses les plus frustrantes pour les utilisateurs, surtout quand c’est un message générique en haut d’un formulaire d’une dizaine de champs et qu’il indique que “Something went wrong” sans aucune autre indication. S’il vous plaît, ne faites pas ça, le minimum serait de dire pourquoi il y a une erreur, la localisation du champ erroné et la solution pour réparer cette erreur ET aussi d’afficher TOUTES les erreurs si il y en a plusieurs, personne n’a envie de soumettre plusieurs fois un formulaire pour découvrir qu’il y avait d’autres soucis que celui annoncé auparavant.
Les mots de passe
Utilisez des sources externes comme OAuth, LDAP, SAML, Kerberos.
Donner la possibilité d’avoir plusieurs fournisseurs et pas seulement Facebook comme source d’authentification.
Si vous voulez quand même gérer l’authentification de votre côté, pensez à ces quelques points :

• Ne fabriquez pas votre système d’encryptage maison
• Évitez une taille de mot de passe minimum obligatoire
• Indiquez la qualité du mot de passe
• Encouragez les “passphrases”
• Autorisez les gestionnaires de mot de passe

Questions secrètes
Évitez de mettre des questions secrètes, ce sont souvent les mêmes qui sont utilisées et aussi faciles à récupérer via l’ingénierie sociale.
Captcha
C’est discriminant pour les utilisateurs avec un handicap, il vaut mieux utiliser des honeypot ou bien une authentification à deux facteurs.

The secrets of Hexagonal Architecture by Nicolas Carlo

Pour clôturer cette première journée bien remplie, on assiste à la présentation de Nicolas Carlo sur l’Architecture Hexagonale, qui est également créateur du Meetup Software Crafter de Montréal dont Zenika est un des sponsors.
Et cela débute par une histoire qu’il a vécue dans un projet avec des exigences de livraison très strictes dans lequel ils ont réussi à ajouter des protocoles de communication à leur code dans des délais très courts sans changer le code métier. Tout cela grâce à l’Architecture Hexagonale qu’ils avaient mis en place dès le début, que l’on connaît également sous le nom de Ports and Adapter Pattern mais dont le surnom Architecture Hexagonale a été introduit en 2005 par Alistair Cockburn dans son blog.
TLDR; Séparer Domaine et Infrastructure = Logiciel maintenable
L’hexagone contient tout ce qui est attrait au domaine alors que tout ce qui est lié à l’infrastructure l’entoure.
Schématiquement, l’Hexagone est séparé en deux côtés:

• à gauche il y a les adaptateurs qui exposent à l’extérieur le métier développé. C’est-à-dire une API, une interface utilisateur, une ligne de commande…
• et à droite nous avons les services tiers nécessaires au domaine comme une base de données, un service web d’authentification, un serveur de mails,…

La valeur du logiciel que l’on développe réside à l’intérieur de l’hexagone, il s’agit du domaine qui ne doit pas être mixé avec le code lié à l’infrastructure comme on pourrait le faire par facilité.
La marche à suivre lorsqu’on veut suivre cette architecture est de d’abord mettre en place la partie droite de l’hexagone, choisir une base de données et l’instancier par exemple ou alors faire le choix de consommer tel ou tel service web externe. Ensuite on peut passer à l’implémentation de notre domaine dont on exposera les fonctionnalités via la partie gauche de l’hexagone que l’on implémente en dernier.
Cette architecture permet de faciliter l’ajout de nouveaux adaptateurs sans avoir à toucher le métier de l’application qui est le cœur du projet qu’il ne faut pas endommager. L’avantage de cette architecture c’est qu’il ne s’agit pas de nouveaux concepts mais au contraire de concepts connus et utilisés dans différents langages (Programmation orientée objet et la programmation par interfaces, programmation fonctionnelle et isolation des effets de bord, principe SOLID). Ne s’agissant que de concepts, toute la difficulté est de les implémenter sans apporter de complexité supplémentaire.
Slides: https://www.nicoespeon.com/en/2019/03/the-secrets-of-hexagonal-architecture/

How to rock a demo by Suzan Ibach

C’est ici Suzan Ibach, aka la “Hockey geek girl”, qui nous présente ici ses meilleurs tips pour cartonner une démo.
TL;DR; S’il faut résumer en seul mot : Préparation !
Comment assurer sa démo? On peut identifier 3 catégories de préparation :

• Visibilité.

La visibilité regroupe les éléments de base de la démo : taille et police d’écriture, contraste des couleurs, lisibilité (écriture noire sur fond blanc, ou blanc sur fond noir ?). On ne parle pas seulement des diapositives, mais aussi de notre IDE ou terminal si l’on montre du code. Un outil intéressant que Suzan nous présente, pour les OS sans zoom built-in : Zoomit Enfin, dernier conseil pour une démo de code : Nettoyer son bureau ! (cacher les icones, ne garder que les app / bureaux essentiels, se déconnecter des services de notifications, courriels, twitter, etc..)

• Backups

Un trou de mémoire, une typo, un point virgule oublié ça arrive à tout le monde.. En démo, c’est tout de suite plus embêtant.. Pourtant il existe des moyens simples d’éviter ces erreurs: copier/coller son code depuis un fichier référence, commenter / décommenter du code, prévoir des code snippets, prévoir plusieurs steps (commits) via git. Autre source de problème à prévoir : une coupure internet.. Afin de pouvoir assurer sa démo même sans connectivité, il faut alors envisager de préparer plusieurs solutions : une solution qui fonctionne en local, des screenshots, ou même éventuellement une vidéo..

• Checklists

Afin d’être sûres de ne rien oublier, des checklists peuvent s’avérer très utiles. En amont, pour s’assurer de disposer du nécessaire à la démo : lancer certains logiciels, certains navigateurs, ouvrir une session, réinitialiser son code (live coding), lister ses backups, contrôler son matériel (câbles, micro, vidéo projecteur..). Lors de vos séances de live coding, avoir un aide-mémoire (cheat sheet) n’est pas interdit. Enfin, une checklist post-démo peut se révéler utile : penser à fermer certaines sessions, annuler certaines ressources créées pour la cause sur une plateforme cloud, il serait dommage de recevoir une facture quelques semaines après pour ce genre d’oubli (cf Suzan, c’est du vécu!).
Pour un exemple de préparation de démo par Suzan, plus d’infos ici : https://github.com/hockeygeekgirl/HowToRockADemo

Jour 2

The quest for Mo’Data, UX and Human Psychology by Martin Legris

Les données sont la nouvelle ruée vers l’or pour tout ce qui concerne l’anticipation du comportement utilisateur et pourtant de plus en plus de réglementations sont mises en place comme le GDPR (General data protection regulation) en Europe, pour protéger les données personnelles.
Les méthodes pour récolter les données de type tracking, cookies, ne sont pas forcément intéressantes pour le besoin utilisateur. Prenons l’exemple d’un produit quelconque que vous venez d’acheter sur internet, vous allez le voir apparaître dans les publicités alors que vous avez déjà comblé ce besoin.
Pourtant il existe des solutions pour amener l’utilisateur à trouver le bon produit :

• Le principe du like/dislike pour filtrer jusqu’au bon produit (Netflix)
• L’évaluation sur plusieurs niveaux, par exemple la couleur du produit, la forme, la taille,ect.

Voire même pousser le concept un peu plus loin et obliger l’utilisateur à mettre une note sur un produit pour avoir accès au suivant, jusqu’à trouver le produit parfait.
Toutes ces solutions augmentent l’engagement auprès des utilisateurs car ils voient un changement immédiat par rapport à leurs actions.
En résumé, il faut se concentrer sur la réaction humaine. Les humains aiment le mouvement et s’exprimer, il suffit d’orienter correctement ces affinités afin de pouvoir mieux servir leurs besoins. Pourtant nous avons tendance à faire de plus en plus d’applications stupides pour avoir plus d’utilisateurs, mais les humains veulent maîtriser leurs outils et explorer leur profondeur.
 

DLL Injection in Windows by Adam Furmanek

Adam Furmanek nous fait une mise au point d’entrée de jeu : Nous ne sommes pas ici pour parler piratage !  
Qu’allons-nous faire alors ? Le but présenté par Adam est d’exécuter notre code dans un processus cible : via injection de DLL, sans modifier le processus cible (pas de recompilation), en ayant accès à la machine librement (bien que nous ne serons pas forcément administrateur). On peut identifier plusieurs cas d’utilisation : extension de fonctionnalités, protection des processus (Windows EMET), spécifier une carte réseau particulière à utiliser (exemple avec forcebindip.exe), etc.
Comment allons-nous procéder ? Tout d’abord, Adam pose un petit rappel sur quelques notions de base, sans trop rentrer en détail :

• “Virtual address SPACE” : Chaque exécutable a son propre espace de mémoire isolé (abstraction des adresses mémoires)

• de façon implicite, au chargement
• de façon explicite, à l’exécution
  • On identifie ici une première méthode d’injection : 1) on mappe la fonction en mémoire, 2) on remplace le fichier DLL

• Ordre de recherche : Il existe également un ordre de recherche des librairies :

• Dans le dossier de l’exécutable
• Puis si la DLL n’est pas trouvée, dans le dossier System
• Puis dans le dossier Windows
• Puis dans le dossier courant
• Puis dans les dossiers listés par la variable d’environnement PATH

• Rebasing modules :

Chaque exécutable et DLL a une adresse de base préférée. Cette adresse identifie l’adresse idéale où le module devrait être mappé en mémoire.
Une DLL peut avoir une section de relocalisation (relocation section). Lorsqu’une DLL ne peut pas être chargée à son adresse préférée, le loader peut modifier la section de relocalisation et ajuster les emplacements mémoires (utilitaires Rebase + Bind)

• ASLR : Address Space Layout Randomization

C’est une technique de sécurité permettant de se prémunir des attaques de type “buffer overflow”. ASLR organise de manière aléatoire en mémoire :

• la position de la Stack
• la position de la Heap
• la position des librairies
• la base de l’exécutable

Place aux démos :

Adam nous présente alors trois méthodes d’injection de DLL

• En utilisant le registry

Au démarrage du processus cible, la librairie User32.dll est chargée. Cette librairie va alors charger les DLL présentes dans un dossier identifié par une clé de registre : HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs  

• En utilisant les Windows hooks

Les hooks nous permettent d’exécuter du code lorsqu’un event est envoyé par le système. Démo à effet “wow” , Adam nous montre comment coder un simple keylogger en quelques minutes..

• En utilisant les threads distants

Les deux premières méthodes ne nous permettent pas de contrôler le moment de l’injection de notre code (au chargement, ou à chaque événement). Cette méthode permet de contrôler le processus cible ainsi que le moment de l’exécution de notre code. Comment ? Grâce aux différentes méthodes proposées par Windows :

• LoadLibrary / LoadLibraryEx : pour charger notre librairie au runtime
• CreateRemoteThread : pour créer un thread distant
• VirtualAllocEx : Pour allouer de la mémoire dans un autre process
• WriteProcessMemory : Pour écrire le chemin de la DLL dans la mémoire précédemment allouée

Le plan final revient à :

• Allouer de la mémoire dans le processus cible
• Y écrire le chemin d’accès à notre DLL.
• Utiliser la fonction LoadLibrary afin de charger notre librairie.

D’autres méthodes d’injections existent encore. Pour plus de détail, rendez-vous sur le blog d’Adam Furmanek

Jour 3

Un zeste de Nest pour réhausser le goût du back-end JS by Cyril Lakech

On constate qu’il existe assez peu d’outils pour structurer et organiser un back en NodeJs – un peu à la manière du très célèbre Spring boot pour les développeurs backend javaistes – alors qu’une flopée de frameworks front-end tels que Angular, React et Vue existent pour les développeurs frontend, la plupart des développeurs backend utilisant Express..   
C’est ici qu’intervient Cyril Lakech en nous présentant NestJS et ses avantages principaux :

• Basé sur Express
• Utilisation de Typescript
• Respect des principes SOLID
• Propose une architecture applicative
• Tests simplifiés
• Tiré du monde d’Angular et Spring Boot

Plus en détail, voici ce qu’apporte, techniquement parlant, Nest :

• Services REST : De simples décorateurs sur les classes / méthodes : @Controller, @Get()

• Providers : Annotés d’un décorateur “@Injectable”, les providers (services, helpers, etc.) sont injectables dans les constructeurs (“angular like”)
• Découpage en composant / modules (et même des modules dynamiques, permettant de charger de la conf de façon asynchrone)
• Middlewares : permettent d’accéder à la requête, réponse, et chaîner d’autres middlewares
• Exception filters: permettent de gérer les exceptions jetées par l’appli, (à la manière des ExceptionHandlers de Spring boot)
• PIPES : via un décorateur sur méthode, ex : ValidationPipe https://github.com/typestack/class-validator
• Testing : simplifié par le découplage avec Express (plus besoin de mocker des objets propres à Express comme “req”, “res”), ainsi que grâce à l’injection de dépendance (toute dépendance peut être facilement mockée)  

Et encore beaucoup de notions à approfondir pour les plus curieux d’entre vous : Interceptors, guards, graphql, microservices, websockets, CLI, authentication, ORM, CQRS, Caching, execution context, PRISMA..
Plus d’infos sur le talk de Cyril : https://github.com/clakech/nestjs-talk

Conclusion

La conférence annuelle ConFoo a tenu ses promesses, ces 3 jours nous ont permis d’aborder des sujets variés que nous avons pu mettre en application dans les semaines qui ont suivi. L’Hotel Bonaventure, lieu de la conférence, offrait un espace immense pour les présentations d’ouverture et le repas (excellent par ailleurs), ainsi qu’un bon nombre de salles permettant d’avoir jusqu’à 9 présentations en parallèle.
Ces 3 jours ont aussi été l’occasion pour une partie de l’équipe Zenika de partager un moment privilégié, d’échanger sur nos sujets favoris et surtout de renforcer nos liens.

Cet article a été co-écrit par 3 consultants de Zenika Montreal : Corentin Cocoual, Cédric Merle et Vincent Vanghelle.