Alors que la date de présentation du projet approche à grand pas, je plonge dans les méandres les plus profondes de mon code et essaye tant bien que mal de progresser afin d’avoir un outil opérationnel, prêt et présentable.
Chapitre I — Page d’outil
Le début de la semaine fut, pour ma part, fort compliqué. La page d’outil me donne plus de fil à retordre que prévu et étant presque entièrement imaginée et développée en Alpha sous du Javascript Vanilla, il m’était très difficile de “convertir” ce code pour qu’il soit adapté au framework que j’utilisais, c’est-à-dire Vue 3.
Lorsque ma perplexité atteint un point de non-retour, je décidai d’aller voir sur les forums, les documentations officielles et même des tutoriels vidéos du framework afin de comprendre ce que j’avais sous les yeux, en vain : je ne trouvais presque rien étant pertinent à ma situation, et les simples bribes de code que je pensais avoir trouvé étaient dépassées et obsolètes, donc inutilisables. Je passerai alors des journées entières à comprendre la moindre partie logique du projet, à essayer différentes méthodes possibles et prendre la solution la plus pertinente et la plus idéale, parmi celles que j’avais essayée (c’était notamment le cas avec l’éditeur de texte, où plusieurs méthodes différentes s’offraient à moi et je dus réaliser un choix arbitraire pour moi continuer à avancer).
J’avançais beaucoup plus lentement que prévu, mais au moins je n’étais pas à l’arrêt et continuait de découvrir de nouvelles fonctionnalités de Vue 3 que je n’avais jusqu’à maintenant soit jamais rencontré soit à peine effleurées. Quand bien même me pensais-je être totalement coincé, Le code et le langage devenaient de plus en plus compréhensibles au fur et à mesure que je progressais dans le développement, et j’avais plus en plus de contrôle sur les lignes que je rédigeais. C’est sans aucun doute grâce aux plusieurs techniques auxquelles j’ai recouru que je pus naviguer dans toute cette mer de complexité encore brumeuse et trouble par moments : je me remis, par exemple, à utiliser mon outil de division temporelle que j’avais déjà évoqué il y a quelques mois lors de mon stage, Pomofocus, qui permet de continuellement m’approvisionner avec la motivation et le courage nécessaire pour travailler sur chaque petite facette du développement, l’une après l’autre.
Ce qui est intéressant avec ce projet, c’est que la partie développement dépasse de très loin n’importe quel autre projet que j’ai réalisé jusqu’ici : s’agit-il de la partie visuelle, où je suis parvenu à utiliser de nouvelles techniques pour parvenir à mes fins (principalement pour tous les titres des sections, qui sont un peu plus visuellement enrichies que le contenu lui-même), ou même encore la partie logique, qui est bien plus poussée que ce que j’eus l’opportunité de présenter pour mon travail de fin de deuxième année ou même l’atelier Ilab du début de cette année scolaire (du moins pour ce que j’ai eu à faire dans cet atelier, c’est-à-dire la partie front-end).
Chapitre II — Base de donnée
À présent que j’avais moyen de tester ma base de donnée dans une situation presque réelle, je m’aperçus qu’il y avait quelques problèmes avec la manière dont je la chargeais dans les coulisses. Dès que l’utilisateur·trice voulait modifier son texte avec l’outil que j’étais en train de construire, il devait subir un gel de l’écran proportionnel au temps de calcul dont avait besoin l’algorithme pour convertir chaque mot en sa version dégenrée. Ce freeze comprend aussi que toute interaction utilisateur·trice était proscrite et qu’iels ne pouvaient faire qu’une seule chose : attendre. Attendre une quantité de temps indéfinie en espérant que la modification se soit bien effectuée. Cela vient du fait que Javascript soit, à condition qu’on ne lui indique l’inverse, ‘single-threaded’, c’est-à-dire qu’il exécute les actions que l’on lui donne l’une après l’autre, ce qui vient affecter l’affichage de l’interface utilisateur·trice ainsi que les interactions entre ces deux-ci, s’agit-il d’un bouton pressé, d’un formulaire envoyé ou bien d’un message de réussite.
Ce temps d’attente incertain représentait bien sûr une véritable brèche dans mon expérience utilisateur·trice que je devais à tout pris résoudre avant de poursuivre la suite du travail. Heureusement, j’avais quelques options à ma disposition afin de regagner la fluidité que je souhaitais :
- je pouvais, en premier lieu, utiliser ce que l’on appelle un Web Worker, technologie assez récente qui permet de faire travailler les opérations les plus lourdes de Javascript dans les coulisses, sans geler l’interface (cette opération reste pour autant client-sided, c’est-à-dire qu’elle dépend des performances du périphérique utilisé par l’utilisateur·trice) ;
- ou alors, je pouvais créer et héberger mon propre API, qui viendrait convertir le texte à ma place et le temps d’exécution ne dépendrait plus du périphérique employé, mais plutôt de la connexion. Cela nécessiterait, en outre, d’être réécrit dans un nouveau langage que je ne maitrisais pas totalement (du PHP, en l’occurrence).
Chacune de ces méthodes avait ses propres avantages et ses inconvénients, mais elles me permettraient toutes les deux de naviguer sous le même cap. Je vais alors opter pour les Web Workers, non seulement par simplicité, mais aussi afin de gagner énormément de temps, car le code était déjà rédigé en Javascript et n’avait plus besoin que d’être passé en asynchrone (c’est-à-dire que les opérations spécifiques sont passées sur un autre cœur et n’affectent pas l’affichage du site). Quelques jours plus tard, le Worker sera finalement opérationnel, permettant au rendu de la page et de ses interactions d’être aussi fluide que possible tout en laissant toute la partie logique travailler dans les coulisses.
Chapitre III — « Qualité de vie »
Il restait encore quelques semaines de travail avant de devoir rendre la version bêta du projet, et il restait encore quelques petits détails çà et là à modifier, à améliorer, voir à ajouter.
Il y avait tout d’abord ce système de suppression des modifications locales, c’est-à-dire que l’utilisateur·trice pouvait s’iel le souhaitait supprimer l’un des mots ayant été converti sans devoir repasser son texte dans l’algorithme (similairement à un bouton “ajouter au dictionnaire” que l’on retrouve sur les outils de correction grammaticale). Pour cela, il fallait reconstruire quelques morceaux assez conséquents du code et modifier la façon dont je récupérais et renvoyais le texte avant et après conversion, car je ne pouvais, à l’heure actuelle, incruster du code HTML (en l’occurrence, des <span>) dans mon contenu textuel. Là où cette sorte de réflexion était encore simple en Javascript, cela devenait un tout autre jeu lorsque l’on travaillait avec un framework, auquel on ne s’est toujours pas habitué. J’avais également l’opportunité d’utiliser une extension externe largement inspirée de l’éditeur de texte que propose Medium, mais je préférai ne pas m’en servir pour multiples raisons, notamment pour assurer la postérité du projet sans dépendre d’une quantité incalculable de plugins, mais aussi pour avoir le contrôle total de mon code et réaliser exactement dont j’avais besoin.
Tout ceci me demandait beaucoup de travail pour peu de choses, mais j’aime penser que cela rejoint la philosophie avec laquelle j’ai démarré mon sujet : je voulais offrir l’expérience la plus agréable possible à mes utilisateur·trice·s potentiels, et la possibilité d’annuler les modifications effectuées par l’ordinateur me semble être un pas dans la bonne direction (surtout dans le cas où la machine ne lit pas le texte de la même manière que les êtres humains et qu’elle a plus tendance à faire des erreurs de conversion).
Chapitre IV — Fin du quatrième acte
De plus en plus proche de la fin, je suis déjà assez content du chemin parcouru et de la quantité de choses que j’ai pu apprendre et découvrir grâce à ce projet (ce qui est le cas avec chacun de mes projets, mais celui-ci s’est avéré particulièrement instructif). Il reste encore quelques détails à adresser et à fignoler avant d’être totalement prêt à présenter ce projet qui me tient à cœur, mais, pour l’instant, je dois me concentrer sur la fonctionnalité principale de mon outil et m’assurer qu’elle fonctionne convenablement. Le reste attendra la phase bêta.
Les différents liens :
- Travail de fin d’année — Compte-rendu du pitch
- Travail de fin d’année — Case Study n°1
- Travail de fin d’année — Case Study n°2
- Travail de fin d’année — Case Study n°3
- Travail de fin d’année — Case Study n°4 [Vous êtes ici]
- Travail de fin d’année — Case Study n°5
