Structure du talk #7

julien-topcu · 2022-03-01T18:11:33Z

Déroulé du talk

0. Prérequis

Liens de référence:

Étapes de préparation pré-live-coding:

Mettre VSCode en thème "fond clair".
Installer Snippet - Visual Studio Marketplace pour VSCode.

Créer snippet "basic functional test" avec Snippet - Visual Studio Marketplace:

contenu du snippet

// @ts-check

// run with: $ npx mocha test/functional/createPlaylist.functional.tests.js

const assert = require('assert');
const { createPlaylist } = require('../../app/domain/features');

describe('playlist', () => {
  it('should be created by a user without playlist', async () => {
    const playlistName = 'summer mega mix 2022';
    const playlist = await createPlaylist('userWithoutPlaylist', playlistName);
    assert.equal(playlist.id, 0);
    assert.equal(playlist.name, playlistName);
  });

  it('should be created by a user with playlist', async () => {
    const playlistName = 'summer mega mix 2023';
    const playlist = await createPlaylist('userWithPlaylist', playlistName);
    assert.equal(playlist.id, 1);
    assert.equal(playlist.name, playlistName);
  });
});

Préparer l'environnement de live coding, dans le terminal de VSCode:

nvm use 
npm install
git checkout migration-start # ancienne version: migration-start-devoxx-2022
docker compose up -d mongo
. ./env-vars-testing.sh 
export MONGODB_PORT=27117 
npm run test-reset

1. Faire une démo d'OpenWhyd

Adrien

La démo
Décrire le problème : Les contributeurs ont lâché l'affaire car trop fragile et trop difficile à comprendre
Survol de la code base :
- Partir de Application.js
- préciser que: pas de typage
- parler du framework maison => fichier app.route, notamment les api --> subdir --> controllers/api/post.js --> fonction intéressante: insertion d'un morceau de musique. (post Controller sur la méthode insert)

Objectifs:

Permettre à quelqu'un qui n'a pas d'expérience sur la code base d'openWhyd d'être autonome dans la correction de bugs.
Le but étant de maintenir l'existant, on veut améliorer sur place ! On ne veut pas faire une fuite en avant, en créant un module from scratch qui paraitrait plus simple à faire mais qui rajouterait de la complexité de maintenance sur le legacy

Donc => Migration in situ

2. Préparation du terrain opératoire: Biopsies Clean Codiennes

But : Y voir plus claire sur la code base
But caché (intention) : Montrer la fragilité de la code base

Expliquer que l'on vise de migrer l'action insert de controllers/api/post
Exécuter les tests d'intégration pour montrer qu'on en a :

npm run test:integration:post # avant, on lançait le serveur, puis: $ npm run test:integration

Changer dans controllers/api/post, p puis uId uNm de l'objet q dans insert. Et expliquer qu'on est en train de changer la structure en base de données.
~~(redémarrer serveur puis)~~ Réexécuter les tests d'intégration et montrer que les messages d'erreurs ne permettent pas de voir ce qu'on a cassé

3. Ajout des approval tests

git checkout migration-start-with-approval-tests
npm install

Expliquer le principe des Approval tests, théorie + pratique.
Montrer un fichier d'approval de When posting a track
Ouvrir approval.tests.js et expliquer le test correspondant
Lancer le test :

npm run test:approval

Montrer dans les logs que l'on a un diff des approvals.
Supprimer la modification de userName et userId

4. Amener plus de lisibilité dans le code

Lisibilité

Adrien:

Survol de insert jusqu'à process playlist en expliquant le code
Montrer que insert a beaucoup de responsabilité => décider que la partie createPlaylist est déjà un scope suffisant à refactorer

Jordan:

~~Extraction de extractPlaylistRequest~~
Passage du bloc try-catch en pure fonction
postRequest.pl = extractPlaylistRequest(...) et dire que ça pourrait être fait directement à l'initialisation de postQuery.
Remplacer l'initialisation à undefined par extractPlaylistRequest(...)
Extraction needToCreatePlaylist dans le if
Comment rendre la séquentialité de createPlaylist plus explicite ?

Adrien:

Wrapper dans une Promise createPlaylist()
Virer le actualInsert() superflu

Diagnostic

Julien : Mais il fait quoi ce createPlaylist ?
Adrien : Présente userModel.createPlaylist()
Jordan & Julien s'étonnent et commentent du couplage du métier dans la couche de persistence

5. Modéliser le domaine

Créer le répertoire domain
Créer le contrat d'entrée du domaine via l'api. Le domaine doit dépendre que des objets du domaine, mais il n'y pas de typage fort en JS.

Julien : On peut migrer TypeScript ?
Adrien : Trop compliqué mais y'a un autre moyen... Tu veux quoi comme types ?

Création du type CreatePlaylist dans api.ts
Création du type Playlistdans types.ts

Julien : Mais du coup c'est du TypeScript, comment on va raccrocher les wagon sans migrer de langage ?
Adrien : Avec la JSDoc

Refactorer l'appel de la Promise(createPlaylist) pour bien détourer la déclaration de la fonction createPlaylist

const createPlaylist = (userId, playlistName) =>
      new Promise((resolve) =>
        userModel.createPlaylist(userId, playlistName, resolve)
);

Appliquer le type CreatePlaylist via JSDoc puis activer la vérification avec ts-check
Montrer que l'on bénéficie du typage dans vscode via l'autocomplétion sur playlist et les warnings de "compilation" si on fait un playlist.toto
Extract de createPlaylist dans features.js dans le domaine.
Appliquer le ts-check dans features
Lancer les approval tests

6. Extraire la logique métier de la couche de persistence

Remontrer le code de userModel.createPlaylist() pour caractériser le métier qu'on veut migrer.
⚠️ Créer un test fonctionnel (ex: test/functional/playlist.functional.test.js) pour figer les comportements que l'on a compris et expliquer qu'on ne s'appuie pas sur les Approvals, car le domaine est testé en isolation pure.
Appliquer le snippet basic functional test (clic droit + "insert snippet") et expliquer les tests
Supprimer la dépendance userModel dans features.createPlaylist() en la commentant
Résumer le code de userModel.createPlaylist() et écrire un "algo" dans features

  await fetch()
  playlist = {
    id:
    name: 
  }
  await save()
  return playlist

Créer spi.ts
Expliquer que les playlists sont stockées dans les utilisateurs, ce qui nécessite de créer un type UserRepository.
Ajouter une fonction getUserById qui retourne une Promise de User
Définir User dans types.ts
features a maintenant besoin d'une instance de UserRepository. Comme on ne veut pas se coupler avec le repository, on crée une factory createFeatures` pour d'injecter une instance.
Typer le paramètre userRepository de la factory
Appeler userRepository.getUserbyId dans createPlaylist
Retourner dans userModel et expliquer la logique de création d'un id de playlist, la copier-coller dans features et la nettoyer.
Julien à Adrien : est-ce qu'on doit sauvegarder tout le user pour sauvegarder une playlist ?
Définir une fonction insertPlaylist dans la SPI dans le UserRepository
L'appeler dans features
Replugguer dans le test fonctionnel via createFeatures
Expliquer la nécessité de créer un Stub de UserRepository
Créer le stub userRepository et la typer avec la SPI. Générer le squelette au moyen de l'IDE.
Créer une base d'utilisateurs dans le test pour initier le repository en reprenant les ids de user dans les tests fonctionnels
Implémenter les fonctions du Stubs
Enrichir les tests pour vérifier la persistance de la playlist

    //premier test
    assert.deepEqual(users[0].playlists, [playlist]);
   //deuxieme test
    assert.deepEqual(users[1].playlists[1], playlist);

Faire passer les tests ($ npx mocha test/functional/playlist.functional.test.js)

7. Recabler le domaine avec la persistance

Créer un répertoire infrastructure avec UserCollection.js
Typer UserCollection avec la SPI et générer le squelette
Retourner dans le controller et rebinder le domain avec une instance de UserCollection
Exécution des tests approvals pour vérifier que le câblage fonctionne
Implémenter UserCollection.getUserById()
Lancer les approvals montrer que ça casse à cause d'un problème de length sur les playlists. Expliquer la différence de modélisation entre la base et le domaine (playlists vs pl).
Définir UserDocument dans infrastructure/type.ts, typer le retour de la requête mongo dans getUserbyId et tenter de retourner le userDocument.
Créer la fonction de mapping mapToUser et expliquer le rôle de l'anti-corruption layer
Relancer les tests d'approval pour montrer que le problème n'est plus là
Implémenter insertPlaylist
Montrer que les tests d'approval ne fonctionnent toujours pas à cause de l'inconsistance des données en base (prefs, mid...).

Jordan reprend la main du copilote.

Jordan : Où est-ce qu'on fait ça ?
Adrien montre d'où ça vient via le fetch et le save dans userModel
Montrer que la migration de données est faite de manière implicite et n'est pas très robuste (s'il n'y a jamais de save après un save).

Appliquer la migration de données

git cherry-pick migrate-db # --> commit: 96d94f5ee3e5d4488615ca054a45b34c8e742a9a

Si le cherry-pick ne passe pas, vider l'index de git
14. Relancer les approvals

8. Découplage du controller

Commencer par le controller post en expliquant qu'on sort du fichier les instanciations. Commenter les require de features et userCollection
Faire passer features à la stack d'appel de insert jusqu'à Application.js
Ne pas oublier subdir.js en montrant app.route
Déplacer la création des objets dans attachLegacyRoutesFromFile
Relancer les tests d'approval et montrer que ça fonctionne

9. Décommisionnement des Approval tests (optionnel)

git checkout main

Aller dans les tests d'intégration de post et de l'infra mongo

TODO:

Voir comment définir les types en JSDoc de manière globale pour éviter les imports

The text was updated successfully, but these errors were encountered:

julien-topcu · 2022-03-01T18:11:47Z

Point du 10/02/2022

choix / décisions

refactoring in-place: on modifie le code existant
partir du principe que ça fair un bail que les serveurs web ne retournent plus d'HTML => on fix une API qui retourne du JSON (pas de présentation)
focus sur une feature avec use case d'écriture/modification (ex: ajouter un morceau à son profil openwhyd: https://github.com/openwhyd/openwhyd/blob/master/test/integration/post.api.tests.js)

cas typiques qu'on aimerait couvrir

faire émerger le domaine depuis une codebase legacy
couplage métier + technique
code metier entre controlleurs et persitance, à séparer
transitionner progressivement de JS à TS
"poison pill" pl.id == 'create' (https://github.com/openwhyd/openwhyd/blob/master/test/integration/post.api.tests.js#L47) => cas à traiter par adaptateur, pour pas que create soit transmis au domaine
manque d'IOC => introduire Nest ?

TODO

Adrien fournit une cartographie rapide des fichiers principaux à refacto
Adrien fait le ménage dans openwhyd => garder seulement:
- features "post track", "profile" et "playlist"
- tests api + cypress correspondants
Voir comment on insère du TypeScript dans cette codebase JS

julien-topcu · 2022-03-01T18:12:01Z

STRATÉGIE DE MIGRATION:

Mesure / Visualisation du coverage sur la feature à refacto:
- Test E2E (GUI)
- Test d'integration (API / Controller)
Analyse du coverage, pour mettre en évidence les cas fonctionnels non couvert
Analyse des tests de plus haut niveau pour voir si des usecases serait plus explicite à ce niveau là
Remboursement de la couverture fonctionnelle:
- Analyse les usecases couvert par les tests E2E / pour les redescendre potentiellement vers l'intégration
- Exploration fonctionnelle pour re-comprendre, les critères d'acceptance manquant
- Ecrire des tests au niveau intégration (controller)
Inversion de controle entre la persistence et le controller /Rendre explicite le DTO coté base de donnée
- Approval tests (DUMPDB MONGO):
  - https://github.com/approvals/Approvals.NodeJS#approvalsverifyasjson
- Objectif: Controller <- Persistence (Mapping -> créer DTO dédiée (Voir pour l'introduction de typescript pour modeliser les types))
Introduction de la couche domaine:
- Aller plus loin avec l'inversion entre le controller et le domaine
  - Objectif: Controller -> Domaine <- Persistence
- Définition du modele métier / ACL -> Mapping
  - Objectif: Controller(DTO / Mapping(ACL) -> Domaine(Modele dedié) <- Persistence
Constat -> Modele métier actuel est anémique:
- Remonter la logique métier de la persistence vers le domaine
- Pousser la loguque métier du controller vers le domaine
Introduction des tests de critére d'acceptance en isolation (TDD avec l'étape précèdent)
Introduction des tests d'intégration vis a vis de notre persistence

julien-topcu · 2022-03-01T18:12:14Z

Remboursement de la couverture fonctionnelle - Etapes

Execution de test E2E

lancement

docker-compose up -d
open http://localhost:8080

login avec "admin" / "admin"
poster une track en collant une URL (ex: https://file-examples-com.github.io/uploads/2017/11/file_example_MP3_700KB.mp3) dans la barre recherche, puis la retrouver sur son profil openwhyd
ouvrir chrome dev tools
cliquer sur le "edit" de la track, changer le nom, valider
récupérer la requete HTTP emise pour éditer le titre ("copy as node.js fetch")
coller dans test/integration/post.api.tests.js, puis finir d'écrire le test => https://gitlab.com/shodo.io/public/hexagonal-architecture-nodejs-migration/-/commit/08bcc1ac83e37cefc54efe1227e4f2d6e60e5689
execution du test:

dans un premier terminal:

. ./env-vars-testing.sh
export MONGODB_PORT=27117
export MONGODB_DATABASE=openwhyd_test
npm start

dans un second terminal:

. ./env-vars-testing.sh
export MONGODB_PORT=27117
export MONGODB_DATABASE=openwhyd_test
npm run test-reset && npm run test:integration

Next steps / TODO

Jordan & Adrien: fournir une liste de scenarios à écrire sous forme de tests d'intégration API
Julien: implémenter certain de ces tests dans test/integration/post.api.tests.js (cf TODOs dans ce fichier)
Adrien: fournir outil de dump MongoDB pour approval tests, si possible compatible avec https://github.com/approvals/Approvals.NodeJS
Jordan: automatiser la procédure d'execution des tests de test/integration/post.api.tests.js

julien-topcu · 2022-03-01T21:49:33Z

Montrer lors de la conf l'intérêt de faire des tests FIRST !

Repartir du test should re-add a track into a new playlist et montrer que son introduction fait péter une demi-douzaine d'autres tests car ils sont liés entre eux.

JKratus · 2022-03-08T10:22:30Z

Montrer l'évolution de la couverture du code liée aux fonctionnalités autour du concept de post, après le remboursement de la dette (test de controller post)

dans un terminal:

docker-compose up -d mongo # starts mongo on port 27117
source ./env-vars-testing-local.sh
npm run test:integration:legacy-post:cov

puis, dans un terminal séparé:

source ./env-vars-testing-local.sh
npm run test:integration:post:cov

Les 2 commandes produisent un rapport qui peuvent être comparé

JKratus · 2022-03-08T11:28:08Z

Pour s'assurer d'être iso par rapport à la persistence d'un post, lancer les tests avec une approche approval testing basé sur des dumps de la db

$ docker-compose up -d mongo
$ npm run -s test:approval:coverage

(les tests approval lancent le serveur et nettoient la DB programmatiquement)

JKratus · 2022-03-08T11:40:03Z

Pour visualiser directement le coverage dans vscode:

Installer Gutter for vscode: https://marketplace.visualstudio.com/items?itemName=ryanluker.vscode-coverage-gutters
Gutter se base sur le fichier coverage/lcov.info
Les commandes npm run test:integration:post:cov et npm run -s test:approval:coverage supprime le repertoire coverage pour avoir la couverture uniquement de la partie souhaitée.
Un fois un coverage généré, cliqué sur la pastille 'Watch' de vscode

Le coverage s'affiche directement sur les fichiers dans l'IDE

adrienjoly · 2022-03-11T09:26:47Z

11 mars

Rappel de strat

virer le dead code + solidifier calcul de coverage
inverser dependance entre controleur et persistence
faire emerger le domaine

TODO

que faire du src ? (decision que c'est du dead code mais snapshoté dans les tests approval)
ajouter couverture pour img
passer en await l'appel à createPlaylist, pour rendre plus lisibles la séquentialité et le retour de fonction => https://github.com/openwhyd/openwhyd-solo/pull/13/files#diff-db419e2f985ae41f450c2e0c2589debe9b177a41d6fc3c26f23c648adf4e1c5eR114

Modélisation domaine

Jordan nous présente la ré-application de ce qu'on avait montré en live-stream:

en fait, User est un agrégat de Playlists

Elements de story-telling

reproduire rapidement ce qui s'est passé pendant le live => aller dans le mur, conclusion: need tests, moar coverage
ajouter des tests => surprise: découverte de side effects entre tests (violation de FIRST) => besoin de structure sûre pour nos prochains tests
- compute la couverture totale: approval + integration (pas forcément à montrer)
grace au coverage, on se rend compte qu'il y a pas mal de use cases couverts par fonction, et pas mal de lignes non couvertes
- charge cognitive: on collapse les parties du code qui sont pas appelées
- clean code: renommer les params, extraction de fonctions, fonctions pures, pour améliorer lisibilité
- en cas de test échoué, lancer seulement un type de test, sans coverage (pour pas niquer les numéros de ligne)
- => en CI, envoyer la coverage totale de npm run test:post:coverage sur codacy
- montrer que une partie de createPlaylist n'est pas couverte (cf https://app.codacy.com/gh/openwhyd/openwhyd/file/68022651853/coverage?bid=17325385&fileBranchId=17325385) => écriture d'un test integration (à montrer en live)
on choisit de commencer par injecter createPlaylist (sous forme de domaine service) car il est deja relativement bien isolé, mais aussi pour avancer vers le retrait du poison pill pl.id=="create"
- wip: refactor: Inject domain + track coverage on CI #14
soit on va vers typescript, soit on continue d'extraire le domaine.

Topo sur sessions effectuées jusque là

10/02 soir: discussion / propositions / planification => https://gitlab.com/shodo.io/public/hexagonal-architecture-nodejs-migration/-/issues/1
16/02 matin: première tentative de refacto, en stream live sur Twitch
25/02 matin: proposition de stratégie avec remboursement de tests => https://gitlab.com/shodo.io/public/hexagonal-architecture-nodejs-migration/-/issues/1#note_855177045, puis déplacement de gitlab vers github => https://github.com/openwhyd/openwhyd-solo (pour réutilisation des workflows de CI)
28/02 aprem: écriture de tests
7/03 matin: écriture de tests (2)
11/03 matin: séance de refacto en mob, en physique => PR refactor: Clean code + branche refactor: extract domain by adrienjoly · Pull Request #14 · openwhyd/openwhyd-solo
23/03 matin: cf Structure du talk #7 (comment), Jordan et Julien se sont retrouvé au SHODO HQ, Adrien était en distanciel
25/03 matin: Adrien a simplifié l'implem du repository/adapter, cf fix: Simplify implementation of userCollection MongoDB adapter #18 (jour commu au lieu de destaff contenu, suite à l'impossibilité d'aller au Froiminaire)
Mardi 29/03: Julien et Adrien vont passer la journée à construire le déroullement du talk sous forme de commits. (cf Structure du talk #7 (comment))
Jeudi 7/04 aprem: Julien et Adrien vont terminer le déroullé
Vendredi 8/04 journée: répétitions entre nous
Mercredi 13/04: répétition générale au SHODAY
Mercredi 20/04: talk donné à Devoxx

adrienjoly · 2022-03-23T10:32:22Z

Matin du mercredi 23 mars

Julien a présenté les étapes d'extraction du domaine depuis le code de createPlaylist => étranglement progressive du legacy, de gauche (APIs) à droite (mongodb)
On est d'accord pour dire que le scope du talk est cet etranglement du use case "creation de playlist lors d'un post de track"
on va prétendre qu'on a executé une migration de données (cf refactor: Hexagonalify create playlist without stowaway pattern #17 (comment))
- à terme, notre implem de repository pourra appeler directement mongodb
- Adrien: ajouter les champs manquants aux données insérées dans nos tests
- virer le fetchUserById() de UserCollection.insertPlaylist() (cf code commenté)
- virer aussi la dépendance vers models/users en utilisant le driver mongo directement dans getUserById
- puis update les snapshots
prochaine séance à prévoir: 1 journée pour construire le cheminement du live coding sous forme de commits

Cf #7 (comment) and #17 (comment). ## Comment tester ```sh docker-compose up -d mongo npm run test:approval source ./env-vars-testing-local.sh npm run test:integration:post ```

adrienjoly · 2022-03-29T10:55:32Z

Mardi 29 Mars (journée)

objectif de la séance: définir le déroulé du talk => écrire les commits dans une branche, avec annotations de ce qu'on devra dire/présenter le jour J (sous forme de commentaires GitHub dans une PR associée à cette même branche)

Matin

Julien a complété la description de ce ticket pour récapituler les grandes étapes
on a décidé de partir des tests approval => création du tag migration-start-with-approval-tests
pendant la pause dej, Adrien a proposé de compléter ces approval tests pour qu'ils couvrent aussi les réponses de l'API

Aprem

on a complété la branche de déroulé (=> fix: migration #19) jusqu'à l'étape "6. Extraire la logique métier de la couche de persistence"
on a décidé de décaler l'injection de dépendances à la fin, pour réduire la charge cognitive du public pendant la phase d'extraction de logique métier => ça a pris plus de temps que prévu => on pose notre Jeudi après midi de la semaine prochaine pour finir ça avant la journée de répétition du Vendredi 8
il ne reste plus qu'à finir le déroulé (commits) pour les parties "7. Injection de dépendance", "8. Migration de donnée" et "9. Décommisionnement des Approval tests", en sachant que Jordan a proposé d'avancer de son côté sur l'écriture de tests DB pour la partie 9.

adrienjoly · 2022-04-07T12:19:37Z

adrienjoly · 2022-04-09T09:26:10Z

Vendredi 8 Avril

Répétition avec Julien et Jordan

=> branche migration-2022-04-08

adrienjoly · 2022-04-14T07:21:50Z

Jeudi 13 Avril

Répétition pendant SHODAY.

=> branche: https://github.com/openwhyd/openwhyd-solo/tree/migration-2022-04-13-shoday

Anti-sèche

branche git à checkout pour l'ajout des approval tests: migration-start-with-approval-tests
commit de la migration de données: ce3d2f4662b62693675c8866d0c3372fa166e424 (à cherry-pick pendant le talk)

adrienjoly · 2022-04-15T08:15:19Z

Vendredi 15 Avril

Je viens de créer deux snippets avec l'extension Snippet - Visual Studio Marketplace:

TODO

revoir ensemble les slides, savoir qui dit quoi
préparer snippets
créer une cheatsheet du déroullé (sous étapes)

=> branche: migration-2022-04-15

See #559 and openwhyd/openwhyd-solo#7. Co-authored-by: Jordan NOURRY <[email protected]> Co-authored-by: Julien Topçu <[email protected]>

adrienjoly · 2022-05-09T13:54:30Z

Pour référence, voici:

l'enregistrement video du talk à Devoxx dans lequel nous avons effectué la migration: Architecturoplastie hexagonale d’un backend Node.js (Jordan Nourry, Adrien Joly, Julien Topçu) - YouTube
les commits d'intégration de cette migration dans la codebase initiale d'Openwhyd, effectués lors du SHODAY du 2022-05-09:
- fix(tests): Import test environment from openwhyd-solo (PR: #560)
- fix: Migrate playlist creation to Hexagonal Architecture (PR: #563)

See #559 and openwhyd/openwhyd-solo#7. Video recording of the Devoxx talk in which we performed that migration: [Architecturoplastie hexagonale d’un backend Node.js (Jordan Nourry, Adrien Joly, Julien Topçu) - YouTube](https://www.youtube.com/watch?v=r2XMwAUqZBA) Co-authored-by: Jordan NOURRY <[email protected]> Co-authored-by: Julien Topçu <[email protected]>

adrienjoly · 2023-06-16T08:03:03Z

Update suite à la répète de Lundi:

j'ai remplacé le tag migration-start pour qu'il pointe vers l'unique commit de npm run test:integration:post controls execution of web server (like in the main openwhyd codebase) #21 => les tests d'intégration de post api n'ont plus besoin qu'on lance le serveur d'openwhyd
j'ai renommé l'ancien tag migration-start --> migration-start-devoxx-2022, au cas où
j'ai simplifié la procédure de préparation du live coding + les mentions à npm start et kill, en accord avec ce changement

Note: je n'ai pas modifié le tag checkout migration-start-with-approval-tests car il me semble qu'on ne lance plus ces tests d'intégration après la migration. => on aura probablement envie de le faire, si jamais on trouve un moyen simple et fluide d'exécuter les nouveaux tests d'intégration (requêtes db via SPI) après la migration.

adrienjoly · 2023-06-16T14:59:29Z

Notes de 2ème répète:

Julien: ne pas hésiter à sauter les slido, le jour J (à minima: le premier)
Adrien: penser à présenter toute la logique de insert, y compris la partie sur les playlists
Adrien: justifier le choix de focaliser sur createPlaylist par le fait que ça ne dépend de rien d'autre => scope réduit
Julien & Adrien: pour rendre la phase de clean code plus rapide, ne pas extraire la constante playlistRequest (cf diff ci-dessous)
Julien: ne pas hésiter à suivre les notes / process du live coding
Adrien: retrouver rapidement les commandes pour runner les tests, et exploiter l'arbre git (checkout / cherry pick)
Julien / idée pour slide de fin: être un poil plus "pratique" sur ce qu'a apporté nos modifs, concrètement
Interactions: restons sur le vouvoiement; et si jamais on switch sans faire exprès, l'assumer explicitement !
Interactions: Ne pas hésiter à exagérer les réactions et les vannes, pour divertir le public !

diff --git a/app/controllers/api/post.js b/app/controllers/api/post.js
index 3728376..e32f36d 100644
--- a/app/controllers/api/post.js
+++ b/app/controllers/api/post.js
@@ -63,6 +63,7 @@ exports.actions = {
       uId: httpParams.uId,
       uNm: httpParams.uNm,
       text: httpParams.text || '',
+      pl: extractPlaylistRequest(httpParams),
       // fields that will be ignored by rePost():
       name: httpParams.name,
       eId: httpParams.eId,
@@ -105,23 +106,18 @@ exports.actions = {
       }
     }
 
-    const playlistRequest = extractPlaylistRequest(httpParams);
-
-    if (needToCreatePlaylist(playlistRequest)) {
+    if (needToCreatePlaylist(postQuery.pl)) {
       const playlist = await features.createPlaylist(
         httpParams.uId,
-        playlistRequest.name
+        postQuery.pl.name
       );
       if (playlist) {
-        postQuery.pl = { id: playlist.id, name: playlistRequest.name };
+        postQuery.pl.id = playlist.id;
         // console.log('playlist was created', q.pl);
       }
     } else {
-      postQuery.pl = {
-        id: parseInt(playlistRequest.id),
-        name: playlistRequest.name,
-      };
-      if (isNaN(playlistRequest.id)) delete postQuery.pl; //q.pl = null;
+      postQuery.pl.id = parseInt(postQuery.pl.id);
+      if (isNaN(postQuery.pl.id)) delete postQuery.pl; //q.pl = null;
     }
 
     actualInsert();

adrienjoly mentioned this issue Mar 12, 2022

refactor: Inject domain + track coverage on CI #14

Merged

adrienjoly mentioned this issue Mar 25, 2022

fix: Simplify implementation of userCollection MongoDB adapter #18

Merged

adrienjoly mentioned this issue Apr 7, 2022

fix: migration #19

Closed

adrienjoly mentioned this issue May 9, 2022

fix: Import test environment from openwhyd-solo openwhyd/openwhyd#560

Merged

adrienjoly mentioned this issue May 9, 2022

fix: Migrate playlist creation to Hexagonal Architecture openwhyd/openwhyd#563

Merged

adrienjoly mentioned this issue Jun 16, 2023

npm run test:integration:post controls execution of web server (like in the main openwhyd codebase) #21

Draft

adrienjoly assigned adrienjoly and julien-topcu Jun 16, 2023

adrienjoly added the documentation Improvements or additions to documentation label Jun 16, 2023

adrienjoly mentioned this issue Jul 28, 2023

fix numbering of new playlists openwhyd/openwhyd#633

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Structure du talk #7

Structure du talk #7

julien-topcu commented Mar 1, 2022 •

edited by adrienjoly

Loading

julien-topcu commented Mar 1, 2022

julien-topcu commented Mar 1, 2022

julien-topcu commented Mar 1, 2022 •

edited by adrienjoly

Loading

julien-topcu commented Mar 1, 2022

JKratus commented Mar 8, 2022

JKratus commented Mar 8, 2022

JKratus commented Mar 8, 2022 •

edited by adrienjoly

Loading

adrienjoly commented Mar 11, 2022 •

edited

Loading

adrienjoly commented Mar 23, 2022 •

edited

Loading

adrienjoly commented Mar 29, 2022 •

edited

Loading

adrienjoly commented Apr 7, 2022 •

edited

Loading

adrienjoly commented Apr 9, 2022 •

edited

Loading

adrienjoly commented Apr 14, 2022 •

edited

Loading

adrienjoly commented Apr 15, 2022 •

edited

Loading

adrienjoly commented May 9, 2022 •

edited

Loading

adrienjoly commented Jun 16, 2023 •

edited

Loading

adrienjoly commented Jun 16, 2023 •

edited

Loading

Structure du talk #7

Structure du talk #7

Comments

julien-topcu commented Mar 1, 2022 • edited by adrienjoly Loading

Déroulé du talk

0. Prérequis

1. Faire une démo d'OpenWhyd

2. Préparation du terrain opératoire: Biopsies Clean Codiennes

3. Ajout des approval tests

4. Amener plus de lisibilité dans le code

5. Modéliser le domaine

6. Extraire la logique métier de la couche de persistence

7. Recabler le domaine avec la persistance

8. Découplage du controller

9. Décommisionnement des Approval tests (optionnel)

julien-topcu commented Mar 1, 2022

Point du 10/02/2022

choix / décisions

cas typiques qu'on aimerait couvrir

TODO

julien-topcu commented Mar 1, 2022

STRATÉGIE DE MIGRATION:

julien-topcu commented Mar 1, 2022 • edited by adrienjoly Loading

Remboursement de la couverture fonctionnelle - Etapes

Execution de test E2E

Next steps / TODO

julien-topcu commented Mar 1, 2022

JKratus commented Mar 8, 2022

JKratus commented Mar 8, 2022

JKratus commented Mar 8, 2022 • edited by adrienjoly Loading

adrienjoly commented Mar 11, 2022 • edited Loading

11 mars

Rappel de strat

TODO

Modélisation domaine

Elements de story-telling

Topo sur sessions effectuées jusque là

adrienjoly commented Mar 23, 2022 • edited Loading

Matin du mercredi 23 mars

adrienjoly commented Mar 29, 2022 • edited Loading

Mardi 29 Mars (journée)

Matin

Aprem

adrienjoly commented Apr 7, 2022 • edited Loading

Jeudi 7 Avril (aprem, Julien + Adrien)

adrienjoly commented Apr 9, 2022 • edited Loading

Vendredi 8 Avril

adrienjoly commented Apr 14, 2022 • edited Loading

Jeudi 13 Avril

Anti-sèche

adrienjoly commented Apr 15, 2022 • edited Loading

Vendredi 15 Avril

TODO

adrienjoly commented May 9, 2022 • edited Loading

adrienjoly commented Jun 16, 2023 • edited Loading

adrienjoly commented Jun 16, 2023 • edited Loading

julien-topcu commented Mar 1, 2022 •

edited by adrienjoly

Loading

julien-topcu commented Mar 1, 2022 •

edited by adrienjoly

Loading

JKratus commented Mar 8, 2022 •

edited by adrienjoly

Loading

adrienjoly commented Mar 11, 2022 •

edited

Loading

adrienjoly commented Mar 23, 2022 •

edited

Loading

adrienjoly commented Mar 29, 2022 •

edited

Loading

adrienjoly commented Apr 7, 2022 •

edited

Loading

adrienjoly commented Apr 9, 2022 •

edited

Loading

adrienjoly commented Apr 14, 2022 •

edited

Loading

adrienjoly commented Apr 15, 2022 •

edited

Loading

adrienjoly commented May 9, 2022 •

edited

Loading

adrienjoly commented Jun 16, 2023 •

edited

Loading

adrienjoly commented Jun 16, 2023 •

edited

Loading