CAW1 2016 Projet de Jérémy LASCAUX, Rémi SAUREL et Florent TONNEAU

De Ensiwiki
Aller à : navigation, rechercher
Nyancast logo.png
Titre du projet Nyancast
Cadre Ensimag Projet Web 2A Alternant

Équipe Jérémy LASCAUX Rémi Saurel Florent Tonneau
Encadrants Sébastien Viardot


Sommaire

Présentation générale

Contexte

Dans le cadre notre deuxième année à l'ENSIMAG et du module CAW (applications web) nous avons dû développer une application web. Après moult réflexions nous avons choisi comme sujet un site centré sur la gestion de podcasts (émissions audio/vidéo).

Description du projet

Nyancast (pour (Not) Yet Another Podcast Manager) est un gestionnaire de podcast audio/vidéo. L'objectif est de proposer une interface simple d'utilisation mais efficace afin de permettre la gestion de podcast ainsi que l'écoute et la visualisation de ceux-ci. Un utilisateur peut ainsi effectuer une recherche de podcasts avec la possibilité de s'abonner, de consulter les nouveaux épisodes, ou encore de reprendre la lecture d'un épisode...

Objectifs du projet

De nos jours grâce au développement de l'Internet, de plus en plus de contenu multimédias sont produits chaque jour, aux quatre coins de la toile. Face à ce flux continu d'informations, il devient parfois complexe pour un internaute de gérer manuellement les podcasts qu'il suit... À travers cette application web, nous avons eu la vocation de proposer un service de gestion de podcasts pour faciliter "la vie" des cybernautes, en leur permettant moyennant inscription de retrouver l'ensemble des podcasts qu'ils suivent, à travers une interface moderne et facile à utiliser.

Cahier des charges

NyanCast UC.png

L'application comporte 3 types d'accès : Visiteur, Utilisateur et Administrateur. Le visiteur a des droits très restreint vu qu'il ne peut que consulter les podcasts existants et s'inscrire sur Nyancast. Quand à l'utilisateur connecté, il peut s'abonner aux podcasts, lire des épisodes, suivre son état d'avancement dans les podcasts auquel il est abonné. L'administrateur a les mêmes droits que les deux précédents à l'exception qu'il peut promouvoir des podcasts en les positionnant sur la page d'accueil.

Documentation

Diagramme de classes

Classes.png

Notre modèle de données est composé de 6 classes. Tout d'abord la classe User est constituée d'un identifiant (username) et d'un userType qui peut être soit un administrateur soit un utilisateur simple. Nous stockons également le mot de passe "hashé" ainsi qu'un sel qui est propre à chaque utilisateur, sel qui permet d'augmenter la sécurité du mot de passe. Ensuite, les classes Podcast et Episode nous permettent de sauvegarder les informations qui sont récupérées depuis l'API Itunes ou le flux RSS du podcast pour le cas de la classe Episode. Dans la classe Podcast, nous avons l'id du podcast (itunesId), le titre, l'auteur, deux liens URL dont un vers l'image du podcast (thumbnailURL) et l'autre vers le podcast lui-même. Un podcast est composé de plusieurs épisodes. Les informations de la classe Episode sont le titre, sa description, sa date, sa durée, ainsi que le lien vers le média qui peut être soit un fichier vidéo soit un fichier audio. Un utilisateur peut s'abonner à plusieurs podcasts (à travers la classe Subscription). Dans un soucis d'efficacité, lors d'une inscription à un podcast nous avons choisi de marquer comme vu tous les épisodes antérieurs à la date de souscription du podcast dernier exclu. Cela nous permet de ne pas créer de status de lecture pour ces épisodes. Par contre, pour chaque nouvel épisode présent dans les podcasts souscris par l'utilisateur nous enregistrons un status et une durée (représentée par la classe PlayingStatus). Le status de la classe PlayingStatus est soit PLAYED qui indique que l'épisode a été lu, UNPLAYED dans le cas où l'épisode n'est pas lu, et PLAYING qui spécifie si un épisode est en cours de lecture.

API

La documentation du projet se trouve à l'adresse suivante : nyancast.github.io. Elle a été rédigée à l'aide du langage YAML et de l'environnement Swagger.

Installation

Pré-requis

  • Java >= 1.8
  • Firefox ou Chromium/Chrome qui supporter les balises multimédias HTML5, et disposer des codecs multimédias adaptés
  • Play 1.3.4

Commandes à exécuter sous la racine du projet

  • play dependencies app --sync
  • play run app

Identifiants de test

Par défaut, deux comptes utilisateur peuvent être utilisés :

  • root / toor (administrateur)
  • user / resu (utilisateur standard)

Environnement de développement

Avec l'appui de l'interface de programmation Itunes, et de nombreux outils comme Play 1.3 et autres Framasoft nous avons pu mener à bien notre projet. Ci-dessous la liste exhaustive des outils utilisés.

Technologies utilisées

  • Front-end :
    • Angular 1.6
    • PureCSS : librairie CSS très légère (utilisé pour les boutons et formulaires)
  • Tests :
    • Play/JUnit 4 : Tests back-end
    • Selenium : Tests front-end
    • Gitlab-ci : Intégration continue

Avancement

Tests

Les tests ont été une part intégrante de notre projet et ce dès le début. Nous avons pour cela utilisé une large panoplie d'outils qui nous ont permis d'écrire des tests de qualité rapidement. Nous avons également fait le choix de mettre en place un mécanisme d'intégration continue en amont du développement, et de se tenir tant que possible à écrire nos tests en parallèle des nouvelles fonctionnalités. Ci-dessous l'état actuel de nos tests.

Selenium

Chacun des cas d'utilisation principaux sont couverts par les tests Seleniums sauf ceux qui touchent à la lecture des flux audio.

  • Visiteur
    • Lancement de l'application
    • Recherche de podcast
    • Inscription
  • Utilisateur
    • Connexion
    • Déconnexion
    • S'abonner à un podcast
    • Se désabonner d'un podcast
    • Accéder au nombre d'épisodes non vus d'un podcast
    • Marquer un épisode comme vu
    • Marquer un épisode comme non vu
    • Charger plus d'épisodes
  • Administrateur
    • Promouvoir un podcast
    • Suppression d'une promotion

API

Contrôleurs

Nous avons procédé à différents types de tests sur les contrôleurs de l'application, des tests unitaires ainsi que des tests fonctionnels. Pour les tests unitaires, nous avons fait un test par type de réponse de chaque contrôleur conformément à notre API REST.

  • Exemples :
    • POST /podcast/{id}/subscribe : 200 OK -> 1 test
    • POST /podcast/{id}/subscribe : 400 Bad Request -> 1 test
    • POST /podcast/{id}/subscribe : 401 Unauthorized -> 1 test

Aussi en terme de tests fonctionnels, nous avons élaboré des parcours utilisateurs (application cliente de l'API) dans lesquelles nous testons la conformité des réponses du serveur pour un parcours donné.

  • Exemple :

POST /user/login : 200 OK
GET /user/subscriptions : 204 No Content
POST /podcast/{id}/subscribe : 200 OK
GET /user/subscriptions : 200 OK
POST /podcast/{id}/unsubscribe : 200 OK
GET /user/subscriptions : 204 No Content

Modèle

Au niveau du Modèle, des tests unitaires sont présents sur les méthodes qui ne sont pas en lien avec la base de données (ou au moins très peu en lien).

Exécution des tests

L'exécution peut s’opérer grâce à la commande "./autotest.sh" néanmoins seuls les tests de l'API seront lancés dû à des problèmes de lancements des tests sélénium avec FirePhoque. Pour lancer tous les types de tests dans votre navigateur :

Fonctionnalités

Nous avons accordé une grande importante aux fonctionnalités "utilisateurs inscrits". Néanmoins, nous n'avons nullement négligé la prise en compte des autres types -administrateurs et visiteur- qui ont quelques fonctionnalités propres. Malheureusement, toutes les fonctionnalités (non vitales) n'ont pas été implémentées. De nombreuses améliorations sont envisageables et sont énumérées plus bas (liste non exhaustive).

Visiteur non inscrit

Recherche d'un podcast

100 %

La recherche de podcasts s'appuie sur l'API Itunes Store, qui nous permet de bénéficier des résultats de la base de données "de référence" en matière de podcasts. Les résultats obtenus de cette API sont mis en cache, afin de limiter le nombre d'appels à Itunes pour des requêtes similaires.

Consulter la description d'un podcast

100 %

Inscription en tant qu'utilisateur

90 %

Les fonctionnalités basiques de gestion d'utilisateurs ont été implémentés (inscription avec couple pseudo/mot de passe). Dans le cadre d'une application Web mise en production, il serait nécessaire de rajouter certaines fonctionnalités, tels que la modification de mot de passe, un mécanisme de réinitialisation de mot de passe oublié, l'inscription par adresse mail avec lien de confirmation, ou encore la protection contre les attaques par force brute sur notre formulaire de login.

Utilisateur inscrit

Connexion

100 %

S'abonner à un Podcast

100 %

L'abonnement à un podcast permet à un utilisateur de suivre son avancement dans la lecture des différents épisodes d'un podcast.

Se désabonner d'un Podcast

100 %

Le désabonnement supprime toutes les informations associées à l'abonnement (état et position de lectures notamment), ainsi côté front-end une confirmation est demandée avant d’exécuter la requête.

Suivi des abonnements

100 %

La page de suivi des abonnements permet à un utilisateur de retrouver l'ensemble de ses podcasts suivis, ainsi que le nombre d'épisodes non lus pour chacun.

Lire des épisodes

100 %

La lecture est gérée entièrement du côté front-end, où le navigateur, qui doit être compatible avec les balises multimédias HTML5, et disposer des codecs multimédias adaptés, s'occupe de charger le flux audio dont l'URL est fournie par le back-end.

Sauvegarde de l'état d'avancement dans la lecture d'un épisode

100 %

Côté front-end, si l'utilisateur est abonné au podcast qu'il écoute, le lecteur audio signale alors au back-end l'avancement de la lecture. Techniquement, cela se traduit par une requête AJAX toutes les 10 secondes pour mettre à jour la position dans la lecture dans l'épisode.

Suivi de l'état de lecture des épisodes

100 %

Chaque épisode d'un podcast auquel l'utilisateur est abonné peut être dans un de ces 3 états : lu, non-lu, en cours de lecture (avec indication de la dernière position connue dans l'épisode). Par défaut à l'abonnement, le dernier épisode disponible est non-lu, le reste est lu. A l'arrivée de nouveaux épisodes, ceux-ci sont marqués comme non-lus par le back-end.

Lecture des flux audios

100 %

Lecture des flux vidéos

0 %

La lecture des flux vidéos nécessite des traitements spécifiques, notamment en terme de design front-end. À l'heure actuelle notre application ne permet que de lire le son d'un podcast vidéo, sans en afficher l'image.

Mise en place de playlist

0 %

Gestion de followers/following

0 %

Administrateur

Promouvoir des podcasts

100 %

Un administrateur peut mettre en avant jusqu'à 4 podcasts sur la page d'accueil du site.

Suppression des promotions de podcasts

100 %

Suppression d'un utilisateur

0 %

Statistiques sur les abonnements des utilisateurs

0 %

Envoyer des invitations par mail

0 %

Fonctionnalités techniques

Mise en cache des requêtes API Itunes

100 %

Rafraîchissement des flux

42 %

Mise en place d'un lecteur audio/vidéo personnalisé

0 %

Screencast

Fichier:Nyanscreencast.mp4

Retour d'expériences

Ce projet fut l'occasion de découvrir une grande diversité d'outils axés sur le web. Nous pensons évidemment à Play qui a été agréable à utiliser, mais aussi à Sélénium qui s'avère assez déroutant au début, mais qui devient très vite indispensable pour les tests "niveau utilisateur". Dans notre choix de réaliser un client riche, nous nous somme tourné vers le framework AngularJS qui nous a permis de faire du Two-way binding (correspondance des données entre le modèle et la vue). Ici encore, le retour d'utilisation a été bigrement convaincant. Enfin, nous avons eu plaisir à réaliser ce projet et nous en garderons de bons souvenirs.

Sources