Recul sur mes missions Flashcards
FDJ : Contexte de la mission
Le contexte est le jeu de loterie : l’application se trouve sur les terminaux que l’on retrouve chez les buralistes. J’ai travaillé sur le projet DPP (Digital PoS Platform).
FDJ : Résultats apportés
Mon apport : Permettre à la FDJ de vendre sa solution à de nouveaux clients que sont les loteries étrangères
FDJ : Equipe Agile sans Tech Lead
J’ai travaillé dans une équipe Agile Scrum. Il n’y avait pas vraiment de Tech Lead, il y avait un tech lead sur le papier mais qui n’avait pas vraiment ce role, la FDJ voulait un TL en interne, mais tous les devs étaient sur le même pied d’égalité, on faisait tous plus ou moins les tâches du TL, on était plutôt Lead sur des sujets qu’on prenait en main de A à Z, on était référent.
FDJ : Refonte de l’application technicien
On a travaillé sur la refonte d’une application technicien pour la remettre au gout du jour, avec des technos plus récentes et un design plus moderne pour inciter les clients à vouloir utiliser la solution.
FDJ : Architecture en microservices
Architecture en microservices avec des microservices packagés et versionnés de façon indépendante. Publication sur un registre npm privé. Release de l’application principale tous le 3 mois contenant les packages des microservices.
FDJ : DevOps
On utilisait la suite Atlassian pour gérer le projet : Jirz Confluence pour le ticketing et la doc mais aussi bitbucket pour les repositories et Bamboo pour la ci cd. On avait un devops dédiés aux tâches devops mais on pouvait aussi être amenés en fonction de nos besoins à adapter le fonctionnnement : on avait des scripts qui permettent de derouler le fonctionnement des jobs de ci : build, test, release, artifiacts, déploiement
FDJ : TSW
DPP est une partie du TSW. Le TSW c’est toutes les briques de l’application qui sont installées dans le terminal : DIP, DLA, DLS, DPP, Front … Ce sont des briques optionnelles, chaque client choisit ce qu’il veut payer comme brique. S’il ne choisit pas une brique, cela veut dire que le client (une loterie étrangère) devra s’occuper de l’implémentation de cette partie lui-même.
FDJ : C’est quoi DPP
C’est une API Node.js qui permet aux clients de simplifier l’accès aux fonctionnalités matérielles du terminal comme l’imprimante, le scanner, l’audio … Et également aux fonctionnalités software comme l’authentification, la configuration système …
FDJ : SSE
On utilise les Server Sent Events pour envoyer des notifications aux clients. Les SSE sont un moyens d’envoyer des messages de façon unidirectionnelle. Les clients s’abonnent aux évènements voulus de leur côté. On les utilisaient pur notifier les clients des évènements matériels. Ensuite les équipes front avec lesquelles on travaillait ont rencontré des problèmes elles devaient ouvrir des canaux pour chaque route et ils étaient limités par la limite de 6canaux ouverts dans le navigateur, on est donc passé aux websockets pour les nouveaux devs.
FDJ : Plugins d’authentification
Certaines fonctionnalités nécessitaient une authentificaiton en amont, et comme nous avions des différents venant de différents pays, chaque client avait un fournisseur d’authentification différent. On a donc mis en place un système spécifique de plugins où de notre côté on a implémenté des fonctions génériques d’authentification comme la création de session, l’execution de fonction en mode connecté, le refresh de token … Le client devait remplir un les paramètres de son serveur d’authentification dans son fichier de configuration et devait développer le plugin qui implémentait l’interface qu’on leur a fourni. Ce qui que nous n’avions pas besoin de stocker le code sensible du client chez nous. Le plugin client était ajouté au build time dans le projet DPP était importé dans le code grâce aux dynamic imports de Javascript.
FDJ : Backend-lib
En plus du backend dpp, toujours dans le but d’être un accélérateur de dev, on a développé un outil qu’on a appelé la backend-lib qui est une librairie front qui permet de faire les appel api au backend sans avoir à faire les requêtes, les paramètres des requêtes sont encapsulées dans notre librairie, le client n’avait plus qu’à appeler les fonctions fournies par la backend-lib pour accéder aux fonctionnalités du terminal. Pour faire ça on a utiliser les typescripts décoratiors.
FDJ : OS du terminal
Avant DPP il n’y avait pas d’API accessible par le client. Le terminal était fourni avec un os linux custom, qui contenait un middleware développé en c++ qui permettait d’interagir avec le matériel. Les clients devaient eux mêmes coder l’utilisation des middlewares dans leur application de loteries pour interagir avec le materiel.
DPP implémente un fork maintenu en interne de la librairie fastcall permettant d’utiliser des librairies c++ dans un serveur node.js. Et une API est fournie pour toutes les interactions nécessaires pour le matériel.
FDJ : Livraisons, releases
On travaillait en Agile Scrum, mais en réalité la vraie chronologie projet était basée sur notre rythme de releases qui était tous les 3 mois pour les versions majeures en plus d’une ou deux versions mineures. Chaque client décide ou non d’intégrer nos releases ou de rester sur une version plus ancienne en fonction de ses besoins en fonctionnalités
RATP - HORUS : Contexte
J’ai travaillé au sein de l’Usine Digitale de la RATP, une factory au sein de laquelle plusieurs projet innovant de la RATP sont développés. Ce sont généralement des projets développés dans un but de livraison de version rapide, en 6 à 12 mois maximum. Et si besoin, lancer le développment d’une V2, d’une V3 etc …
Au sein de l’Usine Digitale, il y a une core team RATP chargée de chapeauter les différents projets, de fournir un cadre commun avec l’architecture devops, un boilerplate d’application commun, qui est amélioré au fur et à mesure des préconisation des persones présente ddans l’Usine Digitale.
RATP - HORUS : C’est quoi Horus ?
Horus est une application de suivi des précurseurs d’incidents. Un précurseur d’incident est tout événement qui peut provoquer un accident grave sur le reseau Ratp. Par exemple une porte mal fermée, des personnes sur les voies, …
RATP - HORUS : Objectif
Je suis arrivé sur le projet en tant que Tech Lead pour travailler sur la refonte de cette application. Mon travail sur ce projet s’est déroulé en 2 étapes.
RATP - HORUS : Cadrage Métier
Une première partie de cadrage sur 6 semaines qui avait pour objectif d’obtenir un MVP à développer.
- Métier : conception, interview
Pour cela, avec le PO et l’UX designer, nous avons beaucoup discuté avec le métier pour comprendre le besoin, pour identifier les point critiques de l’application existante. On a fait des interview utilisateur pour recueillir le ressenti des utilisateurs sur le terrain.
RATP - HORUS - Cadrage - Chiffrage
Ensuite j’ai dû réaliser le chiffrage des fonctionnalités à développer en concertation avec la Core Team RATP. Finalement il s’est avéré que le budget nécessaire était bien plus élevé que le budget alloué pour le projet. Nous avons dû retravailler avec le métier pour trouver des solutions en identifiant les fonctionnalités non vitales pour l’application, trouver des concessions pour simplifier des fonctionnalités et arriver un accord.
RATP - HORUS : Equipe Dév Agile
Ensuite la deuxième partie était bien sûr le développement de l’application. Pour cela j’ai pu récruter une équipe de 3 développeurs, 2 développeurs assez confirmés qui connaissaient déjà le contexte RATP et une développeuse plus junior.
On travaillait sur des sprints de 2 semaines. Ma fonction de Tech Lead impliquait plusieurs taches.
RATP - HORUS : Lead Dev
L’accompagnement de es développeurs avec le Pair Programming, les Code Review, répondre à leurs questions techniques et fonctionnelles
RATP - HORUS : POC
J’ai également travaillé sur la réalisation de POCs pour valider le choix de librairies et l’implémentation de fonctionnalités, en collaboration avec le responsable cyber qui était très regardant. Il testait la sécurité de nos implémentations et de nos librairies, validait les licences des librairies et le score de sécurité sur socket.dev …
RATP - HORUS : Algo 6 mois
Un algorithme de génération de recommandations sur les occurrences des 6 derniers mois pour compléter celui existant qui prend les occurrences des 5 dernières années
RATP - Horus : Inducteurs
L’ajout d’inducteurs : un coefficient à appliquer sur le nombre d’occurrence, pour tempérer le nombre d’occurrence en fonction de facteurs extérieurs comme les grèves …
RATP - HORUS : Texte enrichi
L’implémentation d’un éditeur de texte enrichi permettant de aux opérateurs de remplir leurs rapports mensuels qui étaient auparavant rédigés sur Powerpoint et surtout étaient volatiles, il n’y avait pas un endroit commun pour les collecter