Auteur/autrice : Mickael

  • Une Année Sans Excès D’Écran : Mon Retour D’Expérience

    En tant que développeur passionné de jeux vidéo, je passe une grande partie de mes journées devant un écran, que ce soit pour coder, jouer ou faire de la veille technologique. Cependant, il y a un an, j’ai ressenti le besoin de prendre un virage dans ma façon de travailler. Les distractions constantes—notifications, mails, défilement sans fin sur les réseaux—étaient devenues un frein majeur à ma concentration et à ma productivité. J’ai décidé de réduire mon temps devant les écrans et de revenir à une approche plus traditionnelle : l’écriture manuscrite. Voici comment cette méthode qui n’était plus dans mon vocabulaire a changé ma façon de travailler.


    Pourquoi M’éloigner des Écrans ?

    Lorsque je me plongeais dans une session de veille technologique, il suffisait d’une simple notification pour que je perde le fil de mes pensées. Ce qui commençait comme une recherche ciblée finissait souvent par une spirale de distractions : lire un e-mail, consulter les actualités, puis dérouler sans but dans le vide infini d’Internet. Le résultat ? Une perte de temps énorme et une productivité amoindrie.

    Je savais que pour retrouver le contrôle, je devais adopter une approche plus intentionnelle et moins dépendante des outils numériques. J’ai commencé à utiliser des cahiers comme support principal pour mes travaux de veille, de brainstorming, et de conception.


    Le Pouvoir de l’Écriture Manuscrite

    1. Une Attention Renforcée L’absence de notifications ou de distractions visuelles m’a permis de rester concentré plus longtemps sur mes tâches. Rédiger à la main mes notes et idées exige une présence mentale que les claviers et écrans ne peuvent offrir.
    2. Une Meilleure Mémoire En écrivant à la main, je m’imprègne davantage des concepts que je souhaite retenir. Cette pratique sollicite ma mémoire à un niveau différent et plus profond que la simple frappe au clavier.
    3. Une Créativité Stimulée Le papier blanc est un espace où les idées peuvent s’épanouir sans les limites imposées par les interfaces numériques. Les esquisses, diagrammes, et notes spontanées jaillissent plus naturellement.
    4. Une Curiosité Rééveillée En limitant mon accès à Internet, j’ai appris à trouver des réponses ailleurs : dans les livres, les discussions ou mes propres réflexions. Cela m’a poussé à explorer davantage et à m’ouvrir à de nouvelles sources de savoir.

    Ma Nouvelle Méthode de Travail

    1. Des Cahiers Dédiés J’utilise différents cahiers selon les besoins :
      • Un cahier pour la veille technologique, où je note les dernières tendances et outils.
      • Un cahier pour le brainstorming, idéal pour poser des idées sans contraintes.
      • Un carnet de conception, regroupant mes méthodes de game design et mes concepts.
    2. Lecture Active J’ai remplacé une partie de ma recherche en ligne par des lectures de livres spécialisés. Cela m’offre une vision plus approfondie et structurée que les articles dispersés sur le Web.
    3. Déconnexion Intentionnelle Quand je travaille sur une idée ou un concept, je m’éloigne complètement des écrans. J’éteins même mon téléphone pour éviter toute tentation.

    Les Résultats ?

    En un an, les bénéfices ont été clairs :

    • Une concentration accrue : Je termine mes tâches plus rapidement et avec une meilleure qualité.
    • Une mémoire renforcée : Les idées que je consigne restent gravées plus longtemps.
    • Une créativité renouvelée : Mes concepts sont plus riches et mieux explorés.

    Conclusion

    Réduire mon temps passé devant les écrans a été une décision transformante. Cette expérience m’a appris que parfois, il suffit de revenir aux bases pour regagner en clarté et en efficacité. Que vous soyez développeur, designer ou passionné de tout autre domaine, je vous encourage à essayer : prenez un cahier, un stylo, et laissez vos idées s’épanouir hors des limites numériques.

  • Devlog 2 – Cesse-Adventure Finalement du C#

    Le projet Cesse-Adventure a été initialement développé en GDScript.
    Finalement j’ai décidé de switch de de langage.

    Présentation des avantages et Inconvénients des deux langages

    GDScript

    Avantages

    • Conçu pour Godot : Intégration parfaite avec le moteur.
    • Facile à apprendre : Syntaxe simple, inspirée de Python.
    • Prototypage rapide : Idéal pour tester des idées.
    • Prêt à l’emploi : Pas de configuration supplémentaire.

    Inconvénients

    • Performances limitées : Moins adapté aux projets gourmands.
    • Langage spécifique : Peu utile en dehors de Godot.
    • Compatibilité IDE : Support limité pour des IDE externes comme Visual Studio Code ou JetBrains Rider.

    C#

    Avantages

    • Puissant et polyvalent : Idéal pour des architectures complexes.
    • Écosystème riche : Compatible avec des bibliothèques externes.
    • Performances élevées : Meilleur choix pour des projets exigeants.
    • Compatibilité IDE : Fonctionne bien avec des IDE comme Visual Studio, VS Code et Rider.

    Inconvénients

    • Apprentissage plus long : Le langage plus complexe.
    • Configuration nécessaire : Installation de Mono obligatoire.
    • Workflow légèrement moins fluide : Intégration moins native que GDScript.

    De GDScript à C#

    J’ai choisi de passer de GDScript à C# pour plusieurs raisons. Bien que GDScript soit rapide à apprendre et parfaitement intégré à Godot, j’ai ressenti certaines limites, notamment sur les aspects suivants :

    1. Architecture modulaire : Avec C#, je peux exploiter des concepts avancés comme les interfaces, les génériques et une gestion plus fine de l’architecture de mon projet, ce qui correspond parfaitement à mon approche modulaire.
    2. Compatibilité IDE : En utilisant un IDE comme Visual Studio ou JetBrains Rider, j’ai accès à des outils puissants (debugging avancé, autocomplétion, gestion des packages) qui boostent ma productivité.
    3. Réutilisation des compétences : Développer en C# me permet de transférer plus facilement mes connaissances vers d’autres moteurs (comme Unity) ou projets non liés aux jeux.

    Ce changement m’a demandé un peu d’adaptation, mais les bénéfices en termes de flexibilité et d’efficacité le rendent incontournable pour mes besoins actuels.

  • Intégration de l’Authentification OAuth avec l’API Twitch

    Aujourd’hui, je vais vous raconter comment j’ai intégré l’authentification via OAuth avec l’API Twitch dans mes applications.

    Contexte

    J’utilise l’API Twitch pour me connecter au chat Twitch et intercepter les commandes de chat. Cette API est utilisée dans deux de mes applications : CesseZeApp et Cesse-Adventure. Pour l’authentification, j’utilise OAuth 2.0.

    Pour utiliser l’API Twitch, il faut enregistrer son application. Twitch fournit alors un client ID et un client secret pour utiliser leur système d’authentification. Mon problème est que mes applications sont des clients qui se lancent directement sur un ordinateur, sans passer par un serveur tiers. Je ne peux donc pas utiliser la connexion Client Credentials d’OAuth, car cela exposerait mes identifiants à tous les utilisateurs de l’application.

    Heureusement, OAuth propose le Device Grant Flow, conçu pour ce type de cas.

    Device Grant Flow

    Voici comment ce processus fonctionne de manière simplifiée :

    1. Génération du Code de Validation : J’appelle la route /oauth2/device pour générer l’URL de validation du code.
    2. Validation dans le Navigateur : L’URL est ouverte dans le navigateur par défaut du PC.
    3. Obtention du Token : En attendant la validation du code sur la page du navigateur, la route /oauth2/token est appelée à intervalles réguliers jusqu’à l’obtention du token.
    4. Accès à l’API : Une fois le token obtenu, je peux accéder à l’API.

    Comme tout système d’authentification OAuth, un Refresh Token est fourni avec l’Access Token pour rafraîchir ce dernier avant son expiration.

    Problème avec l’API Twitch

    Cependant, selon la documentation officielle OAuth sur le Device Grant Flow, il est spécifié que la route du refresh token doit pouvoir être appelée sans avoir besoin du client secret, principe même de ce système d’authentification.

    Malheureusement, l’API d’authentification de Twitch exige un client secret pour rafraîchir l’Access Token, ce qui pose problème dans mon cas.


    En résumé, bien que le Device Grant Flow soit idéal pour mes applications, l’exigence du client secret par l’API Twitch pour le rafraîchissement des tokens complique l’intégration sécurisée de ce système.

    J’espère que Twitch pourra ajuster cette exigence à l’avenir pour mieux s’aligner avec les principes de l’authentification OAuth et offrir plus de flexibilité aux développeurs.

  • Devlog 01 – La structure de Cesse-Adventure

    Pour comprendre le contexte de ce devlog je vous invite à lire la présentation de Cesse-Adventure ici.

    Après de longues séances de brainstorming avec Céciliane et Juliette, nous avons pu nous organiser pour commencer nos tâches respectives. Céciliane n’étant pas disponible, nous avançons à deux pour l’instant.

    J’ai d’abord travaillé sur la création de la structure du code que je vais vous présenter, puis à développer le joueur et un niveau prototype qui seront présentés dans un prochain devlog.

    Présentation de l’asset de test.

    Je me suis basé sur un Asset réalisé par Vryell (lien vers l’asset), qui propose une structure de donjon de type roguelike :

    Et de modèle avec trois animations, Idle, Marcher, Attaquer, dans les 4 directions possible (Haut, Bas, gauche, droit).

    Lors de précédent poc que j’avais réalisé, il se trouvait que j’avais une modèle de personnage utilisant les traits de cet asset que j’ai décidé d’utiliser :

    Structure du projet

    Pour développer ce roguelike 2D en vue de dessus avec génération procédurale des niveaux, j’ai conçu une architecture modulaire axée sur la flexibilité et la communication efficace entre les composants. Cette approche utilise les scènes de Godot et les signaux pour garantir une interaction fluide et une maintenance simplifiée.

    Modularité

    Le projet est divisé en modules distincts, chacun responsable d’un aspect spécifique du jeu. Par exemple, nous avons des modules pour la gestion des joueurs (PlayerSystem), des ennemis (EnemiesSystem), et des niveaux. Cette séparation permet une meilleure organisation du code et facilite les tests unitaires et l’évolution des fonctionnalités.

    Orientation Objet

    Chaque entité du jeu, qu’il s’agisse du joueur, des ennemis ou des objets interactifs, est représentée par une classe dédiée. Par exemple, la classe Player gère toutes les propriétés et comportements du joueur, tandis que la classe Enemy fait de même pour les ennemis. Cette approche orientée objet me permet de réutiliser et d’étendre facilement les comportements des différentes entités du jeu.

    Utilisation des Scènes de Godot

    J’utilise également le système de scènes de Godot pour structurer les éléments du jeu. Chaque entité, comme les ennemis ou les niveaux, est définie dans une scène séparée. Cette organisation en scènes facilite la gestion des ressources et des instances dans le jeu.

    Communication par Signaux

    Pour assurer une communication efficace entre les différentes parties du jeu, j’utilise les signaux de Godot. Par exemple, le signal player_moved permet de notifier d’autres systèmes lorsque le joueur se déplace, sans créer de dépendances directes. Cette architecture orientée événement aide à maintenir un couplage faible entre les modules, améliorant ainsi la flexibilité et la maintenabilité du code.

    Conclusion

    En combinant ces principes, l’architecture peut être décrite comme une « Modular Scene-Based and Event-Driven Architecture ». Cette approche me permet de développer de manière structurée et évolutive, tout en tirant parti des puissantes fonctionnalités offertes par le moteur de jeu Godot.

    J’espère que vous avez apprécié cet aperçu de notre architecture. Si vous avez des questions ou des commentaires, n’hésitez pas à les partager ci-dessous !

    Restez à l’écoute pour plus de détails sur le développement de Cesse-Adventure !

  • Le BDD

    (Behavior-Driven Development) ou développement dirigé par le comportement

    L’approche BDD vise spécifiquement à améliorer de manière significative l’efficacité de la collaboration entre les différents rôles impliqués dans un projet.

    Tout comme mes articles sur le Clean Code et le TDD, voici une nouvelle synthèse :

    Le 3 Amigos

    1. Une personne capable de représenter le besoin
    2. Une personne capable de représenter la mise en œuvre
    3. Une personne capable de challenger les deux autres.

    Atelier de spécification, d’expression du besoin. sous forme de scénario.

    Les exemples doivent être exprimés dans le language métier, éviter d’utiliser des termes techniques.

    Des exemples auto-suffisants.

    Conservation des notes prises.

    Compléter les scénarios inversé (ex: Pas de remise si inférieur à 50$, remise au dela de 50$, ici nous avons deux scénarios pour un besoin)

    Automatisation des scénarios

    La syntaxe Gherkin

    Utilisation des étapes :

    Exemple : Given When Then

    On peut ajouter And et But

    On peut remplacer par des termes français

    Given → Étant donné que ou Sachant que ou En tant que

    When → Quand ou Lorsque

    Then → Alors ou Donc

    Ce système peut servir pour l’écriture des tickets et des tests

    Quelques nom d’outils d’automatisation : Cucumber, Behat.

    Utilisation de Persona, DataSet et DataBuilder

  • Le Clean Code

    Avant de poursuivre, je vous invite à consulter mon article dédié au TDD.

    Il s’agit également d’une prise de notes inspirée du livre Software Craft. Voici mon résumé synthétisé :

    N’importe qui peut écrire du code que l’ordinateur comprend; seuls les bons développeurs écrivent du code que les humains comprennent.

    Les questions à se poser

    • Le code n’est-il pas trop complèxe pour ce quíl fait ?
    • N’est-il pas possible de le simplifier ?
    • Les abstractions et autres généralisations introduites le sont-elle à bon escient ?
    • Est-ce qu’on anticipe pas trop sur un possible futur ?
    • Est-ce qu’on comprend à la première lecture ce que le code cherche à faire ?
    • Le code ne tend-il pas à se répéter ? Est-il pertinent d’en réduire la duplication ?
    • le design mis en place autorise-t-il suffisamment de liberté pour la suite ?

    Les règles du clean-code

    • Rester simple et aller à l’essentiel.
    • Révéler l’intention du code
    • Découper les fonctions
    • Respecter l’art du naming
    • Respecter l’art du Storytelling
    • Lorsque l’on modifie du code existant, il doit être mieux écrit que précédemment.
    • Respecter les règles de structure de code (Formatage, Respect des standards, Indentation, )
    • Respecter les niveaux d’abstractions (une fonction enfant doit être en dessous de celle qui l’appelle)
    • Ne pas contourner la règle d’une seule sortie de paramètre par fonction, Si la valeur est complèxe on l’encapsule dans un type dédié.
    • Restraindre le nombre de variable, et le définir au bon endroit
    • Commenter du code si il y a une subtilité, pour aider à comprendre le code; Marquer des problèmes à résoudre (ex : Todo); Apposer des mentions légales.
    • Appliquer ces règles au test.
    • Passer les tests

    Naming

    • Privilégier les nom communs pour les classes et les verbes pour les méthodes.

    Anti-Pattern

    • Acronymes et Abréviations, sauf si le terme fait parti du champ lexical du projet.
    • Termes fourre-tout (ex : Data, Info, Manager, Service) cela rajouter du bruit inutile.
    • Utilisation du Paramètre* (ex : GetArrrayOfProduct → GetProducts)
    • Les noms trop court (ex : i → index)
    • Paramètres* ou d’argument identique au type (ex : string str)
    • Nom trop long, si il est trop long c’est qu’il est possible de découper

    Acronymes à garder à l’esprit :

    • KISS → Keep It Simple And Stupid
    • YAGNI → You Ain’t Gonna Need It
    • TDD → Test Driven Development
    • DRY → Don’t Repeat Yourself

    *Paramètre → type de sortie (return) d’une fonction

  • Le TDD

    Récemment, j’ai découvert un livre passionnant intitulé Software Craft. Fruit de la collaboration entre Cyrille Martraire, Arnaud Thiéfaine, Dorra Bartaguiz, Fabien Hiegel et Houssam Fakih, cet ouvrage plonge au cœur de l’artisanat logiciel. Il explore avec finesse les principes, les pratiques et l’état d’esprit nécessaires pour créer des logiciels de qualité, en mettant l’accent sur des valeurs clés comme la collaboration et l’amélioration continue.

    Suite à cette lecture inspirante, j’ai pris des notes synthétiques dans mon espace Notion, que je vous partage ici :

    Les trois règles du TDD :

    1. On doit écrire un test qui échoue avant d’écrire n’importe quel code de production.
    2. On ne doit pas écrire plus de tests que ce qui est nécéssaire pour échouer ou ne pas compiler.
    3. On ne doit écrire que le code suffisant pour que le test actuellement en échec réussisse.

    Les 3 étapes (Itération) du TDD :

    1. Red (Le test ne passe pas)
    2. Green (Le test passe)
    3. Refactor (Amélioration du code pour une meilleure lisibilité)

    L’étape 3 est requise seulement si il y a besoin d’une refactor

    La rigueur de chaque étape est nécessaire pour performer dans le TDD.

    Remarque : utiliser la règle de triangulation afin d’éviter les valeurs de retour en dur dans le code. Cela consiste à toujours écrire au moins deux tests avec des valeurs différentes. Cependant on ne doit pas le faire dès la première itération. le premier test doit être validé puis un nouveau test est écrit puis échoue ou ne compile pas.

    Les règles d’écritures d’un test

    Anatomie d’un test :

    Concerne le nommage des fonctions de test et/ou des classes.

    1. should/when (ex : Should_raise_an_error_when_denominator_is_zero)
    2. given/when/then (ex: Given_five_as_nominator_and_zero_as_denominator_when_I_divide_nominator_by_denominator_then_an_error_is_raised)

    Corp d’un test :

    Règle du triple A : Arrange/Act/Assert.

    La règle du triple A est une méthodologie de base pour écrire des tests unitaires pour un scénario unique. Elle est divisée en trois sections distinctes. La première section, « Arrange », implique la configuration du test. C’est ici que vous initialiserez les objets, définirez les valeurs ou entrerez les données nécessaires au test. La partie « Act » fait référence à l’exécution de l’action qui doit être testée, tandis que « Assert » est la phase où vous vérifierez si le résultat de l’action est le résultat attendu.

    Écrire du code qui ne compile pas n’est pas intuitif mais avec la méthode TDD on apprend à lâcher prise et utiliser la puissance de l’IDE pour générer le code attendu.

    Voici le code source d’un exemple ou chaque commit représente une étape du TDD : https://github.com/adrunor/FizzBuzz