Idée d'un outil de session recoding web minimaliste basé sur rrweb

En mars 2024, je me suis demandé comment utiliser correctement les termes Epic, Issue, User Story, Goal, Job Story, Vision, Pitch, Feature, Task, Bug, Spike, Dette technique, Theme.

Voici quelques réflexions à ce propos.

Tout d'abord, tous les artefacts suivants sont des Issues : Epic, User Story, Job Story, Vision, Pitch, Feature, Bug, Spike, Task.

Ensuite, Feature, Bug, Spike et Dette technique indiquent la finalité de l'issue, définissant la nature du travail à réaliser.

User Story et Job Story sont des méthodes de formulation d'issues.

J'ai mis beaucoup de temps à réaliser que les termes Epic, Vision, Theme, Pitch, Goal et Task permettent d'indiquer le niveau d'imprécision d'un objectif.

Exemple allant du flou très prononcé à une version faiblement floue :

• Vision – Le niveau le plus large et abstrait, décrivant une aspiration à long terme.
• Theme – Une direction stratégique regroupant plusieurs objectifs ou Epics.
• Pitch – Une proposition d'idée ou une justification d'un projet, pouvant inclure des objectifs mais restant plus conceptuel.
• Goal – Un objectif spécifique à atteindre, souvent mesurable.
• Epic – Une grande fonctionnalité ou un ensemble de tâches qui contribuent à un objectif plus large.
• Task – Niveau le plus précis, une tâche est une unité de travail concrète et actionnable.

Une ou plusieurs Merge Requests constituent une réponse formelle, exprimée en code, parmi toutes les réponses possibles à une demande formulée dans une issue.
Seule cette réponse formelle, exprimée en code, est véritablement précise. Même l'issue, aussi détaillée soit-elle, conserve toujours une part de flou.

Attention tout de même : quand je dis qu'une issue de type Vision est floue, cela ne veut pas dire que son auteur peut bâcler sa rédaction.
Si, par exemple, la description est limitée à 500 mots, l'auteur doit exploiter au mieux cette limite pour présenter sa vision avec précision. L'objectif n'est pas de créer du flou volontairement, mais plutôt d'exprimer clairement un concept qui, par nature, comporte encore des zones d'incertitude à explorer.

Voici quelques exemples d'issue floue publiés ici :

• 2023-10-28_2008
• Projet 11 - "Première version d'un moteur web PKM"
• 2024-09-07_2240

Une issue, en tant que texte écrit, comporte une part inévitable d'ambiguïté et nécessite donc son auteur pour être défendue :

C’est que l’écriture, Phèdre, a, tout comme la peinture, un grave inconvénient. Les œuvres picturales paraissent comme vivantes ; mais, si tu les interroges, elles gardent un vénérable silence. Il en est de même des discours écrits. Tu croirais certes qu’ils parlent comme des personnes sensées ; mais, si tu veux leur demander de t’expliquer ce qu’ils disent, ils te répondent toujours la même chose. Une fois écrit, tout discours roule de tous côtés ; il tombe aussi bien chez ceux qui le comprennent que chez ceux pour lesquels il est sans intérêt ; il ne sait point à qui il faut parler, ni avec qui il est bon de se taire. S’il se voit méprisé ou injustement injurié, il a toujours besoin du secours de son père, car il n’est pas par lui-même capable de se défendre ni de se secourir.

Phèdre - Dialogue de Platon

Conséquence pratique de tout cela :

• L'auteur d'une issue doit être disponible et accorder du temps à la personne qui va implémenter son issue.
• La personne qui implémente cette issue doit accepter l'imprécision de cette issue. En posant des questions, le développeur doit aider l'auteur à rendre cette issue plus précise.
• L'auteur de l'issue doit accepter de recevoir une implémentation qui ne correspond pas exactement à sa vision… et dans ce cas, il doit soit l'accepter ou accorder plus de temps à cette issue afin d'effectuer plusieurs itérations de correction de l'implémentation.

Ces règles pratiques sont aussi valables lorsqu'une issue est déclinée dans des issues avec un niveau de précision supérieur. Par exemple, lors de la rédaction d'issues de type Epic à partir d'une issue de type Vision.

« Permettre à l'auteur de défendre son texte » ne signifie pas exclusivement un dialogue oral. Ce dialogue peut s'effectuer :

• Par chat synchrone ;
• Par commentaire d'issue asynchrone ;
• Par visioconférence ;
• etc

Je pense que le niveau de précision d'une issue détermine le mode de communication à privilégier. Pour les issues de haut niveau d'abstraction — très floues (Vision, Theme, Pitch), la communication orale se révèle généralement plus efficace, car elle permet des échanges dynamiques et immédiats sur des concepts abstraits.

En revanche, pour les issues plus précises (Tasks, certaines Features), je privilégie une approche asynchrone avec des questions écrites détaillées. Cette méthode offre à l'auteur le temps nécessaire pour réfléchir et affiner sa rédaction. Je ne recours à la communication orale que lorsque des problèmes de compréhension persistent malgré les échanges écrits, afin de débloquer rapidement la situation.

---

Je cherche des solutions pour bien indiquer le niveau de précision des issues que j'écris.

Voici quelques exemples d'introductions d'issues :

Cette issue est de type "vision", c'est donc normal qu'elle soit imprécise. Les zones d'ombre seront affinées progressivement dans des sous-issues spécifiques. Pour clarifier certains aspects, des échanges oraux pourront être organisés afin de répondre à vos questions et d'enrichir cette vision.

Autre exemple :

Cette issue a été rédigée avec un souci particulier de précision. Si vous identifiez des erreurs, des incohérences ou si certains points nécessitent des éclaircissements, n'hésitez pas à les signaler dans les commentaires. Pour toute difficulté de compréhension ou doute persistant, je reste disponible pour organiser une session en visioconférence afin de faciliter nos échanges.

Dans la branche gibbon-replay-js du projet Idée d'un outil de session recoding web minimaliste basé sur rrweb, j'ai essayé sans succès d'extraire du code dans un package Javascript.

Pour le moment l'import suivant ne fonctionne pas :

import gibbonReplayJs from 'gibbon-replay-js';

Quand je lance pnpm run build, j'ai l'erreur suivante :

$ pnpm run build
...
x Build failed in 336ms
error during build:
src/routes/(record)/+layout.svelte (2:11): "default" is not exported by "packages/gibbon-replay-js/dist/index.js", imported by "src/routes/(record)/+layout.svelte".
file: /home/stephane/git/github.com/stephane-klein/gibbon-replay-poc/src/routes/(record)/+layout.svelte:2:11

1: <script>
2:     import gibbonReplayJs from 'gibbon-replay-js';

Et quand je lance pnpm run dev, j'ai l'erreur suivante :

$ pnpm run dev

...

11:21:21 [vite] Error when evaluating SSR module /packages/gibbon-replay-js/dist/index.js:
|- ReferenceError: exports is not defined
    at eval (/home/stephane/git/github.com/stephane-klein/gibbon-replay-poc/packages/gibbon-replay-js/dist/index.js:5:23)
    at instantiateModule (file:///home/stephane/git/github.com/stephane-klein/gibbon-replay-poc/node_modules/.pnpm/vite@5.4.3/node_modules/vite/dist/node/chunks/dep-BaOMuo4I.js:52904:11)

11:21:21 [vite] Error when evaluating SSR module /src/routes/(record)/+layout.svelte:
|- ReferenceError: exports is not defined
    at eval (/home/stephane/git/github.com/stephane-klein/gibbon-replay-poc/packages/gibbon-replay-js/dist/index.js:5:23)
    at instantiateModule (file:///home/stephane/git/github.com/stephane-klein/gibbon-replay-poc/node_modules/.pnpm/vite@5.4.3/node_modules/vite/dist/node/chunks/dep-BaOMuo4I.js:52904:11)

Suite à cette frustration, j'ai envie de créer un projet, sans doute nommé javascript-package-playground dans lequel je souhaite étudier les sujets suivants :

• mise en place d'une librairie /packages/lib1/ qui contient une librairie javascript, qui peut être importé avec la méthode ECMAScript Modules ;
• mise en place d'une app NodeJS dans /services/app1_nodejs/ qui utilise lib1 ;
• mise en place d'une app SvelteKit dans /services/app2_sveltekit/ qui utilise lib1 dans un fichier coté server et dans une page web coté browser ;
• mise en place d'une librairie /packages/lib2 qui utilise lib1

Je souhaite décliner ces 2 libs et 2 apps sous plusieurs déclinaisons d'implémentation :

• avec le build basé sur tsc
• avec le build basé sur esbuild
• avec le build basé sur Babel (Javascript)
• et sans build

Et le tout encore dans deux déclinaisons : Javascript et TypeScript.

Je ne souhaite pas supporter CommonJS qui est sur le déclin, remplacé par ECMAScript Modules.

Dans ce playground, je souhaite aussi me perfectionner dans l'usage de pnpm link et pnpm workspace.

#JeMeDemande si ces connaissances sont totalement maitrisées et évidentes chez mes amis développeurs Javascript 🤔 et s'ils les considèrent comme "basiques".

#JaiDécouvert Window.sessionStorage

L'objet global sessionStorage est similaire à Window.localStorage, à la différence que les données enregistrées dans sessionStorage ont une durée vie limitée et expirent à la fin de la session de navigation actuelle.

...

En revanche, une session de navigation n'est valable que pour le contexte de navigation actuel, c'est-à-dire que le fait d'ouvrir une page dans un nouvel onglet ou dans une nouvelle fenêtre provoquera l'initialisation d'une nouvelle session de navigation, ce qui diffère du comportement des sessions utilisant des cookies.

-- from

Je vais avoir besoin de sessionStorage pour le projet Idée d'un outil de session recoding web minimaliste basé sur rrweb.

---

2024-09-14 : j'ai nommé ce projet gibbon-replay.

J'ai envie d'essayer de créer un "mini" service de session recording, basé sur rrweb, SvelteKit et KeyDB ou DragonflyDB.
Je pense que ce projet pourrait être minimaliste 🤔.

-- from

J'ai publié https://github.com/stephane-klein/gibbon-replay (gibbon-replay).

J'ai passé 2h sur ce projet.