Compare commits
6 commits
66ca26e3e3
...
bc6be314e5
Author | SHA1 | Date | |
---|---|---|---|
bc6be314e5 | |||
6f0b43dfea | |||
b9551a956e | |||
127a28f495 | |||
cd747c3271 | |||
46ea6a0e78 |
1
dossier de projet/.gitignore
vendored
Normal file
|
@ -0,0 +1 @@
|
|||
/*.pdf
|
20
dossier de projet/build.sh
Executable file
|
@ -0,0 +1,20 @@
|
|||
#! /usr/bin/env sh
|
||||
|
||||
main() {
|
||||
local file="$(readlink --canonicalize-existing "${0}")"
|
||||
local root="$(dirname "${file}")"
|
||||
local input="${root}/main.md"
|
||||
local output="${root}/main.pdf"
|
||||
pandoc \
|
||||
"${input}" \
|
||||
--highlight-style "tango" \
|
||||
--output "${output}" \
|
||||
--pdf-engine "xelatex" \
|
||||
\
|
||||
&& \
|
||||
evince \
|
||||
"${output}" \
|
||||
&
|
||||
}
|
||||
|
||||
main
|
BIN
dossier de projet/dossier de projet.odt
Normal file
BIN
dossier de projet/images/CORS.png
Normal file
After Width: | Height: | Size: 126 KiB |
BIN
dossier de projet/images/Input Register.jpg
Normal file
After Width: | Height: | Size: 274 KiB |
BIN
dossier de projet/images/Input Register.png
Normal file
After Width: | Height: | Size: 110 KiB |
BIN
dossier de projet/images/MCD.jpg
Normal file
After Width: | Height: | Size: 270 KiB |
BIN
dossier de projet/images/MLD.jpg
Normal file
After Width: | Height: | Size: 242 KiB |
BIN
dossier de projet/images/MPD.jpg
Normal file
After Width: | Height: | Size: 302 KiB |
BIN
dossier de projet/images/MainNav.png
Normal file
After Width: | Height: | Size: 349 KiB |
BIN
dossier de projet/images/MyContext.png
Normal file
After Width: | Height: | Size: 50 KiB |
BIN
dossier de projet/images/Reservation User Session.jpg
Normal file
After Width: | Height: | Size: 310 KiB |
BIN
dossier de projet/images/Screenshot from 2024-10-11 07-30-58.png
Normal file
After Width: | Height: | Size: 515 KiB |
BIN
dossier de projet/images/User.jpg
Normal file
After Width: | Height: | Size: 362 KiB |
BIN
dossier de projet/images/_app tsx1.png
Normal file
After Width: | Height: | Size: 535 KiB |
BIN
dossier de projet/images/_app tsx2.png
Normal file
After Width: | Height: | Size: 200 KiB |
BIN
dossier de projet/images/_document tsx.png
Normal file
After Width: | Height: | Size: 314 KiB |
BIN
dossier de projet/images/accueil et recherche.png
Normal file
After Width: | Height: | Size: 102 KiB |
BIN
dossier de projet/images/argon2.png
Normal file
After Width: | Height: | Size: 102 KiB |
BIN
dossier de projet/images/auth checker.png
Normal file
After Width: | Height: | Size: 349 KiB |
BIN
dossier de projet/images/auth query.png
Normal file
After Width: | Height: | Size: 154 KiB |
BIN
dossier de projet/images/autocomplete.png
Normal file
After Width: | Height: | Size: 141 KiB |
BIN
dossier de projet/images/box modal.png
Normal file
After Width: | Height: | Size: 254 KiB |
BIN
dossier de projet/images/category button.png
Normal file
After Width: | Height: | Size: 230 KiB |
BIN
dossier de projet/images/category entity1.png
Normal file
After Width: | Height: | Size: 356 KiB |
BIN
dossier de projet/images/category entity2.png
Normal file
After Width: | Height: | Size: 244 KiB |
BIN
dossier de projet/images/category id tsx 3.png
Normal file
After Width: | Height: | Size: 182 KiB |
BIN
dossier de projet/images/category id tsx1.png
Normal file
After Width: | Height: | Size: 509 KiB |
BIN
dossier de projet/images/category id tsx2.png
Normal file
After Width: | Height: | Size: 291 KiB |
BIN
dossier de projet/images/category query.png
Normal file
After Width: | Height: | Size: 201 KiB |
BIN
dossier de projet/images/category resolver1.png
Normal file
After Width: | Height: | Size: 537 KiB |
BIN
dossier de projet/images/category resolver2.png
Normal file
After Width: | Height: | Size: 275 KiB |
BIN
dossier de projet/images/category service1.png
Normal file
After Width: | Height: | Size: 388 KiB |
BIN
dossier de projet/images/category service2.png
Normal file
After Width: | Height: | Size: 414 KiB |
BIN
dossier de projet/images/category service3.png
Normal file
After Width: | Height: | Size: 24 KiB |
BIN
dossier de projet/images/class diagram.jpg
Normal file
After Width: | Height: | Size: 426 KiB |
BIN
dossier de projet/images/connexion.png
Normal file
After Width: | Height: | Size: 60 KiB |
BIN
dossier de projet/images/create user.png
Normal file
After Width: | Height: | Size: 53 KiB |
BIN
dossier de projet/images/datasource.png
Normal file
After Width: | Height: | Size: 298 KiB |
BIN
dossier de projet/images/fetch and deploy.png
Normal file
After Width: | Height: | Size: 103 KiB |
BIN
dossier de projet/images/idk.png
Normal file
After Width: | Height: | Size: 177 KiB |
BIN
dossier de projet/images/index ts auth checker.png
Normal file
After Width: | Height: | Size: 266 KiB |
BIN
dossier de projet/images/index tsx.png
Normal file
After Width: | Height: | Size: 122 KiB |
BIN
dossier de projet/images/isHomePage main nav.png
Normal file
After Width: | Height: | Size: 233 KiB |
BIN
dossier de projet/images/jest config.png
Normal file
After Width: | Height: | Size: 46 KiB |
BIN
dossier de projet/images/login tsx1.png
Normal file
After Width: | Height: | Size: 478 KiB |
BIN
dossier de projet/images/login tsx2.png
Normal file
After Width: | Height: | Size: 308 KiB |
BIN
dossier de projet/images/login tsx3.png
Normal file
After Width: | Height: | Size: 63 KiB |
BIN
dossier de projet/images/material test1.png
Normal file
After Width: | Height: | Size: 396 KiB |
BIN
dossier de projet/images/material test2.png
Normal file
After Width: | Height: | Size: 166 KiB |
BIN
dossier de projet/images/material test3.png
Normal file
After Width: | Height: | Size: 308 KiB |
BIN
dossier de projet/images/material test4.png
Normal file
After Width: | Height: | Size: 126 KiB |
BIN
dossier de projet/images/middleware.png
Normal file
After Width: | Height: | Size: 364 KiB |
BIN
dossier de projet/images/mockup accueil.png
Normal file
After Width: | Height: | Size: 665 KiB |
BIN
dossier de projet/images/mockup admin.png
Normal file
After Width: | Height: | Size: 352 KiB |
BIN
dossier de projet/images/mui.png
Normal file
After Width: | Height: | Size: 449 KiB |
BIN
dossier de projet/images/navbar test1.png
Normal file
After Width: | Height: | Size: 345 KiB |
BIN
dossier de projet/images/navbar test2.png
Normal file
After Width: | Height: | Size: 211 KiB |
BIN
dossier de projet/images/navbar test3.png
Normal file
After Width: | Height: | Size: 120 KiB |
BIN
dossier de projet/images/router main nav.png
Normal file
After Width: | Height: | Size: 364 KiB |
BIN
dossier de projet/images/schema.jpg
Normal file
After Width: | Height: | Size: 345 KiB |
BIN
dossier de projet/images/sequence diagram.jpg
Normal file
After Width: | Height: | Size: 342 KiB |
BIN
dossier de projet/images/style mock js.png
Normal file
After Width: | Height: | Size: 30 KiB |
BIN
dossier de projet/images/test link MainNav.png
Normal file
After Width: | Height: | Size: 110 KiB |
BIN
dossier de projet/images/trello.png
Normal file
After Width: | Height: | Size: 671 KiB |
Before Width: | Height: | Size: 110 KiB After Width: | Height: | Size: 110 KiB |
BIN
dossier de projet/images/user service.jpg
Normal file
After Width: | Height: | Size: 292 KiB |
BIN
dossier de projet/images/workflow back.png
Normal file
After Width: | Height: | Size: 285 KiB |
BIN
dossier de projet/images/workflow front.png
Normal file
After Width: | Height: | Size: 284 KiB |
1945
dossier de projet/main.md
Normal file
BIN
exemples/Dossier Projet Leopold.pdf
Normal file
BIN
exemples/Projet CDA Lucie Chevanche Sept 2024.pdf
Normal file
BIN
images/MCD.jpg
Before Width: | Height: | Size: 66 KiB |
BIN
images/MLD.jpg
Before Width: | Height: | Size: 80 KiB |
BIN
images/MPD.jpg
Before Width: | Height: | Size: 119 KiB |
Before Width: | Height: | Size: 127 KiB |
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
|