Dans cet article un peu inhabituel car non technique, je résume les étapes de création de mon modeste "nouveau" setup.

Le matériel​

Aucun sponsoring, ni placement de produit. La plupart des fournitures peuvent être achetées dans des enseignes physiques... Mais c'est plus compliqué en plein confinement.

Avant de me lancer, j'ai évidemment fait le point sur les contraintes esthétiques et budgétaires ainsi que sur l'espace disponible. Mais aussi sur le temps que je voulais et pouvais y accorder. Le bricolage, comme le développement, a ce goût facheux de "on peut toujours faire mieux" et "oups, ça fait déjà X heures que j'y suis".

Plan, ou plateau, ou tablette​

Je le voulais épais et en bois brut, profond d'au moins 60 cm et long de 140 cm. J'ai trouvé chez Leroy Merlin des plans de travail en chêne lamellé collé de 250 x 65 x 3.6 cm, pour 149.5€. J'ai payé 5€ (en magasin) pour une coupe à 140 cm. J'ai déjà prévu de faire un banc avec la chute de 110 cm, mais ça, c'est totalement hors-sujet 😂.

J'ai aussi acheté du vernis pour embellir la teinte du bois et le protéger des liquides (coffee & tea snob speaking 🤓). Un vernis mat couleur chêne clair à 11.90€. J'avais déjà le pinceau (premier prix).

Coût : ~ 167€ (avec une chute de 110 cm).

Enfin, il faut poncer ce plateau ! J'avais déjà la ponceuse, les feuilles abrasives (grain 120 et 240) et les tréteaux. Les tréteaux sont optionnels mais il faut absolument une cale à poncer (à défaut d'une ponceuse) et des feuilles abrasives.

Les pieds​

Je savais précisément ce que je voulais : des cadres en acier d'au moins 70 cm de haut et de 50 cm de profondeur. C'est sur Amazon que j'ai trouvé le meilleur prix. Ce modèle de 72 x 50 x 6 cm, pour 94€ (84€ de pieds, 10€ de livraison).

Pour l'assemblage, j'ai acheté des vis au poids chez Leroy Merlin, de 6 mm de diamètre (le plus épais à la vente, avant de passer aux tire-fonds) et de 30 mm de long, la planche faisant 36 mm d'épaisseur. Coût négligeable : moins de 2€.

Coût : ~ 96€.

Au travail​

Assemblage​

J'ai pu préparer le plateau en attendant les pieds. Les étapes sont relativement simples :

• Ponçage (grain 120), un coup d'aspirateur et on essuie au chiffon humide.
• Première couche de vernis (au pinceau) que je laisse sécher 2 heures.
• Ponçage très léger (grain 240) pour enlever les aspérités ("égrener"), un coup d'aspirateur et on essuie au chiffon humide.
• Deuxième et dernière couche de vernis (toujours au pinceau), que je laisse sécher 24 heures.
• Ponçage superficiel (grain 240) pour obtenir une surface lisse... Et on nettoie encore.

J'ai regardé quelle face avait le meilleur aspect, pour en faire le dessus du bureau. C'est naturellement dans l'autre face que j'ai vissé les pieds.

Et voici ce qu'on obtient pour 263€ (hors pinceau et ponceuse/papier de verre) :

J'ai profité des étapes de ponçage pour arrondir les angles (border-radius quand tu nous tiens !) et rendre la pose des avant-bras plus confortables, en plus d'adoucir le rendu visuel du plan. À ce stade, j'avais déjà investi environ 4 heures dans le projet, en comptant l'aller-retour en magasin.

Pimp My Desk​

C'est super, mais on est encore loin des bureaux de grands seigneurs de Youtube. Certes, mais on peut toujours s'en approcher. Enfin, voilà où j'en suis actuellement :

Un piédestal pour leurs majestés​

J'aime travailler en dual screen, en utilisant mon laptop comme écran secondaire. Pour des raisons de confort (et faciliter son refroidissement), j'ai acheté un support dédié à 30€, simple mais efficace, avec un design tout à fait valide pour ce prix.

Quant à moi, j'ai découvert récemment les joies du coussin repose-pieds et en ai acheté un pour 15€.

Couvrez ce câble que je ne saurais voir​

Le cable management, étape si chère à tant de perfectionnistes, joue un role clé dans le rendu final du setup. J'avais déjà des serre-câbles auto-bloquants, j'ai donc seulement acheté des clips adhésifs sur Amazon pour 12€ et du ruban adhésif double-face pour 10€.

La prise de courant la plus proche étant face au pied "arrière gauche", j'ai profité de celui-ci pour y cacher ma multiprise (collée au double-face). Dans la mesure où je n'ai pas opté pour des pieds réglables (je n'aime pas bosser debout), le reste a été extrêmement simplifié par l'achat d'un bras-support pour mon écran (un vieux iiyama 24" qui prendra bientôt sa retraite) pour 35€, déjà équipé de de bagues passe-câbles.

J'ai suivi deux règles :

• Cacher tout ce qui était visible en étant face au bureau, ou de biais (assis et debout).
• Ne pas faire de "plats de spaghetti", pour faciliter l'ajout de futurs équipements.

Les clips permettent de plaquer les câbles sous le bureau et de les faire remonter jusqu'au bras-support de l'écran, qui permet de tout cacher (hub USB + HDMI + alimentation, branché au laptop avec un seul port USB-C).

Gimme the light​

Enfin, cette petite touche "kikoo" qui fait toute la différence (et un peu de rétro-éclairage la nuit) : la bande de LEDs !

J'ai acheté une longueur de 2 mètres (4 x 50 cm) pour 12€, que j'ai faite passer sur les deux chants face au mur, avec un retour de 50 cm sous le bureau, qui éclaire gentiment le sol. La bande est alimentée en USB et peut être pilotée en bluetooth ou avec sa télécommande.

🦀 Grâce à cet article, j'ai pu récupérer les messages envoyés à la bande, puis identifier ceux qui permettaient de contrôler la couleur et l'intensité lumineuse... Et grâce à cette lib Rust, alterner le Rouge & Vert depuis mon laptop. J'ai donc bien envie de bricoler un plugin Jest qui rythmerait mes sessions de red/green/refacto en TDD 🤩.

Bilan​

Du côté des coûts :

• Environ 263€ pour le meuble (+ une chute de 110 cm de plan)
• Environ 114€ d'accessoires (j'ai utilisé un dixième des clips et du ruban double-face)

Du côté du temps :

• Environ 4 heures pour le meuble
• Environ 2 heures pour l'assemblage du bras, le cable management, le passage des LEDs
• 4 bonnes heures à : récupérer les échanges Bluetooth entre mon smartphone et la bande de LEDs, configurer le bluetooth sur ma machine toute neuve (Arch 5.9+) et m'éclater comme un gosse avec Rust et les couleurs 🤦😂...

J'étais parti pour fabriquer mon propre tiroir, mais cela nécessite beaucoup plus de matériel pour être bien fait. Du coup, j'hésite encore entre plusieurs modèles de caissons noirs en acier.

Mon siège vient d'Ikea, modèle "VOLMAR" (acheté 300€ en 2016).

• Le clavier est un Logitech K800 (49€ lors d'une promotion Amazon, il y a un mois).
• La souris est le modèle 2020 "ergonomique" de VicTising (15€).
• Le hub USB est une sous-marque aussi, à 35€ (HDMI + ports USB + USB-C power).
• Je projette d'acheter l'écran 27" iiyama ProLite XUB2792QSU pour remplacer l'actuel 24".

À très vite pour un article plus technique 🎅 !

Rappel sur la CI​

L'objectif​

La plupart du temps, les développeurs écrivent du code. L'intégration continue encourage la fusion (merge) fréquente de ce code dans le projet, plutôt que d'attendre l'approche d'une livraison pour y intégrer tous les derniers développements simultanément. Cela permet de drastiquement diminuer la quantité de conflits à résoudre entre feature branches. Les équipes de QA apprécient aussi la réduction de la durée/intensité de leurs sessions de test.

En pratique​

Pour augmenter la fréquence des fusions, il est impératif que chaque développeur sache le plus rapidement possible si ses modifications entraînent des régressions. La CI a pour but d'automatiser les tâches garantissant la santé du code : lint, compilation, mesure de qualité, exécution des tests, etc. Ces tâches sont ainsi exécutées à chaque modification du code d'une branche, pour déterminer si le nouveau code est intégrable sans risque. Les erreurs sont ainsi détectées très tôt dans le processus de développement (fail fast!).

En plus des outils de mesure de la qualité et des tests automatisés déjà présents dans le projet, il faut investir dans l'écriture d'un pipeline d'intégration continue. Cet investissement est vite rentabilisé par un gain significatif de productivité (confort, confiance).

Ce que j'utilise : GitLab CI​

GitLab CI est la solution open source de CI/CD intégrée à la plateforme GitLab, elle-même open source. Chaque push sur chaque branche du projet va déclencher l'exécution du pipeline d'intégration. Elle est bien documentée et gratuite dans la limite de 400 minutes par mois sur les shared runners : au-delà, il faut payer, ou utiliser son propre runner.

Il existe d'autres solutions, comme les GitHub Actions, Travis ou CircleCI. Contrairement à ses concurrents, GitLab CI n'offre pas encore de runner "clé en main" sous Mac OS (donc pas de build Xcode).

Enfin, il est possible de transformer n'importe quelle machine (PC, Macbook, carte ARM, serveur dédié...) en runner, en y installant GitLab Runner. J'en dis plus dans la suite de l'article !

🔄 Dessine-moi un pipeline​

Chaque pipeline est constitué d'un ou plusieurs jobs (travaux) regroupés en stages (étapes). Les jobs d'une même stage sont exécutés en parallèle. Si un job échoue, la stage échoue et interrompt l'exécution du pipeline : les stages suivantes ne sont pas exécutées. À moins que le job n'ait été autorisé à échouer. La terminologie change d'une plateforme à une autre, mais on retrouve souvent la même construction. CircleCI parle de Workflows et de Jobs, Travis CI de Build Stages et de Jobs.

La documentation des Pipelines GitLab CI est très bien faite et il existe aussi de nombreuses templates officielles prêtes à l'usage.

👮 Gardons à l'esprit, pour la suite de l'article, qu'un pipeline se doit d'être déterministe et aussi rapide que possible.

La définition du pipeline se fait dans un fichier .gitlab-ci.yml à la racine du projet. GitLab détecte automatiquement ce fichier. Dans mon projet (mono-repo, fullstack), j'ai défini les stages suivant :

# .gitlab-ci.yml
stages:
  - build-and-test
  - deployment

Et je vais présenter, ici, deux jobs de la stage build-and-test : la construction de l'image docker de l'application frontend et celle de l'application backend. Ces jobs sont exécutés, à la racine du dépôt, à chaque fois qu'une modification du code est poussée dans ce dernier.

Frontend​

# .gitlab-ci.yml
# [...]
🏠 Frontend - Build and tests:
  stage: build-and-test
  image: docker:stable
  script:
    - docker build -f app/Dockerfile -t frontend-build .

Le job nommé 🏠 Frontend - Build and tests, associé à la stage "build-and-test", utilise l' image docker docker:stable pour exécuter son script qui consiste en un docker build. Le Dockerfile app/Dockerfile va :

• Installer les modules NPM (yarn install)
• Valider la bonne compilation de l'ensemble de la codebase TypeScript (yarn tsc)
• S'assurer du bon linting du code (yarn lint)
• Vérifier que le projet puisse être construit (yarn build)
• Exécuter les tests unitaires et end-to-end (Cypress) (yarn test et yarn e2e)

# ./app/Dockerfile
# Image cypress : node, npm, yarn + cypress et ses dépendances
FROM cypress/base:14.15.0

WORKDIR /app

ENV NODE_ENV='development'
ENV TZ='UTC'
ENV CI=true

# dans ce projet fullstack, le répertoire ./app contient le frontend
ARG FRONTEND_DIR='/app'
# le frontend et le backend sont des yarn workspaces: chacun son package.json
COPY ${FRONTEND_DIR}/package.json /app/package.json
COPY yarn.lock /app/yarn.lock

RUN yarn install --frozen-lockfile --prefer-offline --no-progress --no-emoji

ADD ${FRONTEND_DIR}/. /app

RUN yarn tsc:all
RUN yarn lint
RUN yarn build
RUN yarn test
RUN yarn cypress install
RUN yarn e2e:ci # start-server-and-test start http://localhost:8000 cypress run

CMD yarn start

Si l'une de ces tâches échoue, la commande docker build échoue, entraînant l'échec du job.

Il est évidemment possible d'exécuter ces commandes yarn directement dans le script du job :

# .gitlab-ci.yml
# [...]
🏠 Frontend - Build and tests:
  stage: build-and-test
  image: node:14.15.0-stretch-slim # on utilise une image node directement !
  script:
    - yarn install --frozen-lockfile --prefer-offline --no-progress --no-emoji
    - yarn tsc:all
    - yarn lint
    # ...

L'avantage d'exécuter ces tâches en construisant une image Docker est de profiter de son build cache incrémental 🐋, quand le pipeline est exécuté systématiquement sur la même machine. Ainsi, à la prochaine exécution de docker build, yarn install ne sera pas ré-exécuté si package.json n'a pas été modifié. Même principe pour lint, build, test : pas exécutés si le code à copier dans ./app n'a pas été modifié.

Backend​

# .gitlab-ci.yml
# [...]
🏗 Backend - Build and tests:
  stage: build-and-test
  image: docker/compose:latest
  script:
    - docker build -f backend/Dockerfile -t backend-build .
    - docker-compose -f backend/ci/docker-compose.yml up --force-recreate --exit-code-from backend

Le job construit une image Docker à partir du Dockerfile backend/Dockerfile, à la manière du projet frontend (install, lint, build, test...).

Si l'image est construite, alors docker-compose est utilisé pour lancer deux containers : un pour lancer les tests d'intégration et end-to-end de l'application backend, un autre pour l'émulateur de la base de données (Firestore).

# backend/ci/docker-compose.yml
version: '3.2'

services:
  backend:
    image: backend-build
    environment:
      FIRESTORE_EMULATOR_HOST: 'firestore-emulator:8081'
      FIREBASE_PROJECT_ID: 'firestore-testing'
      CI: 'true'
    depends_on:
      - firestore-emulator
    command:
      - bash
      - -c
      - |
        for ((i=0;i<30;++i));
        do curl -s firestore-emulator:8081 && break || (echo "Waiting for firestore emulator..." && sleep 1);
        done;
        yarn integration && yarn e2e;

  firestore-emulator:
    # using "alpine" as it is ~600MB smaller (but JDK 8+ is still required)
    image: google/cloud-sdk:316.0.0-alpine
    expose:
      - 8081
    command:
      - bash
      - -c
      - |
        apk --update add openjdk8-jre
        gcloud --quiet beta emulators firestore start --project=firestore-testing --host-port 0.0.0.0:8081

En passant --exit-code-from backend à docker-compose, le job réussit seulement si la commande du service backend (yarn integration && yarn e2e) réussit.

Kudos à mon ex CTO @DigitalLumberjack pour cette technique 💗.

Et c'est tout ?​

C'est un bon début ! Bien sûr, on peut aller beaucoup plus loin, en intégration comme en déploiement. Pour en apprendre davantage sur les possibilités de GitLab CI, je recommande (entre autres) :

• Les jobs conditionnels, avec rules, qui remplace only/expect : pratique, par exemple, pour déployer automatiquement l'application sur un environnement Staging quand le pipeline est exécuté sur la branche master.
• when, utilisable avec ou sans rules, permet avec la valeur manual d'ajouter des jobs à lancer manuellement (e.g. "Déployer en production"), mais aussi des jobs automatiquement lancés suite à un échec du pipeline (on_failure), etc.

🚀 Frontend - Deploy production:
  stage: production
  image: node:14.15.0-stretch-slim
  script:
    - yarn install --frozen-lockfile
    - echo "${FIREBASE_PKEY_FILE_JSON}" | base64 -d > ./firebase-credentials.json
    - yarn firebase deploy --token "${FIREBASE_TOKEN}"
  rules:
    - if: '$CI_COMMIT_BRANCH == "master"' # seulement possible avec "master"
      when: manual

• Les artifacts, fichiers conservés après l'exécution d'un job et téléchargeable par l'interface de GitLab. Utiles pour extraire les logs d'un test de performances, des captures d'écran et vidéos de tests Cypress, des rapports/extraits, etc.

• parallel permettant plusieurs exécutions simultanées d'un même job.

• L'injection de variables d'environnement dans GitLab CI, rendues accessibles dans .gitlab-ci.yml.

• La directive cache qui permet de transférer des fichiers d'un job à un autre. Utile si vous ne pouvez/voulez pas profiter du cache de build incrémental en lançant vos jobs dans des docker build.

• En quête de performances pour les machines virtuelles servant de runners, GitLab CI permet de configurer un cache distribué (AWS S3, Cloud Storage, Azure...).

🏃 Dessine-moi un runner​

Utiliser une machine dédiée peut mener à la réduction du temps d'exécution des pipelines : meilleur hardware 🚀, réutilisation du cache Docker 🐳 (docker build plus rapide) et du cache npm/yarn 📦 (les packages déjà en cache ne sont pas téléchargés à nouveau).
Accessoirement, en n'utilisant pas les shared runners de GitLab, on peut aussi :

• Éviter l'envoi de fichiers/codes sensibles sur des machines qu'on ne possède pas
• Utiliser la CLI Xcode si disponible sur la machine hôte (macOS)
• S'affranchir des limitations (commerciales) sur les shared runners

Si vous souhaitez déployer votre propre flotte de runners (kubernetes, cloud autoscaling, etc), il existe des exemples officiels. Pour ce projet personnel, j'ai utilisé un seul serveur dédié.

Il suffit d'installer l'utilitaire GitLab Runner sur la machine en question (avec docker pour executor) et d'enregistrer le runner dans votre instance GitLab. Les stages du pipeline seront directement exécutés sur la machine enregistrée.

💰 Pour de meilleures performances si votre budget est serré, dans le cas d'un serveur dédié, favorisez (en priorité) un SSD plutôt qu'un disque dur mécanique. Le reste (CPU, RAM) dépendra de ce que vous ferez/lancerez dans vos pipelines. Il vous appartient d'étudier toutes les possibilités en terme de budget (votre machine de travail, un serveur dédié, une flotte de machines virtuelles spot/préemptives...).

Une note sur Cypress​

Si vous rencontrez des problèmes de mémoire (Out of memory) lorsque vous exécutez vos tests e2e utilisant Cypress, c'est peut-être dû à une shared memory (shm) insuffisante, Docker lui allouant 64MB par défaut. Si vous utilisez votre propre runner, vous pouvez augmenter celle-ci en conséquence, en passant par exemple --shm-size=1G à Docker (dans mon cas, directement à docker build) et en ajoutant la même configuration à /etc/gitlab-runner/config.toml avec le paramètre shm_size :

# [...]
[[runners]]
  # [...]
  [runners.docker]
    # [...]
    shm_size = 1073741824

Et avec un projet déjà existant ?​

Démarrez petit ! On peut utiliser une image node officielle et directement exécuter yarn build, yarn test, etc, dans le script d'un unique job :

# .gitlab-ci.yml
stages:
  - build-and-test

build backend:
  stage: build-and-test
  image: node:14.15.0-stretch-slim
  script:
    - yarn install --frozen-lockfile --prefer-offline --no-progress --no-emoji
    - yarn lint
    - yarn build
    - yarn test

Ces quelques lignes suffisent à lancer un pipeline déjà très utile. Dans mon projet "starter" TypeScript, Gatsby, Material-UI (gatsby-gojob-starter), j'ai fourni deux bases de pipeline, une pour CircleCI, une autre pour GitLab CI. Loin d'être des modèles de perfection, elles permettent cependant de se lancer 😬>.

CD, "c'est plus qu'un Job"​

Concernant le Continuous Delivery et le Continuous Deployment, un nouvel article serait de rigueur. Dans le cadre de mon projet personnel, j'ai un environnement de production en continuous delivery : la nouvelle version de master est déployée par une action manuelle. Le job ressemble à celui-ci :

🚀 Frontend - Deploy production:
  stage: deploy
  image: node:14.15.0-stretch-slim
  script:
    - yarn install --frozen-lockfile
    - echo "${FIREBASE_PKEY_FILE_JSON}" | base64 -d > ./firebase-credentials.json
    - yarn firebase deploy --token "${FIREBASE_TOKEN}"
  rules:
    - if: '$CI_COMMIT_BRANCH == "master"'
      when: manual

Pour l'environnement de staging, j'utilise une version légèrement modifié de ce job : il est déclenché automatiquement quand une branche est fusionnée à master et vise staging comme hosting target pour déployer l'application vers un domaine Firebase spécifique. On parle ici de continuous deployment.

🚀 Frontend - Deploy staging:
  stage: deploy
  image: node:14.15.0-stretch-slim
  script:
    - yarn install --frozen-lockfile
    - echo "${FIREBASE_PKEY_FILE_JSON}" | base64 -d > ./firebase-credentials.json
    - yarn firebase deploy --token "${FIREBASE_TOKEN}" --only hosting:staging
  rules:
    - if: '$CI_COMMIT_BRANCH == "master"'

Il est possible de "refactorer" du YAML pour éviter les copy-paste massifs... À vous de jouer 😬.

La technique employée ici est spécifique à Firebase (firebase deploy). Il faut adapter le job aux contraintes techniques (Heroku ? Helm/Kubernetes ? Gestion des environnements...) et professionnelles (Sécurité ? Droits d'accès ? Politique de mise à jour...) de chaque entreprise.

Happy CI/CDing!

L'article est long, mais je pense qu'il apportera l'essentiel du livre à ceux qui n'ont pas le temps de le lire... Sans priver les autres de l'envie de le faire. Et je conseille à tous de le faire 😃.

Cette seconde édition du livre est une réécriture (partielle) pour JavaScript. Son but est de guider les développeurs dans l'amélioration de leur code, par petites itérations, sans en changer le comportement. C'est l'exacte définition du refactoring : changer la structure du code, sans changer son comportement...

Et non, Refactoring ne signifie pas "réécrire un code moche".

Pour ceux qui ne connaissaient pas l'auteur, je vous invite à lire son excellent site et à le suivre sur Twitter.

L'ouvrage présente un long catalogue des techniques de refactorings, consultable sur le site officiel.
J'en profite aussi pour partager Refactoring.Guru qui présente du contenu de qualité sur le refactoring et les design patterns, inspiré des livres comme : Refactoring, Effective Java, Design Patterns (GoF), Head First Design Patterns...

Chapitre 1 - Un premier exemple de Refactoring​

Le livre ouvre directement la marche avec un exemple. Le code de départ présente plusieurs imperfections (et code smells). Et ô surprise, une évolution est demandée par l'utilisateur 😱. Avant de se lancer, l'auteur effectue un rapide "état des lieux" (analyse critique).

Si l'ajout d'une fonctionnalité est compliqué à cause de l'état du code, l'auteur recommande le refactoring avant tout nouveau développement. Et avant de procéder à la moindre modification, il faut s'assurer que le code soit couvert par des tests.
S'ensuivent plusieurs techniques de refactorings du catalogue, en exécutant continuellement les tests pour vérifier que le comportement du code n'ait pas été altéré. Les refactorings appliqués sont assez communs : Extract Function (Method), Inline Variable, Move Method, etc. Petit à petit, le code servant d'exemple devient plus lisible et maintenable.

En résumé​

• Pas de refactoring sans test
• Le refactoring :
  • est effectué en petites étapes, précédées par une avancée dans la compréhension du code
  • ne modifie pas le comportement du code : les modifications ne nécessitent pas de nouveaux tests
  • n'a pas besoin d'être violent : même une petite amélioration est bonne à prendre, Boy scout rule, "Laissez le camp plus propre que vous ne l'avez trouvé"
• Les tests existants sont exécutés continuellement, c'est notre filet de sécurité
• Un code a été "amélioré" lorsqu'il est plus simple à modifier : la productivité du développeur est augmentée car il peut ajouter de la valeur au logiciel plus rapidement... "Code should be obvious".

Au risque de me répéter... Des petites étapes, appuyées par les tests. À l'image des baby steps du TDD, elles permettent d'éviter de longues sessions de debugging. Refactorman n'est pas un héros 😬.

Chapitre 2 - Les fondements du Refactoring​

Martin Fowler donne une définition précise de Refactoring, à la fois en tant que nom et en tant que verbe :

Refactoring (nom) : Changement de la structure d'un code pour faciliter sa compréhension et sa modification, sans changer son comportement observable.

Le comportement observable est celui connu par l'utilisateur. Il n'est pas question du comportement technique (allocations mémoires, utilisation des cycles CPU, etc.).

Refactoring (verbe) : Restructurer du code en appliquant une série de refactorings.

Donc, quand on refactor, on applique des refactorings. La prochaine fois qu'un collègue vous dira "ce code bug, je dois faire une refacto", n'hésitez pas à prendre un air hautain et toxique pour lui expliquer qu'il dit n'importe quoi 😏.

En effet, le terme est souvent mal employé (pour désigner une session de debug, voire la réécriture complète d'un code...). L'auteur a écrit un article à ce sujet : Refactoring Malapropism.

Le Refactoring : Pourquoi ?​

• Faciliter la compréhension du code (et par conséquent, la recherche de bugs)
• Améliorer la conception (design) du logiciel
• Développer plus rapidement

Dans son article Design Stamina Hypothesis, Martin Fowler présente l'hypothèse du seuil de rentabilité du design (qualité, conception), alias design payoff line.

Sous ce seuil, il est possible de gagner en productivité (livrer davantage de fonctionnalités) en négligeant la qualité (le design) du code. C'est ce qu'on appelle Acheter de la dette technique. Passé ce seuil, c'est l'inverse qui se produit : le développement est ralenti, les livraisons prennent du retard, la moindre modification devient coûteuse.

Le refactoring permet, par l'amélioration continue du code, de maintenir un certain niveau de qualité et de productivité 🤓.

Le Refactoring : Quand ?​

L'auteur affirme faire du refactoring en permanence, comme de nombreux développeurs qui y ont pris goût.

Le meilleur moment est celui qui précède l'ajout d'une fonctionnalité, ou la correction d'un bug. C'est ce que Martin appelle le Refactoring préparatoire. Il s'agit d'améliorer l'état du code avant d'avoir à le modifier.

L'auteur définit d'autres "catégories" de refactorings, comme :

• Compréhension : si le code a nécessité un effort intellectuel pour être compris, alors il est certainement possible de l'améliorer. Encore une fois, "Code should be obvious". Des actions aussi simples que Rename Variable peuvent avoir un sérieux impact.
• Ramassage des déchets : quand on remarque que le code est mal conçu, ou inutilement complexe. Il n'a pas besoin d'être entièrement réécrit, mais on peut l'améliorer progressivement, sur la durée. "Laissez le camp plus propre que vous ne l'avez trouvé".

Etc.​

Le chapitre est long et dense. L'article n'a pas pour vocation de couvrir tous les éléments qui donnent sa valeur au livre.

Néanmoins, puisque c'est un vice très répandu dans l'industrie, je partage l'une des notions abordées : la Speculative Generality. On connait tous un dév qui écrit parfois 3 fois plus de code que nécessaire "juste au cas où". Et il est même souvent "prêt à parier que ça va servir".
L'auteur avance l'idée qu'avec un refactoring continu, il est très facile de rendre le code plus flexible au besoin, plutôt que d'anticiper cette flexibilité (flexi-complexité...). C'est l'opposition entre le Use-case driven development et ce que j'appelle le "Just in case" driven development.

Speculative Generality est aussi abordé dans le chapitre 3 sur les code smells. Dans ce chapitre 2, Martin Fowler parle plus précisément de "Speculative flexibility".

Chapitre 3 - Les Smells dans le code​

Une longue série de Code smells, voilà ce qu'est ce (court) chapitre coécrit avec Kent Beck, l'auteur de Test Driven Development: by Example qui est aussi le créateur du "TDD".

Large class, Divergent Change, Shotgun Surgery, Duplicated code... Retrouvez-les sur Refactoring.guru.

Looks familiar...​

Au sujet de Large Class, Divergent Change et Shotgun Surgery, je trouve inévitable le rapprochement avec le Single Responsibility Principle (SRP) d'Uncle Bob, trop souvent mal interpété. En effet, celui-ci ne stipule pas qu'un module ne devrait faire qu'une seule chose mais qu'il ne devrait avoir qu'une seule raison de changer.

"Regroupez les choses qui changent pour les mêmes raisons. Séparez celles qui changent pour des raisons différentes".

En d'autres termes, le SRP (S de SOLID) a pour objectif de limiter l'impact des changements effectués dans le code. On peut considérer que c'est ce que préconise aussi le livre, avec ces smells.

Chapitre 4 - Construire les tests​

Martin Fowler explique la valeur des tests automatisés, leur nécessité dans le refactoring, et le temps qu'ils font économiser en "debugging" pour mieux le réinvestir dans la production de valeur ajoutée.

Si vous êtes, comme moi, habitué et rompu au TDD, ce chapitre ne sera pas le plus passionnant de l'ouvrage. Il a cependant le mérite de présenter les fondamentaux des tests unitaires et de recommander le TDD 🔥.

When you get a bug report, start by writing a unit test that exposes the bug.

Résumé​

Puisque tous les chapitres restants présentent le catalogue disponible en ligne, je passe directement au résumé 🎉.

Au-delà des techniques de refactorings présentées, j'ai apprécié la lecture de cet ouvrage aussi sage que pragmatique. Martin Fowler offrait, déjà en 2000, une solution à certains "travers" de l'industrie que l'on subit encore en 2020. J'aurais d'ailleurs souhaité le lire il y a 10 ans, quand j'ai écrit mes premières lignes de code en tant que Développeur "professionnel".

Quand on démarre un projet, il est impératif d'écrire le minimum de code pour répondre au besoin exprimé, qui est souvent encore mal compris et mal connu. Plus un code est simple, moins il demande d'effort en refactoring... Refactoring qui facilite son évolution tout en contenant sa complexité (inexorablement amenée à croître). Ce qui implique une vélocité préservée pour les développeurs. Comme le dit l'auteur dans le chapitre 3 :

After all, software is meant to be soft.

Puisque le refactoring ne doit pas être effectué sans test, et puisqu'il doit être effectué par petites itérations, c'est un parfait associé du TDD. Mieux que ça, il fait partie intégrante de son mantra "Red, Green, Refactor".

Je conclurai en vous recommandant chaudement la lecture et en citant cette punchline (que j'adore) présente sur la couverture :

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Récemment, c'est avec Nest que j'ai décidé de développer quelques Functions. Dans cet article, je vais rappeler ce que sont les Functions puis présenter une façon simple d'y intégrer Nest. En l'occurrence, avec Firebase Functions (Firebase avec des Cloud Functions).

FaaS : Functions As A Service​

Les Functions permettent de déployer et d'exécuter du code sur un serveur qui ne nous appartient pas. Zéro minute consacrée à la configuration, la sécurisation et l'entretien des machines. Tout ce qui est demandé au développeur, c'est d'écrire son code en respectant quelques règles (langage, structure, temps d'exécution...), puis de le déployer via une CLI, ou à la main.

L'exécution dudit code peut ensuite être déclenchée par un appel HTTP et/ou par un évènement : un fichier déposé sur AWS S3, un utilisateur inscrit dans Firebase Authentication, etc.

Le FaaS offre de nombreux avantages :

• Un déploiement et une disponibilité quasi instantannés du code
• Pas de serveur à louer, configurer, maintenir
• Auto-scaling : la montée en charge (comme la baisse...) est assurée par le service
• Une tarification à la carte dépendante du nombre d'exécutions, de leur durée, de la mémoire vive allouée

Et présente quelques limitations par nature et/ou fournisseur :

• Plafond de ressources, d'exécutions simultanées, de durée d'exécution
• Passé un délai d'inactivité, un délai de démarrage (cold start) est à prévoir à la prochaine exécution

Dessine-moi une Function​

On installe firebase-tools pour utiliser la CLI de Firebase, puis on crée le projet :

npm i -g firebase-tools
mkdir my-cat-in-the-cloud && cd my-cat-in-the-cloud
firebase login
firebase projects:list # vérifie la bonne authentification

firebase init functions # crée un projet ou utilise un existant
* Please select an option: Create a new project
* What language would you like to use to write Cloud Functions? TypeScript # 💖
* Do you want to use TSLint to catch probable bugs and enforce style? No # ESLint ftw
* Do you want to install dependencies with npm now? No # on va s'en occuper nous-même

La CLI génère firebase.json et, le plus intéressant, ./functions. Si on étudie rapidement ce dernier avant de l'effacer (#yolo), on voit dans package.json que sont inclus : firebase-admin, firebase-functions (dependencies) et typescript, firebase-functions-test (dev dependencies). Quant à src/index.ts :

import * as functions from 'firebase-functions';

// Start writing Firebase Functions
// https://firebase.google.com/docs/functions/typescript

export const helloWorld = functions.https.onRequest((request, response) => {
  response.send('Hello from Firebase!');
});

Il expose seulement une function helloWorld qui peut être exécutée localement de deux manières :

• yarn serve pour la servir avec un serveur HTTP: http://localhost:5000/my-cat-in-the-cloud/us-central1/helloWorld ("my-cat-in-the-cloud" étant le nom de mon répertoire et de mon projet Firebase)
• yarn start (ou firebase functions:shell) pour l'utiliser directement en mode shell :

$ yarn start
✔  functions: Emulator started at http://localhost:5000
i  functions: Loaded functions: helloWorld
firebase > helloWorld()
Sent request to function.
firebase >
RESPONSE RECEIVED FROM FUNCTION: 200, Hello from Firebase!

Dans ce code, pas de framework Web particulier : seulement une fonction onRequest qui prend en paramètre un callback de type Requête-Réponse.

Release the Kraken Cat​

Comme annoncé plus haut, on va supprimer ./functions ! ... Et créer un projet Nest à la place.

rm -rf functions
npm i -g @nestjs/cli # si vous ne l'avez pas déjà installé
nest new api && cd api
yarn && yarn add firebase-functions firebase-admin

Puisque le projet Nest a été nommé api, on change la propriété "source" des "functions" dans firebase.json :

{
  "functions": {
    "predeploy": "npm --prefix \"$RESOURCE_DIR\" run build",
    "source": "api"
  }
}

Le fichier api/src/main.ts doit exposer une Function, que l'on nomme très originalement api :

import { NestFactory } from '@nestjs/core';
import { ExpressAdapter } from '@nestjs/platform-express';
import * as express from 'express';
import * as functions from 'firebase-functions';

import { AppModule } from './app.module';

const startNestApplication = async (expressApp: Express.Application) => {
  const app = await NestFactory.create(AppModule, new ExpressAdapter(expressApp));
  return app.init();
};

const server = express();
startNestApplication(server).catch(err => console.error('Nest did not start', err));

export const api = functions.region('europe-west1').https.onRequest(server);

Ensuite, la CLI de Firebase doit connaître le point d'entrée de notre Function. Il faut ajouter une propriété "main" ayant pour valeur "dist/main.js" dans le package.json généré par @nestjs/cli.

Reste à compiler puis à exécuter !

$ yarn build && firebase serve --only functions
✔  functions: Emulator started at http://localhost:5000
i  functions: Watching "/home/vince/blog/my-cat-in-the-cloud/api" for Cloud Functions...
>  [Nest] 20843 - [NestFactory] Starting Nest application...
✔  functions[api]: http function initialized (http://localhost:5000/my-cat-in-the-cloud/europe-west1/api).
# [...]
>  [Nest] 20903 - [NestApplication] Nest application successfully started +2ms

On vérifie que l'API répond à nos requêtes :

$ curl http://localhost:5000/my-cat-in-the-cloud/europe-west1/api
Hello World! # Ça fonctionne 🎉

Et c'est gagné !

Pour déployer la Function, il faut indiquer à Firebase quelle version du runtime (Node.js) utiliser via package.json, et utiliser la commande deploy :

  "engines": {
    "node": "10"
  }

$ firebase deploy --only functions
=== Deploying to 'my-cat-in-the-cloud'...

i  deploying functions
Running command: npm --prefix "$RESOURCE_DIR" run build

> functions@0.0.1 prebuild /home/vince/blog/my-cat-in-the-cloud/api
> rimraf dist


> functions@0.0.1 build /home/vince/blog/my-cat-in-the-cloud/api
> nest build

✔  functions: Finished running predeploy script.
i  functions: ensuring necessary APIs are enabled...
✔  functions: all necessary APIs are enabled
i  functions: preparing api directory for uploading...
i  functions: packaged api (197.62 KB) for uploading
✔  functions: api folder uploaded successfully
i  functions: creating Node.js 10 (Beta) function api(europe-west1)...
✔  functions[api(europe-west1)]: Successful create operation.
Function URL (api): https://europe-west1-my-cat-in-the-cloud.cloudfunctions.net/api

✔  Deploy complete!

Partant de là, on peut imaginer :

• Créer de nouveaux controllers/endpoints (e.g. @Post('api/users'), @Get('healthcheck')...)
• Présenter une documentation Swagger (e.g. api/<route_choise_pour_le_document_Swagger>)
• Ajouter un endpoint pour GraphQL (e.g. api/graphql)

👮 Néanmoins, l'utilisation d'Express et de Nest entraîne nécessairement un surcoût en terme temps de lancement, de temps d'exécution et de mémoire consommée. Je ne recommande pas de le faire en production sous prétexte que "c'est possible". L'article Web Frameworks Implication on Serverless Cold Start Performance in NodeJS traîte bien le sujet, bien qu'il soit concentré sur le Cold start. Pour un fonctionnement optimal, il est recommandé de créer plusieurs Functions très spécialisées (et avec un minimum d'overhead), plutôt qu'une seule offrant une API complète.

À vos use cases 😬 !

Credits à @Jeffdelaney23 pour l'exposition de Nest en tant que Function
Credits à Sam pour le pixel-art de Nuage ☁

vec Node.js et dans le navigateur... Et après je parle beaucoup de WebAssembly 😁.

🦕 Deno ne sera pas abordé dans l'article, mais la version 0.24 supporte désormais l'import des modules WebAssembly.

D'abord, un peu de Rust​

Pour changer des exemples sayHello(name) et add(a, b), on va écrire en Rust une petite lib simpliste qui compte le nombre de jours calendaires séparant deux dates. Par exemple :

• 365 jours entre Noël 2018 et Noël 2019,
• 0 jour entre 2019-11-14 et 2019-11-14T16:58:56.822Z
• 29 jours entre 2012-02-01 et 2012-03-01 (année bisextile)

C'est proche de ce que fait moment.js avec sa fonction diff (momentA.diff(momentB, 'days')). Pour simplifier le cas, la fonction développée prendra en paramètres des timestamps en millisecondes.

👮 Chère "Rust Police", ma pratique du langage est toujours très sporadique. Si tu constates une aberration qui t'offusque, n'hésite pas à me DM sur Twitter 🚨.

Allez viens, on se crée une lib 🚀 ! Je fais l'hypothèse que tu as déjà utilisé Rust et Cargo.

cargo new --lib days-count

Dans src/lib.rs, on se donne la définition suivante :

pub fn count_days_between(timestamp_ms_a: u64, timestamp_ms_b: u64) -> u64 {

On rapporte chaque timestamp au nombre de jours écoulés depuis le 01/01/1970. Par exemple, pour le 10/01/1970 (timestamp : 777600000), on obtient 9 jours écoulés. Il suffit ensuite de retourner la différence des deux.

/// Count the number of calendar days between two dates given as
/// timestamps in milliseconds. Make the assumption that One day is
/// 86_400_000 milliseconds (leap seconds are ignored).
pub fn count_days_between(timestamp_ms_a: u64, timestamp_ms_b: u64) -> u64 {
    let days_count_a = timestamp_ms_a / 1000 / 3600 / 24;
    let days_count_b = timestamp_ms_b / 1000 / 3600 / 24;
    let days_count_between = match days_count_a.checked_sub(days_count_b) {
        Some(difference) => difference,
        None => days_count_b - days_count_a,
    };

    return days_count_between;
}

Et maintenant, du WebAssembly​

Chouette 🦉, on a un code Rust qui fonctionne ! Maintenant, il faut le compiler en WebAssembly. C'est wasm-pack qui s'en charge, en plus de générer aussi le package NPM contenant le binaire .wasm, notre package.json et les fichiers .js permettant le binding Javascript ↔ Rust 🎆. Merci qui ? Merci wasm-bindgen.

# on ajoute la cible permettant de compiler du Rust en WebAssembly
rustup target add wasm32-unknown-unknown
# et on installe wasm-pack
curl https://rustwasm.github.io/wasm-pack/installer/init.sh -sSf | sh

Il faut aussi ajouter une dépendance et une lib à notre fichier Cargo.toml :

# [...]

[dependencies]
wasm-bindgen = "0.2"

[lib]
crate-type = ["cdylib"]

Et enfin, ajouter la macro wasm_bindgen à notre fonction :

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn count_days_between(timestamp_ms_a: u64, timestamp_ms_b: u64) -> u64 {

Dans Node.js​

On compile ensuite notre lib en exécutant :

wasm-pack build --release --target nodejs

⚙ --release pour la compilation optimisée, --target nodejs pour des bindings adaptés.

La commande génère le module NPM dans un dossier ./pkg que l'on va directement utiliser avec Node.js 10+ 🔥 :

mkdir nodejs && cd nodejs
yarn init -y # ou : npm init -y
yarn add --dev ../pkg # ou : npm i -D ../pkg
touch index.js

Dans le index.js fraîchement créé, on importe le module days-count généré par wasm-pack et on exécute notre fonction count_days_between :

const daysCount = require('days-count');

console.log(
  daysCount.count_days_between(
    // 01/02/2012
    BigInt(1330560000000),
    // 01/03/2012
    BigInt(1328054400000)
  )
); // 29 👍

Accessoirement, wasm-pack a aussi généré les typedefs (*.d.ts) des bindings JavaScript... On profite donc du typage, de l'autocomplétion et même d'une JSDoc tirée des commentaires Rust (///) 🎉.

Dans le Navigateur​

La lecture du paragraphe précédent (Node.js) est fortement recommandée.

On recompile notre lib en changeant la --target :

wasm-pack build --release --target bundler

On crée un projet basé sur la template NPM wasm-app :

mkdir browser && cd browser
npm init wasm-app
yarn add --dev ../pkg # ou : npm i -D ../pkg
yarn && yarn build # ou npm install && npm run build

Dans index.js, on procède de la même manière qu'avec Node.js :

import * as daysCount from 'days-count';

// pour changer du console.log 🤷
document.body.append(
  daysCount.count_days_between(
    // 01/02/2012
    BigInt(1330560000000),
    // 01/03/2012
    BigInt(1328054400000)
  )
);

Un coup de yarn start pour lancer webpack-dev-server et on constate sur http://localhost:8080 que "29" est bien ajouté au corps de la page.

Pour les utilisateurs de Webpack, le plugin wasm-pack-plugin est intéressant : il permet l'automatisation du processus que l'on vient de suivre, en important directement un projet Rust.

Pour les utilisateurs de Parcel, il existe aussi une template NPM dédiée : rust-parcel. Le Cargo.toml emploie par ailleurs deux crates très utiles : console_error_panic_hook, wee_alloc.

Ce qu'il faut retenir​

Ok, on a compilé une lib Rust simplissime en WebAssembly, on en a fait un module, on l'a utilisé avec Node.js et Webpack. C'est cool, mais ça ne règle aucun problème... Ou peut-être que si ?

Les principaux bénéfices à en tirer sont :

• Des gains très significatifs de performances dans l'exécution d'opérations longues et/ou intensives (calcul, compression, multimédia, jeux vidéo...).
• La capacité d'utiliser un autre langage que JavaScript dans Node.js et/ou le navigateur. Notamment Rust, C et C++, pour des binaires Wasm optimisés. Si le poids du binaire ou la performance ne sont pas des critères pour votre projet, on peut aussi imaginer que les features du langage utilisé soient un argument suffisant (TypeScript avec AssemblyScript, Go, etc).

Les opportunités apportées par cette technologie sont très prometteuses (et excitantes, ain't they?). Comme beaucoup l'ont dit avant moi, WebAssembly ne remplacera pas JavaScript. Et si l'on s'en tient au seul aspect de la performance, même en JavaScript, V8 offre des performances souvent suffisantes pour beaucoup d'applications... Sans parler des outils plus simples à utiliser (et/ou mieux intégrés) en JavaScript pour le moment : debugging, code splitting, etc.

Mozilla, Intel, Fastly (créateurs de Lucet) et Red Hat ont créé la Bytecode Alliance, ayant pour but d'étendre l'existence de WebAssembly au-delà des navigateurs. Plus d'infos sur le blog de Mozilla... Et concernant Wasmtime et les WebAssembly Interface Types (WASI), cette vidéo de Lin Clark est incontournable 🔥 (et une version plus longue/développée ici).

Ah, au fait. J'ai créé un projet TypeScript (💝) exploitant un binaire Wasm avec Node.js et Webpack, de la même manière que je l'ai exposé en JavaScript dans cet article.

Bonus - Des ressources qui valent le détour​

• Diablo 1 en JavaScript (React) et WebAssembly : diabloweb
• Compiling a face detector written in C to WebAssembly
• ImageMagick compilé en WebAssembly : magica
• Skia, de Google, compilé en WebAssembly : Zubnix/skia-wasm-port
• Un émulateur de Game Boy, développé en TypeScript et compilé par AssemblyScript : wasmboy
• Qt Framework compatible avec WebAssembly : Qt 5.13+
• WebAssembly for Web Developers (Google I/O ’19) et notamment Squoosh (!!)

Un programme chargé que 4 speakers talentueux ont partagé entre : migration dans le cloud, CI/CD, Intelligence artificielle et Machine Learning, bases de données, IoT, sécurité... Slides disponibles ici.

Pourquoi choisir de créer son infra dans le Cloud ?​

C'est Sébastien Stormacq, Developer Advocate, qui ouvre le bal avec "Réussir sa transformation digitale".

Slides disponibles ici

On retiendra, dans les grandes lignes :

• L'agilité et l'élasticité offertes par le Cloud : disponibilité immédiate des machines, dont le cycle de vie est maîtrisé
• Les nouveaux domaines technologiques mis au service des métiers : AI/ML/Data lake, IoT, ...
• Le choix de l'emplacement des données entreposées, parmi 22 régions, en fonction de la latence et des aspects légaux
• Les certifications de l'infrastructure : PCI DSS, HDS, ...
• Le coût total de l'infrastructure (TCO, Total Cost of Ownership) significativement réduit (locaux, équipements, machines, administrateurs, dépannages, planification...)
• L'autonomie offertes aux équipes (grâce à l'agilité/elasticité du Cloud)
• Le site AWS Training, offrant des formations et certifications pour les services AWS.

Pour l'anecdote, Amadou Merico présente dans "Migrer ses data-centers dans le cloud", l'AWS Snowmobile, un container de 14 mètres tiré par un semi-remorque pouvant contenir jusqu'à 100 PB (100000 TB, damn!), spécialement dédié au transfert de données.

Il a aussi assuré une belle présentation sur les différentes base de données AWS, Comment choisir sa base de données.

Les services exploitant IA et ML​

Les intervenants n'ont évidemment pas présenté les 165 services offerts par AWS, mais parmi ceux utilisant IA et ML, on retiendra :

• AWS Rekognition : Analyse intelligente de photos et de vidéos permettant l'identification de personnes, textes, objets... Ainsi qu'un redoutable outil de reconnaissance faciale.
• AWS Polly : Synthèse vocale intelligente, capable (grâce au Machine learning) de lire un texte en utilisant différentes intonations, en s'adaptant aux prononciations d'une langue spécifique.
• AWS Textract : Extraction de texte depuis des documents scannés, avec la capacité d'identifier des zones spécifiques (champs de formulaire, etc).
• AWS Comprehend : Traitement de langue naturelle permettant de déduire d'un texte les organismes cités, le sentiment général (positif, négatif, neutre...), la langue utilisée, etc.
• AWS Translate : Traduction sans langue intermédiaire (e.g. Français => Japonais directement, plutôt que Français => Anglais, puis Anglais => Japonais) basée sur des modèles de deep learning.
• Amazon Lex : Création d'interfaces de type chatbot (basé sur les mêmes modèles d'apprentissage qu'Alexa).

Et face à Google Cloud ?​

Si la majorité des plateformes Cloud offrent les mêmes services fondamentaux, tels qu'EC2, RDS et S3 (respectivement, dans Google Cloud : Compute Engine, Cloud SQL et Cloud Storage), certains services n'ont pas encore d'égal chez leurs rivaux.

Un comparatif (certes proposé par Google 😁) est disponible ici. Celui-ci n'est pas exhaustif : en effet, nul équivalent à AWS Neptune, BDD orientée Graphe. Pas plus qu'à AWS Timestream, BDD chronologique (oui, on parle de besoins de niches 🤷). En revanche, Google Cloud offre une alternative à tous les services suscités (IA/ML). Et aussi, depuis hier, des instances managées d'Elasticsearch (comme AWS Elasticsearch Service).

Mais l'article n'a pas pour but de comparer les plateformes : cela mériterait un livre entier réédité tous les 6 mois, tant les facteurs à prendre en compte sont nombreux et sujets au changement. Richesse fonctionnelle des services, facilité d'utilisation, qualité des documentations, tarifications, SLA, etc.

En conclusion​

Les présentations étaient d'une grande qualité et méritent le coup d'œil (slides disponibles ici) si vous n'avez pas encore franchi le pas du Cloud, pour le déploiement d'applications comme pour l'utilisation de services : les premières utilisations (en heures, en stockage...) des services AWS sont souvent offertes.

Premaccess organisera aussi un récap' du AWS re:Invent 2019 à Marseille, le 19 décembre.

Alias de commandes​

Ce n'est pas grand chose, car on parle de quelques secondes grattées par-ci par-là. Mais grattées jusqu'à plusieurs dizaines de fois par jour, ça compte comme de la productivité 😏 !

Au quotidien, j'utilise le Z shell aka zsh, avec oh-my-zsh. L'idée n'est pas de vous présenter mon thème ou mon setup (Debian 9 avec i3wm), mais de partager quelques alias très pratiques importés par le plugin git de oh-my-zsh. Il est activé par défaut. Vous pouvez aussi les récupérer directement ici et les intégrer à votre fichier run commands (.bashrc, .zshrc...).

Parmi ceux que j'utilise souvent :

• g : git
• ga : git add (gaa pour git add --all)
• gcb : git checkout -b
• gcm : git checkout master
• gc : git commit
• gcn! : git commit --no-edit --amend
• gd : git diff
• ggpur : git pull --rebase origin <current_branch>
• gfa : git fetch --all --prune
• gpf : git push --force--with-lease (gpf! pour --force)
• grb : git rebase (grba pour --abort, grbc pour --continue, grbi pour -i) 💖
• groh : git reset --hard origin/<current_branch>
• gst : git status

Évidemment, on les mémorise à force de réutilisation.

Au passage, oh-my-zsh a aussi un plugin yarn avec quelques alias tous aussi efficaces :

• y : yarn
• ya : yarn add (yad pour --dev)
• yb : yarn build
• yrm : yarn remove
• yst : yarn start
• yt : yarn test 🔥

Et maintenant, parlons de trucs utiles !

Indexation partielle avec git add -p​

C'est une option présentée dans le mode interactif (-i) de git add (cf. le "Book" 📚 !) qui permet l'indexation (staging) partielle d'un fichier.

Exemple "True story"​

Vous travaillez sur une évolution de votre produit en suivant votre cycle Red/Green/Refacto habituel. Et là, c'est le drame. Vous trouvez un bout de code "legacy" ("oh my god, he said the L word! 😱") que vous savez refacto par cœur.

- 👼 : "Fais d'abord passer ton test. Cette refacto peut attendre."
- 👿 : "C'est quoi ce code ?! Allez nettoie, y en a pour 20 secondes !"

Quoi qu'il arrive, le fichier va subir deux modifications, une pour l'évolution, une pour le refactoring.

Plusieurs options s'offrent à vous, dont :

• Pousser tous les changements dans un seul et même commit (DON'T, les commits atomiques, tout ça...)
• Remiser (git stash) les changements, faire et enregistrer le refactoring dans un commit dédié, reprendre les changements remisés (git stash pop)
• Avoir recours à git add -p pour indéxer et commit seulement le refactoring 🤷

Pour traiter un cas simple, les exemples qui suivent montrent l'ajout d'un test unitaire 🙄.

Via la CLI​

Vous devez faire évoluer le code d'un collègue fan de retrospective testing (ou "j'écris mes tests une fois que je crois avoir fini") et vous constatez qu'un cas d'usage n'a pas été couvert. Vous écrivez le test qui va bien et décidez de l'indexer immédiatement :

$ git add -p
diff --git a/src/input-parsing/input-reporting.service.spec.ts b/src/input-parsing/input-reporting.service.spec.ts
index 10e5cc8..b9cf134 100644
--- a/src/input-parsing/input-reporting.service.spec.ts
+++ b/src/input-parsing/input-reporting.service.spec.ts

Pour chaque fichier modifié, ici src/input-parsing/input-reporting.service.spec.ts, le terminal affiche les changements indexables :

@@ -10,6 +10,11 @@ describe('InputReportingService', () => {
     const separatorRow = `🤸;🏋;🚴;🚣;🏊;`;
     const emptyRow = `;;;;;`;

+    it('writes any new file starting with a "separator"', () => {
+      const result = service.generateSynthesis([]);
+      expect(result.startsWith(separatorRow)).toEqual(true);
+    });
+
     it('adds an empty row after a new entry', () => {
       const result = service.generateSynthesis([]);
       expect(result.startsWith(separatorRow)).toEqual(true);

Voici du bullshit code : totalement factice, à usage purement démonstratif. Et oui Jamy !

Stage this hunk [y,n,q,a,d,e,?]? ?

Différentes options s'offrent à vous pour le traitement de ce "hunk" (morceau) :

• y - Indexer le morceau présenté
• n - Ignorer ce morceau et passer au suivant
• q - Abandonner / quitter ce mode interactif
• a - Indexer ce morceau et tous ceux du fichier courant
• d - Ignorer ce morceau et passer au fichier suivant
• e - Modifier manuellement le morceau courant (pour les ajouts !)

Sur des plus gros hunks, quelques autres options sont disponibles :

• g - Sélectionner un morceau dans le fichier courant
• / - Chercher un morceau en utilisant une Regex
• s - Proposer à nouveau ces options avec un morceau plus petit (découpé en plusieurs morceaux)
• j - Marquer ce morceau comme "indécis" et sélectionner le prochain morceau indécis
• J - Marquer ce morceau comme "indécis" et sélectionner le morceau suivant

Dans le cas d'un fichier ayant été modifié à deux endroits, on peut donc indexer un premier morceau, enregistrer un commit, puis à nouveau indexer le deuxième morceau et enregistrer un autre commit.
Comme argumenté dans le premier article de cette série : un historique plus clair, un versionning plus granulaire et des reviewers plus heureux !

Dans VS Code​

L'éditeur offre une interface très pratique pour l'indexation de hunks :

En ouvrant un fichier depuis l'onglet Source Control, on peut sélectionner des morceaux (changés, ajoutés, ou supprimés) et les indexer, ou les désindexer. Je préfère cette approche visuelle, que je trouve plus efficace pour les besoins les plus communs. C'est d'ailleurs une habitude bien ancrée : j'alterne en permanence entre les terminaux et l'éditeur, en fonction de ce qui me proccure la meilleure vélocité 🚀.

VS Code + Git = 💕​

En ce qui concerne VS Code, il y a quelques "trucs" qu'il faut absolument connaître :

Éditeur​

Vous pouvez définir VS Code comme éditeur pour git.
En effet, après avoir vérifié que code était disponible dans votre PATH, lancez la commande git config --global core.editor "code --wait".
La modification de la configuration Git, les rebasages intéractifs, etc, peuvent ainsi être effectués via VS Code :

Ici, il est question d'être efficace : je préfère me retrouver sur VSCode que sur un éditeur vi-like pour ce genre d'opérations. C'est personnel.

GitLens​

Extension absolument incontournable de VS Code, GitLens offre entre autres :

• L'affichage du git blame (auteur/date de la dernière modification) de la ligne courante

const weekMoment = moment() // VinceOPS, a month ago • feat: a week as a period
  .set("week", weekNumber)
  .set("year", year);

• La comparaison, pour le fichier courant, de ses révisions N et N-1 (puis N-1 et N-2, et ainsi de suite)...

Au quotidien, ce sont ces deux premières fonctionnalités qui me sont les plus utiles.

• Dans un onglet dédié de la side bar :
  • L'historique des commits de la branche courante, avec affichage (diff) de chaque modification
  • La navigation dans les différentes branches du dépôt
  • La liste des différentes remises (stash) du dépôt
  • La recherche de commits par auteur, message, SHA1, fichiers modifiés...
  • Plein de trucs que l'on peut faire plus vite depuis un terminal (créer/supprimer/merge une branche, etc)

L'historique des commits d'une branche est très utile pour de la code review, ou pour se remémorer ses derniers travaux 😁. Consultez la liste exhaustive des fonctionnalités, vous dénicherez peut-être votre pépite.

C'est tout pour ce second article. #teaser Dans le prochain, on parlera de amend, de rebase (avec squash et fixup), ainsi que du reflog.

ntre autres, par nostalgie pour la prog. système et surtout pour son interopérabilité optimisée avec WebAssembly. À ce sujet, j'ai d'abord étudié AssemblyScript (compilation TypeScript vers WebAssembly) mais celui-ci n'est pas une option viable pour le moment ("AssemblyScript differs in that it is new and tries another approach. It's not as mature as Emscripten and Rust [...]").

Dans cet article, je partage quelques éléments notables et mes premières impressions sur Rust et son écosystème, en tant que développeur travaillant avec Node.js et TypeScript depuis plus de 4 ans (bien qu'ayant aussi travaillé avec PHP, C, Java, C# et d'autres).

TL;DR: Si vous connaissez déjà bien Rust, vous n'apprendrez probablement rien dans cet article. Je ne suis moi-même pas encore un expert du sujet.

👮 Disclaimer : Un minimum de connaissances en POO et en allocation mémoire est requis pour certains passages de l'article.

Installation et "Hello World"​

L'installation est très simple :

curl https://sh.rustup.rs -sSf | sh
# Pour une mise à jour : `rustup update`

Vous disposez ensuite de Cargo, le gestionnaire de paquets officiel du langage (cargo <update | search | ...>).
Il permet aussi de :

• Créer un projet : cargo new
• Compiler le projet : cargo build
• Générer la documentation du projet : cargo doc
• Lancer l'exécutable du projet : cargo run
• Lancer les tests : cargo test
• Linter le code : cargo clippy (clippy)
• Formatter le code cargo fmt (rustfmt)
• etc, etc

On crée un nouveau projet :

cargo new my_project

Le projet ainsi généré contient : un dépôt git et son .gitignore, Cargo.toml (équivalent au package.json), Cargo.lock (équivalent au package-lock.json / yarn.lock), ainsi qu'un premier Hello World dans src/main.rs.

Et c'est déjà prêt ! L'installation est simplissime et fournit un outil standard effectuant toutes les tâches usuelles du développement : 🎉. Quant au Hello world, on le compile et l'exécute avec cargo run :

// src/main.rs
fn main() {
    println!("Hello world");
}

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.06s
     Running `target/debug/my_project`
Hello world

Remarques et impressions​

Documentations​

La documentation du langage ("The Book") est très bien construite, avec un niveau de détails parfaitement jaugé. On peut y accéder, même hors-ligne, en exécutant la commande rustup doc --book.

J'en profite pour citer l'excellent Rust by Example et les Rust API Guidelines, sans oublier The Rust Reference.

Intégration avec VS Code​

L'équipe en charge du Rust Language Server (comparable au TSserver) a développé un client VS Code : le plugin officiel Rust. Il apporte une intégration complète, quoiqu'encore un peu lente : coloration, autocompletion, documentation, lint, etc.

Ces plugins, bien qu'optionnels, peuvent s'avérer utiles :

• Better TOML pour un meilleur support des fichiers TOML (Cargo.toml).
• crates, qui fournit une interface pour la gestion des versions des crates dans Cargo.toml.

Cargo et les Crates​

Les packages, en Rust, sont composés d'un à plusieurs crates (bibliothèque ou exécutable). Le registre officiel, crates.io en contient à ce jour plus de 29 000, dont certains fournis par l'équipe officielle, comme rand, time et beaucoup d'autres.

Pour ajouter une dépendance au projet, on insère (manuellement) son nom et sa version aux [dependencies] de Cargo.toml :

[dependencies]
rand = "0.7.0"

Chaque paquet est ensuite installé en exécutant cargo build, qui met aussi à jour Cargo.lock.

Quelques éléments notables du langage​

Comme annoncé en introduction, Rust est fortement et statiquement typé. Il offre une inférence (déduction) de typage très efficace. Les trois axes mis en avant par ses créateurs sont la Performance (rapide, gestion de la mémoire efficace, absence de garbage collector...), la Fiabilité (système de typage, utilisation de la mémoire...) et la Productivité (excellente documentation, compilateur très expressif, outils optimaux...).

Immutabilité​

Les variables sont immutables par défaut. On utilise le mot clé mut si l'on souhaite déclarer une variable mutable. La convention de nommage est le snake_case 🐍.

// type "i32" déduit pour les deux variables
let immutable_x = 3 + 5;
let mut mutable_x = 3 + 5;

immutable_x = 5; // err. "Cannot assign twice to immutable variable
mutable_x = 7; // OK

Le compilateur​

Deux mots sur le compilateur, rustc :

• Il repose sur LLVM pour la génération du code machine
• L'expressivité des messages d'erreur est excellente.

Exemple ici (messages copiés en commentaire), lorsqu'on tente de ré-affecter une variable non mutable

fn main() {
    let x = 5; // ❌ error[E0384]: cannot assign twice to immutable variable `x`
     // -
     // |
     // first assignment to `x`
     // help: make this binding mutable: `mut x`

    println!("The value of x is: {}", x);
    x = 6;
    // ^^^^^ cannot assign twice to immutable variable
}

Types et Instances, Méthodes, Visibilité...​

Dans les types du langage, on retrouve les :

• Booléens (bool, 1 octet)
• Entiers signés iX et non signés uX, X étant la taille en bits (8, 16, 32, 64, 128)
• Flottants avec f32 et f64
• Caractères (char 4 octets, support complet d'Unicode ('a', '火', '🔥'))
• Tuples (let tup = ('a', 'b', 'c'), let tup = (5, 4.5))
• Tableaux (à taille fixe; pour des tailles dynamiques, on utilise des vectors, comme en C++)

Pas de null en Rust 🎊, mais une énumération standard Option pouvant contenir une valeur (Some) ou rien (None).

On définit des types personnalisés à l'aide des enum et struct :

enum IpAddressKind {
    V4,
    V6,
}

struct IpAddress {
    kind: IpAddressKind,
    address: String,
}

En effet, pas de classes ni de Programmation orientée Objet, mais d'autres mécanismes remplacent très bien l'héritage, le polymorphisme, etc. Il n'y a d'ailleurs pas de constructeur en Rust : par convention, on définit une fonction associée new responsable de fournir une instance du type défini. C'est par exemple le cas de String::new(), du crate du même nom.
Les fonctions associées ou "Associated functions" sont l'équivalent des méthodes statiques en POO : des fonctions associées à un type, plutôt qu'à une instance. On les exécute avec l'opérateur double colon (::) : <Type>::<method_name>.

L'encapsulation est possible à l'aide du mot clé pub, qui permet de rendre publiques les modules, types, méthodes et fonctions. Par défaut, tout est privé. On peut ajouter des méthodes à un type en définissant une implémentation (impl) :

pub struct Account {
    balance: i64,
}

impl Account {
    pub fn new(amount: i64) -> Account {
        Account { balance: amount }
    }

    pub fn get_balance(&self) -> i64 {
        return self.balance;
    }
}

Le champs balance est privé : il n'est pas accessible par les autres modules constituant le projet.

Pas d'interfaces ni d'héritage, mais Rust supporte également les types génériques ainsi que les Traits.

Ownership​

Cette fonctionnalité de Rust (concept unique !) qui joue un rôle majeur dans sa gestion sûre de la mémoire est basée sur 3 règles simples :

• Chaque valeur stockée en mémoire a une variable désignée comme son "propriétaire"
• Il n'y a qu'un seul propriétaire à la fois
• Quand le scope du propriétaire prend fin, la valeur est supprimée

Lorsqu'une valeur ayant entrainé une allocation mémoire est réassignée ou passée en paramètre, on parle de "move" (transfert de propriété), rendant impossible l'utilisation de la variable initiale :

fn main() {
    let name = String::from("Jean");
    say_hello(name);
    // ❌ error[E0382]: borrow of moved value: `name`
    println!("{}", name);
                // ^ value borrowed here after move
}

fn say_hello(name: String) {
    println!("Hello {}", name);
}

Pour des raisons de performances, Rust ne prend pas l'initiative de faire une copie de cette valeur en mémoire et fait un move. Certaines valeurs sont systématiquement copiées (pass by value), comme les références (et non la valeur qu'elle réfère) et les types scalaires (entiers, caractères...).

On peut passer name par référence (typée &) pour procéder à un emprunt (borrow) :

fn main() {
    let name = String::from("Jean");
    say_hello(&name);
    println!("{}", name);
}

fn say_hello(name: &String) {
    println!("Hello {}", name);
}

L'emprunteur say_hello utilise une référence de name. Lorsque la fin de son scope est atteinte, rien ne se passe : le propriétaire de la valeur n'a jamais changé.
🤔 Que se passe-t-il si l'on essaie de compiler du code modifiant la valeur pour la préfixer avec "Hello" ?

fn main() {
    let s = String::from("Jean");
    prefix_with_hello(&s);
    println!("{}", s);
}

fn prefix_with_hello(name: &String) { // ❌ error[E0596]: cannot borrow `*name` as mutable, as it is behind a `&` reference
                        // ------- help: consider changing this to be a mutable
    name.insert_str(0, "Hello ");
//  ^^^^ `name` is a `&` reference, so the data it refers to cannot be borrowed as mutable
}

Le compilateur explique (littéralement !) que name ne peut pas être emprunté en tant que valeur mutable, car passé par "référence &". Il recommande l'emploi d'une référence mutable, de type &mut String. On applique donc 3 changements : 1- name doit être mutable, 2- passé en tant que "référence &mut", 3- et prefix_with_hello doit accepter le bon type en paramètre :

fn main() {
    let mut s = String::from("Jean");
    prefix_with_hello(&mut s);
    println!("{}", s); // "Hello Jean"
}

fn prefix_with_hello(name: &mut String) {
    name.insert_str(0, "Hello ");
}

En résumé, l'ownership effectue un suivi de chaque partie de code utilisant des valeurs stockées dans le tas (heap), y minimise les duplications, et libère la mémoire occupée par des valeurs inutilisées.

Conclusion​

Encore un article trop long à lire et à écrire, bien qu'il ne contienne même pas 30% de ce que j'aurais voulu y rapporter tellement j'apprécie la découverte de ce langage ! Mais le but est seulement de partager mon enthousiasme avec quelques éléments techniques. Pour les plus curieux, je recommande à nouveau la consultation du Book pour y découvrir, entre autres :

• Les slices
• Le pattern matching, déjà suggéré à la TC39 pour EcmaScript
• Le field init shorthand
• Le testing
• Le threading
• Etc. Lisez tout, en fait 😏.

D'autres articles sur Rust (et donc WebAssembly !) viendront. Soyez prêts !

Credits pour la superbe plage en pixel art 🏖

Commits atomiques​

L'emploi des commits "atomiques" est encore peu courant, alors qu'il constitue la base de tout bon contrôle de version, en tant que concept comme en tant qu'outil, du commit history (avec tout ce qu'il a à offrir) à la code review.

📚 Un commit est dit atomique lorsque :

• Le changement qu'il apporte ne casse pas la cohérence du dépôt (compilation garantie et tests réussis).
• Il concerne une tâche et ne peut être découpé davantage sans enfreindre la règle précédente.
• Son message est précis et explique clairement le périmètre de son opération.

✌ Et les bénéfices sont aussi nombreux qu'évidents.

L'atomicité tend à réduire la taille des commits et à augmenter la fréquence des push : le code est sauvegardé plus régulièrement.

Le périmètre des commits atomiques, en plus d'être clairement défini, est généralement peu fragmenté à travers la codebase : les merge conflicts se raréfient et l'intention des autres développeurs se devine facilement.

L'historique des commits devient très pertinent : chaque entrée décrit précisément une modification; couplé à une convention de commit message, il joue pratiquement le rôle de changelog.

Les revues de code sont plus efficaces, réalisables "commit par commit" : le reviewer peut se concentrer sur chaque modification isolée. Chacune doit aussi être complète : quand c'est approprié, documentation et tests inclus.

Chaque modification apportée à un fichier devient légitime : aucun hors-sujet dans les git blame. Terminés les commits "fix bug" touchant à 9 fichiers dont 150 lignes de code et 7 fonctions ! Naturellement, cela s'accompagne aussi d'une meilleure chasse des régressions (manuelle, ou avec git bisect pour les lords 😁).

... etc!

💡 En pratique, cela se traduit principalement par l'augmentation de la fréquence des commits.

Une nouvelle fonctionnalité ? "feat(dashboard): add the step-by-step tutorial"
Des tests manquants sur une méthode ? "test(fcm): add tests for android payload factory"
Toutes les indentations passées de 2 à 4 espaces (à éviter 😁) ? "style: change indent. from 2 to 4 spaces"

Ces exemples de commits messages sont construits selon la convention suivante : conventional commits.
Ils sont composés :

• d'un type (feat, fix, test...)
• d'un scope optionnel (dashboard, fcm) faisait référence à une partie du code
• d'un message décrivant le changement apporté

Il n'y a aucun mal à faire de très petits commits, pourvu qu'ils respectent les règles citées en introduction. Il est de toute façon plus aisé de regrouper plusieurs commits en un seul, que d'en séparer un en plusieurs.
Dernier point positif : avec un historique clair, le "squash pre-merge" (bouh! 🤮) n'a plus de raison d'être (mais en a-t-il déjà été autrement ? 😁).

Bien qu'il ne permette pas d'éviter cette erreur (mais TypeScript peut aider 😁), l'outil Bugsnag sait (entre autres) remonter automatiquement les erreurs non-gérées de votre application.

Les avantages sont multiples :

• On n'attend pas après les retours utilisateurs pour découvrir qu'une fonctionnalité provoque des runtime errors (#réactivité #blagueDrôle)
• Chaque erreur rapportée peut entraîner le déclenchement d'un Webhook (e.g. créer un issue sur Github, envoyer un message sur Slack...)
• On peut tracer manuellement des cas critiques avec un maximum de metadata, facilitant la reproduction d'un bug ou usage (state, historique des actions Redux, saisies, ID, etc)

Disclaimer :

• Sentry est une excellente alternative à Bugsnag
• Les exemples donnés ci-après nécessitent React 16+ et ses Error Boundaries pour fonctionner.

Après avoir créé un nouveau projet sur Bugsnag (Browser > React), on obtient une clé API permettant d'émettre de nouveaux "événements" (erreur gérée, erreur non-gérée, rapport personnalisé, etc).

Il ne reste qu'à intégrer le client au projet !

yarn add @bugsnag/js @bugsnag/plugin-react
# ou npm install @bugsnag/js @bugsnag/plugin-react

On crée un client bugsnag :

// src/<whatever/bugsnag-client.ts
import bugsnag from '@bugsnag/js';

const bugsnagClient = bugsnag({
  apiKey: BUGSNAG_API_KEY,
  beforeSend: (report) => {
    // les rapports sont ignorés si l'app n'est pas en production
    if (process.env.NODE_ENV !== 'production') {
      report.ignore();
    }

    // le state est ajouté aux données meta du rapport (debugging facilité)
    report.metadata.state = store.getState();
  },
});

export default bugsnagClient;

Deux options sont utilisées :

• apiKey, la clé API fournie par Bugsnag
• beforeSend, un callback appelé avant chaque émission

On peut ajouter toute sorte de données au rapport remonté, facilitant le travail de debug/analyse.

Les erreurs non-gérées : Error Boundary​

Pour rapporter automatiquement les erreurs non gérées, on crée un component Error Boundary avec le client :

// src/<whatever>/BugsnagBoundary.ts
import React, { ReactNode }  from 'react';
import bugsnagReact from '@bugsnag/plugin-react';

import bugsnagClient from './bugsnag-client.ts';

bugsnagClient.use(bugsnagReact, React);

const BugsnagBoundary: FunctionComponent<{ FallbackComponent?: ReactNode }> = bugsnagClient.getPlugin('react');

export default BugsnagBoundary;

BugsnagBoundary est directement utilisable pour envelopper notre component de plus haut niveau :

<BugsnagBoundary>
  <App/>
</BugsnagBoundary>

Cependant, cette solution présente deux défauts :

• Aucun contenu n'est affiché à l'utilisateur si c'est l'étape de rendu (rendering) qui provoque une erreur. Bien que ladite erreur soit remontée à Bugsnag. Un component de remplacement peut être affiché, cas échéant, en le passant à la prop FallbackComponent.
• Les erreurs provoquées lors des phases de conception ne sont plus remontées visuellement par les outils de développement (react-error-overlay, react-hot-loader, etc).

On peut wrapper BugsnagBoundary dans un nouveau composant pour y remédier :

// src/<whatever>/ErrorBoundary.ts
import React, { FunctionComponent } from 'react';

const BugsnagBoundary: FunctionComponent<{ FallbackComponent?: ReactNode }> = bugsnagClient.getPlugin('react');

const ErrorBoundary: FunctionComponent = ({ children }) => {
  if (process.env.NODE_ENV === 'production') {
    return <BugsnagBoundary FallbackComponent={FallbackComponent}>{children}</BugsnagBoundary>;
  }

  return children;
};

export default ErrorBoundary;

BugsnagBoundary n'est rendu qu'en production et affiche FallbackComponent si children ne peut pas l'être. Autrement, seul children est rendu et l'arbre des components reste inchangé.

FallbackComponent reçoit les props suivantes :

type FallbackComponentProps = {
  error: Error;
  info: { componentStack: string };
};

On wrap ensuite notre <App/> avec ErrorBoundary.

Les erreurs gérées : notify​

Les erreurs gérées (et les rapports personnalisés) peuvent être émis avec notify :

// dans un processus critique (en cas d'erreur), ou dans un flux sensible :
bugsnagClient.notify('Unexpected error during Sign Up', {
  metaData: { validation: { errors, signUpForm } },
  severity: 'info',
});

Ici aussi, on ajoute un maximum d'informations facilitant la compréhension du contexte (en prenant garde de ne jamais aller à l'encontre de la RGPD 😬).

Suivi 🧐​

Depuis l'inbox (dans le dashboard), on peut suivre en temps quasi-réel les rapports, leur fréquence, la date de dernière occurrence, les assigner à un développeur, les marquer comme Fixed, etc.

Dans le détail de chaque rapport, on trouve, en plus des Breadcrumbs : la stacktrace, un extrait du code ayant provoqué l'erreur (ou émis le rapport), les données meta rapportées, des données sur l'appareil de l'utilisateur, etc.

📜 Les source maps doivent être hébergées sur Bugsnag, pour permettre le bon usage de cette fonctionnalité (sinon, c'est la portion de code minifiée/transpilée qui est affichée).

Enjoy coding!

Merci à mon très inspirant collègue (et super lead frontend dev 💓) @Timur, pour son indéfectible soutien 🔥.

Un exemple très commun en TypeScript est celui des tableaux, avec Array<T>. T est appelé "paramètres de type" (type parameter, à ne pas confondre avec un type de paramètre 🙃).

const items: Array<number> = [1, 2, 3];
items.push(4); // ok
items.push('a'); // erreur: argument of type 'a' is not assignable to parameter of type 'number'

// "n" est déduit comme étant de type 'number'
const results = items.map(n => n.toFixed(1)); // ["1.0", "2.0", "3.0", "4.0"]

Les mêmes méthodes (push, map, etc) et la même analyse statique existent avec Array<string>, Array<Date>, etc. Array est dit "type générique".

Show time 🎉​

Certains exemples sont volontairement simplistes, l'objectif étant de lever toute ambiguïté en se concentrant sur les sujets de la généricité et du typage 🤗

Grâce aux generics, il est possible de :

🌟 Déclarer des contraintes génériques

On définit une fonction générique pick type-safe permettant de récupérer un extrait d'objet, ici, à l'aide de K extends keyof T, dit "K contraint par T".

function pick<T, K extends keyof T>(source: T, ...keys: K[]): Partial<T> {
  const result: Partial<T> = {};
  keys.forEach(key => result[key] = source[key]);
  return result;
}

const user = { weight: 55, name: 'Winry', birthDate: new Date('1985-06-13') };
console.log(pick(user, 'name', 'weight')); // { name: 'Winry', weight: 55 }

Bien sûr, tout est analysé/déduit par le compilateur tsc et l'IDE sait aussi faire l'auto-complétion des propriétés saisies (name et weight) 🔥.

🌟 Obtenir les propriétés d'un certain type d'une classe ou interface

En utilisant les types conditionnels (conditional types), qui prennent la forme d'une expression ternaire utilisant extends :

type StringProperty<T> = { [P in keyof T]: T[P] extends string ? P : never }[keyof T];

class User {
  birthDate: Date;
  isAdmin: boolean
  firstName: string;
  lastName: string;
}
type S1 = StringProperty<User> // 'firstName' | 'lastName'

On peut rendre ce type générique ... encore plus générique !

// toutes les propriétés de type "A" du type "T"
type PropertyOfType<T, A> = { [P in keyof T]: T[P] extends A ? P : never }[keyof T];

// décliné en :
type StringProperty<T> = PropertyOfType<T, string>;
type NumberProperty<T> = PropertyOfType<T, number>;
type MethodProperty<T> = PropertyOfType<T, (...args: any[]) => any>;
// ...

 
🌟 Définir des types élaborés (mapped types)

Rendus possibles grâce à la généricité, vous connaissez la plupart d'entre eux si vous utilisez TypeScript régulièrement :

• Partial<T> : Type ayant toutes les propriétés de T, optionnelles (modificateur ?).
• Required<T> : Type ayant toutes les propriétés de T, requises (modificateur -?).
• Readonly<T> : Type ayant toutes les propriétés de T, non ré-assignables (modificateur readonly).
• Pick<T, K extends keyof T> : Type ayant toutes les propriétés K de T.

Quelques autres qui, bien qu'absents des lib.*.d.ts, sont très communément utilisés dans les projets TypeScript:

// Type ayant toutes les propriétés de T, pouvant aussi être `null` 
type Nullable<T> = { [P in keyof T]: T[P] | null };

// Type ayant toutes les propriétés de T, sans modificateur `readonly`
type Writable<T> = { -readonly [P in keyof T]: T[P] };

// Type ayant toutes les propriétés de T sauf celles données pour K
// e.g.: Omit<User, 'firstName' | 'lastName'> 
type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>;

// `Partial<T>` supportant plusieurs niveaux de profondeur (sous-objets, sous-sous-objets, etc)
type DeepPartial<T> = {
    [P in keyof T]?: T[P] extends Array<infer U>
    ? Array<DeepPartial<U>>
    : DeepPartial<T[P]>
};

🌟 Introduire des variables de Type à déduire (infer)

L'introduction des types conditionnels (TypeScript 2.8), avec le mot-clé extends, a aussi introduit le mot-clé infer, qui permet de déclarer une variable de type déduit.
DeepPartial<T> en montre un premier exemple ci-dessus, en transformant les Array<U> en Array<DeepPartial<U>> (souhaité) et non en DeepPartial<Array<U>> (insensé).

Autres exemples :

// Type de retour d'une fonction T, introduit comme "R"
type ReturnType<T> = T extends (...args: any[]) => infer R ? R : any;

// Type déduit "U" d'une Promise, d'un Array, d'une fonction, ou T
type Unpacked<T> =
    T extends (infer U)[] ? U :
    T extends (...args: any[]) => infer U ? U :
    T extends Promise<infer U> ? U :
    T;
type U1 = Unpacked<number[]>; // number
type U2 = Unpacked<Promise<string>>; // string
type U3 = Unpacked<Unpacked<Promise<string[]>>>; // string
type U4 = Unpacked<Date>; // Date


// Type (tuple) contenant les types des paramètres d'une fonction
type Parameters<T extends (...args: any[]) => any> = T extends (...args: infer P) => any ? P : never;
// type T1 = Parameters<typeof Math.min> // [number[]]

// Type (tuple) contenant les types des paramètres d'un constructeur
type ConstructorParameters<T extends new (...args: any[]) => any> = T extends new (...args: infer P) => any ? P : never;
// type T2 = ConstructorParameters<typeof Account>

 
🌟 Utiliser un "paramètre du reste" générique

Dans cet exemple, avec ...T[].
On définit un type ColorFilter attendant soit : une et une seule valeur de type Color, ou un opérateur 'AND' ou 'OR' suivi d'au moins deux valeurs de type Color.

type FilterAndOr<T, K = 'AND' | 'OR'> = [T] | [K, T, T, ...T[]];
type Color = 'red' | 'green' | 'blue' | 'yellow' | 'white';

// Permet l'utilisation des valeurs:
// ["blue"]
// ["AND", "blue", "red"]
// ["OR", "yellow", "green", "red"]
// ["AND", "blue", "white", "red", "green"]
type ColorFilter = FilterAndOr<Color>;

 
🌟 Etc, etc, etc

Il existe une infinité de cas d'usage des Generics et il m'est impossible d'en faire une liste exhaustive, cependant, comme tout bon outil, attention à ne pas tomber dans le piège habituel : quand on a un marteau, tout ressemble à un clou 😁.

Pour toujours plus de TypeScript 💕, je vous invite à regarder cette vidéo d'Anders Hejlsberg à la DotJS 2018 à Paris. Enjoy!

Notre application (API REST) est développée avec Nest; Jest sert de framework et lanceur de tests (unitaires, d'intégration, E2E), supertest est utilisé pour exécuter des assertions HTTP.

Suite à un appel HTTP, on souhaite vérifier la mise à jour d'un document dans une base de données Elasticsearch, sachant que l'exécution de celle-ci est asynchrone : c'est un effet de bord. Le client reçoit une réponse avant que la mise à jour ne soit effective.

🕺 Les exemples de code ci-après sont volontairement restreints à une forme simple et concise, facilitant leur lecture et leur compréhension

Test first​

Une première approche naïve (et invalide 🤷) consiste à faire une assertion immédiate, considérant qu'Elasticsearch a déjà été mis à jour :

it('should update the value in Elasticsearch', async () => {
  // appel HTTP
  await request(server)
    .put(endpointURL) // PUT @ "/users/:userId"
    .send(input) // { firstName: 'Mike' }
    .expect(HttpStatus.NO_CONTENT);

  // récupération de la donnée & assertion
  const { document } = await elasticsearchService.get(UserIndex, userId);
  return expect(document.firstName).toBe(updatedUser.firstName);
});

La majorité des exécutions de ce test se soldera par un échec puisque la réponse HTTP arrivera avant qu'Elastic n'ait reçu l'ordre de (ou n'ait pu) se mettre à jour. Cependant, l'essentiel y est. Il ne reste qu'à attendre le succès de notre assertion en la ré-exécutant jusqu'à ce qu'elle passe, ou que le test expire (timeout).

Si le scénario n'est toujours pas clair, voici une ébauche du contrôleur gérant cette route de mise à jour :

Contrôleur​

@Put('/users/:userId')
async updateUser(
  @Param('userId') userId: string,
  @Body(ValidationPipe) user: UserInputDto,
) {
  await this.usersService.update(userId, user);
  this.elasticsearchService.update(UserIndex, { userId, ...user });
}

Contrairement à l'exécution de usersService.update, le contrôleur n'attend pas celle de elasticsearchService.update : il envoie immédiatement une réponse.

⚠ Dans une application réelle, le déclenchement de la synchronisation d'Elasticsearch devrait être effectuée dans/par usersService, avec (par exemple) un gestionnaire d'événements. Pas dans le code du contrôleur 😏.

On souhaite donc écrire un flux consistant à :

1. À intervalle fixe,

• (Ré-)Exécuter l'assertion,
• Ignorer l'erreur lancée s'il y en a une (échec de l'assertion), sauf runtime errors relevant d'un problème de code (TypeError, ReferenceError)
• "Compléter" si une valeur est émise 🎉, ou timeout si le temps imparti est écoulé 😿

⏲ Dans Jest, le délai d'expiration d'un test est de 5 secondes par défaut. Il est possible de le modifier en utilisant jest.setTimeout.

Implémentation​

Le test est modifié pour confier l'exécution de l'assertion à une fonction waitForAssertion, responsable dudit flux :

it('should asynchronously update the value in Elasticsearch', async () => {
  await request(server)
    .put(endpointURL)
    .send(input)
    .expect(HttpStatus.NO_CONTENT);

  await waitForAssertion(async () => {
    const { document } = await elasticsearchService.get(UserIndex, userId);
    return expect(document.firstName).toBe(updatedUser.firstName);
  });
});

Et le code de waitForAssertion, écrit avec RxJS (qui fait partie des dépendances de Nest) : Il existe bien sûr d'autres moyens d'atteindre le même objectif, avec ou sans RxJs.

import { from, interval, throwError } from 'rxjs';
import { catchError, first, switchMap, timeout } from 'rxjs/operators';

/**
 * (Doc. et tests disponibles dans le Gist en fin d'article 📚)
 */
export function waitForAssertion(
  assertion: () => any,
  timeoutDelay: number = 1000,
  intervalDelay: number = 100
) {
  // 1. À intervalle fixe,
  return interval(intervalDelay)
    .pipe(
      // 2. (Ré-)Exécuter l'assertion,
      switchMap(() => from(Promise.resolve(assertion()))),
      // 3. Ignorer l'erreur lancée s'il y en a une (échec de l'assertion), sauf runtime errors relevant d'un problème de code
      catchError((err, o) => (err instanceof ReferenceError || err instanceof TypeError ? throwError(err) : o)),
      // 4.1. "Compléter" si une valeur est émise 🎉,
      first(),
      // 4.2. ou timeout si le temps imparti est écoulé 😿
      timeout(timeoutDelay),
    )
    .toPromise();
}

Code documenté et testé de waitForAssertion : Gist.

L'article n'a pas pour vocation de faire l'inventaire desdits cas mais de présenter le concept avec des exemples pratiques, transposables à tout type d'applications.

Configuration​

La résolution des modules JSON est activée par l'option de compilation resolveJsonModule et permet aux développeurs d'écrire du code exploitant la structure (déduite) du JSON importé.

Les exemples ci-après utilisent un fichier tsconfig.json contenant notamment les valeurs suivantes :

"compilerOptions": {
  "module": "commonjs",
  "esModuleInterop": true,
  "resolveJsonModule": true, // 💟
  "strict": true",
  // ...
}

Cas pratiques​

Fichier de configuration​

Il est commun d'utiliser un fichier de configuration dans les scripts et applications JS/TS. Dans l'exemple suivant (totalement fictif et scabreux, mais tout aussi démonstratif), un script est responsable de vérifier le bon fonctionnement (health check) de services d'envoi de SMS.

sms-settings.json

{
  "providers": {
    "twilio": {
      "apiKey": "1b3b5543-e4c5",
      "expectedMessage": "Hello from Twilio",
      "expectedStatus": 200
    },
    "messagebird": {
      "apiKey": "b78ab91a-4fe5",
      "expectedMessage": "Hi from Messagebird",
      "expectedStatus": "200"
    }
  }
}

Notez la valeur "200" typée comme une chaîne de caractères dans messagebird.expectedStatus (⚠ Spoiler alert : on veut provoquer une erreur de compilation 😁).

Ces configurations sont importées et utilisées par le script suivant :

/* script.ts */
import settings from './sms-settings.json';
// [...]

const providers = settings.providers;

for (const provider of Object.entries(providers)) {
  checkSmsProviderStatus(provider[0], provider[1]);
}

/* sms-check.ts */
interface ISmsProviderConfiguration {
  apiKey: string;
  expectedMessage: string;
  expectedStatus: number;
}

function checkSmsProviderStatus(
  providerName: string, 
  config: ISmsProviderConfiguration
) {
  // [...]
}