L’aiguillage de ton titre

Je me suis recréé un poste de travail sur mon PC principal, ce qui m’a demandé de réinstaller toute la panoplie de dépendances, logiciel, etc. De plus j’ai mis à jour le package.json ce qui a engendré quelques soucis, du coup nettoyage, un tslint réveillé et quelques commits plus tard : une solution fonctionnelle, à nouveau ^^.

Et donc, quelles sont les nouvelles ? J’ai écris l’écran titre, basé directement sur Scene, bien suffisant, et sur un Sprite (et non un Element), c’est là que certaines choses apparaissent comme « au mauvais endroit », trop spécifiques pour être dans TARS, à diviser ou à revoir, la liste n’est pas petite mais ce sont les aléas des POC continus j’imagine.

Cet écran titre est donc la Scene de démarrage, fait apparaître ‘daaboo’ progressivement, attend 2 secondes puis fondu au noir. Il restait ensuite à définir ce qui se passe ensuite, le fameux aiguillage dont j’ai déjà parlé.

L’aiguillage a pris la forme d’un service chef d’orchestre (Conductor) et reçoit les demandes de changements de Scene. Actuellement, on démet et on ajoute à la suite une Scene nommée. Ce n’est pas assez, mal nommé et à revoir, mais après avoir tergiversé une heure sans trouver un angle d’attaque à ce sujet complexe, j’ai décidé de démarrer quelque part et ça fonctionne. Cependant il faut rester clair : c’est à revoir.

C’est la Scene titre qui déclare, une fois arrivé au fondu au noir, la demande de changement de Scene et c’est elle qui sait vers qui elle veut nous rediriger. Ceci démontre bien que cette séquence fait partie du « jeu » et non de TARS. En gros, Conductor reçoit la demande et émet un événement que Game reçoit en s’étant abonné dès le début, ainsi il peut modifier les Scenes actives.

Ceci permet aussi à d’autres Scene qui en auraient l’usage, de s’abonner et de réagir selon les changements. On imagine facilement un HUD se modifier en fonction de la Scene de rendu ou un ensemble de Scene composant un rendu en couche qui auraient besoin de savoir ce qui se passe. Ceci n’est pas un canal de communication (développement spécifique au projet) mais une gestion propre à TARS concernant les Scenes.

Pour étayer ce qui ne va pas dans Conductor il faut s’imaginer une Scene de départ et une Scene à venir, le tout en gardant en tête que chaque Scene a une transition d’arrivée et de départ. Du coup si vous voulez quitter la Scene de départ pour aller vers la suivante, vous déclenchez en fait sa transition de sortie, elle n’est donc pas encore inactive et à retirer de la liste des Scenes actives. C’est cette Scene de départ qui doit en fait se gérer et quand elle a fini, lancer la transition vers la Scene suivante.

Il faut aussi garder en tête que le loader s’affichera si la Scene suivante n’est pas chargée au moment de l’activer et ce, sans transition. Donc pour faire de belles transitions, il faut que les Scenes soient chargées à l’avance ou en tâche de fond, c’est à dire charger la Scene sans la mettre dans les actives et garder le lien quelque part, le récupérer dans une Scene peut-être (ce qui n’existe pas, mais pas bête de le prévoir).

Enfin, une Scene peut s’ajouter par devant ou par dessous une autre, permettant telle ou telle transition ou effet de passage d’une à l’autre. S’ajouter à plusieurs peut-être et retirer de la même manière. Et est-ce utile de penser un remplacement ou déplacement de Scene(s) ? Beaucoup de questions et de gymnastique de code pour gérer l’ensemble.


La suite ?

Conductor sera modifié au cas par cas, jusqu’à remplir tous ses objectifs au mieux. Rien ne sert de se concentrer dessus absolument vu sa complexité.

TARS en lui-même a une belle liste de TODOs (~22) et comme dit ci-avant, certains morceaux doivent en sortir, ce qui ne va pas se faire sans mal.

Du coup, le meilleur moyen d’avancer, même sans serveur/back actuellement, est d’avancer sur le POC d’usage et donc « Nahyan », enfin, un semblant. Je pense continuer d’explorer l’interaction qui sera quand même la base du projet. J’ai émis quelques idées sur le comment mais je vais en faire un article à part entier.

Il reste également l’éditeur comme sujet assez imposant. Là encore, est-ce du TARS ou un outil de jeu. Les types d’Element étant un problème soulevé à sortir de TARS, c’est encore un beau débat.

Il y a de quoi faire c’est certain. Affaires à suivre… 🙂

Comitards 3 : Folk·o·pedia

Cela fait presque 2 ans que c’est dans les cartons, et si on remonte à Comitards 2.3, bien plus encore. Ceci dit, c’est une attente justifiée vis à vis de l’important changement que cela cache. Évidemment, avec le hack du serveur et la perte d’articles, les derniers articles datant de la V2 et de Badawok, le blog manque d’actualité. On va corriger ça avec cet article.

L’idée de base est de pouvoir ajouter plus de types de contenu, ensuite de ne plus devoir modifier le site pour y arriver, et enfin, car je suis seul, que la communauté arrive à s’auto-gérer. En complément, tant qu’à faire, élargir/revoir l’idée de Comitards, profiter du retour d’expérience de l’idée et du site, et ainsi reforger le site entier.

Déjà le constat, le nom « comitard » est souvent mal compris, « Je ne suis pas comitard », et dans d’autres pays cela nécessite une explication. Du coup j’ai émis quelques idées et proposé une sélection à quelques proches concernés. Nous accueillons bien plus que des « comitards », il suffit de regarder les ordres en tous genres. Il s’agit en fait de concerner les acteurs et groupes des traditions, souvent festives. Le folklore dans son ensemble.

Folkopedia a été retenu, voyez y la contraction de folklore et d’encyclopédie, dit folk-o-pedia. Le ‘o’ me fait sourire, comme dans les imaginaires éthyl·o·trons, truc-o-matic, etc. qui contractionnent les mots entre-eux faisant naître un néologisme d’association.

La mécanique du site est également complètement mise à terre. Il ne s’agit pas de simplifier le schéma DB comme la dernière fois ou de faire le grand nettoyage en ajoutant ce qui manquait depuis la dernière fois, mais de repenser intégralement le système de base, et là j’ai été chercher loin.

Une de mes premières missions en tant que consultant au Luxembourg (vers 2011) m’a amené à découvrir les ontologies au travers d’une application dans le domaine de la recherche sur les tests assistés par ordinateurs (TAO/OAT). Très nébuleux pour moi, il m’aura fallu quelques recherches personnelles et un intérêt sur les métadonnées, avec un cours en prime, pour faire le lien avec Comitards. Évidemment pas au premier coup d’oeil.

Notez que j’avais tenté de normaliser le contenu de Comitards via RDF avec le projet FGPI : Folk Groups and People Involved vocabulary. Ceci, par manque de connaissance et de capacité de contrôle n’ira pas plus loin et restera probablement un brouillon intéressant sur un sujet ô combien difficile.

Ceci dit, je me base sur l’idée et non pas une application stricte, car les performances ne sont pas au rendez-vous et j’avais envie d’intégrer un cadre et des définitions pour le concept général. Du coup je repars sur une base de données relationnelles, un schéma spécifique et une optimisation par extraction des données. On aura un cache de lecture simplifié tandis que l’écriture se fera dans le système étalé. Du moins c’est comme ça que je vois la chose. Flexibilité totale et optimisation.

Pour ceux que ça intéresse, prenez toujours en compte l’usage. Combien vont écrire pendant que combien vont lire, que ça soit concurrent ou non. Sur un site comme Comitards, on a très peu d’écriture et beaucoup de lecture. Vous savez donc ce qu’il faut optimiser et pourquoi.

Avec ce nouveau schéma, plus besoin de modifier le site pour ajouter du contenu. Il suffit d’entrer les données du nouveau sujet, ses attributs et les liens possibles. Le tout sera fait via une zone d’admin (j’espère 🙂 ), mais ça reste l’idée.

Pour développer, un « quelque chose » (une photo, une personne, un groupe folklorique, …) est une entité, et celle-ci a des attributs (nom, date de création, histoire, …) et des liens vers d’autres entités (photos, documents, …). Le plus dur là dedans est la définition de chaque chose.

L’ensemble de cette réflexion est basée sur un cahier des charges regroupant tout ce que l’on souhaite intégrer, avoir une vue la plus claire possible du projet, des besoins, optionnels ou non. Ensuite, cela a été soumis à des volontaires de tous horizons, raffinant le premier jet jusqu’à obtenir quelque chose de correspondant à ces cibles. Merci à eux.

Dans cette continuité, merci mon Gros Lézard (Lord Suprachris), pour la belle prise de tête sur la conception du schéma de la base de données. Cela a été périlleux mais on a réussi à faire correspondre tout le cahier des charges en un seul schéma ! Et ça c’est pas rien !

Mais les prises de têtes ne sont pas finies, il y a encore un autre point important que je pensais définit depuis le début : le stack technologique. J’avais oublié un détail : je suis seul. J’avais imaginé un stack très développé, beaucoup de challenges et d’apprentissages, mais avec de telles envies, ce n’est pas demain que le site sortira.

C’est ma compagne, Boudine pour ne pas la citer, qui m’a remis les idées claires avec une réflexion sur le temps déjà passé, la difficulté que je me suis donné et l’inatteignable objectif. Du coup, à contre coeur, mais en sachant le bien fondé, j’ai revu le stack, du moins j’essaye. Il y a beaucoup de niveaux à décortiquer, mais je vais y arriver.

Enfin, car on arrive quand même au bout de l’état des lieux, il y a le design, lui aussi confiant dans les premières maquettes, mais aujourd’hui plus vraiment. Il faut attraper l’utilisateur dans une mécanique fort complexe et rendre ça sexy. Qu’il prenne plaisir à contribuer et à consulter. C’est chaud. Là aussi j’ai sollicité des avis, mais j’ai perdu mon auditoire tant ils se bloquent sur la complexité du projet. Je ne baisse pas les bras, je finirait bien par trouver cette nouvelle interface moderne et flexible capable de répondre aux attentes de Folklopedia.

C’est un peu comme dans Social Network (film de l’histoire de Facebook), j’en garde une phrase intéressante : « On ne sait pas encore ce que c’est ». On sait très bien ce qu’on a développé, bien sur, mais pas forcément ce que ça va ou peut devenir, son potentiel, ses usages et dérives en tous genres.

On en est là, entre une fin de post analyse et de début des travaux, avec un objectif de base débuté avant fin d’année. On avancera entité par entité, outil par outil, il y aura des refontes, des erreurs, des cris et des larmes, mais il y aura surtout un résultat à cette aventure complètement folle :

Numériser les traditions, enregistrer les vécus, préserver l’éphémère : L’encyclopédie folklorique.