CAW1 2017 Projet de Nils BURLAT et Pierre-Antoine PORTE

De Ensiwiki
Aller à : navigation, rechercher
Project schedule.png
Titre du projet Ensilive
Cadre Appli web

Équipe Nils Burlat Pierre-Antoine Porte
Encadrants Sebastien Viardot


Présentation du projet

Website : https://ensilive.herokuapp.com/static/index.html Git : https://github.com/portepa/websimag (private) Trello-like : https://github.com/portepa/websimag/projects/1 (private)

Une vidéo présentant le projet est disponible à ce lien : https://drive.google.com/open?id=0B6YhLojff-3qM19GbGhLeFFuYWs Des comptes de tests sont déjà créés et disponibles pour des tests en production :

  • Administrateur
    • root@root.fr / azerty123
  • Pierre-Antoine Porte
    • pierre-antoine@jaaccelere.com / azerty123
  • Nils Burlat
    • nils@jaaccelere.com / azerty123
  • Sebastien Viardot
    • sebastien@viardot.fr / azerty123

Description générale

Ce projet s'inscrit dans la continuité des cours de construction d'application WEB proposée par l'Ensimag aux étudiants de deuxième année alternants. Nous allons créer une application de notre choix, après avoir défini en binôme un cahier des charges et une organisation de travail.

Description du projet

L'application Ensilive vous permet de prendre des photos depuis la webcam de votre ordinateur, et de les partager aux autres utilisateurs membres de l'application. Dans votre galerie personnelle, toutes les photos que vous avez envoyées ou reçues sont recensées, pour vous permettre de les consulter à nouveau. Attention aux petits malins qui enverraient n'importe quoi : les administrateurs du site peuvent à tout moment supprimer les photos qui ne respectent pas les règles d'usage !

Cahier des charges

Le projet devra comporter les éléments suivants :

  • Utilisation d'un framework : Django utilisant le patron Modèle-Vue-Contrôleur
  • Gestion des rôles avec des utilisateurs différents ayant des droits et des rôles différenciés
  • Site adapté à plusieurs terminaux
  • Mise en place de jeux de tests unitaires
  • Mise en place de jeux de tests fonctionnels
  • Utilisation de l'API Amazon S3

Spécifications

Cas d'utilisation

Voici les différents cas d'utilisation de l'application :

  • Créer des comptes
  • Se connecter
  • Se déconnecter
  • Membres :
    • Prendre une photo
    • Envoyer une photo à un autre membre
    • Consulter les photos envoyées
    • Consulter les photo reçues
  • Administrateurs :
    • Posséder les mêmes droits qu'un membre
    • Visualiser toutes les photos envoyées par les membres
    • Supprimer n'importe quelle photo

Diagramme de classes

Uml-ensilive.png

Notre applications gère des utilisateurs (User). Ces derniers peuvent être administrateurs ou non. Nous utilisons principalement leur adresse email (couplé à leur mot de passe) pour les connecter, et leurs noms et prénoms pour les interactions avec les autres utilisateurs. Les photos (Picture) sont envoyées par des utilisateurs vers d'autres utilisateurs. Chaque photo possède donc un émetteur et un récepteur, pour lesquels nous stockons l'identifiant, le nom et le prénom. Une photo possède également et bien évidemment une URL, et un titre qui la définit.

Réalisation

Environnement

L'architecture a été réalisée de telle manière à ce que Django serve statiquement des fichiers HTML. De la sorte, avec un front-end Angular, nous pouvons utiliser l'API que notre application Django lui met à disposition. Nous avons tout d'abord utilisé Django, sans Django-Rest, cependant de nombreuses fonctionnalités présentes dans Django-Rest (parsing des entités notamment, affichage des entités, authentification avec token (authentification sans état, dites stateless)...) et quelques déboires avec Django nous ont fait recommencer le développement de l'application. Django, comme toute application REST qui se tient, n'est pas fait pour servir des fichiers statiques. Bien que parfois très simple en Java, PHP ou NodeJS, il était très compliqué de faire comprendre à Django de servir des fichiers statiquement. Un autre problème, que nous n'avons malheureusement pas pu régler par faute de temps, vis à vis de ces fichiers front-end statiques est le build. En effet, nous avons utilisé Grunt (un task runner javascript) pour réduire la taille des fichiers, rajouter des variables d'environnement, concaténer les fichiers de scripts en un seul, injecter les dépendances... Cependant, ce build devait également se faire en production, sur Heroku. Hors dans ce qu'Heroku appelle un "buildpack", qui est l'environnement ou le build va se faire, le buildpack Python ne contenait logiquement pas : Npm, Bower ou encore Grunt ce qui rendait ce build impossible.

Nous avons donc envoyé en production les modules Bower et Npm et nous buildons les sources de front-end avant de les commiter. Cela est vraiment une situation pas adapté. Nous aurions préféré faire un bucket S3 statique avec les fichiers sources à l'intérieur, qui pointait suite à un build bien géré avec Grunt (nous n'avons pas réussi à rajouter un fichier de config avec l'URL de l'api différente en développement (http://localhost:8000) de la production (https://ensilive.herokuapp.com)).

Utilisation d'un WebService

Puisque notre application enregistre des photos, il nous fallait les stocker. Nous avons donc décidé d'utiliser l'API d'Amazon S3 pour cela. Lorsqu'un utilisateur veut envoyer sa photo, il fait d'abord une requête sur l'api /signed-request. Cette route fait elle-même une requête auprès d'Amazon S3 pour récupérer une clé de signature, nécessaire pour envoyer un fichier image dans le bucket S3. Le côté front-end peut ensuite récupérer cette clé et envoyer l'image lui-même : cela permet de ne pas envoyer une image lourd jusqu'à notre serveur puis de la renvoyer ensuite vers le S3. Lorsque l'image est envoyée au S3, nous créons alors un objet Picture supplémentaire dans notre application.

Tests

Les tests de l'API ont tous été écrits (tests de réussites et tests d'échecs). On peut les exécuter avec la commande : python manage.py test. Des tests Selenium ont également été écrits, mais très peu car de gros problèmes sont survenus dans notre environnement de travail ce qui a compliqué grandement leur mise en place et leur exécution. Nous avons également mis en place une intégration continue : à chaque fois qu'un commit a lieu, les tests sont exécutés sur une plateforme spécifique : https://app.codeship.com. Un mail nous est envoyé en cas d'erreur !