Semaine 14 – Ember Inspector et préparation du Ember Fest
#web #emberjs #ember_inspector #ember_fest #auto_reveal
Il n’y a pas eu beaucoup d’écriture de code cette semaine. L’objectif principal était de rédiger la première version de la RFC afin que l’équipe core puisse la discuter. Et pour rédiger la RFC, j’ai dû approfondir mes recherches sur la pertinence de ce que l’inspecteur importe actuellement.
Attention aux trous de lapin #
Les investigations de cette semaine m’ont menée à un bug dans l’Inspector actuel : la plupart des services sont marqués comme des propriétés calculées et non comme des services. Ça s’explique par la manière dont l’inspecteur détecte si un objet est un service, qui ne correspond plus aux versions d’Ember supportées. (Une semaine plus tard, ce type de problème expliquera un inconvénient dans l’approche que nous avons suggérée pour la nouvelle API.) La raison pour laquelle j’ai trouvé ce bug est que le morceau de code concerné utilise instanceof Service, où Service est importé depuis Ember.
Les tâches liées à l’Ember Inspector sont difficiles à estimer, car ce type de projet est très proche de la « R&D ». Pour éviter de consommer trop de temps, les développeur·ses doivent constamment garder l’objectif principal en tête et être très prudent·es avec les pistes qu’iel·s décident de suivre. Par exemple, mon objectif est d’implémenter le support de Vite pour l’Inspector, de préférence avant que Vite ne devienne le choix par défaut lors de l’exécution de ember new. Le bug que j’ai trouvé est-il lié à cet objectif ? Si je corrige le bug, quelles sont les chances que instanceof Service soit encore présent dans le code corrigé ? Si les chances sont élevées que l’import de Service ait du sens, alors corriger ce bug n’est pas ma priorité, car ça ne change pas l’API que l’Inspector doit consommer.
Lorsque vous travaillez sur un projet complexe avec des tâches difficiles à délimiter et impossibles à estimer, l’objectif principal est ce qui vous permet de garder le cap chaque fois que vous devez choisir une voie.
auto-reveal #
En parallèle du projet Inspector, nous devons préparer la présentation que nous donnerons à l’EmberFest sur l’Ember Initiative. Nous créerons les diapositives avec auto-reveal.
C’est une bibliothèque appartenant à Mainmatter qui apporte une CLI au-dessus de reveal.js et automatise certaines tâches liées à la construction de thèmes.
La première version de la RFC de l’Inspector a maintenant été soumise, et comme nous avons réussi à la publier juste avant une réunion de l’équipe core, nous aurons des nouvelles la semaine prochaine. En attendant, nous continuons les refactorisations côté Inspector, et nous avançons sur la présentation pour EmberFest.