SnowCamp 2023

**Format** : Talk

**Category** : Frontend

## Qui est l'audience ?

Cette présentation s'adresse aux développeurs frontend avec une première expérience conséquente sur le framework Angular (c'est-à-dire un niveau intermédiaire - 2 ou 3 années d'expérience sur Angular).

L'objectif sera de motiver les développeurs présents lors de la présentation à investir du temps pour monter en compétences sur RxJS, en présentant les avantages que peut représenter l'utilisation de la programmation réactive pour leurs projets et leur carrière.

## De quoi allez vous parler ?

La présentation sera focalisée sur l'utilisation concrète de RxJS au sein d'un projet Angular, au travers de 3 cas d'implémentation courants.
Pour chaque implémentation, nous présenterons un comparatif avec et sans la réactivité.

Voici une version globale de ce que nous présenterons :

### Introduction : Avez-vous le problème que résout RxJS ?

Pour beaucoup de développeurs juniors, RxJS est une technologie étrange, imposée par les créateurs d'Angular dans le framework.

Mais plutôt que de subir cette décision de la Team Angular, il faut rappeler que RxJS permet de faire bien plus que des requêtes HTTP.

L'objectif sera donc de se mettre d'accord sur le problème que RxJS résout : la complexité dans la base de code.

Nous commencerons donc par définir la complexité comme la somme de 3 composantes :

- Un état partagé et mutable. (Shared Mutable State)
- La circulation des données. (Data Flow)
- Le volume de code. (Code Volume)

Nous verrons comment RxJS permet d'adresser efficacement ces 3 composantes de la complexité.

### Partie 1 : 100 opérateurs RxJS en 10 minutes

Un des obstacles principal à l'apprentissage de RxJS est le nombre impressionnant d'opérateurs mis à disposition par la librarie (_plus de 100 !_)

L'objectif sera donc de rendre l'utilisation de ces opérateurs aussi digeste et intuitive que les méthodes utilisées pour le traitement d'un tableau : `map`, `filter` et `reduce`.

Nous verrons que les +100 opérateurs de RxJS peuvent être classés en 4 catégories simples :

- **Création** : _of, fromEvent, interval, timer, combineLatest, forkJoin..._
- **Transformation** : _map, switchMap, mergeMap, concatMap, bufferCount..._
- **Filtrage** : _debounce, throttle, filter, distinctUntilChanged..._
- **Calcul** : _reduce, scan, count, max..._

Pour chacune des catégories, nous verrons qu'il existe plusieurs opérateurs, car RxJS s'occupe de gèrer la dimension du temps en plus d'un simple tableau.

Cette dimension supplémentaire à l'air d'ajouter de la complexité a priori.
Mais cela permet de gérer l'asynchronicité dans notre code, de manière élégante et déclarative.

### Partie 2 : Résoudre des problèmes de la "vraie" vie avec RxJS

Les exemples donnés dans les tutoriels ont toujours l'air d'un monde "enchanteur", que les développeurs n'arrivent pas à appliquer concrètement dans la vraie vie par la suite...

Nous effectuerons 3 ateliers qui seront tous liés à un même _requirement_ d'un client fictif, dans Jira. Nous traverserons 3 couches logicielles du même _requirement_, mais en appliquant la programmation réactive à chaque fois :

**Couche de présentation** (Presentational Layer)

Exemple de gestion réactive de la vue dans le cadre d'un formulaire :
_combineLatest, fromEvent, debounce..._

**Gestion de l'état** (State Management)

Exemple de gestion réactive de l'état impacté par le formulaire précédent:
_BehaviorSubject, scan, next(), seletcors & async..._

**Couche d'accès aux données** (Data Layer)

Exemple de gestion réactive de l'accès aux données depuis un serveur distant :
_Requêtes HTTP & caching (HttpClientModule, catchError, timeout, map & shareReplay), Stratégies de mapping asynchrone (concatMap/mergeMap/switchMap/exhaustMap)_

### Partie 3 : Comment convaincre Mr. Promise et Mr. Fetch API d'utiliser RxJS ?

Une fois que l'on a découvert une nouvelle technologie et que l'on est capable de l'utiliser, il reste le plus dur...
Convaincre ses collègues de changer leurs habitudes pour travailler d'une nouvelle façon.

L'objectif de cette troisième partie sera donc de convaincre le reste de son équipe de se mettre à la réactivité.

Nous présenterons un framework simple qui permet d'expliquer rapidement aux autres membres de son équipe comment utiliser RxJS au quotidien.
Nous avons appelé ce framework : **"Golden River, Muddy River & Golden Road"**.

1. **Golden River** : Quel est le flux idéal que l'on veut obtenir en sortie ? Celui qui contient directement la réponse attendue ?
2. **Muddy River** : Quels flux nous avons déjà à notre disposition ? (_Cf Partie 1: Opérateurs de création_)
3. **Golden Road** : Quels opérateurs appliquer pour atteindre la Golden River à partir de la Muddy River ? (_Cf Partie 2: Opérateurs de transformation, filtrage et calcul_)

### Ouverture, Questions & Réponses

Ouverture : Rappelez que la programmation réactive avec RxJS est un paradigme de programmation qui peut-être utilisé en dehors d'Angular. (Notamment dans les autres frameworks frontend React & VueJS)

Question & Réponses : Répondre aux objections éventuelles et autres questions ouvertes.

## Comment aller vous en parler ?

Le déroulement de la présentation sera un talk plutôt classique, composé principalement de slides et de questions au public tout au long de la présentation.

1. Slides épurés et imagés pour se concentrer sur les explications de l'orateur.
2. Capitaliser sur la création de contenu "online" : c'est un format dans lequel l'attention de l'audience est une ressource rare. Nous essayerons donc de reprendre la même structure de contenu pour ne pas ennuyer l'audience (_présenter une histoire/anectode, donner des exemples concrets, montrer des captures d'écran_).
3. Pas de live coding prévu : pour un premier talk en présentiel devant une audience large, nous trouvons l'exercice déjà suffisamment exigeant.

Est-ce que Firebase vous dit quelque chose ? Vous en avez sûrement entendu parlé et vous l'avez peut-être déjà utilisé, et pour le coup, c'est normal ! Voilà maintenant plusieurs années que de nombreux développeurs l'utilisent pour faciliter la création de back-end scalable et performant.

Mais avez-vous déjà entendu parler d'Appwrite ❓

Peut importe votre réponse, venez découvrir avec nous le duel entre Appwrite la jeune solution open-source et Firebase la flamme de Google 🥊

L'utilisation d'un store au *pattern Flux* est de nos jours choses courantes dans les applications front, ils font même souvent parti de template de création d'un nouveau projet. Néanmoins depuis quelques années, cette domination est remise en question. En effet, elle est souvent accompagnée d'une **complexité** et d'un coup d'entrée sur le code élevé, d'une **maintenance pas évidente** et d'un **boilerplate** important pour ne pas faire grand chose : charger une donnée avec un état de loading, et une gestion de l'erreur.

C'est ici que [TanStack Query](https://tanstack.com/query/v4) intervient, cet outil, cette lib, vous permet de simplement wrapper vos appels réseaux et d'avoir toute la gestion du loading, de l'erreur, de retry, du cache à travers les différents composants, bref de faire tout ce que vous écrivez actuellement dans votre store. TanStack Query vient dans le sillage des hooks, la lib s'utilise donc simplement avec un appel qui vous garantir une maintenance simple, une grande lisibilité et une robustesse à toute épreuve.

Que vous jouiez avec **React**, avec **Vue** (bravo vous êtes les meilleurs), avec **Svelte** ou **Angular** bientôt, cette lib est disponible dès maintenant. Je vous propose de vous la faire découvrir à travers un **live coding** dans lequel on transformera un store en un hook avec TanStack Query, en React et peut être même en Vue si on a le temps.

Avez-vous déjà entendu parler du terme "AI on edge" ? Il s'agit du déploiement d'applications d'IA sur des appareils situés dans le monde physique.
Les avantages ? Moins de latence, plus de sécurité, d'efficacité et surtout de la proximité ! Aujourd'hui, il devient donc de plus en plus important de pouvoir déployer des modèles d'IA capables d'inférer en temps réel.

La vision par ordinateur est particulièrement concernée de par sa progression rapide et son utilisation dans de nombreux domaines : automobile, médical, commerce, ... Elle regroupe de nombreuses techniques comme la classification d'images, la segmentation d'images ou encore la détection d'objets.

Cette dernière permet d'identifier et de localiser les différents objets sur une image ou sur une vidéo. Un célèbre algorithme de détection d'objets, connu pour son fonctionnement rapide, se nomme YOLOv7.

Dans ce talk, nous verrons comment déployer un modèle YOLOv7 pour la détection d'objets sur une carte Raspberry Pi 4.

Pour cela, nous nous intéresserons à l'entraînement et au test d'un modèle YOLOv7 au sein d'un Notebook Jupyter. Nous convertirons ensuite notre modèle pour pouvoir le déployer et faire de l'inférence sur Raspberry Pi.
La finalité ? Un outil de détection d'objets en temps réel à portée de main.

Alors, on embarque ?

Aujourd’hui l’intérêt des chaines de CI/CD n’est plus à démontrer ; elles permettent l’automatisation de nombreuses tâches allant du build d’une application à son déploiement sur des environnements Cloud ou OnPremise gérées par l’entreprise. Mais qu’en est-il lorsque vous déployez / maintenez cette même application chez plusieurs de vos clients et sur des environnements à accès restreint ?

Dans ce retour d’expérience, vous verrez comment nous avons contourné ce problème pour déployer une même application sur plusieurs clusters **Kubernetes** cible sur lesquels nous n'avions pas la main (qu’ils soient OnPremise ou managés) à l’aide de **FluxCD**.

Nous évoquerons les points positifs, négatifs et de vigilance que nous avons pu identifier lors de la mise en place de cet outil dans une démarche **GitOps**.

Les tests d'accessibilités web : on en voit trop peu dans nos chaînes de CI/CD et pourtant, il est possible de faire pas mal de choses ! Les outils et techniques pour automatiser des tests d'accessibilité sont multiples mais relativement méconnus des développeurs web. Que pouvons-nous tester, et comment ? Etudions tout cela ensemble, regardons comment intégrer ces tests dans nos pipelines (Gitlab CI, GitHub Actions, ...).

De l’analytique temps réel pour vos utilisateurs, à la demande, sur des données tout juste intégrées dans le système, à l'échelle . Vous pouvez en voir des exemples lorsque vous regardez votre flux d’activité sur Linkedin ou que vous regardez un dashboard de livraison de votre plat favori.

Pour mettre à disposition de vos utilisateurs ce genre d’analyses temps réels, de nouveaux outils spécialisés émergent comme Apache Pinot.
Cette base de données utilisée par des acteurs comme Linkedin, Stripe et Uber sur des datasets de centaines de TB pourrait bien être la solution que vous attendiez.

Venez découvrir comment mettre en place et utiliser Apache Pinot. Venez mettre de la donnée dans votre vin.

Vous avez déjà eu envie de générer des vidéos ... ?

Vous ne trouvez pas un outil pas cher, facile à prendre en main et pas limiter dans les possibilités ?

Vous avez des bases en HTML, CSS et Javascript ?

**Remotion est fait pour vous !** 🫵🏼

Remotion est une lib open source publiée en 2019, qui permet la génération de gif, d'animations, de vidéos de manière programmatique, à partir de composant React !
Nous allons vous partager notre aventure de création de trailer vidéo dans le contexte des plateformes de streaming sur lesquels nous travaillons chez Bedrock. Nostalgique des programmes du début des années 2000, on a essayé de reproduire quelques bandes d'annonces pour vous rappelez des souvenirs et vous montrer à quel point c'est facile !

Installez-vous et préparez vos pop-corn la séance va commencer ! 🍿

Le code auquel nous sommes pour la plupart confronté.e.s comporte beaucoup d’informations implicites (erreurs, exceptions, nullables, …). Celles-ci se montrent problématiques car elles nécessitent des connaissances poussées de la codebase et génèrent une charge cognitive supplémentaire. Malheureusement, tout ceci augmente la probabilité que les développeur.euse.s fassent des erreurs.
Au cours de ce talk, exemples à l’appui, nous vous montrerons comment rendre plus explicites ces comportements cachés à l’aide de votre système de types. Nous mettrons ensuite en lumière les problématiques qui en découlent et comment les résoudre.

Au cours de ce talk, nous allons présenter :

• les informations qui peuvent exister de façon implicite dans une codebase
• comment rendre ces comportements plus explicites avec des types (Option<>, Result<>, etc)
• highlight des problématiques de composition générés par ces types
• exemple de composition similaire et mieux maîtrisé par les développeur.euse.s : les listes avec les map, flatmap, etc
• Railway programming : transposition de ces concepts sur le Option<> et le Result<>
• bénéfices et inconvénients : quand l’utiliser et quand ne pas l’utiliser (il nous semble important de souligner que ça n’est pas une silver bullet)

Par défaut, nos langages de prédilection sont C# & F#, nous pouvons tout de même envisager d’autres langages pour nos exemples si les organisateurs pensent que cela serait plus adapté à l'audience.

Découvrons ensemble les différentes façons existantes en 2023 pour organiser ses grosses applications frontends et plus particulièrement ses portails d'applications, de façon à éviter leur dépréciation précoce ou leur inmaintenabitilié.
Nous verrons dans un premier temps ce qu'il faut éviter. Puis dans un second temps, à travers des démos de code, nous verrons les structures suivantes :

• L'approche par librairies (npm).
• L'approche par monorepo (avec Nx).
• L'approche micro-frontend.

Pour chacune, nous évoquerons les avantages et inconvénients, ainsi que dans quel cas les utiliser.
Alors parlez ami, et entrez ;)