Pixel

Journée Innovation de Juin 2020

30/06/2020

Fin juin, l’équipe s’est retrouvée pour une nouvelle session de R&D (AKA “journée Inno’ ” chez nous) et voici les sujets qui ont été traités : Application tvOS, Découverte de Deno et Board Game API. Bonne découverte !

Application tvOS

L’objectif de notre journée innovation était de réaliser une application de type liste/détail pour tvOS en utilisant SwiftUI. Nous souhaitions voir qu’elles étaient les interactions possibles, ainsi que les points communs et les différences entre tvOS et iOS.

À la fin de la journée, nous avions une application listant les plus grands succès du Box-office mondial et affichant le détail de ses films (Titre, affiche, résumé et bande-annonce en arrière-plan). Illustration d'une liste Nous avons remarqué des problèmes avec SwiftUI et tvOS tel que la navigation, qui ne permet pas d’afficher une seconde fois le détail d’un film. Ce problème pouvant être réglé en utilisant le développement des vues avec le storyboard.

De plus, nous avons aussi des problèmes d’interaction avec le résumé du film, celui-ci n’étant pas scrollable. Illustration de détail Cette journée nous a démontré la puissance et la facilité de développement d’interfaces graphique avec SwiftUI.

Découverte de Deno

Deno est le nouveau runtime JS/TS fait par le créateur de NodeJS: https://deno.land/

La version 1.0.0 étant sortie le 13 mai, Nous avons souhaitez tester la réalisation d’un premier POC d’API sur le sujet.

Ayant de l’expérience sur NodeJS, c’est sereinement que nous avons attaqué le sujet Deno, bien que la communauté ne semble pas être encore vaste et les articles bien rares.

Notre idée était de proposer une API gérant des utilisateurs via un CRUD basique, l’objectif étant avant tout d’appréhender Deno.

Notre environnement de travail se constitue donc :

  • de Deno, dont la mise en place est simple et rapide,
  • de Oak, un framework permettant de gérer les appels http ainsi que les routes :https://deno.land/x/oak
  • d’un container MongoDB sur Docker pour la gestion de la persistance. Le choix de MongoDB a été fait par défaut: Nous aurions souhaité utiliser un ORM pour nous connecter à une BDD relationnelle(MySQL ou MariaDB par exemple), mais lors de notre journée Innovation, aucun ORM n’était disponible pour Deno. N’ayant aucune expérience sur MongoDB mon camarade et moi, faire ce choix nous a permis également de mettre en premier pied dans l’univers du NoSQL de type “Document store”.

Concentrons nous désormais sur le coeur de notre journée, l’API.

En nous appuyant sur Oak, nous avons mis en place l’ensemble de l’architecture comprenant modèle, contrôleur, services et routes. Le framework est simple et efficace. Nous avons très vite trouvé les éléments dont nous avions besoin et mis en place la partie serveur http de l’API: Extrait de code de l'API Les deux seuls problématiques que nous avons rencontrées lors de notre journées sont liés à la couche de persistance :

  • Gestion des identifiants pour récupérer les éléments stockés,
  • Absence de structure en NoSQL, ce qui est évidemment, son but premier… Il semble donc que le problème ne soit pas lié aux technologies utilisées mais à un trop grand historique d’utilisation des SGBDr qui nous à poussés à tenter d’exploiter MongoDB hors de son contexte classique.

Conclusion de notre journée, Deno est prometteur:

  • la mise en place d’un projet est simple,
  • la compatibilité Typescript native sans compilation intermédiaire en JS est un réel gain de temps,
  • la suppression du package.json et des nodes_modules au profit d’un import via URL est un confort certain.
  • la communauté avance très vite pour ajouter de nouveaux modules(un premier ORM a été publié entre notre journée innovation et la rédaction de cet article) Cependant, Deno se positionne face à des concurrents déjà en place depuis très longtemps, ayant des communautés conséquentes et investies.

Il est donc évident que cela semble trop tôt pour partir en production avec Deno, mais qu’il faudra suivre de près ses futures évolutions avant d’envisager la bascule Node — Deno.

Board Game API

Objectif

Après deux mois à travailler à distance, les “moments d’équipe” nous manquent, notamment les parties de jeux de société du midi. Plutôt que d’utiliser les services en ligne existants, pourquoi ne pas développer notre propre outil interactif et évolutif, dans lequel nous pourrons venir intégrer petit à petit les différents jeux que nous aimons ?

L’objectif technique est de réaliser une plateforme de développement de jeux de plateau. Générique et évolutive, elle permettra de jouer aux cartes, aux dés, aux dames, à n’importe quel type de jeu. Chaque jeu prend la forme d’un module qui apporte son matériel spécifique (cartes, dés, pions) ainsi que ses règles. La plateforme est agnostique.

Technologies utilisées

Pour le backend, nous avons besoin de synchroniser la partie avec chaque joueur. Nous utilisons donc les WebSockets, et leur intégration dans NestJS.

Pour le plateau de jeu, nous avons choisi d’utiliser le framework Phaser qui permet de réaliser des jeux utilisant les Canvas et WebGL.

Travail réalisé

Sur la base d’un exemple Phaser affichant un paquet de cartes, nous avons créé un plateau de jeu présentant une pioche.

Chaque joueur a la possibilité de piocher une carte, que ce soit son tour ou non (comme dans la “vraie vie” ^^), et de la déplacer sur le plateau. Les déplacements de cartes sont synchronisés entre chaque joueur mais chacun peut placer sa pioche où il le souhaite.

Nous avons également ajouté sur les cartes une indication de couleur permettant à tous de savoir qui a pioché chaque carte. Illustration du plateau de jeu

Conclusion

NestJS simplifie beaucoup la mise en place de l’API.

L’arrivée dans Phaser est un peu délicate du fait d’un manque de visibilité de la documentation (documentation officielle, documentation officieuse, documentation de plugins, documentation v2/v3). Néanmoins, une fois le “tri” fait, le framework est simple d’utilisation. De plus, la quantité d’exemples de code et de cas d’usages permet de démarrer rapidement.

Étant donné le peu de temps à notre disposition, nous avons développé cette application en mode rush, sans prendre le temps de penser l’architecture. Le POC est concluant et le projet va désormais nécessiter une phase de réflexion :

  • Comment faire en sorte que le serveur soit réellement agnostique (et permettre de jouer à la bataille, au tarot, aux dames ou à dessinez c’est gagné) ?
  • Comment faire en sorte que la partie spécifique au jeu vienne s’emboîter simplement dans la partie générique ? Il faudra également l’ouvrir pour lui donner vie :
  • Choisir une licence libre !
  • Développer les premiers jeux.
#Continuous Improvement
#Innovation
#Development
red pixel blue pixel