Aujourd’hui on va aborder un sujet un peu technique mais que j’espère rendre intéressant en l’expliquant de façon simple.

Vous le savez sûrement si vous traînez ici, je participe à un projet qui s’appelle Karaoke Mugen. Il s’agit principalement de deux éléments : un gestionnaire de sessions de karaokés et une base de données de ceux-ci. On est pas beaucoup à bosser sur KM en vrai, en tous cas de façon régulière. On obtient des contributions de nombreuses personnes de temps à autres (et ça nous fait chaud au coeur à chaque fois, vous avez pas idée) mais si on devait restreindre à uniquement à ce qu’on appelle des « mainteneurs », alors on peut dire qu’on est 2 en moyenne.

Vous êtes probablement étonnés. Vous vous dites « mais comment font-ils autant de choses tous seuls? ». La réponse va vous étonner : non, on ne se drogue pas et on n’avale pas non plus des litres de café. La vraie réponse c’est qu’on a mis en place des outils et des méthodes pour nous faciliter la vie et ainsi perdre le moins de temps possible en opérations fastidieuses.

C’est ce que je vais essayer de vous expliquer ici. La méthode de travail Karaoke Mugen peut s’appliquer à nombre d’autres projets, et beaucoup de gens ignorent tout simplement ce que l’informatique peut faire pour eux.

On va commencer par la base de karaokés car elle intéressera je pense, le plus grand nombre.

La base de karaokés

Tout d’abord, c’est quoi la base de karaokés de KM ? Un karaoké est composé de :

• Une vidéo
• Un fichier avec les paroles « timées » c’est à dire séparées et horodatées en syllabes afin que le logiciel de lecture puisse les afficher en synchronisation avec l’audio. Cette synchro est manuelle et effectuée par les soins de l’auteur du « time ».
• Un fichier de métadonnées du karaoké. Les métadonnées se sont toutes ces petites informations qui caractérisent la chanson : titre, série, interprête(s), année, type (opening d’animé, ending, insert song, concert live, etc.)

Le stockage

Les pré-requis

Comme on allait travailler avec des fichiers il était important de versionner. C’est à dire qu’on ait une trace, immuable, de qui a fait quoi et quand, et de pouvoir revenir en arrière en cas de souci. Le but n’est pas de fliquer les gens, c’est pas la mentalité du tout. Ce qui compte, c’est qu’on puisse retracer l’histoire d’un fichier, qu’on sache quand il a été modifié, par qui et pour quelle raison. Par exemple si quelqu’un supprime un karaoké parce que c’est un doublon avec un autre, on doit savoir pourquoi et au pire si on s’aperçoit que c’était une bétise, de revenir en arrière.

L’idée ce n’est pas de faire des chasses aux sorcières mais de pouvoir annuler les bétises pour aller de l’avant. L’erreur est humaine et même si quelqu’un faisait une action malveillante, une journalisation est primordiale car elle permet d’annuler de facto n’importe quelle action de ce type.

Wikipedia marche sur le même principe.

Si aujourd’hui on peut versionner du texte, cela n’est pas possible pour la vidéo, qui non seulement prend de la place mais est aussi un format difficilement journalisable et je vais expliquer pourquoi.

Le versionnage, c’est quoi ?

Comment ça marche ? Je vais pas vous faire un cours, mais disons que vous ayez plusieurs versions du même fichier au fil du temps. Plutôt que de stocker N fois le fichier, on va stocker uniquement les modifications effectuées, et ce par ligne. Par exemple si je rajoute une ligne, ma modification est mineure et le coût en taille sera tout aussi mineur, car pour afficher ma nouvelle version, je n’ai besoin que de la version de base plus ma modification.

Sur deux ou trois versions différentes vous voyez pas de problème, maintenant imaginez sur 9000 versions (puisque c’est le nombre de versions de la base de karaokés par exemple, à l’heure où j’écris ces lignes). La base de karaokés pèse sans les vidéos (donc que du texte) 150 Mo environ. Et la taille de la base avec cette journalisation est de 450 Mo seulement. Oui c’est 3 fois sa taille mais pour avoir 9000 versions de la base avec soi, c’est incomparable.

Les vidéos

Donc la première question à se poser c’est celle du stockage. Il a fallu, au début du projet en 2017 stocker tout ça sur une machine disponible 24/7 et avec un bon débit. Cette machine je l’ai déjà et il s’agit de Shelter. On a donc aménagé un espace, accessible par FTP à nos différents membres.

On avait le choix avec d’autres outils, notamment Nextcloud mais il n’a pas été retenu pour deux raisons : la première c’est qu’avec un grand nombre de fichiers (à l’époque on en avait 4000, aujourd’hui plus du double) Nextcloud est assez lent. La seconde c’est que nextcloud synchronise les fichiers sur différents ordis. Ainsi, une boulette faite par quelqu’un (l’effacement d’un fichier, la modification d’une vidéo par une de moins bonne qualité, fichier corrompu, etc.) se répercute sur tout le monde d’un coup. Là on est certains qu’en cas de coup dur, d’autres personnes ont potentiellement tous les fichiers chez eux et peuvent réparer l’erreur commise plus facilement.

Ça aurait pu être intéressant de versionner des vidéos, mais vu les remplacements qu’on fait de temps à autres il y aurait eu beaucoup trop de perte de place et de performances… Imaginez bien que chaque fois que quelqu’un téléchargerait la base de karaokés pour travailler dessus, il faudrait qu’il télécharge aussi les 12 versions de la vidéo A, les 3 versions de la vidéo B… On pourrait utiliser Git LFS pour ça, mais après quelques essais le problème restait entier, mais pour nous : l’espace de stockage nécessaire aurait été beaucoup trop important.

Côté format technique, on a choisi de rester très safe : MP4 avec codec h264 8 bit en vidéo, AAC en audio.

• Pourquoi pas le MKV ? Parce que le MKV a deux défauts. Le premier étant qu’il n’est pas reconnu par les navigateurs web (ça permet aux karaokés de fonctionner quand vous allez sur live.karaokes.moe ). Le second défaut c’est aussi sa qualité : le MKV permet d’embarquer des meta données, dont des sous-titres. On aurait pu par exemple distribuer les karaokés comme de simples fichiers MKV contenant absoluemnt tout, mais ça veut dire aussi que si on change le sous-titre ou le chanteur d’un karaoké, bah il faut réuploader toute la vidéo. Ça veut dire aussi qu’un utilisateur doit se taper le download du nouveau fichier. Bien sûr ça réglerait pas mal de soucis et simplifierait pas mal de choses quand on y pense, mais comme pour manger ses morts, est-ce bien raisonnable ?
• Pourquoi pas du h265 en codec vidéo ? Le h265 ou HEVC produit des fichiers plus petits pour la même qualité, mais n’est pas encore nativement lu partout. Déjà le codec est payant sur certaines plateformes comme Windows alors qu’il est inclus sur les systèmes Apple. L’autre problème c’est qu’il n’est pas décodé matériellement par un Raspberry Pi, et ça empêcherait KM de fonctionner dessus.
• Pourquoi pas du AV1 ? Le dernier codec prometteur du moment c’est l’AV1 et il est plutôt balèze, mais il est aussi très peu optimisé et du coup il faut un temps de ouf pour encoder un générique de 1min30 avec. Et selon les vidéos on n’y gagne pas toujours beaucoup…

Le reste

Tout le reste est donc du texte, et contrairement aux vidéos on peut donc les versionner. On avait commencé avec SVN au début mais on s’est vite aperçu que c’était peu pratique et qu’il y avait bien plus de possibilités avec Git. Git est utilisé massivement de par le monde pour gérer du code source de programmes, mais on peut l’utiliser pour gérer aussi tout ce qui contient du texte. Ça tombe bien, nos données de karaokés ce n’est que ça !

On a donc utilisé un GitLab autohébergé sur Shelter plutôt que Github ultra connu et centralisé. Non pas par idéologie : je n’ai rien contre les services centralisés, mais à fonctionnalités égales j’ai tendance à préférer des outils que je peux maîtriser plutôt que de faire confiance à un tiers. Ceci étant dit, Github s’est beaucoup amélioré ces dernières années et GitLab est clairement à la traîne, mais c’est un autre débat.

Je vais pas refaire l’historique car la structure de la base de karaokés a énormément changé en 3 ans pour atteindre une certaine maturité aujourd’hui, donc on va se concentrer sur ce à quoi elle ressemble actuellement.

On reprend ce qu’on a dit plus haut :

• Une vidéo (stockées hors de git)
• Des paroles
• Des métadonnées
• Du karaoké
• De la série (quels sont ses noms internationaux/traductions? Ses alias? Par exemple My Hero Academia c’est aussi connu en MHA, etc.)
• De ses tags, des étiquettes qui permettent de catégoriser plus facilement les karaokés. Par exemple si c’est un opening ou un ending, si c’est interprêté par Aya Hirano ou Bernard Minet, etc. Toute info qui peut se retrouver sur plusieurs karaokés, ce sont des tags.

Ces fichiers sont au format JSON, qui est un format facilement lisible et où on peut structurer des données. Je vais pas faire un cours sur le JSON encore une fois, mais disons que ça permet de ranger les données dans un certaine ordre et une certaine hiérarchisation afin de les traîter plus facilement, et de plus simplement manipuler de futures extensions du format.

Aparté sur le format des paroles

Les formats de fichier pour du karaoké existent, il y en a plusieurs, mais ils ont tous des défauts. On s’est naturellement tourné vers l’ASS qui permet une grande customisation, c’est ce qui est utilisé notamment par les groupes de fansub mais aussi par les éditeurs de simulcast du marché afin de sous-titrer leurs vidéos. Comme il est très maléable (on peut faire de jolis effets avec, placer du texte où on veut, et. ) ça nous est apparu le choix le plus naturel, sans compter que le format est documenté. On avait cependant d’autres choix :

• Le format Toyunda d’Epitanime : Epitanime est une asso étudiante de l’école d’informatique Epita/Epitech (je sais jamais comment on dit au final) à Paris, mais ça vous le saviez probablement déjà. Ils ont un format qu’ils utilisent mais il était, au début du projet Karaoke Mugen, n’ayons pas peur des mots, particulièrement obsolète et mal documenté. Une version plus à jour, affichant le texte en HD par exemple, existe depuis le début de l’année 2020 2019, mais l’association garde jalousement tout ce travail pour soi, ce qui est fort dommage, car en faisant ainsi, il suffirait que l’asso disparaisse pour que tout ce qui a été crée pour (tous ces karaokés quoi) soient rendus inutilisables. Imaginez que le code source du format, du lecteur vidéo adapté, se retrouve sur un disque dur externe et que celui-ci crame. On se retrouverait alors sans le code source, car comme étant privé, peu de copies en ont été faites. Ça et puis l’association n’aime pas trop les contributions extérieures. Peut-être est-ce une forme de fierté mal placée, qui fait qu’ils refusent d’utiliser ce qui ne vient pas d’eux mais Karaoke Mugen existe en partie à cause de cette fermeture, dûe notamment au fait qu’il s’agit d’un projet étudiant présenté à l’école, et que par conséquent il est compliqué de l’ouvrir à l’extérieur. L’autre désavantage du format à l’époque (début 2017 si vous suivez) c’est que, un peu comme Ultrastar, il n’est pas lié au temps. Pour le format Toyunda pré-2019 on ne compte pas en « temps » mais en « nombre d’images » pour savoir quand on doit afficher telle ligne ou telle syllabe. Changez la vidéo, par exemple pour une vidéo de meilleure qualité, avec en plus un changement d’images par seconde (passez de 23,96 à 24 ou 25 images par seconde, par exemple) et pouf, votre karaoké est tout décalé et inutilisable, il faut le refaire. J’exaggère un tant soit peu mais l’idée est là. Heureusement le nouveau format est basé sur le temps.
• Le format Ultrastar : il a l’avantage d’être documenté même sommairement, et il existe pas mal de karaokés de ci de là. Il y a cependant une gestion de la note pour le scoring (ultrastar restant un jeu à la base) qui ne nous servait pas. L’éditeur est aussi peu commode, malheureusement et un éditeur peu pratique. Comme pour Toyunda ça ne se gère pas au temps mais au « beat », avec un nombre de beat par minute écrit en début de karaoké.
• Le format Karafun : Je le connais assez peu, c’est Dysp qui a crée un convertisseur vers le format ASS, mais l’éditeur fourni est aussi peu utilisable, et le format obsolète.
• Le format KAR : Il s’agit d’un format aussi mais celui-ci est associé aux musiques au format MIDI. Comme nous utilisons des vidéos, ce n’était pas utilisable en l’état et pareil, les outils sont vétustes.
• Les formats du web, le SRT ou le VTT : Des formats amplement documentés, mais qui sont plus adaptés au sous-titrage : on ne peut donc pas afficher de colorisation à la syllabe, ce qui est un peu dommage pour le karaoké.
• Le format Soramimi : Découvert sur le tard, moins flexible que l’ASS. On aurait pu l’utiliser mais ça aurait été dire adieu à divers effets possibles. De toutes façons quand on l’a découvert on avait déjà amorcé l’utilisation de l’ASS. Si le format est documenté et facilement lisible, il est aussi peu maintenu.

Même si Aegisub n’est plus activement développé, le code source est libre et comme l’ont illustré les sympathiques membres du club Japan7 de l’école d’ingénieurs ENSEEIHT, on peut le patcher pour corriger les bugs et ajouter des fonctionnalités. Merci à eux pour le travail fourni !

D’ailleurs, en parlant de Japan7, eux et le Bakaclub, ainsi que les membres du club Japanim de l’ENSSAT nous prêtent régulièrement main forte en participant aux discussions autour du karaoké, mais aussi en développant des outils pour la communauté. Par exemple Japan7 et Bakaclub ont mis en place des automatismes pour nous prévenir dés qu’ils ajoutent un nouveau karaoké, ce qui nous permet d’aller voir si on ne l’a pas déjà et is on doit l’ajouter ou non à la base de Karaoke Mugen. Quant aux membres de l’ENSSAT, ils ont permis la conversion du format Karafun vers ASS car ils avaient beaucoup de karaokés faits sur ce format… Ça fait pas mal chaud au coeur de voir des fans de karaoké se rassembler pour trouver des solutions et travailler ensemble.

Les méthodes

La base étant hébergée sur notre Gitlab, on a deux principaux outils autres que git à disposition, les Issues et le CI/CD.

Les Issues, c’est quoi ?

C’est un système de gestion de tâches et de bugs. Normalement d’ailleurs, on utilsie un système d’issue ou de tickets pour du code informatique. Cela permet aux gens de signaler des bugs. Un bug = une issue.

• On peut assigner une personne à une issue. C’est pratique pour savoir qui travaille sur quoi en ce moment. Plus que pour fliquer encore une fois c’est surtout pour savoir s’il y a des tâches libres qu’on peut effectuer, ou demander à la personne responsable si on peut aider, etc.
• On peut affecter l’issue à un jalon. On utilise pas ça pour la base de karaokés mais pour l’application de gestion de session, KM App, oui : ça permet de se donner des points d’étape et de se dire « Bon, ce truc là ça sera corrigé pour la version 3, ça pour la version 4, etc.) et ça nous permet d’avoir des objectifs clairs pour ne pas se sentir enseveli sous trop de taff.
• On peut mettre des étiquettes. On en a un petit paquet : en cours, sorti trop tôt du four, mauvaise qualité, à intégrer… On range ainsi les issues dans des catégories pour mieux les organiser. Sorti trop tôt du four, par exemple, c’est pour les karaokés qu’on a intégré un peu tôt dans la base (genre la chanson vient de sortir) et on est pas certains de la transcription des paroles. La date d’échéance correspond souvent à la date de sortie du CD Single. Ainsi on peut corriger les paroles le cas échéant.
• On peut coller une date d’échéance : ça permet de se souvenir de revoir si l’issue est toujours valide lorsque la date indiquée viendra ou sera dépassée.

Tout ça nous permet de garder une vision de ce qu’il y a à faire : chaque karaoké a intégrer, à corriger, chaque suggestion a sa propre issue, et quand on effectuer la tâche concernée, on ferme l’issue, et on voit le compteur descendre d’un air satisfait.

Le CI/CD

C’est l’acronyme de Continuous Integration / Continuous Development. Encore un terme issu de la programmation mais qui sert nos besoins ici. Un CI/CD est une suite de tâches que le serveur va executer à chacun de vos ajouts/modifications dans la base de karaokés. Quand Kmeuh poste un nouveau karaoké, le CI/CD est déclenché et va effectuer différentes choses pour nous :

• Il s’assure que la base de karaokés est testée. C’est à dire qu’il vérifie que chaque fichier dedans existe. Que chaque fichier de paroles ou vidéo s’appelle correctement et est bien à sa place. Ça évite que quelqu’un qui télécharge la base de karaokés se retrouve avec des karas qui ne fonctionnent pas.
• Une fois le test fait, il met à jour kara.moe ainsi que live.karaokes.moe pour que le(s) nouveau(x) karaoké(s) soient disponibles pour le public

En gros, le mainteneur a juste à envoyer son nouveau karaoké sur git et ça s’occupe de contrôler et mettre en place le tout.

Les notifications

Grâce à Gitlab et son intégration à Slack, il est possible d’être notifié sur le canal Discord dés que les choses suivantes se passent :

• Quelqu’un crée une issue, la ferme, ajoute un commentaire…
• Quelqu’un ajoute un ou des commits à la base de karaokés ou le code du serveur ou de l’application KM
• Un pipeline du CI/CD se plante en erreur, il faut alors aller la rectifier

Quoi, on a un Slack ? Non, Discord nous suffit amplement, mais Discord accepte les notifications Slack, donc on a juste fait en sorte que Gitlab en emette à Discord via des Webhook. C’est très simple à mettre en place et ainsi on est prévenus de la moindre modification.

Les services en ligne / Karaoke Mugen Server

Karaoke Mugen c’est une app, et on y reviendra après, mais c’est aussi plein de petits services qu’il a fallu développer. On a alors décidé de faire ça sous une bannière commune appelée Karaoke Mugen Server, même si tout n’est pas inclus dedans…

Le formulaire d’ajout

Y’a un gros problème avec ce que je viens de dire dans la section sur le CI/CD : toutes ces manips (commit sur git, etc.) peuvent être assez décourageantes pour l’utilisateur lambda qui veut juste créer des karaokés. C’est pour ça qu’à un moment, assez tôt, on s’est dit qu’on allait créer un formulaire d’ajout de karaoké dans la base. On l’a d’abord crée pour l’app Karaoke Mugen avant de l’adapter à Karaoke Mugen Server.

Ce formulaire a dû être pensé pour être le plus simple possible, et surtout il fallait contrôler un minimum ce qu’on nous envoie. Par exemple vérifier que les paroles envoyées sont bien au format ASS.

Bref c’était assez satisfaisant de le voir utilisé de temps à autres, c’est comme une boîte à lettres pour nous : on est notifiés quand un karaoké est déposé dessus car l’envoi du formulaire fait appel à une API Gitlab pour créer une issue automatiquement.

kara.moe/base

Il s’agit d’un navigateur de la base de données de Karaoke Mugen, qu’on appelle KMExplorer. Il fait partie de KMServer.

Il permet, entre autres, d’afficher sur des pages web toutes les infos des karaokés de KM, pour faire un catalogue.

C’est pour nous avant tout une vitrine de la base de données. On a prévu par exemple de permettre de vous connecter avec votre compte utilisateur pour ajotuer des karas directement en favoris d’ici, mais on a juste pas le temps.

Les comptes en ligne

C’est ce qui vous permet d’utiliser un même login/mot de passe sur plusieurs sessions de Karaoke Mugen. Ca permet aussi d’avoir vos favoris à un seul endroit et réutilisables peu importe chez qui vous faites du karaoké !

Il faudrait qu’on permette aux utilisateurs de créer et gérer leur compte depuis une interface web sur Internet, hélas ça demande du temps à développer, et pour le moment il faut donc le faire depuis l’application uniquement.

Dans un souci de respect des infos de l’utilisateur, vous pouvez à tout moment supprimer votre compte en ligne depuis l’application Karaoke Mugen.

Je sais pas si on est RGPD-compliant et je le pense vraiment pas, mais on fait ce qu’on peut.

Le raccourcisseur d’URL kara.moe

Une jolie petite idée de Ziassan nous a permis de résoudre plus ou moins le souci de l’URL à taper pour les utilisateurs de Karaoke Mugen. Au début du développement il fallait taper l’IP locale de la machine. Pas très pratique pour les utilisateurs de retenir « 192.168.0.1:1337 ».

Du coup, on a mis en place le système suivant :

• Au démarrage, votre Karaoke Mugen envoie à KM Server votre adresse IP et port locaux (192.168.0.10 et 1337 par exemple) ainsi que votre adresse IP publique (votre adresse sur Internet en gros). Tout ceci est stocké dans une petite base de données nettoyée régulièrement.
• Quand vous allez sur http://kara.moe, KM Server vous répond et vous redirige vers l’IP et port de votre KM local (192.168.0.10:1337) si votre adresse IP publique (internet) est la même que celle du KM local.

Ca marche plutôt bien et c’est simple à retenir. Seul bémol : on a des soucis avec les adresses en IPv6…

Branches et environnement

Pour KM Server, comme il s’agit d’un outil en ligne, nous avons deux environnements : kara.moe et dev.kara.moe. Ils correspondent aux branches master et dev du dépôt git de KM Server. Quand on fait des modifs lourdes ou possiblement à tester, on pousse sur la branche dev. Quand on doit corriger un bug rencontré on le fait sur master, et régulièrement on fusionne les deux branches l’une sur l’autre et inversement pour être bien à jour des deux côtés. C’est le yin et le yang.

L’application Karaoke Mugen

Le choix du online/offline

Aujourd’hui une écrasante majorité des applications tournent en ligne. Youtube a son contenu en ligne. Vous ne pouvez pas lancer Youtube sur votre ordi sans connexion Internet. Trello, Twitter, Facebook, là je cite que des trucs qui me passent par la tête mais vous aurez compris, tous ces services sont « centralisés ». Certes, sans Internet ils n’existeraient pas car leur contenu est sur Internet, mais il n’empêche que par exemple vous ne pouvez pas héberger votre propre version de Youtube chez vous sur votre ordi et vous y connecter. Enfin si, ça s’appelle Peertube mais c’est pas à la portée du premier venu.

A une époque, on installait beaucoup plus d’applications sur son ordinateur que maintenant. Mais ça veut dire aussi, par exemple, qu’on est dépendant d’un service tiers, d’internet, de la bonne volonté de quelqu’un de garder le service en marche. Si demain youtube s’arrête, on aura plus les vidéos nulle part. Si demain Trello s’arrête on aura le bec dans l’eau car on ne pourra plus utiliser le logiciel en question.

Cette approche a des désavantages comme je viens de le signaler. La perénité du service, la confiance (on confie ses données à quelqu’un), mais aussi, soyons honnêtes, beaucoup d’avantages pour le développeur :

• Un environnement simplifié : les gens accèdent à l’appli par un navigateur web, on a pas à coder tout le rendu graphique avec tous les problèmes que ça comporte entre cette version de Windows et cette version de Linux ou macOS. Alors oui les navigateurs ont aussi leurs petites différences, mais ça reste très souvent minime à gérer. C’est en tous cas bien moins pire que de gérer des applciations natives entre Windows, Mac et Linux.
• Une gestion du contenu simplifiée : l’utilisateur n’a plus à télécharger les vidéos, il peut les streamer depuis Internet. Du coup on a pas à gérer le stockage de celles-ci, la gestion des dossiers, de l’espace disque… Les comptes utilisateurs existent aussi à un seul endroit, ce qui permet de communiquer simplement entre eux (c’est notamment un avantage que Twitter a sur Mastodon, qui est décentralisé.)
• Les mises à jour : après tout, c’est plus simple de MAJ l’app de notre côté plutôt que d’attendre que les gens fassent la mise à jour chacun de leur côté… Les bugs sont ainsi réparés plus rapidement et pour tout le monde.

Dés le début du développement de Karaoke Mugen on voulait faire en sorte que vous soyez maîtres de vos données, et de l’application. Pour nous c’était aussi ne plus avoir de responsabilité vis à vis de l’hébergement d’un service. Si KM avait été un site web et non une applicaton téléchargeable, si jamais KM coupait en plein karaoké en convention (serveur qui redémarre, etc.) on aurait l’air fins. Pour nous, c’était primordial de laisser la main à l’utilisateur, et malheureusement ça se fait de moins en moins… Je vois beaucoup trop de services cools qui sont incapables de fonctionner de manière autonome, sans Internet, sans leur développeur… parce que aussi, pour eux, ça permet de garder une forme de main mise sur l’outil.

Mais voilà, ça nous a rajouté des bâtons dans les roues. Essayons d’être concrets :

• Il faut gérer le fait que vous pouvez être ou non connecté à Internet.
• Il faut gérer le fait que vous pouvez avoir un compe en ligne ou local. Il faut gérer le fait que vous devez quand même pouvoir vous connecter sur KM avec un compte en ligne si l’instance avait Internet au moment où le compte a été connecté dessus…
• Et les karaokés, il faut pouvoir les récupérer chez soi, écrire un système de téléchargement, de fil d’attente, de mise à jour. Ca serait tellement plus simple si c’était nous qui mettions à jour la base de données. Et du coup cette version locale de la base, il faut pouvoir la sauvegarder, la restaurer, vérifier que les fichiers sont tous disponibles au moment de la lecture, tester si y’a des problèmes, si tout est à jour…
• Faut créer un installeur et un executable, vérifier que tout fonctionne sous Windows, Mac et Linux.
• Pas de configuration, de clé de chiffrement ou de mots de passes à gérer…
• Pas de calcul du gain audio à faire par votre ordi.
• Pas de PostgreSQL a gérer.
• Pas de mpv et son API facétieuse à gérer.
• Pas besoin de ce raccourcisseur d’URL en kara.moe
• … vous en voulez encore ? 🙂

Voilà, Karaoke Mugen, l’application, c’est pas évident à gérer, mais on a fait le choix de prendre la route la plus difficile pour que vous puissiez gérer comme bon vous semble vos données.

Les versions

Vous l’aurez remarqué, on aime bien notre système de numérotation : on prend une lettre de l’alphabet, on choisit un rpénom de waifu d’animé qui commence par cette lettre, et on ajoute un adjectif idiot. Cela est hérité d’Ubuntu et d’autres projets. Quand j’écris ces lignes on va sortir Nadia Naturiste. On change l’adjectif pour chaque version mineure. Voici un petit historique :

• v1.2.0 « Akari Amoureuse » (07/05/2017)
• v1.3.0 « Belldandy Bolchévique » (11/05/2017)
• v1.4.0 « Chitoge Chatoyante » (13/05/2017)
• v1.5.0 « Darkness Délirante » (19/05/2017)
• v1.6.0 « Emilia Eblouissante » (26/05/2017)
• v2.0.0-alpha « Finé Folklorique » (29/08/2017)
• v2.0.0-beta1 « Finé Flegmatique » (18/09/2017)
• v2.0.0-beta2 « Finé Foutraque » (29/09/2017)
• v2.0.0-rc1 « Finé Fiévreuse » (25/10/2017)
• v2.0.0 « Finé Fantastique » (06/11/2017)
• v2.0.1 « Finé Fantastique » (11/11/2017)
• v2.0.2 « Finé Fantastique » (12/11/2017)
• v2.0.3 « Finé Fantastique » (12/11/2017)
• v2.0.4 « Finé Fantastique » (20/11/2017)
• v2.0.5 « Finé Fantastique » (01/12/2017)
• v2.0.6 « Finé Fantastique » (15/02/2017)
• v2.0.7 « Finé Fantastique » (17/02/2018)
• v2.1.0-rc1 « Gabriel Glandeuse » (05/04/2018)
• v2.1.0 « Gabriel Glamoureuse » (18/04/2018)
• v2.1.1 « Gabriel Grivoise » (03/05/2018)
• v2.1.2 « Gabriel Gênante » (16/05/2018)
• v2.2.0-rc1 « Haruhi Hargneuse » (24/05/2018)
• v2.2.0 « Haruhi Hagiographique » (05/06/2018)
• v2.2.1 « Haruhi Hypnotisante » (19/06/2018)
• v2.2.2 « Haruhi Hibernante » (03/07/2018)
• v2.2.3 « Haruhi Hyperactive » (16/07/2018)
• v2.3.0-rc1 « Ichika Immergée » (07/08/2018)
• v2.3.0 « Ichika Idolâtrice » (14/08/2018)
• v2.3.1 « Ichika Insouciante » (22/08/2018)
• v2.3.2 « Ichika Imperturbable » (03/09/2018)
• v2.4.0 « Juri Judicieuse » (07/11/2018)
• v2.4.1 « Juri Joviale » (28/11/2018)
• v2.4.2 « Juri Joueuse » (13/12/2018)
• v2.5.0 « Konata Karaokiste » (30/04/2019)
• v2.5.1 « Konata Kiffante » (06/05/2019)
• v2.5.2 « Konata 4-Koma » (22/05/2019)
• v2.5.3 « Konata Kimono » (30/06/2019)
• v3.0.0-rc1 « Leafa Lumineuse » (17/11/2019)
• v3.0.0-rc2 « Leafa Lumineuse » (22/11/2019)
• v3.0.0 « Leafa Lumineuse » (29/11/2019)
• v3.0.1 « Leafa Loyale » (16/12/2019)
• v3.0.2 « Leafa Langoureuse » (09/01/2020)
• v3.1.0 « Mitsuha Mélodramatique » (22/01/2020)
• v3.1.1 « Mitsuha Mélancolique » (04/03/2020)

Les branches

Sur tout git qui se respecte, il y a une branche master. Chez nous, la branche master est la version stable la plus à jour de Karaoke Mugen. Si on a sorti une version nuémrotée, il est possible que master soit un poil plus à jour parce qu’on a fait une ou deux corrections, mais pas assez pour justifier une nouvelle version numérotée.

A côté de ça, on a la version en cours de développement baptisée « Next ». C’est la branche expérimentale, la branche de tous les dangers, des sensations fortes et des plus grandes émotions. On y corrige bugs, mais on y ajoute aussi des fonctionnalités (qui ne marchent jamais du premier coup.)

Quand on doit travailler sur la résolution d’un gros souci ou une nouvelle fonctionnalité rapportée sur une issue, Gitlab nous permet de créer automatiquement une « demande de fusion » et une branche. Du coup on travaille sur cette branche sans impacter la branche next tant qu’on a pas fini. Dès qu’on a fini, testé, retesté (mais jamais assez), on termine la demande de fusion : Gitlab s’occupe alors de fusionner notre branche sur next puis de la faire disparaître, et ferme ensuite l’issue automatiquement. C’est un gros gain de temps lors du développement, parce qu’en deux clics tout est réglé.

Le CI/CD

On a déjà parlé tout à l’heure de ce que c’était.

On applique ce système à d’autres développements que la base : par exemple pour l’application, nous avons :

• Une tâche pour tester l’application avec ce qu’on appelle des tests unitaires : lire les infos d’un karaoké, chercher les karaokés qui contiennent « Dragon Ball », ajouter un karaoké en favori… On automatise ces tests en programmant un robot qui va les faire pour nous. Si tous les tests sont OK alors l’app est considérée comme utilisable. On ne fait jamais suffisament de tests, mais ces derniers prennent du temps à écrire. Ils nous permettent surtout de vérifier si avec une modification on a pas cassé une fonction fondamentale de Karaoke Mugen.
• Une tâche de compilation : on transforme le code lisible par un humain en code « machine » afin qu’il soit plus rapide que quand on fait du développement où le code « humain » est transformé en code « machine » à la volée (c’est plus lent mais ça nous permet de nous y retrouver).
• Une tâche de packaging : l’application est compressée, les fichiers nécessaires sont ajoutés à une enveloppe, un installeur, etc. On fournit des versions pour Linux, Windows et macOS donc il y a 3 tâches à réaliser
• Une tâche de déploiement : c’est le moment où le package préalablement fait est mis à dispo sur le site web.

Les sites web de KM

Le portail karaokes.moe

Il s’agit d’un bête portail en PHP avec Composer qu’on voulait mettre en place. Rien de bien méchant à signaler mais le côté intéressant c’est que pour ces sites, le CI/CD permet de les déployer directement une fois qu’on a fait une modif dans le git. Quelqu’un pousse une modif, paf ça envoie la modif sur le site web directement. On appelle ça un déploiement.

Karaoke Mugen Live

Avant qu’on fasse Karaoke Mugen, Rin utilisait le domaine karaokes.moe pour héberger une version du logiciel AnimeOpenings. Ce logiciel est utilisé sur openings.moe pour passer des openings et endings aléatoirement. On l’a donc repris pour faire live.karaokes.moe et ainsi montrer les karaokés disponibles au monde entier. Mais on est allés un peu plus loin : AnimeOpenings étant un logiciel libre, nous avons remonté les problèmes aux développeurs et aidé à trouver des solutions. On a même soumis des patches pour corriger des petits soucis à droite à gauche. On fait ça également avec l’application Karaoke Mugen a plus petite échelle, avec tous les modules dont il est composé.

Le site web mugen.karaokes.moe

Site web de l’application, il a été écrit avec l’outil Jekyll, qui est un générateur de sites web statiques. En gros il prend le texte qu’on écrit, et selon un système de règles et de modèles crée rapidement un site web statique. C’est plus rapide qu’un wordpress, mais c’est pas aussi simple à mettre en oeuvre, surtout pour l’utilisateur lambda. Ca nous permet aussi du coup de versionner encore une fois le contenu du site web pour qu’on puisse revenir à n’importe quelle version à tout moment.

La documentation

Le site de documentation est écrit avec l’outil MkDocs, qui est comme Jekyll cité plus haut mais pour les sites de documentation.

On fait souvent des passes sur cette documentation pour l’enrichir ou la corriger. Chaque version majeure est d’ailleurs l’occasion de la relire pour changer ce qui est maintenant différent. C’est aussi là qu’on garde la documentation sur comment faire un karaoké, les recommandations, les règles, bref tout ce qui fait foi.

Le bot twitter/mastodon

Vous l’avez probablement remarqué si vous suivez notre Twitter ou compte Mastodon : à 19h03, on poste chaque jour un karaoké pris au hasard. Il a fallu pour ça écrire un bot qui interroge la base de données de Karaoke Mugen et qui s’occupe de faire le post. Ce n’était pas évident mais ça a permis de jouer avec l’API Twitter (et voir que c’est un peu de la merde).

Les images docker

Docker, pour ceux qui l’ignorent, est un service de containeur. Nous on s’en sert pour le CI/CD : les tests, les déploiements, etc, utilisent docker pour avoir un environnement toujours identique d’un passage à l’autre, et surtout pour avoir toute une suite d’outils installés d’office dans le containeur du CI/CD pour bien travailler efficacement.

Si le hub Docker fourmille d’images en tous genres et pour toutes les situations, pour Karaoke Mugen il nous fallait par exemple une image avec node ET php pour les tests de la base. On a donc du faire une image docker nous-même. Rien d’insurmontable mais c’est toujours ça de plus à faire!

Conclusion

Je pourrais encore vous parler longtemps encore de tout ce qui a été fait autour de Karaoke Mugen pour que la tâche des mainteneurs et des développeurs soit la plus simple possible. On est pas loin d’une quasi industrialisation qui nous a pris du temps à pondre mais qui aujourd’hui nous facilite grandement la vie. Je vois mal comment on pourrait revenir en arrière. Et encore, il ya plein de choses améliorables, pensez-vous ! On est loin de l’état de l’art qui se fait au niveau professionnel aujourd’hui et qui permettent à de nombreuses boîtes de corriger des bugs avant même que les utilisateurs s’en aperçoivent par exemple…

Mais il ne faut pas oublier que nous ne sommes qu’une petite équipe, 5 personnes tout au mieux sur leur temps libre. Avec si peu de ressources, quand je regarde dans le rétroviseur, je vois tout le travail accompli, et pas seulement les lignes de code. C’est toute une organisation qui a été mise en place, et je pense qu’on sous-estime pas mal tout ce que l’informatique peut faire pour nous dans la gestion de projets : il faut juste quelqu’un qui s’y connait, et surtout vouloir changer ses habitudes. Git, personne de non-informaticien au sein de l’équipe ne l’a appris en une heure, il a fallu se familiariser et ça n’a pas été évident. Mais c’est un outil qui rend énormément service sur le long terme.

J’espère que cette lecture vous aura plu, et c’est avec un énorme plaisir que je vous en dirai plus si vous avez des questions, alors n’hésitez pas !