created separate jury blanc folder
This commit is contained in:
parent
cd747c3271
commit
127a28f495
4 changed files with 123 additions and 0 deletions
Binary file not shown.
Binary file not shown.
123
jury blanc/jury blanc
Normal file
123
jury blanc/jury blanc
Normal file
|
@ -0,0 +1,123 @@
|
|||
Le projet que je vais vous présenter aujourd'hui a été fait dans le cadre de ma formation avec la Wild Code School. Sur ce projet, nous avons été 4. Nous avons choisi d'appeler notre groupe et projet oros, qui veut dire montagne en grec ancien. Comme on a créé une application pour louer des biens pour les sports de montagne, cela avait un sens pour nous.
|
||||
|
||||
Lorsqu'on a commencé à travailler la conception de notre projet, on a decidé de commencer tout d'abord avec la merise. Pour nous c'était le meilleur moyen de commencer à conceptualiser notre application et surtout l'organisation de nos données dans notre système de gestion de base de données.
|
||||
|
||||
La première chose qu'on a trouvé utile de faire, c'était de faire un brainstorming et créer des phrases qui aident à imaginer comment fonctionner notre application.
|
||||
|
||||
Un utilisateur se connecte à au minimum 1 session et au maximum 1 session.
|
||||
La session est faite par au minimum 1 utilisateur et au maximum 1 utilisateur.
|
||||
Un utilisateur fait au minimum 1 réservation mais peut en faire plusieurs.
|
||||
La réservation est faite par au minimum 1 utilisateur et au maximum 1 utilisateur.
|
||||
La réservation contient au moins un matérial et au maximum plusieurs matériaux.
|
||||
Le matérial peut recevoir 0 réservations et au maximum plusieurs réservations.
|
||||
Chaque matérial appartient à 1 catégorie.
|
||||
Chaque catégorie peut contenir 0 matériaux et au maximum plusieurs matériaux.
|
||||
|
||||
Avec ceci, on a pu créer une phrase qui résume nos idées, et on peut créer le modèle conceptuel de données selon cette phrases.
|
||||
|
||||
La phrase qui résume : Un ou plusieurs utilisateurs envoient une réservation qui contient du matériel, qui appartient à 1 catégorie, et elle contient la date du début, la date de la fin, et le user id.
|
||||
|
||||
Après avoir créer le modèle conceptuel des données, nous avons procédé à créer le modèle logique des données. On a enlévé le cardinal le plus petit chaque fois, et en faisant ça, on s'est rendu compte qu'on allait avoir un tableau Many to Many, alors afin d'éviter ce problème, nous avons créé un tableau intermédiaire, reserved_material, qui contient les ids de matérial et de la réservation, ainsi que la quantité réservée, et le prix de la réservation. Non seulement ce tableau aide à faire intermédiaire, mais c'est un récap qui peut être partagé avec l'utilisateur une fois leur réservation est finalisée.
|
||||
|
||||
Une fois le modèle logique de données a été créé, on a procédé avec le modèle physique de données. Pour ce modèle, c'était important de réflechir quel type de données pour chaque colonne, et chaque fois qu'une clé étrangère sera utilisé, on l'a indiqué avec FK pour foreign key.
|
||||
|
||||
Une fois la merise a été terminée, nous avons procédé avec l'UML, ou Unified Modeling Language / Langage de Modélisation Unifié. Comme il y a énormément de diagrammes UML, nous avons choisi de nous concentrer sur deux - le diagramme de classe, et le diagramme de cas d'utilisation.
|
||||
|
||||
Pour le diagramme de classe, nous nous reposons sur ces idées :
|
||||
|
||||
Nous cherchons à développer un système qui gère la location des matériaux à notre magasin.
|
||||
Ce magasin contient des matériaux.
|
||||
Un matérial est caracterisé par son nom, sa description, son image, son stock initial, son prix.
|
||||
Un matérial est attribué à au moins une catégorie, qui a son nom.
|
||||
Pour louer un matérial, un utilisateur doit créer un compte sur le site, avec son prénom, nom de famille, son email et un mot de passe.
|
||||
Chaque fois qu'un utilisateur se connecte à notre site, cela crée une session, où nous pouvons garder les information de leur caddy dans un fichier JSON.
|
||||
|
||||
Multiplicités
|
||||
Une réservation est relié à au minimum et au maximum 1 utilisateur, alors 1
|
||||
Un user est relié à au minimum et au maximum 1 session, alors 1
|
||||
Chaque réservation doit avoir au moins un matérial et au maximum plusieurs, alors 1..*
|
||||
ReservedMaterial peut avoir plusieurs matériaux, mais au moins 1, alors 1..*
|
||||
Un matérial peut être disponible en plusieurs exemplaires, mais au moins 1, alors 1..*
|
||||
Chaque matérial appartient à 1 catégorie, alors 1
|
||||
|
||||
Portée
|
||||
On peut avoir plusieurs types de portées pour nos attributs : public, private, protected, par exemple. On a décidé de garder tout public à part les mots de passe pour un utilisateur, qui sont privés, pour les raisons de sécurité. De cette façon, les autres classes ne pourront pas y accèder, et cela protège ces données.
|
||||
|
||||
|
||||
En plus de montrer les liens entre chaque Entity, on a aussi profité de notre diagramme de classe pour imaginer des services. Dans le slide, on voit bien comment on est censés créer chacun des services, en utilisant User comme exemple, et le code que nous avons créé pour create user. On a aussi créé un type InputRegister pour user afin de regrouper les infos nécessaires pour un User.
|
||||
|
||||
Le dernier diagramme sur lequel nous avons travaillé avant de nous mettre à coder, c'était le diagramme de cas d'utilisation. Après beaucoup de discussion, on voulait qu'un simple visiteur puisse regarder la catalogue, mais si la personne veut faire une réservation, il faut créer un compte et se logger. Alors c'est pour cela que le visiteur ainsi que le client loggué ait accès pour voir les matériaux sur le site. L'admin, cependant, a des droits qu'un client n'a pas - par exemple, il peut créer, mettre à jour, et supprimer des matériaux si nécessaire.
|
||||
|
||||
Pour conclure aujourd'hui, je vous présente un schéma de notre application.
|
||||
Le schéma commence en bas, avec le développeur, qui fait des commits avec git. Une fois commité et vérifié, le dév push sur main, ou fait un pull request. Cela déclenche les actions github, et les tests mis en place check si tout va bien. Si les tests passent, les nouvelles images sont publiées sur dockerhub, et puis on peut déclencher un webhook ou faire un fetch and deploy afin de récupérer tout ce qu'il faut pour le serveur. Côté client, notre projet utilise Next avec React, ainsi que material UI. Sur le serveur, on utilise node et express, notre BDD utilise postgreSQL, et finalement pour faire les requêtes on utilise graphQL. Notre projet est écrit en typescript, qui est transpilé en Javascript.
|
||||
|
||||
maximales mcd
|
||||
mcd - pas de FK - il y en avait pas ?
|
||||
|
||||
mld - enlever des cardinalités - OK
|
||||
category id dans une autre couleur - OK
|
||||
diagramme de séquence
|
||||
montrer un extrait de diagramme de classe
|
||||
|
||||
|
||||
|
||||
|
||||
sécurité
|
||||
|
||||
type orm ça évite les injections SQL _
|
||||
jsx qui évite les attaques XSS _
|
||||
hachage de mot de passe _ argon2
|
||||
express middleware
|
||||
|
||||
token
|
||||
cookie httponly qui évite les attaques XSS protection côté client
|
||||
cors définissant les
|
||||
middleware
|
||||
protocol https
|
||||
caddy certificat
|
||||
|
||||
jwt
|
||||
|
||||
Dans GraphQL qu'est-ce qu'un resolver ?
|
||||
fonction ou methode qui résout une valeur pour un type ou field dans un schema. c'est ce qui connecte les fields, les queries, les mutations et souscriptions à leurs sources de données et les micro-services
|
||||
fonction qui récupère les données
|
||||
***Les resolvers servent à faire le mapping entre le schéma et le code, pour dire, par exemple, telle requête va exécuter telle logique.***
|
||||
|
||||
Qu'est-ce que l'UI et l'UX - définir les deux
|
||||
UI = user interface - interaction entre l'utilisateur et le système
|
||||
UX = user experience - l'expérience général d'un produit ou site web - globalité
|
||||
***designer UI s'occupe du lient entre la machine et l'homme. il est responsable de la conception générale de l'interace, de la clarté de la navication... voir screenshot***
|
||||
|
||||
Qu'est-ce qu'une requête HTTP et de quoi est-elle constituée ?
|
||||
regarde screenshot
|
||||
|
||||
A quel types d'informations les codes de réponses suivants font-il références ?
|
||||
10x - information ?
|
||||
20x - succès
|
||||
30x -
|
||||
40x - erreur client
|
||||
50x - erreur serveur
|
||||
|
||||
Qu'est-ce que l'intégration continue (CI) ?
|
||||
Pratique devops qui automatise l'intégration du changement de code de multiple contributeurs à un seul projet de développement. Cela permet
|
||||
|
||||
***methode de dev logiciel devops avec laquelle les devs integrent regulirement leur modifications de code à un référentiel centralisé, suite à quoi des opérations de création et de test sont automatiquement menées. L'intégration continue désigne souvent l'étape de création ou d'intégration du processus de publication de logiciel, et implique un aspect automatisé et un aspect culturel (apprendre à intégrer fréquemment). Les principaux (voir capture d'écran)
|
||||
|
||||
Qu'est-ce que le déploiment continu (CD) ?
|
||||
Pratique devops
|
||||
sert à automatiser la mise en production
|
||||
|
||||
Citez les verbes HTTP utilisés dans une API REST et à quoi ils servent ?
|
||||
Get - récupérer les infos
|
||||
Post - créer les infos
|
||||
Put - mettre à jour info existent en entière
|
||||
Patch - mettre à jour info existante en partie
|
||||
Delete - supprimer
|
||||
|
||||
Qu'est-ce que l'OWASP ?
|
||||
|
||||
|
||||
C'est quoi un design pattern ?
|
||||
form réutilisable d'une solution à un problème de conception logicielle
|
||||
- créationnelle (singleton)
|
||||
- structurelle
|
BIN
jury blanc/jury blanc.odp
Normal file
BIN
jury blanc/jury blanc.odp
Normal file
Binary file not shown.
Loading…
Reference in a new issue