Sprint 1 : 30/09 - 14/10
Audric
-
Travail sur la gestion de projet : J'ai travaillé sur l'élaboration du WBS. J'ai mis en forme des tâches plus précises à partir des users stories du Backlog. Le découpage à permis de trouver plus facilement une estimation du temps. J'ai ensuite mis toutes ces tâches sous forme de diagramme WBS. Voici la liste des tâches : https://docs.google.com/spreadsheets/d/1o1EDNBiHa7J4rkEH6tZk9IvwduC9VrGYJXL_cNzbzns/edit#gid=0
-
Reflexion serveur Docker :
Gère des conteneurs logiciels afin de virtualiser des environnement linux sur une machine.
Les conteneurs utilisent l'OS de la machine -> plus performant qu'une VM qui elle a son propre OS Image docker = template de conteneur contenant des librairies et fichiers de configurations pré-installés
-
Reflexion sur un design pattern Façade, collaboration avec félix pour une architecture de classe basée sur des Managers qui gèrent leurs propores parties de l'application
-
Elaboration du diagramme de classe avec description des classe connus
Félix
-
Travail sur la gestion de projet : Réalisation du PERT et sa description, de la description de WBS, de l'estimation des tâches et de la durée globale.
-
Travail sur la réflexion de la conception : J'ai réfléchi à la future architecture simplifiée des différentes parties de notre application. J'ai fait une représentation pour pouvoir l'expliquer.
-
Le modèle est composé de nos classes et autres en Dart/Flutter.
-
La base de données (en PostgreSQL) sert pour toutes les informations à conserver : tous les likes, les informations des comptes utilisateurs, les messages. Comme Docker semble pouvoir acceuillir ce genre de chose et qu'il y a une implémentation Docker de prévu pour nos projets sur Code#0, voila pourquoi.
-
Le service web (une application qui communiquera par HTTP) servira à traiter les informations en direct donc trier les localisations (qu'on pourra communiquer avec un paquage que j'ai trouvé) et envoyer à chaque utilisateur la liste des profils qu'il peut voir. C'est la seule idée qui m'est venu pour pouvoir récupérer des données de plusieurs utilisateurs en même temps (leurs localisations), les traiter en commun (les trier par localisations), puis en renvoyer à chacun (une liste des utilisateurs que l'appli peut proposer à chacun, en cache en local on pourrait mettre tous les id des déjà vu et les enlever de la liste lorsqu'on la reçoit). Comme la BDD, Docker semble être bien (intégré à Code#0, peut hébergé une appli).
-
La CI/CD est pour nos tests. Après avoir fait plus de recherches (et après avoir fait le schéma...), dans Code#0 c'est Drone qui à l'air d'être fait pour la CI et non pas Docker.
-
L'API Web Spotify sera pour récupérer les musiques en direct.
-
L'ORM fera les requêtes vers la base de données, il y a des outils à utiliser en Dart pour le faire.
-
L'image Docker sera celle sur Code#0 (il faut apprendre à s'en servir).
-
-
Recherche sur comment mener à terme la conception : Listes des liens pour des outils qui me semblent pouvoir être utiles pour notre projet (ça à l'air de correspondre à notre besoin avec un regard EN SURFACE /!\)
-
L'ORM entre un serveur PostegreSQL utilisable en Dart : il semble possible de gérer la connection à une base de données (que l'on va créer), de faire des requêtes sur cette base et de la modifier, tout cela avec un seul outil
-
Package permettant de faire des requêtes HTTP : c'est une présentation de comment utiliser le package avec un exemple, ça nous servira pour le service web qu'on va créer pour gérer les localisations
-
Comment créer une base de données PostegreSQL dans une image Docker : il faudra d'abord comprendre un peu mieux comment marche Docker je pense
-
-
Début du développement des classes : J'ai créé les classes User, Conversation, Message et les ai testé en faisant converser et en affichant la conversation entre des User. Par la suite je me suis rendu compte que ma façon de concevoir le programme était mauvaise : je me plaçais dans le cas où je devais gérer tous les User alors qu'en réalité l'application ne doit en gérer qu'un.
-
Réflexion sur les différentes parties de l'application Flutter en elle-même : définition de ce qui allait vraiment composer notre application. Cela ne portais pas vraiment sur la base de données, l'API, ... mais plutôt sur les différentes classes et/où interfaces dont nous allions avoir besoin (voir diagramme de classes).
-
Renseignement sur fonctionnement de l'API Spotify : ajout requêtes http, création d'un projet API Spotify.
Dorian
-
Création de ticket et organisation du Kanban : J'ai écrit les différents tickets sur Code first pour pouvoir organiser le Kanban, puis nous les avons modifié avec les nouvelles informations du Kanban que Félix et Audric ont changés. J'ai ensuite organiser ces tickets dans le Kanban dans les différentes sections que propose ce tableau.
-
Modification du backlog grâce aux taches du WBS : J'ai réecrit le backlog dans un tableau Exel et j'ai rajouté et enlenvé des tâches en fonction du WBS réalisé par Félix.
-
Réalisation du Gantt : J'ai réalisé le Gantt du projet grâce aux dates et aux tâches du WBS. J'ai réalisé ça grâce à l'application Gantt Project, puis j'ai exporté le résultat en PDF en en PNG.
-
Recherche sur la liaison Spotify : J'ai effectué des recherches sur la liaison entre l'API Web Spotify et le Flutter.
Lucas
-
Redaction dossier : Rédaction de la partie sur les indicateurs de projets
-
Réalisation des premieres pages de connexion en flutter : Page de connexion, inscription et la page d'acceuil finalisé
-
Création de la branche pour travailler sur les vues : création de la branche et configuration d'android studio pour push
-
Recherche sur la navigation etre les pages et boutons flutter: j'ai regardé des tutos et appliqué sur ma brranche pour pouvoir naviguer entre les vues "mainpage" connexion et inscription et ajoutt d'une animation au click sur les boutons de validation
-
Ajout de la navbar j'utilise les widgets fourni par google pour faire une navbar fonctionnel avec des icons personnalisés