doc: add start of CP 8 DWWM documentation
This commit is contained in:
parent
52c964b388
commit
bd926d0c29
41
app/components/common/Mermaid.tsx
Normal file
41
app/components/common/Mermaid.tsx
Normal file
@ -0,0 +1,41 @@
|
||||
import MermaidRenderer from "react-mermaid2";
|
||||
|
||||
type MermaidProps = {
|
||||
path: string;
|
||||
};
|
||||
|
||||
export function Mermaid(props: MermaidProps) {
|
||||
return (
|
||||
<MermaidRenderer
|
||||
chart={`
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
|
||||
box rgba(139,92,246,.1) Navigateur
|
||||
actor Utilisateur
|
||||
end
|
||||
|
||||
box rgba(139,92,246,.1) Serveur
|
||||
participant Routeur
|
||||
participant Contrôleur
|
||||
participant Modèle
|
||||
participant Vue
|
||||
end
|
||||
|
||||
participant Base de données
|
||||
|
||||
Utilisateur->>Routeur: Je veux voir la page d'accueil
|
||||
Routeur->>Contrôleur: Appelle la méthode \`home\`
|
||||
alt Si des données sont nécessaires
|
||||
Contrôleur->>Modèle: Demande les données
|
||||
Modèle->>Base de données: Récupère les données
|
||||
Base de données-->>Modèle: Retourne les données
|
||||
Modèle-->>Contrôleur: Retourne les données
|
||||
end
|
||||
Contrôleur->>Vue: Demande le HTML
|
||||
Vue-->>Contrôleur: Retourne le HTML généré
|
||||
Contrôleur->>Utilisateur: Retourne le HTML généré
|
||||
`}
|
||||
/>
|
||||
);
|
||||
}
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Activité Type 1 - Développer la partie front-end d'une application web ou web mobile sécurisée
|
||||
description: Synthèse et explications des attentes relatives à l'activité type 1 du titre professionnel DWWM (01280m04).
|
||||
description: Synthèse et explications des attentes relatives à l'activité type 1 du titre professionnel Développeur Web et Web Mobile (DWWM-01280m04).
|
||||
tags: [DWWM]
|
||||
---
|
||||
|
||||
|
||||
@ -6,48 +6,124 @@ tags: [DWWM]
|
||||
|
||||
## 📚 Références
|
||||
|
||||
- REAC _(mise à jour du 02/07/2024)_, pages 15 et 16
|
||||
- RE _(mise à jour du 02/07/2024)_, page 9
|
||||
- REAC _(mise à jour du 02/07/2024)_, pages 23 et 24
|
||||
- RE _(mise à jour du 02/07/2024)_, page 11
|
||||
|
||||
## 📋 En résumé
|
||||
|
||||
Ce qui est attendu de ta part, c'est d'expliquer **comment** on peut installer et configurer les prérequis pour exécuter ton projet.
|
||||
Le front-end : c'est **fini** !
|
||||
Mais avant de nous attaquer au back-end d'un point de vue code, on va voir ce qui est attendu dans cette CP qui parle de la mise en place d'une base de données relationnelle.
|
||||
|
||||
Tu as utilisé un framework PHP et React en front ?
|
||||
Tu devras alors expliquer comment installer PHP, Composer, Node.js, npm _(ou autre gestionnaire de dépendances Node)_ et les autres dépendances nécessaires à ton projet comme la base de données !
|
||||
{% callout type="question" title="Mais attend ! J'ai juste une base de données non relationnelle à mettre en place, c'est bon ?" %}
|
||||
J'aurai aimé te dire que oui, mais ça va être un poil trop léger pour cette compétence...
|
||||
Mais garde sous la main ta base de données non relationnelles
|
||||
pour la prochaine compétence, ça te servira 😉
|
||||
{% /callout %}
|
||||
|
||||
Et pour te donner un ordre d'idée, voici ce que ça peut donner :
|
||||
## 🎨 Modélisation de la base de données
|
||||
|
||||
- Versionning _(Git, SVN, ...)_
|
||||
- IDE ou éditeur de code _(Visual Studio Code, PhpStorm, ...)_
|
||||
- Langages/runtimes _(PHP, Node.js, ...)_
|
||||
- Gestionnaires de dépendances _(Composer, npm, ...)_
|
||||
- Serveurs web _(Apache, Nginx, ...)_
|
||||
- Base de données _(MySQL, PostgreSQL, ...)_
|
||||
- DevOps _(Docker, Vagrant, ...)_
|
||||
- etc.
|
||||
Commençons par le commencement : **comment créer une base de données relationnelle ?**
|
||||
|
||||
Tu l'as compris, c'est vaste !
|
||||
Mais heureusement, tu dois uniquement expliquer comment installer et configurer les outils que tu as utilisés pour ton projet.
|
||||
Il y a pléthore de possibilités, mais ici on va s'attarder sur une méthodologie française _(cocorico 🐓)_ qui est la méthode **Merise**.
|
||||
On va se baser sur différents schémas issus de cette méthode pour créer notre base de données relationnelle, à savoir :
|
||||
|
||||
Si tu fais un projet Laravel et React, pas besoin d'expliquer comment installer et configurer Ruby et Java, par exemple 😉
|
||||
1. Le **dictionnaire des données** : qui va recenser toutes les données que l'on va stocker par la suite dans notre base de données
|
||||
2. Le **MCD** _(Modèle Conceptuel des Données)_ : qui va représenter les données et leurs relations, sous la forme d'entités et d'associations dans un schéma graphique
|
||||
3. Le **MLD** _(Modèle Logique des Données)_ : qui va représenter les données sous forme de tables et de relations, dans un schéma graphique
|
||||
4. Le **MRD** _(Modèle Relationnel des Données)_ : qui va représenter les mêmes informations que le MLD, mais cette fois-ci en format texte
|
||||
5. Le **MPD** _(Modèle Physique des Données)_ : qui va représenter les données sous forme de tables et de relations, en intégrant les types de données et les contraintes
|
||||
|
||||
{% callout type="note" title="Utilisation de XAMPP, WAMP, MAMP, LAMP, Laragon etc." %}
|
||||
Tu remarqueras que j'y ai indiqué un ordre dans la liste ci-dessus.
|
||||
Si je peux te donner un indice : ce n'est pas pour rien que c'est une liste ordonnée 😉
|
||||
|
||||
Si tu utilises un logiciel comme XAMPP, WAMP, MAMP, LAMP, Laragal etc., tu as évidemment le droit de le mentionner dans ta présentation et dossier de projet.
|
||||
Donc si tu réalises un dictionnaire de données après avoir fait ton MPD, c'est que tu n'as pas compris l'objectif du dictionnaire de données ! _(par exemple)_
|
||||
|
||||
Toutefois, il est préférable que tu saches expliquer comment installer et configurer les éléments nécessaires de manières individuelles.
|
||||
Si tu souhaites en savoir plus sur la méthode Merise, je t'invite à lire les articles dédiés sur le Memento.
|
||||
Voici un lien vers l'introduction de la méthode Merise !
|
||||
|
||||
{% quick-link
|
||||
title="Introduction à Merise"
|
||||
href="/docs/merise/"
|
||||
description="Parlons un peu de Merise, la fameuse méthodologie de modélisation pour la conception de bases de données."
|
||||
icon="presets"
|
||||
/%}
|
||||
|
||||
## 💾 Sauvegardes de la base de données
|
||||
|
||||
C'est bien beau de créer une base de données, mais si on ne la sauvegarde pas, on risque de tout perdre en cas de problème...
|
||||
|
||||
Certains hébergeurs permettent de faire des sauvegardes automatisées, mais dans le cas où tu dois toi-même sauvegarder ta base de données, il existe plusieurs solutions :
|
||||
|
||||
- **Les sauvegardes manuelles** : qui consistent à exporter le contenu de ta base de données dans un fichier _(généralement au format SQL)_
|
||||
- **Les sauvegardes automatiques** : qui consistent à automatiser le processus de sauvegarde, généralement via un script ou un outil dédié
|
||||
|
||||
On va se concentrer _(que très rapidement, ne t'inquiète pas !)_ sur la partie automatisée, puisqu'elle permet également de comprendre comment faire une sauvegarde manuellement.
|
||||
|
||||
Pour mettre en place l'automatisation, on peut mettre en place une tâche planifiée : un processus qui va s'exécuter à intervalles réguliers pour sauvegarder notre base de données.
|
||||
Sur Linux, on parlera d'un `cron job` _(ou `tâche cron` en français)_.
|
||||
|
||||
Sans rentrer dans les détails de configuration d'une tâche cron, on va devoir la créer en donnant plusieurs informations :
|
||||
|
||||
- **Le chemin vers le script de sauvegarde** : qui va contenir les commandes pour sauvegarder notre base de données
|
||||
- **La fréquence d'exécution** : qui va déterminer à quelle fréquence notre tâche va s'exécuter _(toutes les heures, tous les jours, toutes les semaines, etc.)_
|
||||
- **Le compte utilisateur** : qui va exécuter la tâche, généralement le compte de l'utilisateur qui a les droits d'accès à la base de données
|
||||
|
||||
{% callout type="note" title="Exemple de script `bash` pour sauvegarder une base de données PostgreSQL" %}
|
||||
{% snippet path="bash/pg_cron_file.sh" language="bash" showLineNumbers=true /%}
|
||||
|
||||
Ce script va permettre de sauvegarder une base de données PostgreSQL en exportant son contenu dans un fichier SQL.
|
||||
Il est important de remplacer les variables `DB_USER`, `DB_NAME` et `BACKUP_DIR` par les informations de ta base de données.
|
||||
|
||||
Une fois ce script créé, il suffira de le rendre exécutable et de le planifier dans une tâche cron pour automatiser la sauvegarde de ta base de données.
|
||||
|
||||
{% snippet path="bash/pg_cron_register.sh" language="bash" /%}
|
||||
|
||||
Et voilà ! Ta base de données sera sauvegardée toutes les nuits à minuit, sans que tu aies besoin d'intervenir manuellement.
|
||||
{% /callout %}
|
||||
|
||||
## 🛡️ Sécurité et confidentialité des données
|
||||
|
||||
On ne le répétera jamais assez, mais la sécurité et la confidentialité des données sont primordiales pour toute application.
|
||||
|
||||
Pour garantir la sécurité de ta base de données, il est recommandé de mettre en place plusieurs mesures :
|
||||
|
||||
- **Les sauvegardes régulières** : pour éviter de perdre des données en cas de problème
|
||||
- **Les mises à jour régulières** : pour corriger les failles de sécurité et les bugs
|
||||
- **Les accès restreints** : pour limiter l'accès à la base de données aux seules personnes autorisées
|
||||
- **Les mots de passe forts** : pour éviter les attaques par force brute ou par dictionnaire
|
||||
- **Les connexions sécurisées** : pour éviter les interceptions de données
|
||||
|
||||
Mais la sécurité ne s'arrête pas là, il est également important de garantir la confidentialité des données :
|
||||
|
||||
- **Le chiffrement des données** : pour éviter que des tiers puissent lire les données stockées, en cas de fuite
|
||||
|
||||
{% callout type="warning" title="Identifiants de connexion" %}
|
||||
Même en développement sur ta machine locale, prend l'habitude de ne jamais utiliser les identifiants par défaut de ta base de données _(comme `root` sans mot de passe par exemple)_.
|
||||
|
||||
L'objectif est de te mettre dans les conditions réelles d'un environnement de production, où la sécurité est primordiale. Ça t'évitera de prendre de mauvaises habitudes qui pourraient te coûter cher par la suite.
|
||||
{% /callout %}
|
||||
|
||||
## ➕ Informations complémentaires
|
||||
|
||||
{% callout type="warning" title="Versions des outils et dépendances" %}
|
||||
Si tu utilises une autre méthode de modélisation que Merise, tu as évidemment le droit de le faire !
|
||||
Fais juste attention à une chose...
|
||||
|
||||
Même si le choix des outils que tu utilises est libre, il est important de préciser les versions que tu as utilisées pour ton projet.
|
||||
{% callout type="warning" title="Attention au respect des documents !" %}
|
||||
Si tu utilises une autre méthode de modélisation, fais attention à bien respecter les noms des documents.
|
||||
|
||||
Étant donné que chaque version corrige probablement diverses failles de sécurité et/ou ajoute des fonctionnalités, c'est le bon moment pour montrer que tu prends la veille technologique au sérieux.
|
||||
Par exemple, si tu fais un MCD, il faut que tu l'appelles comme ça et pas autrement.
|
||||
Mais si tu fais un MCD il faut qu'il respecte la méthode Merise, **sinon ce n'est pas un MCD**.
|
||||
|
||||
Ton jury peut être très pointilleux là-dessus, donc fais attention à bien respecter les noms des documents, leur contenu et leur structure.
|
||||
|
||||
N'oublie pas : tu as toutes les ressources nécessaires pour réaliser un MCD, un MLD ou un MPD sur le Memento 😉
|
||||
|
||||
{% quick-link
|
||||
title="Introduction à Merise"
|
||||
href="/docs/merise/"
|
||||
description="Parlons un peu de Merise, la fameuse méthodologie de modélisation pour la conception de bases de données."
|
||||
icon="presets"
|
||||
/%}
|
||||
{% /callout %}
|
||||
|
||||
## 🛠️ Ressources conseillées
|
||||
@ -56,8 +132,40 @@ _En cours de rédaction..._
|
||||
|
||||
## 🎯 Critères d'évaluation
|
||||
|
||||
- Les outils de développement nécessaires sont installés et configurés
|
||||
- Les outils de gestion de versions et de collaboration sont installés
|
||||
- Les conteneurs implémentes les services requis pour l'environnement de développement
|
||||
- La documentation technique de l'environnement de travail est comprise, en langue française ou anglaise (niveau B1 CECRL pour l'anglais)
|
||||
- Le système de veille permet de suivre les évolutions technologies et les problématiques de sécurité en lien avec l'installation et la configuration d'un environnement de travail
|
||||
- Les données du schéma conceptuel et leurs relations sont identifiées et prises en compte
|
||||
- Le schéma physique est conforme aux besoins exprimés dans le dossier de conception et respecte les règles des bases de données relationnelles
|
||||
- Les règles de nommage sont respectées
|
||||
- La sécurité, l'intégrité et la confidentialité des données est assurée
|
||||
- La base de données de tests mise en place est conforme au schéma physique
|
||||
- Les utilisateurs sont créés avec leurs droits respectifs conformément au dossier de conception
|
||||
- La base de données créée est sauvegardée et elle peut être restaurée en cas d'incident
|
||||
- La documentation technique des bases de données est comprise, en langue française ou anglaise _(niveau B1 du CECRL pour l'anglais)_
|
||||
|
||||
## 🤯 Aller plus loin
|
||||
|
||||
Pas trop mal à la tête ? On continue un tout petit peu ? 😅
|
||||
Tu as vu qu'on précise entre parenthèses la longueur des données, mais pourquoi on fait ça ?
|
||||
|
||||
Tu n'es pas sans savoir que pour stocker des données et que pour les stocker, il nous faut de l'espace.
|
||||
Et cet espace, on le définit en fonction de la longueur de nos données : on parle alors d'allocation.
|
||||
|
||||
En précisant une valeur entre les parenthèses, on vient dire à notre SGBD combien de place il doit réserver pour stocker nos données **au maximum**.
|
||||
|
||||
Dans le cas d'un `VARCHAR(30)`, on réserve 30 caractères pour stocker notre donnée, même si elle n'en fait que 5 _(allocation **dynamique**)_.
|
||||
Dans le cas d'un `CHAR(30)`, on réserve également 30 caractères, mais cette fois-ci on "complète notre donnée avec des espaces" pour atteindre les 30 caractères _(allocation **statique**)_.
|
||||
|
||||
Si on ne précise pas de longueur, le SGBD va réserver une place par défaut qui varie d'un SGBD à l'autre.
|
||||
Donc ce n'est pas parce que tu te dis : "255 caractères c'est très bien pour mon `VARCHAR`, pas besoin de le préciser puisque c'est la valeur par défaut !" que tu as raison... 😅
|
||||
Si demain la norme change et que l'allocation par défaut pour les types `VARCHAR` passe à 100 caractères au lieu de 255 caractères, tu risques de te retrouver avec des données tronquées !
|
||||
|
||||
## 🧠 Documentations
|
||||
|
||||
- [Éditions ENI - Merise - Guide pratique (4e édition), par **Jean-Luc Baptiste**](https://www.editions-eni.fr/livre/merise-guide-pratique-4e-edition-modelisation-des-donnees-et-des-traitements-manipulations-avec-le-langage-sql-conception-d-une-application-mobile-android-ou-ios-9782409046667)
|
||||
- [Medium - Non, les ID n'ont pas leur place dans un MCD, par **Jean Prulière**](https://jeanpruliere.medium.com/non-les-id-nont-pas-leur-place-dans-un-mcd-43b5cd5ce9b6)
|
||||
- [SQL.sh - Cours et tutoriels SQL](https://sql.sh/)
|
||||
- [Wikipédia - UML](<https://fr.wikipedia.org/wiki/UML_(informatique)>)
|
||||
|
||||
## 🛠️ Outils
|
||||
|
||||
- [Looping - Logiciel de modélisation de bases de données](https://www.looping-mcd.fr/)
|
||||
- [Mocodo - Logiciel en ligne de modélisation de bases de données](https://www.mocodo.net/)
|
||||
|
||||
@ -1,63 +1,165 @@
|
||||
---
|
||||
title: DWWM CP 1 - Installer et configurer son environnement de travail en fonction du projet web ou web mobile
|
||||
description: Synthèse et explications des attentes relatives à la compétence professionnelle 1 du titre professionnel DWWM (01280m04).
|
||||
title: CP 6 - Développer des composants d'accès aux données SQL et NoSQL
|
||||
description: Synthèse et explications des attentes relatives à la compétence professionnelle 6 du titre professionnel Développeur Web et Web Mobile (DWWM-01280m04).
|
||||
tags: [DWWM]
|
||||
---
|
||||
|
||||
## 📚 Références
|
||||
|
||||
- REAC _(mise à jour du 02/07/2024)_, pages 15 et 16
|
||||
- RE _(mise à jour du 02/07/2024)_, page 9
|
||||
- REAC _(mise à jour du 02/07/2024)_, pages 25 et 26
|
||||
- RE _(mise à jour du 02/07/2024)_, page 11
|
||||
|
||||
## 📋 En résumé
|
||||
|
||||
Ce qui est attendu de ta part, c'est d'expliquer **comment** on peut installer et configurer les prérequis pour exécuter ton projet.
|
||||
Gros morceau la création de bases de données, n'est-ce pas ? 😅
|
||||
On va pouvoir souffler un coup en parlant maintenant de l'accès à ces bases de données. _(enfin, souffler... pas trop quand même)_
|
||||
|
||||
Tu as utilisé un framework PHP et React en front ?
|
||||
Tu devras alors expliquer comment installer PHP, Composer, Node.js, npm _(ou autre gestionnaire de dépendances Node)_ et les autres dépendances nécessaires à ton projet comme la base de données !
|
||||
Et tu sais quoi, comme tout ce qu'on a vu jusqu'à maintenant, on va alléger un peu les choses en parlant de merveilleux outils comme les **ORM** et les **ODM** !
|
||||
|
||||
Et pour te donner un ordre d'idée, voici ce que ça peut donner :
|
||||
{% callout type="question" title="C'est quoi un ORM et ODM ? Quelles sont les différences ?" %}
|
||||
Les ORM _(Object-Relational Mapping)_ et les ODM _(Object-Document Mapper)_ sont des outils qui permettent de faire le lien entre les bases de données et les langages de programmation.
|
||||
|
||||
- Versionning _(Git, SVN, ...)_
|
||||
- IDE ou éditeur de code _(Visual Studio Code, PhpStorm, ...)_
|
||||
- Langages/runtimes _(PHP, Node.js, ...)_
|
||||
- Gestionnaires de dépendances _(Composer, npm, ...)_
|
||||
- Serveurs web _(Apache, Nginx, ...)_
|
||||
- Base de données _(MySQL, PostgreSQL, ...)_
|
||||
- DevOps _(Docker, Vagrant, ...)_
|
||||
- etc.
|
||||
- Les ORM sont utilisés pour les bases de données relationnelles, comme MySQL, PostgreSQL ou SQLite. Ils permettent de manipuler les données de la base de données sous forme d'objets, ce qui facilite leur utilisation dans le code.
|
||||
- Les ODM sont utilisés pour les bases de données NoSQL, comme MongoDB. Ils fonctionnent de la même manière que les ORM, mais pour les bases de données NoSQL.
|
||||
|
||||
Tu l'as compris, c'est vaste !
|
||||
Mais heureusement, tu dois uniquement expliquer comment installer et configurer les outils que tu as utilisés pour ton projet.
|
||||
En gros, les ORM et les ODM permettent de simplifier la manipulation des données dans le code, en évitant d'avoir à écrire des requêtes à la main.
|
||||
{% /callout %}
|
||||
|
||||
Si tu fais un projet Laravel et React, pas besoin d'expliquer comment installer et configurer Ruby et Java, par exemple 😉
|
||||
Alleeeez, on va voir ça de plus près ! 😎
|
||||
|
||||
{% callout type="note" title="Utilisation de XAMPP, WAMP, MAMP, LAMP, Laragon etc." %}
|
||||
## ⚙️ Utilisation d'un ORM ou d'un ODM
|
||||
|
||||
Si tu utilises un logiciel comme XAMPP, WAMP, MAMP, LAMP, Laragal etc., tu as évidemment le droit de le mentionner dans ta présentation et dossier de projet.
|
||||
{% callout type="question" title="Je fais mes requêtes SQL à la main, il faut que j'apprenne à utiliser un ORM/ODM ?" %}
|
||||
**Non** ! _(enfin, pas pour passer la certification en tout cas)_
|
||||
D'un certain côté, c'est nettement plus intéressant de savoir réaliser les requêtes par toi-même, sans utiliser d'outils qui génèrent du SQL à ta place.
|
||||
|
||||
Toutefois, il est préférable que tu saches expliquer comment installer et configurer les éléments nécessaires de manières individuelles.
|
||||
En entreprise, tu vas certainement utiliser ces fameux outils, mais dès que l'on va chercher à avoir les requêtes les plus optimisées possibles, il va falloir mettre les mains dans le cambouis !
|
||||
{% /callout %}
|
||||
|
||||
Mais alors, pourquoi faire des requêtes à la main quand on peut utiliser un ORM ou un ODM ?
|
||||
Eh bien, c'est simple : les ORM et les ODM te permettent de manipuler les données de la base de données sous forme d'objets, ce qui est beaucoup plus pratique et lisible dans le code.
|
||||
|
||||
Tu peux créer, lire, mettre à jour et supprimer des données sans avoir à écrire de requêtes SQL ou NoSQL.
|
||||
|
||||
Cependant ça vient aussi avec son lot de contraintes et de limitations...
|
||||
|
||||
Un ORM ou un ODM ne va pas forcément te permettre de faire tout ce que tu veux et dans certains cas, tu vas devoir écrire des requêtes SQL ou NoSQL à la main.
|
||||
D'autre part, ces outils peuvent aussi avoir un impact sur les performances de ton application, surtout si tu fais des requêtes complexes ou si tu manipules de grandes quantités de données.
|
||||
|
||||
Imagines un peu si tu réalises une application qui doit gérer des tonnes de données en temps réel, comme une application de spéculation boursière 😅
|
||||
|
||||
{% callout type="warning" title="Les ORM et ODM, c'est cool, mais pas magique" %}
|
||||
Si tu comptes présenter un projet avec un ORM ou un ODM, il va falloir que tu sois capable de justifier tes choix techniques et de montrer que tu sais ce que tu fais... et ce que fait l'outil que tu utilises !
|
||||
|
||||
Tu dois être capable de répondre à des questions comme celle-ci :
|
||||
|
||||
> Quelle est la requête SQL générée par l'ORM/ODM pour cette opération ?
|
||||
|
||||
Ton jury ne cherchera pas à te piéger, mais il attend de toi que tu sois capable de comprendre ce que tu fais et pourquoi tu le fais.
|
||||
{% /callout %}
|
||||
|
||||
## 🔎 Intégrité des données
|
||||
|
||||
L'intégrité des données, c'est le fait de garantir que les données stockées dans la base de données sont correctes et cohérentes, de la création jusqu'à la suppression.
|
||||
Si dans un champ de ta base de données tu attends un nombre entier, tu ne vas pas accepter une chaîne de caractères, n'est-ce pas ?
|
||||
|
||||
Et pour garantir cette intégrité, on va mettre en place des vérifications **avant** d'insérer ou de mettre à jour des données dans la base de données.
|
||||
|
||||
Rien de plus simple bien entendu !
|
||||
|
||||
Tu t'attends à avoir une adresse email dans un champ ?
|
||||
Alors tu vas vérifier que l'adresse email est bien une adresse email, et non pas une chaîne de caractères lambda.
|
||||
|
||||
## 🔐 Confidentialité des données
|
||||
|
||||
La plupart du temps, nos bases de données vont accueillir des données confidentielles, comme :
|
||||
|
||||
- Des mots de passe
|
||||
- Des informations personnelles _(nom, prénom, adresse, etc.)_
|
||||
- Des données sensibles _(informations bancaires, médicales, etc.)_
|
||||
|
||||
Bien que notre bases de données se doit d'être sécurisée dans son accès et ses permissions, dans le cas d'une fuite il est important de sécuriser ces données.
|
||||
|
||||
Pour les mots de passe, on va les hacher avant de les stocker dans la base de données.
|
||||
|
||||
{% callout type="question" title="C'est quoi le hachage ?" %}
|
||||
Le hachage est une manière de sécuriser un contenu textuel en le transformant en une chaîne de caractères "aléatoire", appelée **hash**.
|
||||
|
||||
Il est important de noter que le hachage est **unidirectionnel**, c'est-à-dire qu'il est impossible de retrouver la valeur d'origine à partir de son hash contrairement au **chiffrement**.
|
||||
{% /callout %}
|
||||
|
||||
{% callout type="question" title="Et le chiffrement, ça sert à quoi ?" %}
|
||||
Comme le hachage, le chiffrement permet de sécuriser des données. Cependant : le chiffrement est **bidirectionnel**.
|
||||
C'est à dire que l'on peut retrouver les données d'origine à partir des données chiffrées.
|
||||
|
||||
Si tu as déjà eu l'occasion d'envoyer des "messages codés", c'est que tu as déjà utilisé le chiffrement sans pour autant le savoir !
|
||||
L'un des chiffrements les plus connus est le **chiffre de César**, qui consiste à décaler les lettres de l'alphabet d'un certain nombre de positions.
|
||||
|
||||
Par exemple :
|
||||
|
||||
> Message : "Bonjour"
|
||||
> Décalage : 3
|
||||
>
|
||||
> Message chiffré : "Erqmruxu"
|
||||
|
||||
{% callout type="warning" title="Attention !" %}
|
||||
Le chiffrement n'est pas une solution de sécurité absolue, il est possible de retrouver les données d'origine à partir des données chiffrées.
|
||||
D'ailleurs le chiffre de César est un chiffrement très simple à casser, on ne va donc pas l'utiliser pour protéger les données sensibles !
|
||||
{% /callout %}
|
||||
|
||||
On va privilégier un algorithme de chiffrement qui se base sur une **clé secrète**, qui sera la clé pour chiffrer et déchiffrer les données.
|
||||
C'est d'ailleurs plus ou moins ce qui est fait avec la célèbre [machine Enigma](<https://fr.wikipedia.org/wiki/Enigma_(machine)>) utilisée par les allemands pendant la Seconde Guerre Mondiale pour chiffrer leurs messages et éviter qu'ils soient interceptés et compris par les alliés.
|
||||
|
||||
{% /callout %}
|
||||
|
||||
## ➕ Informations complémentaires
|
||||
Mais alors, comment on peut s'y prendre ?
|
||||
|
||||
{% callout type="warning" title="Versions des outils et dépendances" %}
|
||||
🥁🥁🥁
|
||||
|
||||
Même si le choix des outils que tu utilises est libre, il est important de préciser les versions que tu as utilisées pour ton projet.
|
||||
Avec des bibliothèques, tout simplement ! 🙃
|
||||
_(Ou si tu es un peu fou, tu peux essayer de le faire toi-même, mais attention à ce que ce soit **réellement sécurisé** sinon tu en deviens le seul et unique **responsable**)_
|
||||
|
||||
Étant donné que chaque version corrige probablement diverses failles de sécurité et/ou ajoute des fonctionnalités, c'est le bon moment pour montrer que tu prends la veille technologique au sérieux.
|
||||
Tu as notamment des bibliothèques _(Node.js)_ qui sont très utilisées :
|
||||
|
||||
{% /callout %}
|
||||
- Hachage : `bcrypt` _(ou encore `argon2`)_
|
||||
- Chiffrement : `crypto` _(module natif de Node.js en plus, si ça c'est pas la classe 😎)_
|
||||
|
||||
## 🛠️ Ressources conseillées
|
||||
Je te laisse te plonger dans les documentations associées, que tu retrouveras _(presque)_ tout en bas de cette fiche.
|
||||
|
||||
_En cours de rédaction..._
|
||||
Et naturellement : **PERSONNE** ne doit avoir accès à ces données, à part les personnes autorisées/concernées bien entendu.
|
||||
|
||||
## 🎯 Critères d'évaluation
|
||||
|
||||
- Les outils de développement nécessaires sont installés et configurés
|
||||
- Les outils de gestion de versions et de collaboration sont installés
|
||||
- Les conteneurs implémentes les services requis pour l'environnement de développement
|
||||
- La documentation technique de l'environnement de travail est comprise, en langue française ou anglaise (niveau B1 CECRL pour l'anglais)
|
||||
- Le système de veille permet de suivre les évolutions technologies et les problématiques de sécurité en lien avec l'installation et la configuration d'un environnement de travail
|
||||
- Les traitements relatifs aux manipulations des données répondent aux fonctionnalités décrites dans le dossier de conception
|
||||
- L'intégrité et la confidentialité des données sont maintenues
|
||||
- Les cas d'exception sont pris en compte
|
||||
- Toutes les entrées sont contrôlées et validées dans les composants serveurs sécurisés
|
||||
- Les tests unitaires et de sécurité sont associés à chaque composant
|
||||
- La démarche structurée de résolution de problème est adaptée en cas de dysfonctionnement
|
||||
- Le système de veille permet de suivre les évolutions technologiques et les problématiques de sécurité liées aux bases de données SQL et NoSQL
|
||||
|
||||
## 🤯 Aller plus loin
|
||||
|
||||
T'es encore là ? Tu aimes ça les ~patates~ bases de données, hein ? 😏
|
||||
Alors dans ce cas, je te recommande chaudement de te pencher sur PostgreSQL qui est, à mon sens, l'une des seules **vraies** bases de données relationnelles.
|
||||
|
||||
Je ne m'étalerai pas sur ce sujet, mais désolé MySQL/MariaDB de ne pas être au niveau... 😅
|
||||
|
||||
Les ressources que je m'apprête à te recommander sont un peu plus avancées, mais ce sont d'excellentes portes d'entrées vers des métiers comme DBA par exemple.
|
||||
Tu retrouveras des notions très bien expliquées et pertinentes pour t'améliorer sur le sujet dans les ressources de [Dalibo](https://www.dalibo.com/formations).
|
||||
|
||||
{% callout type="note" title="Gratuité des formations Dalibo" %}
|
||||
Dalibo propose des formations, mais qui ne sont pas gratuites pour autant.
|
||||
Seuls les supports de cours sont disponibles gratuitement, aux formats EPUB et PDF.
|
||||
|
||||
Tu peux retrouver ces supports sur la page [Formations](https://www.dalibo.com/formations) du site de Dalibo.
|
||||
{% /callout %}
|
||||
|
||||
## 🧠 Documentations
|
||||
|
||||
- [SQL.sh - Cours et tutoriels SQL](https://sql.sh/)
|
||||
- [Dalibo - Formations](https://www.dalibo.com/formations)
|
||||
- [Wikipédia - Chiffrement de César](https://fr.wikipedia.org/wiki/Chiffrement_par_d%C3%A9calage)
|
||||
- [bcrypt - Documentation](https://www.npmjs.com/package/bcrypt)
|
||||
- [argon2 - Documentation](https://www.npmjs.com/package/argon2)
|
||||
- [crypto - Documentation](https://nodejs.org/api/crypto.html)
|
||||
|
||||
@ -1,63 +1,193 @@
|
||||
---
|
||||
title: DWWM CP 1 - Installer et configurer son environnement de travail en fonction du projet web ou web mobile
|
||||
description: Synthèse et explications des attentes relatives à la compétence professionnelle 1 du titre professionnel DWWM (01280m04).
|
||||
title: CP 7 - Développer des composants métier coté serveur
|
||||
description: Synthèse et explications des attentes relatives à la compétence professionnelle 7 du titre professionnel Développeur Web et Web Mobile (DWWM-01280m04).
|
||||
tags: [DWWM]
|
||||
---
|
||||
|
||||
## 📚 Références
|
||||
|
||||
- REAC _(mise à jour du 02/07/2024)_, pages 15 et 16
|
||||
- RE _(mise à jour du 02/07/2024)_, page 9
|
||||
- REAC _(mise à jour du 02/07/2024)_, pages 27 et 28
|
||||
- RE _(mise à jour du 02/07/2024)_, page 12
|
||||
|
||||
## 📋 En résumé
|
||||
|
||||
Ce qui est attendu de ta part, c'est d'expliquer **comment** on peut installer et configurer les prérequis pour exécuter ton projet.
|
||||
Maintenant que l'on sait modéliser et dialoguer avec notre base de données, on va pouvoir s'attaquer à la logique métier de notre application.
|
||||
Dans le cadre d'un projet web, ça représentera principalement nos contrôleurs, middlewares et services.
|
||||
|
||||
Tu as utilisé un framework PHP et React en front ?
|
||||
Tu devras alors expliquer comment installer PHP, Composer, Node.js, npm _(ou autre gestionnaire de dépendances Node)_ et les autres dépendances nécessaires à ton projet comme la base de données !
|
||||
Si tu as déjà travaillé sur un projet web, tu as probablement déjà entendu parler du design pattern MVC.
|
||||
Et si ce n'est pas le cas, pas de panique, on va voir ensemble ce que c'est !
|
||||
|
||||
Et pour te donner un ordre d'idée, voici ce que ça peut donner :
|
||||
## 💡 Le design pattern MVC
|
||||
|
||||
- Versionning _(Git, SVN, ...)_
|
||||
- IDE ou éditeur de code _(Visual Studio Code, PhpStorm, ...)_
|
||||
- Langages/runtimes _(PHP, Node.js, ...)_
|
||||
- Gestionnaires de dépendances _(Composer, npm, ...)_
|
||||
- Serveurs web _(Apache, Nginx, ...)_
|
||||
- Base de données _(MySQL, PostgreSQL, ...)_
|
||||
- DevOps _(Docker, Vagrant, ...)_
|
||||
- etc.
|
||||
Le design pattern MVC est un modèle d'architecture logicielle qui sépare les données, la logique métier et l'interface utilisateur.
|
||||
|
||||
Tu l'as compris, c'est vaste !
|
||||
Mais heureusement, tu dois uniquement expliquer comment installer et configurer les outils que tu as utilisés pour ton projet.
|
||||
|
||||
Si tu fais un projet Laravel et React, pas besoin d'expliquer comment installer et configurer Ruby et Java, par exemple 😉
|
||||
|
||||
{% callout type="note" title="Utilisation de XAMPP, WAMP, MAMP, LAMP, Laragon etc." %}
|
||||
|
||||
Si tu utilises un logiciel comme XAMPP, WAMP, MAMP, LAMP, Laragal etc., tu as évidemment le droit de le mentionner dans ta présentation et dossier de projet.
|
||||
|
||||
Toutefois, il est préférable que tu saches expliquer comment installer et configurer les éléments nécessaires de manières individuelles.
|
||||
- **Modèle** : représente les données de l'application. Il contient les classes qui permettent de manipuler les données.
|
||||
- **Vue** : représente l'interface utilisateur. C'est ce que l'utilisateur voit et avec quoi il interagit.
|
||||
- **Contrôleur** : fait le lien entre le modèle et la vue. Il contient la logique métier de l'application.
|
||||
|
||||
{% callout type="warning" title="Les schémas disponibles en ligne" %}
|
||||
Il existe de nombreux schémas qui expliquent le design pattern MVC mais ils ne sont pas tous corrects.
|
||||
Enfin, si, ils sont corrects... mais certains ne s'appliquent pas à tous les frameworks et architectures.
|
||||
{% /callout %}
|
||||
|
||||
## ➕ Informations complémentaires
|
||||
Pour t'aider à mieux te représenter un schéma MVC avec les ordres de flux de données et de contrôle :
|
||||
|
||||
{% callout type="warning" title="Versions des outils et dépendances" %}
|
||||
{% img alt="Schéma MVC pour une application web basique" src="/patterns/mvc.webp" className="max-h-96 mx-auto" /%}
|
||||
|
||||
Même si le choix des outils que tu utilises est libre, il est important de préciser les versions que tu as utilisées pour ton projet.
|
||||
|
||||
Étant donné que chaque version corrige probablement diverses failles de sécurité et/ou ajoute des fonctionnalités, c'est le bon moment pour montrer que tu prends la veille technologique au sérieux.
|
||||
{% callout type="question" title="Pourquoi la Vue ne retourne pas directement au client ?" %}
|
||||
La vue ne retourne pas directement au client car elle doit passer par le contrôleur.
|
||||
On ne s'en rend pas forcément compte, mais la vue est généralement générée par le contrôleur via un moteur de template _(EJS, Twig, etc.)_.
|
||||
|
||||
Une fois le HTML généré, le contrôleur s'occupe de l'envoyer dans la réponse HTTP au client.
|
||||
C'est ce qui permet de garder une séparation entre la logique métier et l'interface utilisateur.
|
||||
{% /callout %}
|
||||
|
||||
## 🛠️ Ressources conseillées
|
||||
Le concept est simple : chaque partie de l'application a un **rôle bien défini** et ne doit pas empiéter sur le rôle des autres.
|
||||
|
||||
_En cours de rédaction..._
|
||||
{% callout type="question" title="Et si j'ai des middlewares ?" %}
|
||||
Dans la majorité des cas, les middlewares s'exécutent avant le contrôleur même si on peut en avoir à différents moments de la circulation de la donnée.
|
||||
Si tu as déjà utilisé Express, tu as probablement déjà utilisé un middleware pour vérifier si l'utilisateur est connecté avant de lui afficher une page qui est réservée aux utilisateurs connectés.
|
||||
{% /callout %}
|
||||
|
||||
{% callout type="note" title="Le cas de React (ou Vue, Angular, Solid, etc.)" %}
|
||||
D'après toi, est-ce que React doit être considéré comme la vue dans le design pattern MVC ?
|
||||
La réponse est **non** !
|
||||
|
||||
React est une bibliothèque _(pas une "librarie" et encore moins un framework ⚠️)_ JavaScript qui permet de créer des interfaces utilisateur, mais elle n'est pas liée de manière directe à un serveur.
|
||||
Certes, on va consommer une API pour récupérer des données, mais React n'est que le réceptacle de ces données côté client _(navigateur)_.
|
||||
|
||||
On va donc faire simple : on parlera plutôt d'une architecture "client-serveur" avec React côté client et notre API côté serveur.
|
||||
Mais ça n'empêche pas que ton API puisse être une API REST _(ou GraphQL)_ qui respecte le design pattern MVC !
|
||||
Tout dépendra de si tu demandes dans ton serveur back-end de retourner une vue _(HTML)_ au navigateur.
|
||||
{% /callout %}
|
||||
|
||||
## 🧑⚖️ Règles et conventions de nommage
|
||||
|
||||
Peu importe le contexte dans lequel tu réalises le projet que tu vas soutenir face à ton jury, tu dois respecter les règles et conventions de nommage de l'entreprise.
|
||||
Si tu fais un projet personnel, tu peux définir les tiennes, du moment que tu es en mesure de les expliquer à ton jury et que tu les respectes du début à la fin.
|
||||
|
||||
{% callout type="note" title="La cohérence, c'est la clé" %}
|
||||
Pense à être cohérent en ce qui concerne la langue utilisée.
|
||||
|
||||
{% callout type="warning" title="Pas de franglais !" %}
|
||||
Évite de mélanger plusieurs langues dans tes nommages.
|
||||
Si tu choisis de travailler en français, reste en français.
|
||||
Si tu choisis de travailler en anglais, reste en anglais.
|
||||
{% /callout %}
|
||||
|
||||
D'ailleurs, je te recommande chaudement de travailler en anglais ne serait-ce que pour te familiariser avec la langue de Shakespeare qui est, on le rappelle, la langue la plus répandue dans le monde de l'informatique.
|
||||
|
||||
Tu as évidemment le droit d'utiliser des traducteurs en ligne pour t'aider à trouver le bon mot _(ou la bonne expression)_, on ne te demande pas d'être bilingue !
|
||||
{% /callout %}
|
||||
|
||||
Au delà de la langue utilisée, on va également parler de la syntaxe des noms de fichiers, dossiers, classes, méthodes, variables, etc.
|
||||
Pour t'aider à te lancer, tu peux t'inspirer des conventions de nommage les plus répandues que tu trouveras facilement en ligne.
|
||||
|
||||
Au passage, tu as la possibilité de configurer ton éditeur de texte pour qu'il respecte ces conventions de nommage.
|
||||
Sur VSCode, l'extension [ESLint](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) te permettra de vérifier que ton code respecte bien les conventions de nommage que tu auras définies et [Prettier](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) te permettra de formater ton code automatiquement selon ces mêmes conventions.
|
||||
|
||||
Ça me permet également de te rappeler que tu dois **documenter ton code** et ce, **dans la langue définie pour le projet**.
|
||||
Le premier réflexe à avoir est de documenter l'installation et l'utilisation de ton projet dans le fichier `README.md` à la racine de ton projet.
|
||||
|
||||
Ensuite, n'ai pas peur d'abuser de la JSDoc _(ou PHPDoc si tu travailles en PHP)_ pour documenter tes fonctions et méthodes.
|
||||
Par contre, n'abuse pas des commentaires potentiellement "inutiles" qui alourdissent la lecture de ton code, ça peut être contre-productif.
|
||||
|
||||
## 🔄 Le jeu d'essai et les tests unitaires
|
||||
|
||||
Histoire de faire simple : commençons par le jeu d'essai !
|
||||
|
||||
### 🎮 Le jeu d'essai
|
||||
|
||||
Le jeu d'essai est un ensemble de données qui permet de tester le bon fonctionnement de l'application.
|
||||
Ce type de test se compose de trois parties :
|
||||
|
||||
- **Les données d'entrée** : ce sont les données que tu vas envoyer à ton application pour tester son comportement.
|
||||
- **Les données de sortie attendues** : ce sont les données que tu attends en retour de ton application.
|
||||
- **Les données de sortie obtenues** : ce sont les données que ton application te renvoie.
|
||||
|
||||
Si on prend l'exemple d'un formulaire d'inscription où nous vérifions que l'utilisateur utilise une adresse e-mail valide et unique, ainsi qu'un mot de passe fort _(12 caractères minimum, au moins une majuscule, une minuscule, un chiffre et un caractère spécial)_, voici ce que pourrait donner notre jeu d'essai :
|
||||
|
||||
{% tabs defaultSelectedTab="invalid" %}
|
||||
{% tab value="invalid" label="Données invalides" %}
|
||||
|
||||
- **Les données d'entrée** :
|
||||
- Adresse e-mail : `mauvaise-adresse@email`
|
||||
- Mot de passe : `password`
|
||||
- **Les données de sortie attendues** :
|
||||
- Erreur : `Adresse e-mail invalide`
|
||||
- Erreur : `Le mot de passe ne respecte pas les critères de sécurité requis`
|
||||
- **Les données de sortie obtenues** :
|
||||
- Erreur : `Adresse e-mail invalide`
|
||||
- Erreur : `Le mot de passe ne respecte pas les critères de sécurité requis`
|
||||
|
||||
{% /tab %}
|
||||
|
||||
{% tab value="valid" label="Données valides" %}
|
||||
|
||||
- **Les données d'entrée** :
|
||||
- Adresse e-mail : `bonne-adresse@email.fr`
|
||||
- Mot de passe : `Password123&` _(bon, le mot de passe n'est absolument pas "fort", mais il respecte les critères imposés)_
|
||||
- **Les données de sortie attendues** :
|
||||
- Succès : `Utilisateur inscrit avec succès`
|
||||
- **Les données de sortie obtenues** :
|
||||
- Succès : `Utilisateur inscrit avec succès`
|
||||
|
||||
{% /tab %}
|
||||
|
||||
{% tab value="email-already-used" label="Adresse email déjà utilisée" %}
|
||||
|
||||
- **Les données d'entrée** :
|
||||
- Adresse e-mail : `adresse-email@utilisee.fr`
|
||||
- Mot de passe : `Password123&`
|
||||
- **Les données de sortie attendues** :
|
||||
- Erreur : `Adresse e-mail déjà utilisée`
|
||||
- **Les données de sortie obtenues** :
|
||||
- Erreur : `Adresse e-mail déjà utilisée`
|
||||
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
{% callout type="note" title="Faire ces tests facilement" %}
|
||||
Si je te parle de client HTTP, tu me réponds... ?
|
||||
[Bruno](https://www.usebruno.com/) ? [Postman](https://www.postman.com/) ? [Insomnia](https://insomnia.rest/) ?
|
||||
|
||||
Bingo ! 🎉
|
||||
|
||||
Utiliser un client HTTP comme Bruno, Postman ou Insomnia te permettra de tester facilement les routes de ton API, et de vérifier que les données que tu envoies sont bien traitées par ton serveur.
|
||||
{% /callout %}
|
||||
|
||||
### 🧪 Les tests unitaires
|
||||
|
||||
Les tests unitaires, c'est un peu comme le jeu d'essai, mais en plus automatisé et surtout axé sur les fonctions et méthodes de ton application.
|
||||
|
||||
Le gros avantage que ça va te permettre, c'est de t'assurer que toutes les fonctionnalités développées fonctionnent comme prévu et ce, à chaque fois que tu modifies ton code.
|
||||
Oui oui, tu as bien lu : **à chaque fois que tu modifies ton code**, pas forcément à chaque fois que tu modifies une fonction ou une méthode qui avait déjà des tests unitaires.
|
||||
|
||||
Alors pas forcément à la moindre modification, je veux plutôt dire que le but est de vérifier avant de livrer !
|
||||
Tu peux d'ailleurs faire en sorte que **tous les tests unitaires** doivente passer avant de pouvoir pusher ton code sur la branche principale de ton dépôt Git. Au début c'est casse pied, mais tu verras que ça te permettra de gagner du temps sur le long terme.
|
||||
|
||||
L'objectif c'est de t'assurer que tu ne casses pas une fonctionnalité existante en ajoutant une nouvelle fonctionnalité ou en modifiant une fonctionnalité existante pour garantir que ton projet reste fonctionnel et ne casse pas sous les mains des utilisateurs.
|
||||
|
||||
## 🎯 Critères d'évaluation
|
||||
|
||||
- Les outils de développement nécessaires sont installés et configurés
|
||||
- Les outils de gestion de versions et de collaboration sont installés
|
||||
- Les conteneurs implémentes les services requis pour l'environnement de développement
|
||||
- La documentation technique de l'environnement de travail est comprise, en langue française ou anglaise (niveau B1 CECRL pour l'anglais)
|
||||
- Le système de veille permet de suivre les évolutions technologies et les problématiques de sécurité en lien avec l'installation et la configuration d'un environnement de travail
|
||||
- Les traitements répondent aux fonctionnalités décrites dans le dossier de conception
|
||||
- Les composants métier sont sécurisés
|
||||
- Les bonnes pratiques de la programmation orientée objet _(POO)_ sont respectées
|
||||
- Les règles de nommage sont conformes aux normes de qualité de l'entreprise
|
||||
- Le code source est documenté, y compris en anglais
|
||||
- Un jeu d'essai fonctionnel et les tests unitaires ont été réalisés pour les composants concernés
|
||||
- Les tests de sécurité sont réalisés
|
||||
- La démarche structurée de résolution de problème est adaptée en cas de dysfonctionnement
|
||||
|
||||
## 🧠 Documentations
|
||||
|
||||
- [Wikipédia - Design pattern MVC](https://fr.wikipedia.org/wiki/Mod%C3%A8le-vue-contr%C3%B4leur) _(Attention, le schéma présenté n'est pas forcément le plus adapté à tous les frameworks et architectures)_
|
||||
- [Wikipédia - Conventions de nommage](https://fr.wikipedia.org/wiki/Convention_de_nommage)
|
||||
- [JSDoc - Documentation](https://jsdoc.app/)
|
||||
- [PHPDoc - Documentation](https://www.phpdoc.org/)
|
||||
|
||||
## 🛠️ Outils
|
||||
|
||||
- [Bruno](https://www.usebruno.com/)
|
||||
- [Postman](https://www.postman.com/)
|
||||
- [Insomnia](https://insomnia.rest/)
|
||||
|
||||
@ -1,44 +1,21 @@
|
||||
---
|
||||
title: DWWM CP 1 - Installer et configurer son environnement de travail en fonction du projet web ou web mobile
|
||||
description: Synthèse et explications des attentes relatives à la compétence professionnelle 1 du titre professionnel DWWM (01280m04).
|
||||
tags: [DWWM]
|
||||
title: CP 8 - Documenter le déploiement d'une application dynamique web ou web mobile
|
||||
description: Synthèse et explications des attentes relatives à la compétence professionnelle 8 du titre professionnel Développeur Web et Web Mobile (DWWM-01280m04).
|
||||
tags: [DWWM, Déploiement, Backend, Reverse Proxy, Serveur Web]
|
||||
---
|
||||
|
||||
## 📚 Références
|
||||
|
||||
- REAC _(mise à jour du 02/07/2024)_, pages 15 et 16
|
||||
- RE _(mise à jour du 02/07/2024)_, page 9
|
||||
- REAC _(mise à jour du 02/07/2024)_, page 29
|
||||
- RE _(mise à jour du 02/07/2024)_, page 12
|
||||
|
||||
## 📋 En résumé
|
||||
|
||||
Ce qui est attendu de ta part, c'est d'expliquer **comment** on peut installer et configurer les prérequis pour exécuter ton projet.
|
||||
Allez, on clos la dernière compétence professionnelle de ce millésime 2023 avec la documentation du déploiement !
|
||||
Et heureusement, on n'attend pas de toi de maîtriser un serveur dans les détails, mais d'expliquer **comment** mettre en ligne ton projet.
|
||||
|
||||
Tu as utilisé un framework PHP et React en front ?
|
||||
Tu devras alors expliquer comment installer PHP, Composer, Node.js, npm _(ou autre gestionnaire de dépendances Node)_ et les autres dépendances nécessaires à ton projet comme la base de données !
|
||||
|
||||
Et pour te donner un ordre d'idée, voici ce que ça peut donner :
|
||||
|
||||
- Versionning _(Git, SVN, ...)_
|
||||
- IDE ou éditeur de code _(Visual Studio Code, PhpStorm, ...)_
|
||||
- Langages/runtimes _(PHP, Node.js, ...)_
|
||||
- Gestionnaires de dépendances _(Composer, npm, ...)_
|
||||
- Serveurs web _(Apache, Nginx, ...)_
|
||||
- Base de données _(MySQL, PostgreSQL, ...)_
|
||||
- DevOps _(Docker, Vagrant, ...)_
|
||||
- etc.
|
||||
|
||||
Tu l'as compris, c'est vaste !
|
||||
Mais heureusement, tu dois uniquement expliquer comment installer et configurer les outils que tu as utilisés pour ton projet.
|
||||
|
||||
Si tu fais un projet Laravel et React, pas besoin d'expliquer comment installer et configurer Ruby et Java, par exemple 😉
|
||||
|
||||
{% callout type="note" title="Utilisation de XAMPP, WAMP, MAMP, LAMP, Laragon etc." %}
|
||||
|
||||
Si tu utilises un logiciel comme XAMPP, WAMP, MAMP, LAMP, Laragal etc., tu as évidemment le droit de le mentionner dans ta présentation et dossier de projet.
|
||||
|
||||
Toutefois, il est préférable que tu saches expliquer comment installer et configurer les éléments nécessaires de manières individuelles.
|
||||
|
||||
{% /callout %}
|
||||
Tu as le droit d'utiliser des plateformes de déploiement en ligne comme Vercel, Netlify, Heroku, etc.
|
||||
Mais la compréhension, même basique, d'un serveur Linux est quelque chose d'extrêmement apprécié et enrichissant.
|
||||
|
||||
## ➕ Informations complémentaires
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Activité Type 2 - Développer la partie back-end d'une application web ou web mobile sécurisée
|
||||
description: Synthèse et explications des attentes relatives à l'activité type 2 du titre professionnel DWWM (01280m04).
|
||||
description: Synthèse et explications des attentes relatives à l'activité type 2 du titre professionnel Développeur Web et Web Mobile (DWWM-01280m04).
|
||||
tags: [DWWM]
|
||||
---
|
||||
|
||||
@ -11,13 +11,13 @@ tags: [DWWM]
|
||||
|
||||
## 📋 En résumé
|
||||
|
||||
Cette activité type concerne tout ce qui est relatif à la conception _(maquettes, arborescence etc.)_ et à la création de l'interface.
|
||||
Cette activité type concerne tout ce qui est relatif à la conception _(diagrammes, documentation etc.)_ et au développement de la logique métier côté serveur.
|
||||
|
||||
Voyons un peu plus en détail ce qui est attendu pour chacune de ces compétences professionnelles ! 🚀
|
||||
|
||||
Elle est divisée en 4 **compétences professionnelles** _(CP)_ :
|
||||
|
||||
- **CP 1** : Installer et configurer son environnement de travail en fonction du projet web ou web mobile
|
||||
- **CP 2** : Maquetter des interfaces utilisateur web ou web mobile
|
||||
- **CP 3** : Réaliser des interfaces utilisateur statiques web ou web mobile
|
||||
- **CP 4** : Développer la partie dynamique des interfaces utilisateur web ou web mobile
|
||||
- **CP 5** : Mettre en place une base de données relationnelle
|
||||
- **CP 6** : Développer des composants d'accès aux données SQL et NoSQL
|
||||
- **CP 7** : Développer des composants métier coté serveur
|
||||
- **CP 8** : Documenter le déploiement d'une application dynamique web ou web mobile
|
||||
|
||||
13
app/data/snippets/bash/pg_cron_file.sh
Normal file
13
app/data/snippets/bash/pg_cron_file.sh
Normal file
@ -0,0 +1,13 @@
|
||||
#!/bin/bash
|
||||
|
||||
# Variables
|
||||
DB_USER="user"
|
||||
DB_NAME="database"
|
||||
BACKUP_DIR="/path/to/backup"
|
||||
DATE=$(date +"%Y%m%d%H%M%S")
|
||||
|
||||
# Création du répertoire de sauvegarde
|
||||
mkdir -p $BACKUP_DIR
|
||||
|
||||
# Sauvegarde de la base de données
|
||||
pg_dump -U $DB_USER $DB_NAME > $BACKUP_DIR/$DB_NAME-$DATE.sql
|
||||
5
app/data/snippets/bash/pg_cron_register.sh
Normal file
5
app/data/snippets/bash/pg_cron_register.sh
Normal file
@ -0,0 +1,5 @@
|
||||
# Ouvrir le fichier de tâches cron
|
||||
crontab -e
|
||||
|
||||
# Ajouter la tâche de sauvegarde, toutes les nuits à minuit
|
||||
0 * * * * /path/to/backup.sh
|
||||
@ -7,6 +7,7 @@ import { Callout } from "@syntax/Callout";
|
||||
import React from "react";
|
||||
import { Snippet } from "@/components/syntax/Snippet";
|
||||
import { Iframe } from "@/components/common/Iframe";
|
||||
import { Mermaid } from "@/components/common/Mermaid";
|
||||
// import path from "path";
|
||||
|
||||
// const __dirname = path.resolve();
|
||||
@ -90,6 +91,23 @@ const tags = {
|
||||
},
|
||||
},
|
||||
},
|
||||
mermaid: {
|
||||
render: Mermaid,
|
||||
attributes: {
|
||||
path: { type: String },
|
||||
},
|
||||
},
|
||||
img: {
|
||||
render: ({ src, alt = "", className = "" }: { src: string; alt: string; className: string }) => (
|
||||
<img src={src} alt={alt} className={className} loading="lazy" />
|
||||
),
|
||||
attributes: {
|
||||
src: { type: String },
|
||||
alt: { type: String },
|
||||
className: { type: String },
|
||||
},
|
||||
selfClosing: true,
|
||||
},
|
||||
iframe: {
|
||||
render: Iframe,
|
||||
attributes: {
|
||||
|
||||
@ -31,6 +31,7 @@
|
||||
"react": "^19.0.0",
|
||||
"react-dom": "^19.0.0",
|
||||
"react-highlight-words": "^0.21.0",
|
||||
"react-mermaid2": "^0.1.4",
|
||||
"react-toastify": "^11.0.5",
|
||||
"reading-time-estimator": "^1.12.0",
|
||||
"simple-functional-loader": "^1.2.1",
|
||||
|
||||
12490
app/pnpm-lock.yaml
generated
12490
app/pnpm-lock.yaml
generated
File diff suppressed because it is too large
Load Diff
BIN
app/public/patterns/mvc.webp
Normal file
BIN
app/public/patterns/mvc.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
@ -152,7 +152,6 @@ class DocsService {
|
||||
public async getDoc(namespace: "docs" | "certifications", key: string) {
|
||||
try {
|
||||
await this.fetchDocs();
|
||||
console.log(this.cache.keys());
|
||||
const doc = this.getFromCache(`/${namespace}/${key}`);
|
||||
|
||||
if (!doc) {
|
||||
|
||||
Loading…
Reference in New Issue
Block a user